Как исправить ошибку «нарушена целостность структуры конфигурации» в 1С:Предприятие?

← На главную

Ошибка «нарушена целостность структуры конфигурации» — одна из наиболее распространенных проблем в клиент-серверных информационных базах 1С:Предприятие. В большинстве случаев она возникает в результате использования механизма динамического обновления конфигурации («демонического обновления»), когда в момент фиксации изменений происходит сбой сетевого соединения, аварийное завершение процесса кластера серверов rphost или зависание транзакции на стороне СУБД.

В результате нарушается целостность системных таблиц Config и ConfigSave, а служебный манифест версий метаданных versions рассинхронизируется с фактическими записями объектов. Пользовательский режим «1С:Предприятие» при этом может продолжать работать, однако запуск «Конфигуратора» завершается аварийно или окно дерева метаданных оказывается пустым.

Разберем по шагам причины сбоя и рассмотрим проверенные способы восстановления работоспособности конфигурации.

Почему возникают ошибки при попытке исправить таблицу Config прямым SQL-запросом?

Проанализируем частую ошибку системных администраторов и разработчиков, пытающихся вручную переименовать или удалить записи динамического обновления с постфиксами _dynupdate_ в таблице Config с помощью SQL-запросов вида:


UPDATE Config 
SET FileName = SUBSTRING(FileName, 0, 37)
WHERE FileName LIKE '%_dynupdate_%'

При выполнении подобного скрипта СУБД выдает исключение: Violation of PRIMARY KEY constraint 'ByNameNo_Config'. Cannot insert duplicate key in object 'dbo.Config'.

Выясним причину: в таблице Config первичный ключ является составным и включает поля FileName и PartNo. При динамическом обновлении крупные бинарные данные метаданных могут дробиться на составные части с добавлением расширений (например, .0, .1). Обрезание имени файла функцией подстроки без учета составного ключа и существующих базовых записей приводит к коллизии уникальности с уже существующим идентификатором GUID. Выполнять такие модификации без глубокого понимания внутренней структуры формата хранения крайне небезопасно.

Способ 1. Восстановление через выгрузку в файловый режим и обновление метаданных

Рассмотрим основной и наиболее безопасный алгоритм, который помог автору вопроса восстановить доступ к конфигурации без риска потери пользовательских данных:

Очистим кэш конфигурации и сеансовых данных. Завершим все активные сеансы пользователей в консоли администрирования кластера 1С. На локальном компьютере администратора удалим каталоги временных файлов в %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8. Также на стороне сервера 1С:Предприятие остановим службу 1C:Enterprise Server Agent и в каталоге кластера srvinfo\reg_XXXX удалим папки серверного контекста с префиксом snccntx. Запустим службу сервера заново.
Выгрузим данные в файл выгрузки. Создадим резервную копию базы данных в формате .dt средствами конфигуратора или командной строки.
Развернем базу в файловом варианте. Создадим новую пустую файловую информационную базу на локальном диске и загрузим в нее полученный .dt файл. В файловом режиме механизм проверки структуры часто позволяет открыть дерево метаданных.
Выполним изменение структуры или обновление. Откроем конфигурацию в файловой базе. Обновим конфигурацию на следующий релиз поставщика через меню Конфигурация - Поддержка - Обновить конфигурацию либо выполним принудительную реструктуризацию (например, добавим и удалим временный вспомогательный реквизит в любой объект, после чего выполним Обновить конфигурацию базы данных). В процессе полного сохранения платформа заново сформирует системный файл versions и корректно очистит все зависшие временные слои.
Выполним тестирование и исправление. Перейдем в меню Администрирование - Тестирование и исправление..., включим проверку логической и ссылочной целостности, а также реиндексацию таблиц.
Перенесем базу обратно на сервер СУБД. Выгрузим исправленную файловую базу в .dt и загрузим ее в рабочую серверную информационную базу (предварительно сделав резервную копию средствами СУБД).

Способ 2. Восстановление через пакетный запуск из командной строки

Если графический интерфейс Конфигуратора падает сразу при запуске, разберем возможность вызова утилиты пакетного запуска 1cv8.exe без отображения графического окна:

1. Попробуем выполнить откат к стабильной конфигурации базы данных:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /RollbackCfg

Параметр /RollbackCfg отменяет незафиксированные изменения редактируемой конфигурации и приводит ее в соответствие с конфигурацией базы данных.

2. Если есть файл эталонной конфигурации (.cf того же релиза), загрузим его принудительно:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /LoadCfg "C:\backup\clean.cf" /UpdateDBCfg

Способ 3. Очистка подвисших маркеров динамического обновления средствами SQL

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

Важно: перед выполнением любых операций на уровне СУБД обязательно создадим полную резервную копию базы данных (резервную копию .bak в MS SQL Server или дамп в PostgreSQL) и остановим службу сервера 1С:Предприятия.

Выполним очистку таблиц служебных состояний:


-- Очищаем таблицу несохраненной конфигурации
DELETE FROM ConfigSave;

-- Удаляем маркеры незавершенной фиксации
DELETE FROM Config WHERE FileName IN ('commit', 'dynamicCommit', 'dbStruFinal');
DELETE FROM Config WHERE FileName LIKE '%DynamicallyUpdated%';
DELETE FROM Params WHERE FileName LIKE '%DynamicallyUpdated%';

-- Удаляем временные версионные записи динамического обновления
DELETE FROM Config WHERE FileName LIKE '%_dynupdate_%';

Обратим внимание: очистка таблиц _ConfigChngR и _ConfigChngR_ExtProps, которую иногда советуют на форумах, не исправляет целостность метаданных. Эти таблицы предназначены исключительно для регистрации изменений конфигурации в планах обмена (РИБ). Их очистка лишь сбросит очередь регистрации обновлений для распределенных узлов, но не устранит повреждение структуры в основной таблице Config.

Способ 4. Полная замена таблицы Config из копии базы

Пользовательские данные (документы, справочники, регистры) хранятся в таблицах с префиксами _Reference, _Document, _InfoReg и не затрагиваются таблицей метаданных Config. Если имеется недавняя резервная копия этой же информационной базы того же релиза, применим следующий порядок восстановления:

Остановим кластер серверов 1С:Предприятия.
Создадим резервную копию поврежденной базы на уровне СУБД.
Очистим метаданные в поврежденной базе и перенесем их из эталонной копии:


TRUNCATE TABLE [ПоврежденнаяБаза].[dbo].[Config];
TRUNCATE TABLE [ПоврежденнаяБаза].[dbo].[ConfigSave];

INSERT INTO [ПоврежденнаяБаза].[dbo].[Config]
SELECT * FROM [РезервнаяКопия].[dbo].[Config];

После завершения переноса запустим службу сервера 1С, войдем в Конфигуратор и выполним Конфигурация - Проверка конфигурации.