Повреждена база 1С и выскакивает «Ошибка СУБД»: пошаговый ремонт

Обновлено 07.10.2026 · 10 мин

Содержание

Ошибку СУБД в 1С чаще всего исправляют в два шага: сначала копируют базу, затем проверяют её. Файловую базу проверяют утилитой chdbfl.exe из папки bin платформы, а потом в Конфигураторе запускают Администрирование → Тестирование и исправление. Клиент-серверную базу проверяют средствами самой СУБД (DBCC CHECKDB в MS SQL, журналы и REINDEX в PostgreSQL), и только потом — тем же тестированием из Конфигуратора.

Обычная картина: бухгалтер проводит документ, программа зависает, после перезапуска видит Ошибка СУБД: Файл базы данных поврежден. Часто перед этим пропадало электричество или отваливался сетевой диск. Ниже порядок действий, при котором файл базы можно восстановить без потери данных.

Шаг 0. Сначала копия, потом диагностика

Любой ремонт начинайте с копии повреждённой базы. Утилиты исправления удаляют битые записи. Если что-то пойдёт не так, без копии вернуть их будет нельзя.

Попросите всех пользователей выйти из базы. Закройте Конфигуратор.
Для файловой базы скопируйте папку с базой целиком: в ней лежит 1Cv8.1CD и папка журнала 1Cv8Log.
Для SQL-базы сделайте полную резервную копию средствами СУБД (BACKUP DATABASE в MS SQL, pg_dump в PostgreSQL).
Запишите точный текст ошибки. Целиком, вместе с тем, что идёт после двоеточия.

Текст после слов «Ошибка СУБД:» и есть диагноз. Платформа просто передаёт вам сообщение, которое вернул движок базы. По нему видно, где искать: в файле, на диске, в SQL Server или в PostgreSQL.

Как прочитать текст ошибки СУБД и найти причину в логах

Первым делом определите, какой у вас вариант базы. Это видно в окне запуска: у файловой базы в строке пути стоит File=, у серверной — Srvr= и Ref=.

Типичные формулировки и что за ними стоит

Фрагмент сообщения	Вариант базы	Вероятная причина
`Файл базы данных поврежден`	Файловая	Обрыв записи в `1Cv8.1CD`: питание, сеть, сбой диска
`Нарушение целостности структуры конфигурации`	Любая	Прервано обновление или реструктуризация
`Отказано в доступе`, `Access denied`	Файловая	Нет прав на папку базы или файл держит антивирус
`The transaction log for database ... is full`	MS SQL	Переполнен журнал транзакций
`Could not allocate space for object`	MS SQL	Закончилось место под файл данных
`deadlocked on lock resources`	MS SQL	Взаимная блокировка, обычно не повреждение
`No space left on device`	PostgreSQL	Закончился диск на сервере СУБД
`could not read block`	PostgreSQL	Повреждена страница таблицы или индекса

Если ошибка про место на диске или блокировку, ремонтировать базу не нужно. Нужно освободить диск или разобраться, кто держит блокировку. Повреждение — это сообщения про «поврежден», «целостность», «could not read block».

Где смотреть логи

📒 Журнал регистрации базы. В Конфигураторе: Администрирование → Журнал регистрации. В БП 3.0 и ЗУП 3.1 без Конфигуратора: Администрирование → Обслуживание → Журнал регистрации. Отберите события с уровнем «Ошибка» за время сбоя.
🖥️ Журнал событий Windows. Раздел «Система»: ошибки диска (источники disk, Ntfs) рядом по времени почти всегда объясняют повреждение файловой базы.
🗄️ Лог SQL Server. Файлы ERRORLOG в папке Log экземпляра или узел «Журналы SQL Server» в Management Studio.
🐘 Лог PostgreSQL. Папка log внутри каталога данных кластера (в старых сборках — pg_log).
⚙️ Технологический журнал 1С. Включается файлом logcfg.xml в папке conf платформы. Для разбора ошибок СУБД собирайте события EXCP, а при необходимости DBMSSQL или DBPOSTGRS.

Пример минимальной настройки технологического журнала, который пишет только исключения:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1C_TechLog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Технологический журнал быстро растёт. Включайте его на время диагностики и после удаляйте logcfg.xml, иначе забьёте диск и получите новую ошибку СУБД.

Диагностика: выберите симптом

Ремонт файла базы 1Cv8.1CD: chdbfl и тестирование

Для файловой базы есть два инструмента. Утилита chdbfl.exe чинит сам файл на физическом уровне. Тестирование и исправление в Конфигураторе чинит логику данных. Порядок важен: сначала файл, потом логика.

Утилита chdbfl.exe

Она лежит в папке установленной платформы, например C:\Program Files\1cv8\8.3.x.x\bin\chdbfl.exe. Берите версию из той же платформы, которой открываете базу.

Убедитесь, что в базе никого нет. Утилите нужен монопольный доступ к файлу.
Запустите chdbfl.exe. Укажите путь к файлу 1Cv8.1CD.
Сначала нажмите «Выполнить» без флажка исправления. Утилита только покажет ошибки.
Если ошибки есть, поставьте флажок «Исправлять обнаруженные ошибки» и запустите ещё раз.
Дождитесь конца. Для базы в несколько гигабайт это десятки минут, окно в это время может не отвечать — не закрывайте его.

После исправления утилита может сообщить, что часть записей удалена. Это нормально для битых страниц, но такие данные потом придётся проверить вручную.

Тестирование и исправление в Конфигураторе

Откройте базу в режиме Конфигуратора и выберите Администрирование → Тестирование и исправление. Включите проверки по нарастающей.

Проверка	Что делает	Когда включать
Реиндексация таблиц	Пересобирает индексы	Всегда, первым проходом
Проверка логической целостности	Ищет нарушения структуры записей	Всегда
Проверка ссылочной целостности	Ищет «битые» ссылки на удалённые объекты	Если в отчётах видны `<Объект не найден>`
Пересчёт итогов	Пересчитывает итоги регистров	Если не сходятся остатки
Сжатие таблиц	Убирает пустое место в файле	Для файловой базы, после ремонта
Реструктуризация таблиц	Пересоздаёт таблицы целиком	Последний шаг, когда остальное не помогло

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

Тот же набор можно запускать без окон, ночью, из пакетного файла. Это удобно для больших баз и регламента.

"C:\Program Files\1cv8\8.3.x.x\bin\1cv8.exe" DESIGNER /F"D:\Base\Buh" /N"Администратор" /P"пароль" ^
  /IBCheckAndRepair -ReIndex -LogIntegrity -RecalcTotals -IBCompression -BadRefNone ^
  /Out"D:\Base\check_log.txt"

Флаг -TestOnly включает режим без исправлений. Полный список ключей — в справке платформы по параметру /IBCheckAndRepair.

Если chdbfl не справился

Есть приём, который часто спасает базу: выгрузка в .dt и загрузка в новую пустую базу. При загрузке файл 1Cv8.1CD собирается заново, и старые битые страницы в него не попадают.

В Конфигураторе: Администрирование → Выгрузить информационную базу.
Создайте новую пустую базу в другой папке.
Откройте её Конфигуратором: Администрирование → Загрузить информационную базу.
Запустите тестирование и исправление уже в новой базе.

Если выгрузка падает на той же ошибке СУБД, значит повреждение глубже. Тут два пути: резервная копия или специалист.

Клиент-серверная база: проверка в MS SQL и PostgreSQL

В серверной базе chdbfl.exe не применяется. Файлов 1CD там нет, данные хранит СУБД. Начинайте с её средств.

MS SQL Server

Проверьте целостность базы запросом в Management Studio. Имя базы — то, что указано в свойствах информационной базы в консоли кластера.

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

✅ Пустой вывод — физических повреждений нет. Ищите причину в 1С: целостность конфигурации, итоги, блокировки.
⚠️ Есть ошибки и в конце указан минимальный уровень REPAIR_REBUILD — исправление без потери данных возможно, обычно это повреждённые индексы.
⛔ Указан REPAIR_ALLOW_DATA_LOSS — исправление удалит часть данных. Сначала восстанавливайте из резервной копии.

Исправление требует однопользовательского режима:

ALTER DATABASE buh_base SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('buh_base', REPAIR_REBUILD);
ALTER DATABASE buh_base SET MULTI_USER;

WITH ROLLBACK IMMEDIATE сразу обрывает все подключения к базе, в том числе сеансы 1С. Незаписанные документы пропадут. Делайте это вне рабочего времени и предупредите людей.

PostgreSQL

Посмотрите лог сервера за время сбоя. Если ошибка указывает на индекс, перестройте индексы базы:

REINDEX DATABASE buh_base;
VACUUM ANALYZE;

REINDEX блокирует таблицы на время работы, база в это время для 1С недоступна. Если же сообщение про чтение блока самой таблицы, ремонт через SQL рискован. Проверяйте диск и поднимайте копию.

Затем — 1С

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

Очистка кэша 1С и временных файлов

Часть «ошибок СУБД» живёт не в базе, а в кэше. Признак: у одного пользователя ошибка есть, у другого на той же базе нет.

Клиентский кэш. Закройте 1С и удалите папки с длинными именами из GUID в каталогах:

%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8

Файлы ibases.v8i и другие файлы в корне этих папок не трогайте — там список баз. Можно и без ручного удаления: добавьте ключ /ClearCache в строку запуска базы и откройте её один раз.

Кэш сервера 1С. На сервере кэш лежит в папке srvinfo\reg_1541, в подпапках snccntx…. Порядок:

Предупредите пользователей: при остановке службы оборвутся все сеансы на этом сервере.
Остановите службу «Агент сервера 1С:Предприятия».
Удалите подпапки snccntx…. Остальное содержимое reg_1541 не трогайте: там реестр кластера.
Запустите службу.

Файл блокировки файловой базы. В папке базы есть 1Cv8.1CL. Если база не открывается после аварийного выхода, а в ней точно никого нет, файл можно удалить. Пока кто-то работает, удалять нельзя: следующий вход без блокировки может испортить данные.

Профилактика: регламентные работы и защита от повторов

Повреждение почти всегда вызвано внешней причиной. Уберите её, иначе ремонт придётся повторять.

Для файловой базы

💾 Ежедневная резервная копия: выгрузка .dt или копирование папки базы, когда в ней никого нет.
🛡️ Исключите папку базы и файлы *.1CD из проверки антивирусом в реальном времени.
🔌 Источник бесперебойного питания с автоматическим выключением компьютера.
🌐 Не держите базу на нестабильном сетевом диске и тем более на облачной папке с синхронизацией. Это частая причина повреждения файла.
🔧 Раз в месяц — тестирование и исправление по ночному bat-файлу.

Для SQL-базы

Настройте план обслуживания. Примерный ориентир:

Операция	Частота
Полная резервная копия	Ежедневно
Копия журнала транзакций (модель Full)	Каждые 1–4 часа
Обновление статистики	Ежедневно
Перестроение индексов	Раз в неделю
`DBCC CHECKDB`	Раз в неделю
Пробное восстановление копии	Раз в месяц

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

Профилактика ошибок СУБД

Есть ежедневная копия, и её пробовали восстановить
Папка базы исключена из антивируса
Стоит ИБП с автовыключением
Свободно не меньше 20% диска под базу и журналы
Плановые проверки целостности идут по расписанию

Выполнено: 0 / 5

Когда пора звать специалиста

Самостоятельный ремонт заканчивается там, где дальнейшие действия могут уничтожить данные. Остановитесь и обратитесь к администратору или в обслуживающую организацию, если:

⛔ chdbfl.exe завершается с ошибкой или после исправления база всё равно не открывается;
⛔ выгрузка в .dt падает, а свежей резервной копии нет;
⛔ DBCC CHECKDB требует REPAIR_ALLOW_DATA_LOSS;
⛔ база в MS SQL перешла в состояние SUSPECT или не переходит в оперативный режим;
⛔ в журнале Windows идут ошибки диска — сначала меняют диск, потом чинят базу.

Чем меньше попыток вы сделали на оригинале, тем больше шансов у специалиста. Отдавайте ему копию, снятую до ремонта, а не базу после трёх запусков утилит.

Ориентир по стоимости: разовое восстановление файловой базы обычно обходится примерно в несколько тысяч рублей. Сложные случаи с SQL и потерей данных стоят ориентировочно от 10–15 тыс. рублей и выше, зависит от объёма и срочности.

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

Можно ли запускать chdbfl.exe, пока пользователи работают в базе?

Нет. Утилите нужен монопольный доступ к файлу 1Cv8.1CD. Сначала выгоните всех, потом запускайте.

Пропадут ли данные после тестирования и исправления?

В режиме «Только тестирование» ничего не меняется. В режиме исправления могут удалиться битые записи и очиститься ссылки, если вы выбрали эти варианты. Поэтому копия до запуска обязательна.

Почему ошибка СУБД появляется только у одного пользователя?

Чаще всего виноват его локальный кэш или права на папку базы. Очистите кэш через ключ /ClearCache и проверьте доступ к сетевой папке под его учётной записью.

Помогает ли сжатие таблиц при ошибке СУБД?

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

Как часто нужно делать тестирование и исправление?

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

Помогла статья?