Создание распределенной информационной базы (РИБ) — стандартная задача при масштабировании бизнеса, автоматизации удаленных филиалов или создании тестовых «веток» для разработки. Однако при работе с крупными базами данных, такими как Управление торговлей, стандартный механизм выгрузки начального образа через конфигуратор часто превращается в головную боль. Процесс может длиться часами, прерываться ночными сбоями СУБД или завершаться неочевидными ошибками платформы.
В этой статье мы подробно разберем, почему возникает популярная ошибка «Начальный образ может быть выгружен только во вновь созданную или пустую ИБ той же версии...», как бороться с ночными прерываниями длительных транзакций, а также по шагам рассмотрим альтернативный и самый быстрый метод создания РИБ из обычной резервной копии (бэкапа) всего за пару минут.
Данная ошибка возникает из-за повышенной чувствительности платформы 1С к состоянию целевой базы данных. Если вы заранее создали базу данных на сервере MS SQL или PostgreSQL, зарегистрировали ее в консоли администрирования 1С и попытались указать ее в качестве целевой, платформа заблокирует процесс. Для 1С «пустая» база — это база, в которой нет абсолютно никаких внутренних таблиц конфигурации. Даже если вы просто один раз запустили эту базу в режиме конфигуратора или загрузили туда структуру метаданных через файл .cf, она уже перестает считаться пустой.
Чтобы успешно обойти это ограничение, выполните следующие шаги:
Выгрузка образа для баз размером более 50-100 Гб требует колоссальных ресурсов. Если вы запустили процесс на ночь, а утром обнаружили, что сессия конфигуратора закрылась или завершилась аварийно, мы имеем дело с одной из трех системных проблем:
Во-первых, переполнение лога транзакций (LDF) и базы TempDB. При выгрузке начального образа СУБД выполняет одну гигантскую транзакцию. Лог транзакций (файл .ldf) исходной и создаваемой баз начинает лавинообразно расти. Если на диске СУБД заканчивается свободное место или установлены жесткие ограничения на авторасширение файлов базы данных, SQL-сервер принудительно прерывает транзакцию и откатывает все изменения назад.
Решение: Перед началом выгрузки переведите модель восстановления (Recovery Model) целевой базы данных на SQL-сервере в режим Simple (Простая). Убедитесь, что на дисках СУБД достаточно свободного места (с запасом в 2-3 раза превышающим объем исходной базы) для роста служебной базы tempdb.
Во-вторых, ночные регламентные процедуры СУБД. На большинстве рабочих серверов настроены автоматические планы обслуживания: резервное копирование, реиндексация таблиц, обновление статистик или очистка процедурного кэша. Если во время работы длительной транзакции 1С запустится процесс создания бэкапа или реиндексации, таблицы будут заблокированы, что приведет к ошибке взаимной блокировки (deadlock) и аварийному закрытию сеанса 1С.
Решение: Временно отключите все регламентные задания в СУБД и самой платформе 1С на период создания начального образа.
В-третьих, таймауты сетевых соединений и службы кластера. В настройках кластера серверов 1С существуют параметры, отвечающие за принудительное завершение «спящих» или слишком длительных соединений (например, ibConnKeepAliveTimeout). Если процесс выгрузки зависает на одном тяжелом объекте, кластер может посчитать соединение зависшим и разорвать его.
Решение: Увеличьте таймауты соединений в консоли кластера 1С и настройках SQL-сервера на время проведения технических работ.
Для по-настоящему больших баз данных классический метод выгрузки начального образа через конфигуратор становится неэффективным. Вместо мучительного ожидания мы можем применить профессиональный метод преобразования обычной копии базы данных в рабочий периферийный узел РИБ. Этот способ занимает ровно столько времени, сколько требуется на восстановление бэкапа базы данных средствами SQL.
Давайте подробно разберем этот процесс по шагам.
Сначала нам необходимо зарегистрировать будущий подчиненный узел в центральной базе, чтобы система знала о его существовании и могла готовить для него пакеты обмена.
ПланыОбмена.Полный).SUB, и наименование (например, "Филиал Восток").MAIN). Запишите эти коды, они понадобятся нам далее.Нам необходимо получить точную копию центральной базы на момент создания узла.
.bak).На данный момент восстановленная копия базы считает себя центральной (главной) базой. Нам нужно программно объяснить платформе, что теперь эта база является подчиненным (периферийным) узлом по отношению к центральной базе.
// Определим ссылку на узел, который должен стать главным для этой базы
УзелЦентральнойБазы = ПланыОбмена.Полный.НайтиПоКоду("MAIN");
Если Не УзелЦентральнойБазы.Пустая() Тогда
// Устанавливаем признак того, что текущая база подчинена центральной
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентральнойБазы);
Сообщить("База успешно преобразована в подчиненный узел РИБ!");
Иначе
Сообщить("Внимание! Узел с кодом MAIN не найден в этой базе.");
КонецЕсли;
Метод ПланыОбмена.УстановитьГлавныйУзел() производит важнейшее системное изменение: он блокирует возможность изменения конфигурации в данной базе. С этого момента конфигурация заблокирована для редактирования и может обновляться только путем загрузки файлов обновлений из главного узла.
Так как наша новая база была создана из полной копии центральной базы, в ней осталась информация обо всех зарегистрированных изменениях для обмена с другими узлами. Если не очистить эти данные, то при первом же сеансе обмена периферийная база попытается выгрузить гигабайты ненужной информации обратно в центр.
Для предотвращения этой ситуации выполните в подчиненной базе следующий код:
// Очищаем регистрацию всех изменений для узла центральной базы
ПланыОбмена.УдалитьРегистрациюИзменений(УзелЦентральнойБазы);
Сообщить("Регистрация изменений успешно очищена.");
После выполнения этих процедур настройте параметры транспорта обмена (каталог, FTP или email) и выполните первый тестовый запуск синхронизации. Сначала запустите обмен в центральной базе на выгрузку, а затем в подчиненной базе на загрузку. Вы увидите, что обмен прошел мгновенно, а конфигурации баз абсолютно идентичны.