Как создать копию базы 1С по одной организации с регулярным обновлением?

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

Вариант 1. Использование распределенной информационной базы (РБД) с фильтрацией

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

Рассмотрим, с какими сложностями можно столкнуться при использовании РБД:

1. Передача изменений конфигурации. В классическом РБД любые доработки метаданных главного узла обязаны приниматься в подчиненном узле с монопольной блокировкой информационной базы, что усложняет автоматическое обновление копии.
2. Нарушение ссылочной целостности. В комплексных конфигурациях (таких как УПП или ERP) множество объектов нормативно-справочной информации и регистров не имеют прямого реквизита или измерения Организация (например, справочники статей затрат, номенклатуры, регистры учета затрат). Без явного описания логики миграции зависимых данных в подчиненной базе появятся битые ссылки (объект не найден).
3. Эскалация блокировок таблиц изменений. Механизм регистрации изменений создает системные таблицы для каждого типа метаданных. При редких обменах (например, раз в неделю) объем накопленных записей вырастает. При выполнении метода ПланыОбмена.ВыбратьИзменения() или записи новых данных СУБД может накладывать блокировки уровня страниц или всей таблицы изменений, что способно приводить к таймаутам и взаимным блокировкам (deadlocks) у пользователей, работающих в рабочей базе по другим организациям.

Если выбран вариант с обменом через планы обмена, проанализируем способы минимизации блокировок:

1. Отключение автоматической регистрации объектов. В свойствах плана обмена для метаданных следует установить свойство «Авторегистрация» в значение «Запретить», а регистрацию выполнять точечно через подписки на события.
2. Программный отбор получателей. В обработчиках событий ПередЗаписью или ПриЗаписи нужный узел плана обмена добавляется в коллекцию адресатов только при соответствии условию:

Если Источник.Организация = УзелОбмена.Организация Тогда
    Источник.ОбменДанными.Получатели.Добавить(УзелОбмена);
КонецЕсли;

Такой подход исключает регистрацию лишних записей для других 29 организаций и снижает нагрузку на системные таблицы регистрации.

Вариант 2. Универсальный обмен данными без признака РБД

Рассмотрим вариант создания отдельного плана обмена без признака распределенной информационной базы. Обмен данными настраивается с помощью правил конвертации данных (КД) или HTTP-сервисов.

Разберем преимущества этого подхода:

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

Вариант 3. Разворачивание копии из бэкапа с ограничением прав (RLS) или очисткой

Если база-витрина требуется исключительно для чтения (например, для проверки аудиторами раз в неделю), наиболее надежным и простым решением является работа с полной копией базы, созданной средствами СУБД во внерабочее время.

Разберем по шагам схему реализации:

1. Автоматическое восстановление резервной копии. По расписанию в выходные дни скрипт СУБД восстанавливает актуальный бэкап рабочей базы на отдельном сервере витрины.
2. Настройка доступа через RLS. Аудиторам выдается учетная запись с профилем доступа, в котором настроено ограничение прав на уровне записей (RLS) по целевой организации. Аудитор видит исключительно разрешенную организацию, при этом целостность всех движений и регистров гарантированно сохраняется.
3. Альтернативная скриптовая очистка данных. Если требуется физически исключить чужие данные из базы, после восстановления резервной копии запускается регламентная обработка, которая удаляет документы остальных организаций.

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