Ошибка «Нарушена целостность структуры конфигурации» в 1С 8.3: чем лечить базу

Сообщение «Нарушена целостность структуры конфигурации» в 1С 8.3 означает, что платформа не смогла собрать метаданные базы из служебных таблиц: часть описания конфигурации битая или записана не до конца. Данные учёта при этом обычно целы — ломается именно «чертёж» базы, а не документы и проводки. Исправить целостность структуры конфигурации 1С 8.3 можно четырьмя путями: откатить незавершённую запись конфигурации, починить файл базы утилитой chdbfl.exe, загрузить заведомо рабочую конфигурацию из .cf, либо развернуть резервную копию.

В 9 случаях из 10 ошибка выскакивает не сама по себе, а после события: аварийно закрылся конфигуратор во время сохранения, упал сервер при обновлении конфигурации базы данных, закончилось место на диске, отвалилась сеть у файловой базы. Поэтому первый шаг — не кнопки нажимать, а вспомнить, что происходило с базой за 10 минут до ошибки.

Дальше — порядок действий от безопасного к радикальному, с путями меню и ключами командной строки.

Что значит «нарушена целостность структуры конфигурации» и где именно ломается

Конфигурация в 1С 8.3 хранится не файлами, а записями в служебных таблицах базы:

• 🔹 Config — текущая конфигурация базы данных, разложенная на сотни бинарных кусков;
• 🔹 ConfigSave — конфигурация, открытая в конфигураторе, но ещё не сохранённая в базу;
• 🔹 DBSchema — схема физических таблиц СУБД, соответствие метаданных реальным таблицам;
• 🔹 IBVersion — версия формата информационной базы;
• 🔹 Files — служебные файлы, в том числе признак активного обновления.

Платформа при старте читает Config и DBSchema и собирает из них дерево метаданных. Если хотя бы один кусок не читается, не совпадает контрольная сумма или в таблице остался маркер незавершённой транзакции записи — сборка падает с этим сообщением.

Как выглядит текст ошибки

Формулировки отличаются по версии платформы и способу запуска:

• Нарушена целостность структуры конфигурации
• Ошибка загрузки конфигурации: Нарушена целостность структуры конфигурации
• Внутренняя ошибка: Нарушена целостность структуры конфигурации
• Ошибка при открытии конфигурации базы данных. Нарушена целостность структуры конфигурации

Иногда рядом идёт вторая строка про ошибку СУБД или про «неверный формат хранилища» — тогда первопричина в диске или в СУБД, а целостность конфигурации лишь следствие.

Почему нарушается целостность структуры конфигурации

Типовые первопричины, по частоте:

Что проверить до начала лечения

Пункт про релизы не формальность. Если не знаете, какой релиз конфигурации был в базе, вы не сможете подобрать правильный .cf — а загрузка чужого релиза поверх битой базы превратит частичную проблему в полную.

Диагностика по симптому: куда идти дальше

Способ 1. Чистка кеша клиента и проверка версии платформы

Начинайте с самого дешёвого. Если ошибка локальная, дальше идти не придётся.

1. Закройте все сеансы 1С на проблемном компьютере, проверьте в диспетчере задач, что процессов 1cv8.exe и 1cv8c.exe нет.
2. Удалите содержимое папок кеша:
   • %LOCALAPPDATA%\1C\1cv8
   • %APPDATA%\1C\1cv8
3. Запустите клиент с принудительной очисткой кеша:

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

4. Сверьте релиз платформы и требования конфигурации. Бухгалтерия 3.0, ЗУП 3.1, УТ 11 и ERP 2 в свежих релизах требуют платформу не ниже определённой версии; на старой платформе конфигурация может не собираться.

Способ 2. Проверка физической целостности файловой базы утилитой chdbfl

Для файловых баз (1Cv8.1CD) у 1С есть отдельная утилита проверки физической целостности. Она не входит в меню конфигуратора, её запускают вручную.

1. Попросите всех выйти, остановите веб-сервер и службы, которые держат базу.
2. Скопируйте файл 1Cv8.1CD в надёжное место — утилита правит файл на месте.
3. Запустите chdbfl.exe из каталога платформы:

C:\Program Files\1cv8\8.3.27.1606\bin\chdbfl.exe

4. Укажите путь к 1Cv8.1CD, поставьте галочку Исправлять обнаруженные ошибки и нажмите «Выполнить».
5. Дождитесь окончания. На базе 15–20 ГБ проверка идёт от 30 минут до нескольких часов.

Для клиент-серверной базы на MS SQL или PostgreSQL этой утилиты нет. Там аналог — проверка средствами СУБД:

DBCC CHECKDB ('accounting_base') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Способ 3. Тестирование и исправление информационной базы

Штатный инструмент конфигуратора. Путь: Конфигуратор → Администрирование → Тестирование и исправление.

Галочки, которые относятся к структуре:

• ✅ Реиндексация таблиц информационной базы — перестроить индексы;
• ✅ Проверка логической целостности информационной базы — главная для нашей ошибки;
• ✅ Проверка ссылочной целостности информационной базы — битые ссылки;
• ⬜ Пересчёт итогов — не обязателен, но лишним не будет;
• ⬜ Сжатие таблиц информационной базы — долго, только при нехватке места;
• ⬜ Реструктуризация таблиц информационной базы — самая тяжёлая операция, включайте осознанно.

Режим внизу окна: сначала Только тестирование, чтобы увидеть список проблем без правок. И только потом — Тестирование и исправление.

Для ссылочной целостности на первом прогоне ставьте Не изменять. Если битые ссылки нашлись — Создавать объекты сохранит историю документов «пустышками», Очищать ссылки обнулит их, а Удалять объекты — крайний случай и только после согласования с бухгалтерией.

То же из командной строки, удобно для длинных прогонов по расписанию:

"C:\Program Files\1cv8\8.3.27.1606\bin\1cv8.exe" DESIGNER ^
 /F "D:\Bases\Buh" /N "Администратор" /P "pwd" ^
 /IBCheckAndRepair -ReIndex -LogIntegrity -RecalcTotals -TestOnly ^
 /Out "D:\logs\check.txt" /DisableStartupMessages

Убрать -TestOnly — и прогон пойдёт с исправлением. Лог в /Out потом читается глазами: там видно, какие таблицы ругались.

Способ 4. Загрузка конфигурации из файла .cf

Если конфигурация типовая и не доработана, проще всего заменить её целиком на эталон того же релиза.

1. Скачайте дистрибутив ровно того релиза конфигурации, который стоял в базе, и достаньте из него 1Cv8.cf.
2. В конфигураторе: Конфигурация → Загрузить конфигурацию из файла, укажите .cf.
3. На вопрос об обновлении базы данных ответьте «Да» — платформа выполнит Обновить конфигурацию базы данных.
4. Проверьте поддержку: Конфигурация → Поддержка → Настройка поддержки — должен быть статус «на поддержке» без снятых замков.

Та же операция пакетно:

"C:\Program Files\1cv8\8.3.27.1606\bin\1cv8.exe" DESIGNER ^
 /S "srv-1c\buh" /N "Администратор" /P "pwd" ^
 /LoadCfg "D:\dist\1Cv8.cf" /UpdateDBCfg -Server

Способ 5. Откат незавершённой записи конфигурации на уровне СУБД

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

Лечение — вернуть базу к состоянию «до записи»: убрать метку и очистить незафиксированную конфигурацию разработчика.

MS SQL Server:

-- 1. Полный бэкап
BACKUP DATABASE [buh_base] TO DISK = 'D:\backup\buh_before_fix.bak'
  WITH INIT, COMPRESSION;

-- 2. Есть ли метка незавершённой записи
SELECT FileName, DATALENGTH(BinaryData) AS len
FROM Config WHERE FileName = 'commit';

-- 3. Если строка есть — чистим несохранённую конфигурацию и метку
DELETE FROM ConfigSave;
DELETE FROM Config WHERE FileName = 'commit';

PostgreSQL (имена таблиц в нижнем регистре):

select filename from config where filename = 'commit';
delete from configsave;
delete from config where filename = 'commit';

После этого запустите конфигуратор. База должна открыться в том виде, какой был до неудачного сохранения. Повторите обновление заново — уже с монопольным доступом.

Если строки commit нет, способ не ваш: проблема не в прерванной записи, идите к восстановлению из копии.

Способ 6. Выгрузка-загрузка .dt и восстановление из резервной копии

Классический приём «перелить базу через .dt» на этой ошибке работает редко: выгрузка сама читает метаданные и падает там же. Пробовать стоит, когда конфигуратор всё-таки открывается.

1cv8.exe DESIGNER /F "D:\Bases\Buh" /N "Админ" /P "pwd" /DumpIB "D:\out\buh.dt"
1cv8.exe DESIGNER /S "srv-1c\buh_new" /N "Админ" /P "pwd" /RestoreIB "D:\out\buh.dt"

Если .dt не выгружается — остаётся восстановление:

1. 🔸 MS SQL: RESTORE DATABASE из последнего .bak, затем в кластере серверов переподключить ИБ.
2. 🔸 PostgreSQL: создать новую базу и залить дамп pg_restore.
3. 🔸 Файловая база: подменить 1Cv8.1CD копией, снятой при остановленной работе.
4. 🔸 После восстановления — сверить остатки и догрузить документы за потерянный период руками или через обмен.

Отчёты для контроля после восстановления: Отчёты → Стандартные отчёты → Оборотно-сальдовая ведомость, затем Анализ учёта и экспресс-проверка учёта. В ЗУП 3.1 дополнительно — Зарплата и кадры → Отчёты по зарплате → Анализ взносов в фонды.

Сравнение способов: что быстрее и чем рискуете

Нарушена целостность структуры конфигурации 1С 8.3 при обновлении: разбор

Это самый частый контекст ошибки, и лечится он иначе, чем «просто битая база». Обновление конфигурации проходит в две фазы: сначала платформа пишет новую конфигурацию в ConfigSave, затем переносит её в Config и перестраивает таблицы. Обрыв между фазами и даёт нарушенную целостность.

Что обрывает обновление:

• 🔹 в базе остались активные сеансы — платформа не получает монопольный доступ и ждёт, администратор убивает процесс;
• 🔹 переполнился лог транзакций MS SQL или кончилось место в каталоге PostgreSQL;
• 🔹 упал рабочий процесс rphost по лимиту памяти или служба сервера 1С;
• 🔹 динамическое обновление применялось на работающих пользователях;
• 🔹 реструктуризация большой таблицы ушла в таймаут.

Порядок восстановления после сорванного обновления:

1. Остановите службу сервера 1С, проверьте отсутствие rphost, rmngr, ragent.
2. Снимите бэкап текущего состояния — да, битого. Он пригодится, если дальше станет хуже.
3. Выполните откат незавершённой записи по способу 5.
4. Освободите место: переведите базу MS SQL в Recovery model = Simple на время обновления или усеките лог.
5. Поставьте блокировку сеансов: консоль Администрирование серверов 1С Предприятия → информационная база → Блокировка начала сеансов → признак установлен, код разрешения задан.
6. Запустите обновление заново из конфигуратора, не динамическое: Конфигурация → Обновить конфигурацию базы данных с монопольным доступом.
7. После успеха — обязательно Тестирование и исправление в режиме только тестирования, чтобы убедиться, что база чистая.

Особенности по конфигурациям

Ошибка платформенная и не зависит от прикладного решения, но нюансы есть.

Бухгалтерия 3.0. Ломается чаще всего на квартальных обновлениях с реструктуризацией регистров НДС. Контроль после лечения — Отчёты → Анализ учёта → Экспресс-проверка ведения учёта.

ЗУП 3.1. Болезненны регистры по взносам и НДФЛ: сверьте начисления с отчётом по страховым взносам за закрытый период.

УТ 11. Тяжёлые регистры товародвижения, реструктуризация долгая. Проверка — Склад и доставка → Отчёты → Ведомость по товарам на складах.

ERP 2. Много подсистем и обменов. Узел распределённой базы (РИБ) нельзя восстанавливать из старой копии без согласования с центральным узлом — развалите обмен. Сначала разберитесь с номерами сообщений.

Типичные ошибки при лечении

• ❌ Чинить без бэкапа. «Тестирование и исправление» с удалением объектов необратимо. Бэкап — минута, восстановление данных руками — недели.
• ❌ Сразу включать все галочки тестирования, включая реструктуризацию и сжатие. Прогон на большой базе уходит на сутки, а причина была в кеше клиента.
• ❌ Загружать .cf другого релиза «потому что нашёлся». Получите каскад ошибок обновления поверх битой структуры.
• ❌ Копировать 1Cv8.1CD на живой базе и считать это резервной копией. Копия файловой базы снимается только при отсутствии сеансов.
• ❌ Править Config вслепую, удаляя «подозрительные» строки. В Config лежит вся конфигурация; лишнее удаление делает базу нерабочей окончательно.
• ❌ Перезапускать обновление по кругу, не разобравшись с причиной обрыва. Если места на диске нет, пятая попытка закончится так же, как первая.
• ❌ Игнорировать журнал СУБД и Windows. Ошибки ввода-вывода означают железо; лечение базы на умирающем диске — потеря времени.

Как не получить эту ошибку снова

1. 🛡 Автоматические бэкапы средствами СУБД: полный раз в сутки, лог транзакций каждый час. Проверка восстановления хотя бы раз в квартал.
2. 🛡 Обновления конфигурации — только в окне без пользователей, с блокировкой начала сеансов, без динамического обновления.
3. 🛡 Мониторинг свободного места на дисках базы, логов и tempdb. Порог тревоги — 20%.
4. 🛡 Файловые базы на 5+ пользователей переводить в клиент-серверный вариант. Файловая база по сети — главный поставщик таких ошибок.
5. 🛡 Исключения в антивирусе для каталогов базы, srvinfo и файлов *.1CD, *.mdf, *.ldf.
6. 🛡 ИБП на сервер и на СУБД. Половина повреждений — это внезапное отключение питания.
7. 🛡 Перед сложным обновлением — тестовая копия базы и прогон обновления на ней.

Частые вопросы