Обновление платформы «1С:Предприятие» — это ответственная процедура, которая затрагивает ядро системы и механизмы взаимодействия с базой данных. Среди системных администраторов и разработчиков часто возникает вопрос: достаточно ли просто сделать копию средствами SQL Server или необходимо дополнительно выгружать базу в файл .dt? Рассмотрим этот вопрос подробно, проанализируем риски и определим правильную стратегию подготовки к обновлению.
Разберем фундаментальное различие между средствами СУБД и механизмом выгрузки 1С. Выгрузка в формат .dt — это логическая копия данных. В процессе ее создания платформа последовательно считывает данные из таблиц SQL и упаковывает их во внутренний проприетарный формат. Рассмотрим, к чему это может привести:
.dt может завершиться успешно, но при попытке загрузить этот файл в новую (или ту же самую) базу платформа может выдать критическую ошибку. В такой ситуации вы останетесь с нерабочей базой и бесполезным файлом выгрузки..dt становится крайне ресурсозатратной операцией. Платформа активно использует оперативную память и временные каталоги. Нередки случаи, когда процесс прерывается через несколько часов из-за нехватки памяти..dt требует исключительного захвата базы, что останавливает работу пользователей на длительный срок.В противовес этому, средства SQL Server (формат .bak) делают физический снимок данных. Это гарантирует, что база будет восстановлена ровно в том состоянии, в котором она была на момент создания копии, независимо от внутренних логических ошибок 1С. Поэтому основным правилом при любом обновлении (платформы или конфигурации) является создание полной резервной копии средствами SQL.
Проанализируем ситуацию, когда выполняется переход между конкретными релизами, например, с 8.3.15 на 8.3.16. В подобных обновлениях часто меняются механизмы взаимодействия платформы с СУБД, обновляются компоненты защиты и методы работы с индексами. Основная опасность заключается не в «физическом разрушении» таблиц SQL, а в следующих аспектах:
Для минимизации рисков при смене версии платформы на SQL-сервере, рекомендуем придерживаться следующей последовательности действий:
Прежде чем делать бэкап и обновлять платформу, выясним состояние базы. Рекомендуется запустить процедуру «Тестирование и исправление» в конфигураторе на текущей (старой) версии платформы. Выберем хотя бы пункт «Проверка логической целостности». Если база содержит ошибки, их лучше исправить до миграции на новое ядро.
Выполним полное резервное копирование через SQL Server Management Studio (SSMS). Это обеспечит нам «точку возврата». Посмотрим на пример команды для создания бэкапа через скрипт:
BACKUP DATABASE [Имя_Вашей_Базы]
TO DISK = N'D:\Backups\Before_Update.bak'
WITH FORMAT, INIT, NAME = N'Full Backup before platform update';
Это обязательный ритуал. После установки новой платформы и остановки службы агента сервера 1С:Предприятие, необходимо очистить содержимое папки snacc (она находится в каталоге реестра кластера, обычно это C:\Program Files\1cv8\srvinfo). Также полезно очистить временные файлы профиля пользователя, под которым запускается служба сервера.
Разберем особенности установки. При установке новой версии платформы обновляется агент сервера 1С. Важно учитывать:
comcntr.dll. Это делается командой:
regsvr32 "C:\Program Files\1cv8\8.3.16.XXXX\bin\comcntr.dll"
Без этого внешние интеграции и некоторые обработки могут перестать работать.
При первом запуске базы на новой платформе может произойти массовый пересчет итогов или реиндексация. Проанализируем состояние SQL-сервера в этот момент: возможен резкий рост базы TempDB. Убедитесь, что на диске с временной базой SQL достаточно свободного места.
После успешного запуска важно помнить, что сама база данных продолжает работать в режиме совместимости со старой версией. Чтобы задействовать все оптимизации новой платформы, этот режим нужно изменить в свойствах конфигурации. Внимание: это действие требует отдельного тестирования, так как изменение режима совместимости может поменять поведение запросов и некоторых функций языка 1С.
Подведем итоги нашего анализа. Использование .dt перед обновлением платформы на SQL-сервере не является обязательным и не может служить единственным средством страховки. Правильная стратегия:
.bak средствами SQL..dt может быть сделана только как «дополнительная мера» для очень маленьких баз, но она никогда не заменит полноценный бэкап СУБД.Таким образом, если вам «сказали, что базы могут полететь», это правда лишь в том смысле, что ошибки кэша или индексов могут помешать запуску. Но имея под рукой актуальный SQL-бэкап, вы всегда сможете вернуть систему в рабочее состояние за считанные минуты.