← На главную

В практике обслуживания 1С нередко возникает ситуация, когда боевой сервер предприятия обладает слабой производительностью или сильно перегружен текущими задачами. Регламентное ночное окно ограничено, а установка масштабного релиза конфигурации с последующим выполнением обработчиков обновления занимает десятки часов. В таких условиях логичным решением выглядит временный перенос информационной базы на мощный локальный компьютер или выделенный производительный сервер для проведения всех этапов обновления с последующим возвратом данных. Разберем по шагам, как правильно организовать этот процесс, какие опасности таит перенос через файл выгрузки .dt, что произойдет с журналом регистрации и почему процедуры послеобновления могут выполняться медленно.

Вариант 1. Использование механизма выгрузки и загрузки базы через DT

Выгрузка информационной базы в файл .dt через меню Конфигуратора Администрирование > Выгрузить информационную базу является самым доступным способом для разработчика, не требующим прямого доступа к консоли управления СУБД. Однако этот способ имеет ряд важных технических особенностей, которые необходимо учитывать:

1. Ограничения по объему: формат .dt не предназначен для регулярного резервного копирования баз средних и крупных объемов. Если база данных занимает более нескольких десятков гигабайт, в процессе формирования или загрузки .dt может произойти аварийное завершение процесса из-за исчерпания оперативной памяти.
2. Внешние тома для хранения файлов: если в конфигурации включено хранение присоединенных файлов в томах на диске, сами файлы не включаются в состав выгрузки .dt. Их необходимо переносить отдельно на уровне файловой системы.
3. Сброс индексов и статистики: при загрузке .dt на целевой сервер СУБД все таблицы и индексы создаются заново. После загрузки обновленной базы на боевой сервер база не содержит актуальной статистики распределения данных. Обязательно выполните регламентные процедуры СУБД — обновление статистики и реиндексацию, иначе запросы пользователей после запуска начнут существенно зависеть от неоптимальных планов выполнения.

Вариант 2. Перенос через резервную копию СУБД (предпочтительный способ)

Проанализируем более надежный и профессиональный метод — перенос базы средствами СУБД (например, создание резервной копии .bak в Microsoft SQL Server или дампа в PostgreSQL). Этот способ полностью сохраняет структуру данных, исключает ошибки конвертации платформы и отрабатывает в разы быстрее, чем упаковка данных в архив .dt.

Главный подводный камень при работе с бэкапами СУБД — совместимость версий. Рассмотрим правила переноса на примере MS SQL Server:

1. Резервную копию, созданную на более старой версии СУБД (например, SQL Server 2016), можно без проблем восстановить на более новой версии (например, SQL Server 2019 или 2022).
2. Обратная совместимость не поддерживается: бэкап, созданный на более новой версии SQL Server, невозможно восстановить на старом сервере. Поэтому версия СУБД на временном быстром компьютере должна быть в точности такой же или более старой, чем на боевом сервере.

Вариант 3. Подключение быстрого сервера 1С напрямую к рабочей СУБД

Если узким местом является не дисковая подсистема сервера баз данных, а слабый процессор и нехватка памяти для рабочих процессов rphost, существует альтернативный способ. Разберем его суть:

1. На быстром компьютере устанавливается и запускается служба сервера 1С:Предприятия той же версии платформы, что и на боевом сервере.
2. В локальной консоли администрирования регистрируется информационная база, которая указывает на существующую базу данных на рабочем SQL-сервере.
3. На время проведения обновления на основном слабом сервере отключаются регламентные задания и блокируется работа пользователей, а все ресурсоемкие операции реструктуризации и выполнения кода запускаются через локальный мощный сервер 1С.

Поведение журнала регистрации при переносе базы

Выясним причину частых вопросов о сохранности истории событий. Журнал регистрации 1С хранится отдельно от таблиц СУБД — в файловой структуре каталога кластера серверов (в папке srvinfo). На современных версиях платформы он по умолчанию ведется в формате SQLite (файл 1Cv8.lgd).

Рассмотрим, как ведет себя журнал регистрации при различных манипуляциях:

1. Файл .dt не содержит в себе журнал регистрации. Ни старый текстовый формат (.lgf), ни новый SQLite-формат (.lgd) не выгружаются в архив.
2. При разворачивании базы на временном компьютере создается новый, абсолютно чистый журнал регистрации. Все события, происходящие во время обновления (включая ошибки отложенных обработчиков), будут записаны в этот локальный журнал.
3. При обратной загрузке .dt в существующую базу на боевом сервере привязка к старому файлу журнала обычно сохраняется, так как идентификатор базы в кластере не меняется. Однако существует риск повреждения или перезаписи файла журнала. Перед загрузкой обязательно сохраните копию файла 1Cv8.lgd из каталога соответствующей базы в srvinfo.
4. Если необходимо перенести записи журнала, созданные в процессе обновления на временном компьютере, можно воспользоваться выгрузкой журнала регистрации в файл через меню Конфигуратора или режим предприятия и последующим объединением.

Почему процедуры послеобновления данных выполняются долго при низкой нагрузке CPU

При выполнении дополнительных процедур обработки данных (механизмы БСП / отложенное обновление) часто наблюдается парадоксальная картина: процессор загружен слабо, диск не испытывает пикового потока чтения/записи, но сам процесс длится часами. Проанализируем причины такого поведения:

1. Фоновый режим с паузами: по умолчанию отложенные обработчики БСП спроектированы так, чтобы не мешать работе пользователей. Обработка выполняется порциями в один фоновый поток, делая паузы (задержки) между итерациями выборок данных.
2. Характер нагрузки: обновление данных производит огромное количество мелких транзакций и проверок логической целостности. Производительность в этом случае упирается не в пропускную способность диска (МБ/с), а в дисковую латентность и количество операций ввода-вывода (IOPS).
3. Как ускорить процесс: откройте форму Результаты обновления программы (раздел Администрирование > Обслуживание > Результаты обновления программы) и включите приоритетный режим выполнения обновления. Это снимет искусственные паузы и задействует максимально допустимое количество параллельных фоновых заданий для распределения нагрузки по ядрам процессора.

Рекомендуемый пошаговый алгоритм безопасного обновления

1. Завершите сеансы всех пользователей на боевой базе и установите блокировку начала сеансов и регламентных заданий.
2. Сделайте полную резервную копию базы средствами СУБД (или через .dt, предварительно убедившись в наличии свободного места и скопировав каталог 1Cv8.lgd).
3. Разверните копию на производительном компьютере и выполните сравнение/объединение конфигураций или накат файла обновления .cfu/.cf.
4. Примените изменения конфигурации базы данных (F7) и запустите 1С:Предприятие в режиме отладки/обновления.
5. Дождитесь завершения всех отложенных процедур обновления в приоритетном режиме через форму контроля обновления БСП.
6. Выгрузите обновленную базу и верните ее на рабочий сервер выбранным способом.
7. Выполните регламентные процедуры СУБД (обновление статистик, реиндексация), снимите блокировку регламентных заданий и откройте доступ пользователям.