Как ускорить реструктуризацию базы 1С

Реструктуризация в 1С — это процесс приведения физической структуры базы данных в соответствие с изменённой конфигурацией: добавление реквизитов, изменение типов полей, создание новых таблиц и индексов. На больших базах процесс может занимать часы и даже сутки, блокируя работу пользователей. Основные причины медленной реструктуризации — большой объём таблиц, фрагментированные индексы, нехватка ресурсов сервера и лишние изменения, накопленные в одном обновлении.

Ускорить процесс можно двумя путями: уменьшить объём работы, которую выполняет реструктуризация, и убрать внешние тормозящие факторы — медленные диски, конкуренцию за ресурсы СУБД, неоптимальные настройки. В большинстве случаев заметный эффект даёт комбинация обоих подходов, а не какой-то один приём.

Почему реструктуризация занимает много времени

При реструктуризации 1С не просто меняет описание таблицы — для многих операций платформа создаёт новую таблицу, копирует в неё все данные, перестраивает индексы и только потом удаляет старую структуру. Если таблица содержит сотни миллионов записей, полное копирование становится самой долгой частью процесса.

Особенно тяжёлые случаи — изменение типа существующего реквизита, добавление измерения в большой регистр, изменение состава индексов на крупных таблицах. Простое добавление нового реквизита без значения по умолчанию обычно проходит быстро, а вот заполнение нового поля вычисляемым значением для всех записей — это уже полный проход по таблице.

Дополнительное время уходит на проверку логической целостности и реструктуризацию связанных объектов: изменение одного справочника может затронуть десятки таблиц, где он используется как тип. Поэтому оценивать длительность нужно не по числу изменённых объектов в конфигураторе, а по реальному объёму затронутых данных.

Подготовьте базу перед обновлением

Главный резерв скорости закладывается до запуска обновления. Начните с регламентных операций СУБД: перестройте индексы на самых больших таблицах и обновите статистику. На фрагментированных индексах полное сканирование и копирование таблиц выполняются заметно медленнее, а устаревшая статистика заставляет СУБД выбирать неэффективные планы запросов.

Проверьте свободное место на дисках. Реструктуризации требуется место под копию изменяемых таблиц, а серверу СУБД — под рост журнала транзакций. Ориентир — запас не меньше размера самых крупных затрагиваемых таблиц, а для баз с массовыми изменениями лучше иметь существенный запас. Нехватка места в середине процесса — один из самых неприятных сценариев: откат тоже занимает время.

Если в базе есть исторические данные, которые можно свернуть или выгрузить в архив, сделайте это заранее. Уменьшение объёма таблиц напрямую сокращает время копирования при реструктуризации. Свертка базы или вынос старых периодов в отдельную базу — трудоёмкая, но самая действенная мера для разросшихся систем.

Используйте выгрузку и загрузку для файловых баз

Для файловых баз существует неочевидный, но эффективный приём: выгрузка базы в файл .dt и загрузка обратно. При загрузке платформа создаёт все таблицы заново с нуля, и последующая реструктуризация уже работает с компактной, дефрагментированной структурой. На сильно фрагментированных базах это может сократить время обновления в разы.

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

Для клиент-серверных баз прямой аналог не работает, но там доступны штатные средства СУБД: перестроение кластерных индексов, сжатие таблиц и перенос базы на более быстрые диски дают схожий эффект.

1. 1
   Сделайте и проверьте резервную копию базы
2. 2
   Завершите все сеансы пользователей и фоновые задания
3. 3
   Перестройте индексы и обновите статистику на крупных таблицах
4. 4
   Проверьте запас свободного места на дисках данных и журналов
5. 5
   Для файловой базы при масштабном обновлении — выполните цикл выгрузки/загрузки dt
6. 6
   Запустите обновление конфигурации в монопольном режиме
7. 7
   После завершения проверьте целостность данных и работу ключевых операций

Разбейте большое обновление на этапы

Если база пропустила несколько релизов, не всегда выгодно накатывать всё сразу. Обновление через промежуточные версии иногда быстрее суммарно, потому что каждая реструктуризация затрагивает меньше объектов и работает на меньшем объёме накопленных изменений. Это также упрощает поиск проблемы, если на каком-то этапе что-то пойдёт не так.

Для собственных доработок действует то же правило: не смешивайте в одном обновлении добавление новых объектов и тяжёлые изменения существующих больших таблиц. Сначала выпустите релиз с добавлениями (они реструктуризируются быстро), затем отдельным этапом — изменения типов и индексов на крупных регистрах.

Отдельный приём — отложенные обработчики обновления. Перенесите заполнение новых реквизитов и пересчёт данных в отложенные обработчики, которые выполняются после основного обновления, когда пользователи уже могут работать. Сама реструктуризация при этом завершится быстрее, а массовое заполнение данных пойдёт фоном.

Оптимизируйте серверную часть

Реструктуризация — это прежде всего нагрузка на дисковую подсистему и СУБД. Если база лежит на медленных дисках, никакие настройки конфигурации не дадут радикального ускорения. Размещение файлов данных и журналов транзакций на быстрых SSD, а лучше — разнесение их на разные физические устройства, даёт самый ощутимый прирост.

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

На время реструктуризации имеет смысл временно увеличить ресурсы, если инфраструктура это позволяет: добавить память виртуальной машине, отключить параллельные нагрузки, настроить модель восстановления базы в соответствии с политикой резервирования. После завершения обновления настройки возвращают к штатным.

Сравнение подходов

Подготовка базы (индексы, статистика, место)

Подходит всегда, дёшево по времени. Ограничение: не поможет при слабых дисках и огромном объёме данных

Выгрузка/загрузка dt

Эффективна для файловых баз с большой фрагментацией. Не применима напрямую к клиент-серверному варианту

Разбиение обновления на этапы

Хорошо при пропущенных релизах и собственных доработках. Требует дополнительного тестирования каждого этапа

Усиление оборудования

Даёт радикальный эффект при упоре в диски и память. Требует затрат и остановки сервиса

Типичные ошибки при реструктуризации

Самая распространённая ошибка — запуск обновления в рабочее время «на живую» с надеждой, что успеет. Даже если пользователей отключить в момент старта, незавершённые фоновые задания и висящие сеансы могут держать блокировки и растягивать процесс. Обновление планируйте на технологическое окно с запасом времени.

Вторая ошибка — отсутствие проверенной резервной копии. Копия, которую никто не пытался восстановить, не считается копией. Перед масштабной реструктуризацией поднимите копию на тестовом сервере и прогоните обновление там: заодно получите реальную оценку длительности.

Третья группа ошибок — попытки ускорить процесс опасными способами: принудительное завершение процесса СУБД, перезагрузка сервера «чтобы освободить память», ручное вмешательство в таблицы базы в обход платформы. Такие действия почти гарантированно приводят к повреждению данных и долгому восстановлению.

Как проверить результат после обновления

Завершение реструктуризации без ошибок в журнале — необходимое, но недостаточное условие. После обновления запустите тестирование и исправление базы в режиме проверки логической целостности, либо штатные средства проверки СУБД. Убедитесь, что количество записей в ключевых таблицах соответствует ожиданиям.

Затем проверьте прикладную сторону: откройте основные отчёты, проведите тестовые документы, выполните типовые операции пользователей. Особое внимание — объектам, чья структура менялась: новые реквизиты должны быть доступны, отложенные обработчики обновления — запущены и завершены без ошибок.

Мониторьте систему первые часы работы: медленные запросы после реструктуризации часто указывают на необходимость повторно обновить статистику — планы запросов могли устареть после массового перемещения данных.

Контрольные точки

Как проверить результат

Журнал обновления конфигурации

Норма

Нет ошибок реструктуризации, отложенные обработчики завершены

Тревожный признак

Ошибки применения изменений или зависшие обработчики

Количество записей в изменённых таблицах

Норма

Совпадает с данными до обновления

Тревожный признак

Расхождения в числе записей

Скорость типовых операций

Норма

Отчёты и проведение работают как раньше или быстрее

Тревожный признак

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

Свободное место и состояние журналов СУБД

Норма

Запас места сохраняется, журналы в штатном состоянии

Тревожный признак

Раздутый журнал транзакций, критически мало места

Частые вопросы

Можно ли прервать реструктуризацию, если она идёт слишком долго?

Штатной безопасной отмены в середине процесса нет. Принудительное завершение процесса или перезагрузка сервера почти всегда оставляют базу в несогласованном состоянии, после чего потребуется восстановление из копии или длительный откат транзакций СУБД. Правильная стратегия — тестовый прогон на копии заранее, чтобы знать реальную длительность, и достаточное технологическое окно.

Помогает ли тестирование и исправление ускорить реструктуризацию?

Напрямую — нет, но косвенно да: в процессе тестирования с включённым реиндексацией перестраиваются индексы, что ускоряет последующие массовые операции. Однако само тестирование на большой базе тоже занимает много времени, поэтому для клиент-серверных баз эффективнее выполнять обслуживание индексов штатными средствами СУБД.

Почему добавление одного реквизита реструктуризируется часами?

Если реквизит добавляется в объект, тип которого используется во множестве таблиц (например, в составной тип или в объект с большим числом связанных регистров), платформа изменяет все затронутые таблицы. Дополнительно замедляет процесс заполнение нового реквизита значением по умолчанию — это полный проход по всем записям. Проверьте список изменяемых таблиц в окне реструктуризации: там видно реальный масштаб работ.

Ускорит ли процесс перевод файловой базы в клиент-серверную?

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

Что делать, если реструктуризация зависла без видимого прогресса?

Сначала проверьте, действительно ли процесс работает: активность дисков, загрузку процессора СУБД, наличие активных запросов и блокировок через монитор активности СУБД. Часто процесс не завис, а выполняет тяжёлое копирование таблицы. Если активности нет и есть долгие блокировки — найдите и завершите блокирующий сеанс. Завершать сам процесс реструктуризации — крайняя мера.

Как часто нужно обслуживать базу, чтобы обновления проходили быстро?

Регулярность зависит от интенсивности работы: для активно используемых баз перестроение индексов и обновление статистики обычно планируют еженедельно или ежедневно в нерабочие часы, для умеренно нагруженных — реже. Главный ориентир — не допускать состояния, когда база годами работает без обслуживания: именно такие базы реструктуризируются мучительно долго.