← На главную

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

Разберем, как правильно организовать процедуру автономной обрезки центральной базы (ЦБ) и периферийных баз (ПБ) так, чтобы массивы удаляемых исторических данных не мигрировали по каналам связи, а обмен продолжил функционировать стабильно.

Вариант 1. Свертка ЦБ с последующей очисткой таблицы регистрации изменений

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

Разберем по шагам строгую последовательность действий:

1. Завершение текущих циклов обмена: перед началом работ необходимо провести полноценный двусторонний сеанс обмена между всеми узлами. ЦБ должна принять все вечерние данные из ПБ, а ПБ — получить все актуальные пакеты из ЦБ. Это гарантирует, что на момент свертки в таблице изменений нет зависших оперативных документов.
2. Блокировка пользователей: монопольно останавливаем работу пользователей во всех узлах.
3. Внедрение вспомогательных объектов: если для фиксации входящих остатков используется специальный документ (например, Документ.ВводОстатков или универсальный корректировщик регистров), в конфигураторе для данного метаданного устанавливаем правило миграции «Все базы» (если остатки должны уйти в ПБ) либо «Место создания» (если в каждом узле остатки будут формироваться автономно).
4. Проведение процедуры свертки: выполняем обработку по удалению устаревших документов, очистке строк с мертвым ассортиментом и проведению документов фиксации остатков.
5. Очистка таблицы регистрации изменений: поскольку стандартные методы встроенного языка Удалить() и Записать() регистрируют каждую операцию, очищаем таблицу 1SUPDTS (или _1SUPDTS в формате SQL). Чтобы не затереть новые важные объекты, которые могли создаваться параллельно, рекомендуется точечно очищать записи по идентификаторам удаленных типов метаданных, либо полностью занулять таблицу, если перед сверткой был выполнен полный обмен.
6. Синхронная свертка на ПБ: аналогичная процедура обрезки и очистки таблицы 1SUPDTS выполняется автономно на стороне каждой периферийной базы.
7. Возобновление штатного обмена: базы запускаются в обычном режиме.

Вариант 2. Создание новых периферийных баз после свертки

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

Разберем порядок действий при таком подходе:

1. В центральной базе выполняем полную свертку и удаление устаревших данных.
2. В режиме «Конфигуратор» → «Администрирование» → «Распределенная ИБ» → «Управление» для каждого филиала создаем новое описание периферийной базы (либо переинициализируем существующее).
3. Выполняем первичную выгрузку компактных данных из очищенной ЦБ.
4. На стороне филиала перед началом рабочего дня старая база архивируется, а на ее место разворачивается файл первичного образа.

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

Вариант 3. Подмена баз и таблиц УРБД через СУБД (для баз на SQL)

Выясним способ ускоренной свертки без длительного прерывания работы филиалов с помощью манипуляций на уровне SQL-сервера:

1. В ЦБ создается новый узел с двусторонним обменом, в который выгружаются только базовые справочники.
2. В ЦБ создаются и выгружаются документы ввода остатков на начало актуального периода, а также документы за последние рабочие периоды.
3. Выполняются два контрольных сеанса обмена для сброса очереди регистрации.
4. Средствами СУБД выполняется подмена таблиц регистрации УРБД у рабочей и новой сокращенной базы, после чего переключаются пути подключения.

Вопросы пересчета итогов регистров на ПБ при изменении метаданных

Проанализируем частый вопрос: если в процессе свертки в конфигурацию добавляются новые документы (например, универсальный документ корректировки регистров), вызовет ли передача нового файла 1Cv7.MD в периферийную базу автоматический пересчет всех регистров?

Поведение платформы 1С 7.7 в данном случае строго регламентировано:

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

Важные технические предостережения

При реализации автономной схемы свертки обратите внимание на следующие нюансы:

1. Риск появления битых ссылок: если в ПБ задним числом будет введен документ, содержащий ссылку на позицию номенклатуры, которая уже физически удалена из ЦБ, то при последующем обмене в центральной базе данный реквизит отобразится как «Объект не найден». Удалять номенклатуру следует только тогда, когда она гарантированно вычищена из всех табличных частей на всех узлах.

2. Границы последовательностей: после массового удаления документов прошлых периодов необходимо программно или интерактивно скорректировать границу последовательности документов (таблица 1SSTREAM), чтобы предотвратить попытки системы перепровести удаленный исторический период при первом же проведении документа задним числом.