При работе с распределенными информационными базами (РИБ) в экосистеме 1С:Предприятие специалисты часто сталкиваются со скрытыми механизмами платформы, которые могут существенно влиять на производительность и стабильность системы. Один из таких механизмов — регистрация изменений конфигурации для узлов РИБ. Если в вашей базе данных создан план обмена, у которого установлен признак «Распределенная ИБ», платформа начинает вести строгий учет всех доработок и обновлений метаданных, чтобы впоследствии передать их в подчиненные узлы.
Проблема обостряется, когда обмен фактически не используется (или подчиненные узлы давно заброшены), но флаг «Распределенная ИБ» остается активным. В этом случае служебные таблицы регистрации начинают лавинообразно разрастаться, что приводит к многократному увеличению времени реструктуризации базы данных при обновлениях или даже к полной невозможности применить изменения. В этой статье мы подробно разберем, как устроен этот механизм изнутри, в каких таблицах СУБД хранятся эти данные и какими методами можно выполнить их полную и безопасную очистку.
Для начала проанализируем, как именно платформа 1С осуществляет запись изменений метаданных. Когда разработчик вносит изменения в конфигурацию (например, правит программный код в модулях, добавляет новые реквизиты, изменяет формы) и выполняет обновление конфигурации базы данных (клавиша F7 в Конфигураторе), платформа фиксирует эти действия.
Если для какого-либо плана обмена включено свойство «Распределенная ИБ», платформа автоматически генерирует разностное обновление конфигурации (дельта-пакет) в формате XML и бинарных данных. Эти сведения записываются в физические таблицы базы данных SQL отдельно для каждого зарегистрированного узла этого плана обмена. Эти таблицы имеют следующие системные имена:
_ConfigChngR — основная таблица регистрации изменений конфигурации. В ней хранятся ссылки на узлы обмена и идентификаторы измененных объектов метаданных._ConfigChngR_ExtProps — вспомогательная таблица регистрации изменений дополнительных (внешних) свойств конфигурации.Если подчиненные узлы не получают обновления регулярно, то при каждом последующем изменении основной конфигурации новые порции данных добавляются к уже существующим записям в этих таблицах. В крупных информационных базах с активной разработкой количество записей в таблицах _ConfigChngR может легко превысить сотни тысяч или даже миллионы строк, занимая гигабайты дискового пространства на сервере СУБД.
Давайте выясним причину, почему переполнение таблиц _ConfigChngR и _ConfigChngR_ExtProps является критичным для администраторов и программистов 1С. При каждом обновлении конфигурации базы данных платформа выполняет сопоставление текущей структуры метаданных с накопленным «хвостом» зарегистрированных изменений для РИБ. Если этот хвост слишком велик, процесс реструктуризации может зависнуть на этапе обновления служебных таблиц.
Более того, при обновлении платформы на современные релизы (например, линеек 8.3.22, 8.3.24 и выше) СУБД может аварийно завершить работу Конфигуратора, выдав одну из следующих критических ошибок:
DBSchema.В таких ситуациях стандартное обновление базы данных становится заблокированным, и администраторам приходится прибегать к экстренным методам очистки системы.
Рассмотрим важный нюанс встроенного языка 1С. Для удаления регистрации изменений обычных данных (справочников, документов, регистров) программисты используют стандартную конструкцию:
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Данные);
Однако для изменений самой конфигурации этот метод не применим. Платформа 1С:Предприятие не предоставляет разработчику инструментов встроенного языка для прямого управления таблицами _ConfigChngR. Попытка передать объект конфигурации в качестве параметра удаления вызовет ошибку времени выполнения. Соответственно, решать задачу очистки приходится другими доступными методами.
Если в вашей системе распределенная база данных больше не используется (или признак «Распределенная ИБ» был установлен по ошибке, как в ситуации автора обсуждения), самым простым и безопасным решением является снятие этого флага в метаданных.
Проанализируем этот процесс по шагам:
F7 или выбрав меню "Конфигурация" -> "Обновить конфигурацию базы данных").При принятии изменений платформа 1С распознает, что данный план обмена больше не является распределенным. В этот момент СУБД выполняет автоматическую очистку и последующее физическое удаление таблиц _ConfigChngR и _ConfigChngR_ExtProps. Весь накопившийся мусор удаляется абсолютно штатно и бесследно.
Если вы не можете отключить признак РИБ, так как обмен реально функционирует, но таблицы сильно раздуты из-за зависших пакетов, очистить их можно только путем подтверждения приема сообщений периферийным узлом.
Платформа автоматически очищает записи в таблице _ConfigChngR, относящиеся к конкретному узлу, только после того, как из этого узла будет получен входящий файл обмена, содержащий подтверждение (квитанцию) приема номера сообщения, в котором были переданы изменения конфигурации. Убедитесь, что:
Если конкретный подчиненный узел завис, перестал обновляться или связь с ним потеряна, а таблицы регистрации для него продолжают расти, можно прибегнуть к пересозданию узла:
При удалении узла платформа автоматически очистит все связанные с ним записи регистрации во всех таблицах изменений, включая изменения конфигурации.
В критических ситуациях, когда база данных заблокирована ошибкой реструктуризации (ошибка SDBL) и зайти в Конфигуратор для снятия признака РИБ невозможно, единственным выходом остается прямое вмешательство в базу данных на уровне СУБД (MS SQL Server, PostgreSQL и др.).
Важно: Перед выполнением любых операций на уровне СУБД обязательно сделайте полную резервную копию базы данных (бэкап средствами SQL Server)! Все операции должны проводиться в монопольном режиме при остановленной службе сервера 1С:Предприятия.
Рассмотрим правильный вариант SQL-запроса для очистки этих таблиц. Откройте среду управления СУБД (например, SQL Server Management Studio) и выполните следующие инструкции:
-- Безопасная очистка таблиц регистрации изменений конфигурации
DELETE FROM dbo._ConfigChngR;
DELETE FROM dbo._ConfigChngR_ExtProps;
Обратите внимание на то, почему мы используем именно команду DELETE, а не мгновенный TRUNCATE TABLE. Хотя TRUNCATE работает быстрее и не забивает лог транзакций, его использование может нарушить внутренние механизмы сопоставления структуры таблиц с системной таблицей DBSchema, хранящей внутреннее описание метаданных 1С. Использование команды DELETE гарантирует корректное поведение платформы при последующем запуске Конфигуратора.
После успешного выполнения запроса запустите службу сервера 1С и откройте Конфигуратор. Процесс реструктуризации и обновления конфигурации должен пройти быстро и без ошибок SDBL.
Если ваша база данных является файловой (имеет формат *.1CD), вы не сможете выполнить SQL-запрос напрямую. При возникновении аналогичных проблем в файловом варианте используйте один из следующих подходов:
.dt), после чего создайте новую чистую файловую базу и загрузите этот файл обратно. При выгрузке-загрузке платформа производит оптимизацию структуры таблиц и может автоматически отбросить некорректный мусор регистрации.Tool_1CD). С его помощью можно открыть файл базы данных, найти таблицы _ConfigChngR и _ConfigChngR_ExtProps и очистить в них строки вручную. Помните, что использование сторонних утилит сопряжено с рисками повреждения файла базы данных, поэтому создание резервной копии файла 1Cv8.1CD перед началом работ строго обязательно.Мы детально проанализировали скрытый механизм платформы по регистрации изменений конфигурации. Для предотвращения подобных проблем в будущем мы рекомендуем соблюдать следующие правила администрирования: