Создание распределенной информационной базы (РИБ) — стандартная задача для крупных торговых и производственных сетей, работающих на платформе «1С:Предприятие». Однако на практике этот процесс нередко сопровождается техническими сбоями. Особенно часто администраторы и разработчики сталкиваются с непредвиденным поведением системы при попытке сформировать начальный образ подчиненного узла на стороне SQL-сервера.
В этой статье мы подробно проанализируем две взаимосвязанные проблемы, которые часто возникают при развертывании РИБ (на примере конфигурации «Управление торговлей, редакция 11»): ошибку SDBL «Не удается открыть транзакцию при выключенных индексах» при стандартном создании образа и последующую «Ошибку формата представления изменений», возникающую при попытке обойти первую проблему альтернативными методами.
---
Данная ошибка возникает в самом конце процесса генерации начального образа подчиненного узла, когда база данных развернута в клиент-серверном варианте (MS SQL Server, PostgreSQL, IBM DB2 или Oracle Database).
Выясним причину этого поведения. Технология SDBL (внутренний язык запросов и механизмов СУБД в платформе 1С) во время создания начального образа пытается оптимизировать запись огромного массива данных. Для ускорения процесса платформа временно отключает (деактивирует) некластеризованные индексы в создаваемой базе данных подчиненного узла. После завершения копирования таблиц система пытается открыть транзакцию, чтобы активировать индексы обратно и зафиксировать изменения. В этот момент из-за внутренних архитектурных коллизий некоторых релизов платформы механизм SDBL блокируется, вызывая критический сбой.
Рассмотрим подробнее три основных способа решения этой проблемы.
Описанное поведение является официально зарегистрированным багом платформы 1С (особенно часто оно проявлялось на релизах линеек 8.3.15 и 8.3.16, включая сборку 8.3.16.1148). В более поздних и стабильных релизах платформы (начиная с 8.3.17 и выше) разработчики 1С устранили эту уязвимость механизма SDBL.
Если у вас есть возможность провести плановое обновление, настоятельно рекомендуется обновить платформу на сервере приложений и на всех рабочих станциях до актуального и стабильного релиза.
Поскольку ошибка SDBL жестко привязана к работе драйверов СУБД на SQL-сервере, мы можем полностью исключить влияние серверных механизмов на этапе создания образа, выполнив процедуру локально.
Разберем этот процесс по шагам:
.1CD на локальном диске или SSD-накопителе)..dt..dt. Начальный образ успешно развернут на сервере без единой ошибки транзакций.Если первые два варианта по каким-то причинам не подходят, администратор баз данных может проверить состояние индексов непосредственно в SQL. Иногда в процессе некорректно завершенных транзакций или динамических обновлений часть индексов таблиц центральной базы данных переходит в состояние disabled.
Для исправления ситуации выполните следующие действия:
ALTER INDEX ALL ON [Имя_Таблицы] REBUILD.---
Часто программисты пытаются обойти проблемы создания начального образа так называемым «альтернативным» способом, который официально описан на ресурсах ИТС. Суть метода заключается в том, что вместо стандартной выгрузки образа создается абсолютно чистая база из файла конфигурации .cf центральной базы, а затем в ней программно прописываются настройки планов обмена и загружаются зарегистрированные изменения.
Однако при первом же сеансе синхронизации (при вызове метода ПрочитатьИзменения()) система может выдать критическую ошибку: «Ошибка формата представления изменений». Это означает, что структура XML-файла сообщения обмена, отправленного из центра, не совпадает с тем, что ожидает увидеть парсер подчиненного узла.
Проанализируем ключевые причины возникновения этой ошибки и пошагово разберем методы их устранения.
При альтернативном создании РИБ программист вынужден вручную прописывать коды узлов в планах обмена обеих баз. XML-сериализатор крайне чувствителен к любым расхождениям в идентификаторах.
Разберем пример: в центральной базе данных для подчиненного узла задан код «МСК» (русскими буквами). Если в подчиненной базе при создании карточки предопределенного узла ЭтотУзел вы укажете код «мск» (в нижнем регистре), «MCK» (латинскими буквами) или случайно допустите пробел в конце строки «МСК », то принимающая сторона не сможет сопоставить отправителя в заголовке XML-файла и выдаст ошибку формата.
Решение: Скопируйте коды узлов из центральной базы через буфер обмена. Убедитесь, что в подчиненной базе код элемента ЭтотУзел (который символизирует саму подчиненную базу) посимвольно совпадает с кодом этого же узла, зарегистрированным в центральной базе.
При первом обмене номера отправленных и принятых сообщений в карточках настроек узлов должны быть строго скоординированы. Если подчиненная база является абсолютно чистой, она ожидает входящее сообщение под номером 1 (или 0 в зависимости от настроек). Если из центральной базы выгрузить пакет, в котором в заголовке XML будет указан иной порядковый номер (например, если синхронизация ранее уже пыталась выполняться), подчиненный узел отклонит пакет как некорректный.
Решение: В обеих базах перед началом первого обмена вручную (или с помощью специализированных обработок) обнулите номера сообщений. Номер отправленного сообщения из центральной базы должен соответствовать номеру ожидаемого принятого сообщения в подчиненной базе.
Чтобы чистая база данных начала позиционировать себя как подчиненный узел РИБ, ей необходимо программно назначить главного родителя. Для этого используется метод ПланыОбмена.УстановитьГлавныйУзел().
Посмотрим на пример правильной реализации этой процедуры. В подчиненной базе необходимо запустить внешнюю обработку со следующим кодом:
// Определяем узел, который станет главным (наша центральная база)
УзелГлавный = ПланыОбмена.УдалитьИмяВашегоПланаОбмена.НайтиПоКоду("ЦБ");
Если Не УзелГлавный.Пустая() Тогда
// Устанавливаем связь
ПланыОбмена.УстановитьГлавныйУзел(УзелГлавный);
Предупреждение("Главный узел успешно установлен. Перезапустите сеанс!");
Иначе
ВызватьИсключение "Не найден узел с указанным кодом для назначения главным!";
КонецЕсли;
Важный нюанс: После выполнения этого кода необходимо обязательно завершить работу текущего сеанса 1С и запустить программу заново. В противном случае настройки сессии не обновятся на уровне кэша приложения, и первая попытка чтения XML-пакета вызовет ошибку формата.
Если в центральной базе незадолго до выгрузки конфигурации .cf или формирования пакета изменений выполнялось динамическое обновление (без монопольного выгона пользователей и перезапуска службы сервера), структура таблиц метаданных в оперативной памяти сервера 1С и реальная структура в СУБД могут разойтись.
При выгрузке данных сериализатор сформирует XML-структуру на основе кэшированных "динамических" метаданных, а подчиненный узел, развернутый из честного файла конфигурации, не сможет ее прочесть.
Решение: В центральной базе выполните «демонополизацию» — завершите все сеансы пользователей, очистите серверный кэш метаданных, запустите Конфигуратор и выполните полноценное обновление конфигурации базы данных через клавишу F7 (или через меню Конфигурация - Обновить конфигурацию базы данных).
Иногда ошибка формата возникает из-за того, что в тело XML-сообщения попадает битый объект (например, ссылка на несуществующий элемент справочника, недопустимые спецсимволы в строковых реквизитах документов или некорректные записи в регистрах сведений).
Проанализируем ситуацию и выявим проблемный объект экспериментальным путем:
---
Создание РИБ альтернативным способом — отличная и документированная практика, спасающая в условиях нестабильной работы СУБД. Главное при её реализации — соблюдать абсолютную идентичность конфигураций (использовать строго актуальный .cf), синхронность кодов планов обмена вплоть до регистра символов и не забывать про обязательный перезапуск сессии после назначения главного узла.