Свертка (обрезка) базы данных в условиях непрерывного производства — это всегда вызов. Когда информационная база разрастается до огромных размеров, стандартные обработки свертки могут работать неделями, а структура данных может начать давать сбои. В такой ситуации использование механизма Распределенных Информационных Баз (РИБ) становится одним из наиболее эффективных и безопасных способов получения «чистой» базы с актуальными данными за выбранный период.
В этой статье мы подробно разберем, как подготовить и реализовать план перехода на новую базу с использованием РИБ, на что обратить внимание при работе с 1С:УПП 1.3 и как минимизировать время простоя системы.
Традиционная свертка через удаление старых документов часто приводит к проблемам с транзакционными логами SQL, блокировкам и долгому ожиданию. Метод через РИБ позволяет нам создать «клон» системы, в который попадут только нужные данные начиная с определенной даты. Главное преимущество этого метода — сохранение уникальных идентификаторов (GUID) всех объектов, что критически важно для корректной работы внешних интеграций и исторических ссылок внутри системы.
Прежде всего, нам необходимо проанализировать состав используемого плана обмена (обычно это план обмена «Полный»). Разберем по шагам, что нужно проверить:
Стандартный механизм Создать начальный образ в 1С при больших объемах данных часто зависает или завершается ошибкой. Рассмотрим альтернативный, более быстрый путь:
1. Сделаем полную копию рабочей базы средствами SQL Server.
2. В этой копии программно «разорвем» связь, чтобы превратить её в обычную базу. Для этого выполним код:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
3. В центральной базе создадим новый узел РИБ. Запомним его код.
4. В созданной копии (которая станет нашей новой рабочей базой) назначим этот узел главным. Это делается программно путем установки ссылки на соответствующий узел плана обмена.
Чтобы в новую базу не летел «мусор» из прошлого, нам нужно ограничить регистрацию изменений. Проанализируем ситуацию: нам нужны все справочники, но документы только с 01.01.2021.
Для этого в подписках на события, которые регистрируют изменения документов, добавим условие. Пример логики:
Если ТипЗнч(Источник) = Тип("ДокументОбъект.ЗаказПокупателя") Тогда
Если Источник.Дата < '20210101000000' Тогда
Возврат; // Не регистрируем старые документы
КонецЕсли;
КонецЕсли;
Рассмотрим подробнее: этот код предотвращает попадание старых данных в таблицу регистрации _DataChngRec. Если документ был изменен в старой базе, но его дата меньше пороговой, он просто не пойдет в обмен.
Так как мы создали новую базу как полную копию (через SQL), в ней изначально есть все данные. Теперь их нужно удалить. Но делать это нужно крайне аккуратно:
ПланыОбмена.УдалитьРегистрациюИзменений(ЭтотУзел);
Проанализируем специфику УПП 1.3. Если в вашей базе используется РАУЗ (Расширенная аналитика учета затрат), помните: расчет себестоимости опирается на ключи аналитики и движения в регистрах «Учет затрат». При обрезке базы через РИБ крайне важно:
Когда данные в новой базе синхронизированы и старье удалено, наступает момент подмены. Выясним последовательность действий:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено).Если структура базы сильно повреждена («посыпалась»), использование РИБ может перенести ошибки на уровне SQL таблиц. В таком случае рассмотрим вариант с Универсальным обменом в формате XML. Процесс выглядит так:
Этот способ дольше, но он гарантирует пересоздание таблиц базы данных «с нуля», что лечит многие логические ошибки структуры.
Резюмируем: Использование РИБ для создания актуальной копии базы с определенной даты — это рабочий и надежный механизм для крупных систем. Он позволяет избежать длительного простоя, сохраняет целостность ссылок и дает возможность подготовить новую базу в фоновом режиме, не прерывая основное производство.