[recovery mode] Разделяй и обновляй! Экономим место, время и ресурсы сервера 1С
В прошлый раз мы рассказали, как изменялись наша инфраструктура и принципы работы с базами 1С, коих у нас бесчисленное множество уже полтысячи, и про то, как мы автоматизируем работу с таким количеством данных. Однако, трудности и костыли всё ещё есть, и с ростом числа клиентов Кнопки нам приходится придумывать новые и улучшать старые способы оптимизации. Одна из основных проблем при работе с большим количеством баз 1С — накатывание обновлений. Сегодня мы расскажем о технологии разделения данных, которая позволяет уменьшить количество баз и упростить их обслуживание.
Найти документацию по механизму разделения баз достаточно трудно: есть небольшая статья на основополагающем сайте, но нам она принесла мало пользы. Есть старый добрый Гугл, но чтобы разобраться в тонкостях, придётся долгими часами бороздить выдачу в поисках нужного куска информации. У нас другого выбора не было, а у вас теперь есть эта статья. Надеемся, она пригодится.
Хватит это терпеть! При работе с 1С, обновлять приходится многое: конфигурацию, КЛАДР, списки банков (лишают их лицензий, знаете ли), курсы валют (ох уж эти экономически нестабильные евро и доллары), списки пользователей, обработки, версию платформы. На хорошем железе обновление КЛАДРа со всеми регионами для одной базы занимает около получаса. Обновление конфигурации занимает от 10 минут до нескольких часов (при накатывании пачкой).Когда база одна, две, десять, всё это можно сделать в виде ежедневной рутинной работы. Когда несколько десятков — на это уходит очень много времени, но справиться можно. Когда баз сотни, а на дворе сибирское лето последний день отчётности, может случится так, что обновить все базы просто физически невозможно — не хватит времени и серверных ресурсов.
Не стоит забывать и о том, что в каждой отдельной базе живёт её величество Конфигурация, которая не отличается от базы к базе ни на байт. Живёт и ест место, при том, что в конфигурацию так же нужно загружать изменения, вставлять обработки и расширять стандартную функциональность.
Итак, если у вас есть несколько ничем (кроме организаций) не отличающихся баз, с одинаковой конфигурацией, механизм разделения может существенно облегчить жизнь (не без дёгтя, но об этом позже). Иначе очень скоро придётся нанимать армию админов:)
Базовая сегрегация Для начала, нужно определить признак, по которому вы будете разделять базу. Разделитель может иметь любой тип данных, мы используем строку длинной 10 символов: ИНН организации. Главное — название разделителя (общего реквизита) не должно совпадать с уже существующими объектами конфигурации, то есть его нельзя назвать, например, «Организации», так как уже есть такой справочник. Мы назвали разделитель «Группа компаний».После этого берём вашу типовую конфигурацию с пустой базой, заходим в конфигуратор и открываем раздел «Общие реквизиты». Добавляем общий реквизит и меняем значение «Разделение данных» на «Разделять»:
Конфигуратор предложит создать параметры сеанса — безмолвно соглашаемся и идём дальше. После создания «Общего реквизита» с включённым свойством разделения, база данных становится похожа на многоэтажный дом. В доме есть элементы доступные всем и с каждого этажа: лифт, лестничный пролёт, коммуникации, а есть что-то уникальное, доступное только в пределах этажа: квартиры, коридор, окна. Метафора простая, и, надеюсь, понятная:)
Для входа в определённую организацию (или область базы) необходимо сообщить разделитель в строке подключения к базе или указать его в v8i файле (о которых мы рассказывали в прошлый раз).
[Кнопка 7710967300 БУХ РБ]
Connect=Srvr=»%servername%»; Ref=»%base_name%»;
AdditionalParameters=/Z »-0,-0,+7710967300»
После /Z указываем общие реквизиты по порядку. Так как в нашей типовой бухгалтерии уже есть два общих системных реквизита, указываем для них значение -0 чтобы они не использовались, а в качестве третьего (который мы создали) передаём ИНН.
1000 и 1 чекбокс
Теперь нужно определить, какая часть данных будет являться общей для всех областей. Всё это настраивается через конфигуратор. В свойствах общего реквизита, который мы только что создали, есть пункт «Состав» открывающий небольшой список из 800 параметров: 
Подбор параметров оставляем на ваше благоразумие, усмотрение и окружение. Вот наш вариант (аккуратнее, там 20 000 пикселей).
Разделитель также даёт возможность настроить отдельный список пользователей для каждой базы — это может пригодиться, если у вас сотни пользователей — при входе в определённую базу не придётся проматывать этот список до кровавых мозолей. Мы это не используем, потому что настроили прозрачную авторизацию.
Выгружаем данные из текущих баз
Для выгрузки данных из текущих баз, мы используем универсальный XML-обмен. Нельзя просто так взять и выгрузить базу, нужно настроить правила обмена, иначе при загрузке могут (и обязательно возникнут) ошибки и конфликты, а вторая база просто не пролезет. Напомним, что мы делим области базы для каждой организации и в нашем случае работают такие правила обмена. Если вам вздумается использовать другой разделитель, придётся пораскинуть мозгами и чекбоксами. Главное — не использовать типовую выгрузку — это приведёт к дублированию всех предопределённых записей.
Хозяйке на заметку: справочники и документы лучше выгружать отдельно — так можно избежать лишних ошибок в момент загрузки.
Загружаем данные в разделённую базу
Запускаем 1С с параметром /Z »-0,-0,+%ваш разделитель%», указывая разделитель той организации, данные которой собираемся загрузить. Запускаем универсальный обмен и скармливаем ему полученные при выгрузке файлы: сперва справочники, потом документы. Повторяем эту операцию для каждой базы-области.
Чтобы упростить задачу, мы осуществляем выгрузки массово, предварительно запуская чуть исправленную стандартную обработку через командную строку (/Execute c:\выгрузка.epf). Затем вручную загружаем полученные файлы в разделённую базу.
Как потратить больше времени, чтобы потратить меньше времени Процесс разделения — штука не быстрая. Напомним, что у нас сейчас больше 500 организаций, но за пару недель мы успели разделить только 70. Однако, мы точно знаем, что уже через полгода поблагодарим прошлых себя за проделанную работу и кучу сэкономленных времени и сил.Бухгалтеры Кнопки не замечают перехода организаций из обычной базы в разделённую, для них процесс проходит безболезненно. Попа горит только у админов:)
Побочные эффекты: экономия места 1 к 20, косвенное увеличение скорости работы — неоценимо. В абсолютных цифрах: 50 организаций занимают 2 Гб пространства в SQL, тогда как одна отдельная база занимает от 800 Мб. Формально, можно экономить на лицензиях, так как каждый бухгалтер будет запускать несколько копий одной базы, а не десяток разных.
Обещанная ложка дёгтя, даже четыре: если кто-то из пользователей запорол данные в одной организации, приходится откатывать назад всю разделённую базу — нельзя просто взять и откатить одну область данных приходится более тщательно тестировать обновления, особенно те, которые добавляют или изменяют справочники если нужно передать базу клиенту (или слить налоговой:), приходится делать обратную процедуру: выгружать организацию из разделённой базы при помощи универсального обмена, затем загружать в пустую обычную базу и из неё сохранять в.dt-файл в разделённой базе нельзя управлять регламентными заданиями (например, не получится автоматически обновить курсы валют) Первые три ложки не такие горькие — они просто заставляют нас быть более внимательными. А вот что делать с четвёртой мы пока не знаем, но усердно исследуем.
