Куда сохраняется начальный образ 1С РИБ и как создать его для большой базы данных

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Стандартный механизм: где искать файл образа

Когда мы инициируем процесс через встроенные средства платформы, например, используя метод СоздатьНачальныйОбраз или через интерфейс «Планов обмена», система начинает подготовку данных. Важно понимать разницу между местом, где данные обрабатываются, и местом их итогового сохранения.

Проанализируем логику работы системы:

  1. Интерактивный запрос: Если процесс запускается из интерфейса в обычном режиме, система запросит путь для сохранения файла (или создание новой папки для файловой базы) только в самом конце успешного формирования образа. До этого момента файл не будет виден в целевой директории.
  2. Временные файлы сервера: В клиент-серверном варианте основная работа происходит на стороне сервера приложений 1С. В процессе подготовки данных система создает временные файлы в папке Temp профиля пользователя, под которым запущен агент сервера 1С. Эти файлы могут иметь расширения .1cd или .tmp и занимать значительный объем дискового пространства.
  3. Программное создание: Если мы вызываем создание образа из кода, путь передачи данных обычно описывается в параметрах метода, и файл появится там только после завершения транзакции формирования.

Если процесс прерывается ошибкой, временные файлы могут «зависнуть» в папке Temp, что приведет к нехватке места на сервере. Поэтому при работе с большими базами крайне важно следить за свободным местом на системном диске сервера приложений.

Проблемы при создании образа на больших базах

Рассмотрим ситуацию, когда стандартный механизм не справляется. Чаще всего это происходит по трем причинам:

Метод ручного создания узла из копии базы данных

Проанализируем наиболее надежный способ создания узла для базы размером в несколько сотен гигабайт. Вместо использования штатного механизма СоздатьНачальныйОбраз, мы пойдем по пути клонирования всей информационной базы. Этот метод позволяет избежать долгой выгрузки и гарантирует идентичность конфигурации.

Разберем этот процесс по шагам:

Шаг 1. Создание полной копии. Сначала сделаем бэкап центральной базы средствами SQL Server и восстановим его как новую базу (будущий подчиненный узел).

Шаг 2. Подготовка центральной базы. В основной базе в нужном ПланОбмена создадим новый узел. Запомним его код (например, «УЗ1»).

Шаг 3. Превращение копии в подчиненный узел. Теперь нам нужно программно объяснить базе-копии, что она больше не главная, а является подчиненным узлом «УЗ1». Для этого в базе-копии нужно выполнить следующий код:


// Устанавливаем признак того, что данная база является подчиненной
// Параметр СсылкаНаУзел должен указывать на узел, который является главным (центр)
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);

Шаг 4. Настройка идентификации. В этой же базе-копии необходимо изменить код в объекте ЭтотУзел. Код должен совпадать с тем кодом, который мы задали в центральной базе для этого филиала.

Очистка лишних данных в подчиненном узле

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

Во-первых, нужно удалить все регистрации изменений, которые «приехали» из центральной базы, иначе при первом же обмене система попытается отправить всё содержимое базы обратно в центр:


// Полная очистка таблиц регистрации изменений для всех планов обмена
МассивПланов = ПланыОбмена.ПолучитьИзменения();
Для Каждого План Из Метаданные.ПланыОбмена Цикл
    ПланыОбмена.УдалитьРегистрациюИзменений(ПланыОбмена[План.Имя].ЭтотУзел());
КонецЦикла;

Во-вторых, если в филиале должны быть только определенные данные (например, за последний год или только по конкретной организации), необходимо удалить лишние документы — с этой задачей справится обработка выборочного удаления данных организаций. Для ускорения этого процесса рекомендуется использовать метод записи набора записей с флагом ОбменДанными.Загрузка = Истина, чтобы отключить проверки и триггеры.

Альтернатива: Синхронизация через пустую базу

Рассмотрим еще один вариант, который часто оказывается стабильнее РИБ на плохих каналах связи — использование обмена через брокеры, универсального формата EnterpriseData или использование «чистой» базы.

В этом случае мы:

  1. Создаем новую пустую базу с той же конфигурацией.
  2. Настраиваем синхронизацию данных.
  3. Запускаем первичную выгрузку только необходимых объектов.

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

Важные рекомендации для системных администраторов

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

Таким образом, мы выяснили, что путь к файлу образа запрашивается системой интерактивно, а в случае возникновения технических трудностей на больших объемах данных, всегда можно прибегнуть к методу «ручного» формирования узла через копирование базы и использование метода УстановитьГлавныйУзел.

← На главную