Обновление серверных баз 1С:Предприятие 8.3, особенно когда речь идет о типовых конфигурациях вроде «Бухгалтерия предприятия» или «Зарплата и управление персоналом», является критически важной операцией. Часто администраторы сталкиваются с дилеммой: тратить ли время на последовательное обновление каждого релиза с промежуточными запусками или можно «перепрыгнуть» сразу через несколько версий. В этой статье мы разберем оптимальные стратегии, проанализируем технические риски и выясним, почему привычные методы могут быть опасны.
Перед началом любых работ мы обязательно создаем резервную копию. Рассмотрим, почему опытные специалисты предостерегают от использования формата .DT в качестве основного бэкапа для серверных баз. Выгрузка в .DT — это логический слепок данных, а не физическая копия всей базы. Проанализируем основные риски:
.DT не хранит индексы и статистику, он пересоздает их заново при загрузке. На больших базах процесс восстановления может затянуться на сутки..DT даже в файловом варианте без доступа к сайту 1С.Разберем правильный подход: для серверных баз всегда используем Full Backup средствами SQL Server (или PostgreSQL). Это гарантирует физическую целостность данных и минимальное время восстановления. Выгрузку в .DT оставим только для задач переноса базы между разными СУБД.
Рассмотрим ситуацию, когда нам нужно обновить конфигурацию сразу за целый квартал (несколько релизов подряд). Выясним, какой из трех популярных вариантов наиболее безопасен:
Вариант А: Последовательное обновление через Конфигуратор с промежуточными запусками.
Мы накатываем один релиз, обновляем конфигурацию базы данных (клавиша F7), затем запускаем «1С:Предприятие» в монопольном режиме. Ждем завершения всех обработчиков обновления данных и только после этого переходим к следующему релизу. Это самый долгий, но и самый надежный путь.
Вариант Б: Массовое обновление в Конфигураторе без промежуточных запусков.
Мы накатываем файлы обновлений (.CFU или .CF) один за другим, а предприятие запускаем только в самом конце. Рассмотрим опасность этого метода: если в промежуточном релизе была логика переноса данных (например, разделение одного счета на два субсчета), то без запуска обработчика данные могут просто исчезнуть или распределиться некорректно. Последующие релизы уже не найдут данных в нужных полях, и база будет испорчена.
Вариант В: Автоматическое обновление в режиме «1С:Предприятие».
Современные конфигурации позволяют запустить процесс из пользовательского интерфейса. Система сама скачает нужные дистрибутивы и применит их. Проанализируем ситуацию: этот метод хорош для небольших баз, но на серверных решениях он часто завершается ошибками из-за таймаутов или блокировок процессов.
Разберем подробнее, что происходит внутри системы при запуске после обновления. В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) используется механизм отложенного обновления. Процедуры делятся на два типа:
Если мы обновляемся по варианту «Б», список этих процедур суммируется. Однако процедуры последующих релизов часто опираются на результат работы предыдущих. Чтобы избежать конфликтов, мы рекомендуем использовать вариант «А» или автоматизировать его через скрипты.
Посмотрим на ситуацию, когда нужно «перепрыгнуть» через 10–15 релизов. Вместо последовательной накатки множества .CFU, мы можем использовать один файл .CF последнего нужного релиза. Это значительно экономит время на реструктуризации таблиц в Конфигураторе.
Важно: Это не отменяет необходимости выполнения обработчиков! Даже если вы обновили структуру одним файлом, при запуске системы 1С поймет, что пропущено множество версий, и начнет последовательно запускать все обработчики за каждый пропущенный релиз. Выясним причину: это необходимо для обеспечения целостности данных, так как в промежуточных версиях могли удаляться старые реквизиты, данные из которых должны были «перетечь» в новые объекты.
Чтобы не сидеть весь день у монитора, выполняя однотипные действия, рассмотрим возможность автоматизации. Мы можем использовать параметры командной строки 1С. Разберем пример логики скрипта:
/UpdateCfg)./UpdateDBCfg).Для автоматического запуска обработчиков в пользовательском режиме можно использовать параметры:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE
/S "ServerName\BaseName"
/N "Admin" /P "Password"
/C "ВыполнитьОбновлениеИЗавершитьРаботу"
При использовании подсистемы БСП такой запуск инициирует процедуры обновления. Существуют также готовые инструменты, такие как «Обновлятор-1С», которые реализуют этот цикл автоматически.
После завершения всех этапов обновления на сервере, мы рекомендуем выполнить еще два важных действия:
1. Очистка серверного кэша. Иногда старые метаданные «залипают» в памяти сервера, что приводит к ошибкам Объект не найден. Проанализируем ситуацию: лучше всего перезапустить службу 1C:Enterprise Server и удалить содержимое папок snccntx в каталоге серверной базы.
2. Обновление статистик SQL. Поскольку структура таблиц при массовом обновлении сильно меняется, планы запросов могут стать неоптимальными. Выполнение команды UPDATE STATISTICS в SQL Server позволит вернуть системе былую производительность.
Подводя итог нашему анализу, сформулируем золотое правило: никогда не пренебрегайте промежуточными запусками в режиме «Предприятие». Даже если это занимает много времени, это единственный способ гарантировать, что ваши учетные данные (счета, субконто, регистры) корректно трансформировались согласно логике разработчиков 1С. Используйте SQL-бэкапы, проверяйте файл v8upd.htm на наличие ключевых (контрольных) релизов и всегда делайте пробное обновление на копии базы перед работой с «боевым» сервером.