При обновлении крупных или сильно устаревших информационных баз (например, при переходе с редакции 11.3 на 11.4 в «1С:Управление торговлей») администраторы часто сталкиваются с необходимостью выполнять обновление в несколько последовательных шагов. Этот процесс состоит из двух фаз: обновление структуры метаданных в конфигураторе и последующий запуск базы в режиме «1С:Предприятие» для выполнения обработчиков обновления (обработки данных).
Вторая фаза зачастую занимает в разы больше времени, чем первая. В связи с этим возникает соблазн: можно ли последовательно применить все промежуточные файлы обновлений в Конфигураторе, а режим «1С:Предприятие» запустить лишь один раз в самом конце?
В этой статье мы подробно разберем, почему делать так категорически нельзя, к каким критическим последствиям это приведет на уровне СУБД и какими штатными и сторонними инструментами можно реально ускорить этот рутинный процесс.
Рассмотрим детально, что происходит с базой данных на каждом этапе. Когда разработчики выпускают новые релизы, структура хранения данных претерпевает изменения. Для наглядности проанализируем классический трехэтапный сценарий эволюции метаданных:
Справочник1, в котором активно ведутся и накапливаются данные.Справочник1 и спроектировали более оптимизированный Справочник2. На этом этапе в конфигурацию добавляется специальный обработчик обновления Библиотеки стандартных подсистем (БСП). Его задача — при первом запуске «1С:Предприятия» перенести (мигрировать) всю информацию из старой структуры в новую. При этом Справочник1 еще физически присутствует в метаданных, но помечен как «неиспользуемый».Справочник1 полностью удаляется разработчиками из метаданных за ненадобностью.Теперь представим, что мы решили сэкономить время и обновили конфигурацию в конфигураторе сразу с Версии 1 до Версии 3, минуя запуск предприятия на Версии 2.
Во время принятия изменений в конфигураторе платформа выполнит реструктуризацию СУБД. Поскольку в Версии 3 объекта Справочник1 больше нет, соответствующая таблица в SQL-базе будет физически удалена вместе со всеми вашими данными. После этого мы наконец запускаем режим «1С:Предприятие». Система обнаруживает, что необходимо выполнить отложенные обработчики для перехода с первой версии на третью. Запускается обработчик из Версии 2, который пытается прочитать данные из таблицы Справочник1... и процесс завершается аварийной ошибкой, так как этой таблицы физически больше не существует в базе данных!
Даже если бы обработчик содержал защитный код (проверку на существование метаданных) и не упал с ошибкой, результат был бы плачевным: данные из первого справочника просто не перенеслись бы во второй и были бы безвозвратно утеряны.
Более того, при запуске «1С:Предприятия» в самом конце система все равно будет обязана выполнить абсолютно все отложенные обработчики для всех промежуточных версий. Выигрыш по времени окажется минимальным, а риски получить скрытые логические ошибки в учете — колоссальными.
Вердикт: запускать режим «1С:Предприятие» и дожидаться окончания работы критически важных обработчиков обновления на каждом шаге обновления строго обязательно!
Однако существуют эффективные инженерные методы, позволяющие ускорить фазу выполнения обработчиков обновления в разы.
По умолчанию отложенное обновление БСП выполняется в фоновом режиме, чтобы пользователи могли сразу начать работу. Но если мы выполняем техническое обновление на копии или в технологическое окно, нам не нужно обеспечивать доступ пользователей. Мы можем заставить систему бросить все ресурсы на выполнение обработчиков.
Для этого мы можем запустить информационную базу со специальным ключом командной строки ВыполнитьОтложенноеОбновлениеСейчас. Давайте посмотрим, как выглядит пример такой команды запуска:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\Bases\Trade_Copy" /N "Администратор" /P "Пароль" /C "ВыполнитьОтложенноеОбновлениеСейчас"
Что происходит при таком запуске?
Мало кто знает, что современные версии Библиотеки стандартных подсистем поддерживают параллельное (многопоточное) выполнение тяжелых обработчиков данных. На многопроцессорных серверах это способно сократить время обновления в разы.
Мы можем явно указать платформе, в какое количество потоков следует производить обновление. Для этого используется еще один параметр запуска ЧислоПотоковОбновления:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\Bases\Trade_Copy" /N "Администратор" /P "Пароль" /C "ЧислоПотоковОбновления;16"
В данном примере мы жестко задали выполнение в 16 потоков. Рекомендуется выбирать это число исходя из количества свободных ядер процессора на сервере приложений 1С и сервера СУБД. Если в процессе работы в журнале регистрации вы начнете замечать частые ошибки взаимных блокировок (Deadlocks) СУБД, это число следует уменьшить (например, до 8 или 4).
Также настроить этот параметр можно программно. Для этого в режиме «1С:Предприятие» можно изменить значение константы КоличествоПотоковОбновленияИнформационнойБазы.
Если мы не используем запуск через конфигурационную строку, мы можем ускорить процесс непосредственно из интерфейса программы. Выполним следующие шаги:
ДефрагментацияИндексов и другие фоновые процессы, не связанные напрямую с обновлением, и временно отключаем их, чтобы высвободить ресурсы сервера.Поскольку обработчики обновлений производят миллионы операций записи (инструкции INSERT и UPDATE), производительность дисковой подсистемы и настройки СУБД становятся бутылочным горлышком. Перед началом выполнения цепочки обновлений обязательно проведем техническую подготовку СУБД:
FULL (Полная) в режим SIMPLE (Простая). Это отключит бесконечный рост транзакционного лога (файла .ldf) и значительно снизит нагрузку на диски. После завершения всех этапов обновления верните модель FULL и сразу сделайте полную резервную копию.
EXEC sp_updatestats;
Начиная с версии платформы 8.3.11, разработчики «1С» добавили механизм оптимизированной реструктуризации баз данных. В обычном режиме платформа копирует данные таблиц во временные структуры средствами самой платформы. Оптимизированный же режим перекладывает эту задачу на плечи СУБД, выполняя in-place изменения.
Чтобы включить этот режим, необходимо открыть файл конфигурации платформы conf.cfg (обычно он находится в каталоге C:\Program Files\1cv8\conf) и прописать следующие параметры:
UpdateMode=Background
DbmsRedefinition=True
Это позволит сократить время выполнения реструктуризации таблиц в Конфигураторе (при нажатии клавиши F7) в несколько раз, особенно на терабайтных базах данных.
Чтобы не сидеть часами у монитора, контролируя каждый шаг («Обновил в Конфигураторе -> Запустил Предприятие -> Подождал -> Повторил сначала»), настоятельно рекомендуется использовать специализированные инструменты автоматизации.
Программа «Обновлятор-1С» является признанным стандартом для выполнения подобных задач. Вы можете настроить в ней пакетный режим работы. Программа самостоятельно:
Использование автоматизации полностью исключает человеческий фактор, когда администратор по невнимательности может пропустить критически важный промежуточный запуск или начать накатывать следующий релиз поверх еще не завершившихся фоновых процессов обработки данных.