Переход от распределенной информационной базы (РИБ) к работе в едином узле — задача, требующая не только организационных усилий, но и четкого понимания технических процессов платформы 1С. Часто возникает вопрос: достаточно ли просто отключить регламентные задания обмена, или же необходимо полностью «разрывать» связи между узлами? В этой статье мы подробно разберем, как корректно завершить работу в режиме РИБ, минимизировать риски и оптимизировать базу данных после объединения.
Для начала проанализируем ситуацию, когда мы просто отключаем расписание обмена в пользовательском режиме. Многие полагают, что этого достаточно, но это не совсем так. Рассмотрим, как работает механизм регистрации изменений. В 1С регистрация объектов (документов, справочников) происходит непосредственно в момент их записи. База «знает», что у нее есть зарегистрированные периферийные узлы в плане обмена, и при каждом сохранении объекта делает запись в специальные таблицы регистрации изменений (так называемые таблицы _Chng).
Важный момент: если мы просто выключим фоновые задания, регистрация изменений все равно будет продолжаться «в пустоту». Это приведет к следующим последствиям:
Поэтому правильной стратегией является не просто остановка транспорта данных, а полное удаление информации о РИБ из конфигурации и базы данных.
Если нам нужно превратить периферийный узел в полноценную самостоятельную базу (например, для проверки данных перед окончательным слиянием или если часть филиалов остается работать автономно), необходимо получить монопольный доступ к базе и снять признак «подчиненности». Рассмотрим два основных способа решения этой задачи.
Способ А: Использование параметра запуска ResetMasterNode
Этот способ является классическим. Мы запускаем толстый клиент 1С из командной строки с определенным флагом. Выясним, как это выглядит на практике:
1cv8.exe ENTERPRISE /F "ПутьКБазе" /ResetMasterNode
Этот ключ заставляет систему при запуске очистить ссылку на главный узел. После этого база перестает считать себя периферийной, и в ней снимаются ограничения на редактирование объектов, которые ранее могли быть заблокированы (например, константы или настройки учетной политики, приходящие только из «центра»).
Способ Б: Программное отключение через встроенный язык
Если база расположена на сервере, удобнее выполнить команду прямо в коде. Разберем пример кода, который полностью разрывает связь с главным узлом:
// Выполняется в подчиненном узле для его отвязки
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого метода свойство ПланыОбмена.ГлавныйУзел() будет возвращать Неопределено, и база станет автономной.
В центральной базе нам не нужно «отвязываться», так как она сама является главной. Однако нам необходимо исключить регистрацию изменений для узлов, которые больше не участвуют в обмене. Проанализируем последовательность действий:
Простое удаление узла не всегда мгновенно очищает физические таблицы на уровне СУБД. Посмотрим на критически важные действия по оптимизации после отключения РИБ:
Очистка таблиц регистрации изменений: Если в базе накопились миллионы записей для обмена, который так и не состоялся, они могут занимать гигабайты пространства. После удаления узлов рекомендуется выполнить операцию «Тестирование и исправление» с установленным флагом «Сжатие таблиц» (Shrink). Это позволит СУБД вернуть свободное место операционной системе.
Удаление настроек БСП: В современных конфигурациях (Бухгалтерия 3.0, ERP, УТ 11) механизмы обмена глубоко интегрированы с Библиотекой Стандартных Подсистем. После удаления узла в базе могут остаться записи в служебных регистрах:
Рекомендуем тщательно проверить эти регистры и убедиться, что после удаления помеченных объектов в них не осталось «фантомных» записей.
При работе в РИБ каждому узлу обычно назначается уникальный префикс (например, «МСК», «СПБ»). Рассмотрим ситуацию: вы объединили все данные в одну базу. Теперь при создании новых документов система будет использовать префикс текущего узла.
Проанализируем риски: Если вы оставите старые префиксы в документах «для истории», это нормально. Однако, если вы планируете продолжать нумерацию с новыми префиксами, нужно проверить, не возникнет ли сбоев в автонумерации. Иногда полезно программно перенумеровать документы за последний период, чтобы привести их к единому стандарту центральной базы, но это требует осторожности из-за возможных ссылок из внешних систем.
При «отказе от РИБ по-живому» (когда мы просто отключаем механизмы обмена в работающей базе) все GUID (уникальные идентификаторы) объектов сохраняются. Это огромный плюс, так как все внутренние и внешние связи остаются целыми.
Обратите внимание: Если бы вы решили перенести данные в новую чистую базу через XML, GUIDы могли бы измениться, что привело бы к дублям или разрывам связей с внешними сервисами (например, с интеграцией интернет-магазина или системами электронного документооборота). При использовании метода ResetMasterNode или программной отвязки таких проблем не возникает.
Подведем итог нашему исследованию. Для успешного ухода от РИБ мы рекомендуем придерживаться следующего алгоритма:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено).Такой системный подход гарантирует, что ваша база данных будет работать максимально быстро, а в системе не останется «мусорных» данных от старых механизмов распределенной работы.