← На главную

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

Подход 1. Свертка на изолированной копии (или подчиненном узле) с последующей синхронизацией

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

1. Установка даты запрета изменения данных. В рабочей базе устанавливаем границу запрета редактирования на планируемую дату свертки (например, 31 декабря исторического года). Это гарантирует, что пользователи не изменят старые документы в процессе выполнения работ.
2. Создание копии и настройка регистрации изменений. Создаем копию базы. В рабочей базе включаем регистрацию изменений на плане обмена (или используем механизм РИБ / низкоуровневую репликацию изменений), чтобы фиксировать все новые документы и справочники, создаваемые пользователями.
3. Выполнение свертки на копии. В изолированной копии выполняем полный цикл свертки: формируем документы ввода остатков, зачищаем исторические движения регистров, удаляем устаревшие документы, выполняем пересчет итогов и тестирование и исправление. На копии эти операции можно выполнять в максимальное число потоков без риска заблокировать пользователей.
4. Подгрузка накопленных данных (дельты). По завершении свертки на копии запускаем регламентный перенос документов и справочников, созданных пользователями в основной базе за время проведения процедуры. Процесс синхронизации выполняется итеративно до минимального отставания.
5. Финальное технологическое окно. В период наименьшей активности (например, технологическое окно на 10–30 минут) блокируем вход пользователей в старую базу, выполняем финальную дозагрузку последних изменений в свернутую базу и перенаправляем пользователей (через перенастройку строк подключения в кластере серверов 1С или смену сетевых псевдонимов СУБД) на обновленную чистую базу.

Подход 2. Пакетная очистка регистров на уровне СУБД и порционный ввод остатков

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

1. Ввод корректировок в неактивном состоянии. Заранее формируем и загружаем документы КорректировкаЗаписейРегистров с отключенной активностью записей (свойство Активность = Ложь у набора записей). Включение активности набора записей выполняется мгновенно, что исключает рассинхронизацию остатков:
   Скопировать код

   
   НаборЗаписей = РегистрыНакопления.ВзаиморасчетыСКонтрагентами.СоздатьНаборЗаписей();
   НаборЗаписей.Отбор.Регистратор.Установить(ДокументКорректировки);
   НаборЗаписей.Прочитать();
   Для Каждого Запись Из НаборЗаписей Цикл
       Запись.Активность = Истина;
   КонецЦикла;
   НаборЗаписей.Записать();
   

2. Удаление движений малыми порциями (Batching). Прямое удаление миллионов записей одним SQL-запросом вызывает эскалацию блокировок (Lock Escalation) со строк на всю таблицу (Table Lock при превышении порога в 5000 записей). Удаление старых записей регистров необходимо производить строго порциями по 1000–3000 строк с паузами между транзакциями (WAITFOR DELAY на уровне SQL), чтобы СУБД успевала отпускать разделяемые блокировки.
3. Контроль журнала транзакций (LDF). Массовые операции удаления в модели Full Recovery Model вызывают лавинообразный рост файла журнала транзакций. На период выполнения очистки частоту резервного копирования лога транзакций увеличивают до 1–3 минут.
4. Очистка оборотных регистров и регистров сведений. Оборотные регистры накопления и периодические регистры сведений срезаются проще всего, так как не требуют расчета и фиксации входящих остатков на дату среза. Их очистку безопаснее всего проводить в часы наименьшей нагрузки по ночам.

Подход 3. Свертка через симметричные документы и последовательности

Альтернативный метод выполнения свертки силами самой платформы 1С без использования прямых SQL-запросов:

1. Устанавливаем дату запрета редактирования.
2. Создаем документ ввода остатков с симметричными движениями («плюс» и «минус»), который на дату среза компенсирует все движения прошлых периодов.
3. Фоновым процессом поэтапно обходим документы от самых старых к новым, очищая движения конкретного документа и синхронно корректируя компенсирующую часть симметричного документа остатков.
4. Такая обработка может работать неделями в фоновом режиме, обрабатывая документы небольшими пачками и не вызывая взаимных блокировок (deadlocks) в текущем рабочем периоде.

Критические технические нюансы при онлайн-свертке

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

1. Смещение периода рассчитанных итогов. Удаление старых записей из основной таблицы движений регистра не очищает автоматически исторические срезы таблицы итогов. После зачистки движений необходимо программно сместить нижнюю границу итогов с помощью метода УстановитьПериодРассчитанныхИтогов().
2. Сдвиг границ последовательностей. В конфигурациях с партионным учетом удаление или изменение документов сбрасывает границы последовательностей на дату самого раннего измененного документа. Чтобы фоновые задания регламентного проведения не начали перепроводить базу за прошлые годы, границы всех последовательностей принудительно передвигаются на дату свертки вызовом метода Установить() у объектов последовательностей.
3. Предотвращение появления битых ссылок («Объект не найден»). Если регистры взаиморасчетов или партий не закрывались «в ноль» и содержат аналитику по старым документам, удаление этих документов породит битые ссылки в субконто и реквизитах. Перед физическим удалением документов ссылки на них заменяются на служебный документ-заглушку («Ввод начальных остатков») во всех незакрытых остатках.
4. Запрет сжатия базы (Shrink) в рабочее время. Выполнение операций сжатия файлов базы данных (DBCC SHRINKFILE) в процессе активной работы пользователей категорически запрещено, так как приводит к тотальной фрагментации индексов (до 99%) и тяжелым блокировкам страниц данных. Высвобождение места на диске СХД переносится на регламентные выходные дни.