Как исправить ошибку СУБД в 1С

Ошибка СУБД в 1С означает, что платформа не смогла выполнить операцию с базой данных: прочитать таблицу, записать документ или получить блокировку. Текст ошибки обычно содержит фразы вроде «Ошибка СУБД: таблица повреждена», «Lock request time out», «Transaction deadlock» или коды SQL Server и PostgreSQL. Причина почти никогда не в самой 1С — она кроется в базе данных, дисковой подсистеме, сети или настройках сервера СУБД.

Первое правило при любой ошибке СУБД — не перезапускать всё подряд и не запускать «лечение» вслепую. Неверные действия на повреждённой базе могут превратить частично читаемые данные в полностью нечитаемые. Прежде чем что-либо исправлять, зафиксируйте точный текст ошибки, момент её возникновения и сделайте копию базы любым доступным способом.

Подход к исправлению зависит от режима работы: файловая база (файл 1Cv8.1CD) или клиент-серверная (Microsoft SQL Server, PostgreSQL). Инструменты и риски в этих сценариях различаются, поэтому дальше материал разбит по типовым ситуациям.

Как понять, что именно сломалось: читаем текст ошибки

Формулировка ошибки — главный диагностический признак. «Ошибка формата потока» и «повреждён файл базы данных» указывают на физическую порчу файловой базы. «Could not continue scan with NOLOCK» или «database is suspect» — на проблемы в MS SQL Server. «Lock request time out period exceeded» и «deadlock victim» говорят не о повреждении, а о конкуренции сеансов за ресурсы.

Обязательно посмотрите технологический журнал 1С и журнал ошибок самой СУБД (для MS SQL — ERRORLOG, для PostgreSQL — postgresql-*.log). Там видно, какая таблица, индекс или запрос стали источником сбоя. Без этой информации любое «лечение» будет гаданием.

Обязательные действия до начала исправления

Прежде всего сделайте резервную копию. Для файловой базы — скопируйте файл 1Cv8.1CD при отсутствии активных сеансов. Для серверной — выполните полный backup средствами СУБД, а не выгрузку в dt: выгрузка из повреждённой базы может оборваться или унаследовать дефект.

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

Исправление файловой базы

Для файловых баз существует два основных инструмента. Первый — утилита chdbfl.exe из каталога bin установленной платформы. Она проверяет физическую целостность файла 1Cv8.1CD на низком уровне и умеет исправлять ошибки структуры страниц. Запускается на копии файла при закрытых сеансах: укажите путь к файлу, отметьте «Исправлять обнаруженные ошибки» и дождитесь результата.

Второй инструмент — «Тестирование и исправление» в конфигураторе (Администрирование → Тестирование и исправление). Оно работает на уровне логики данных: проверяет ссылочную целостность, пересчитывает итоги, перестраивает индексы. Для начала выбирайте режим «Тестирование» без исправления, чтобы оценить масштаб проблемы, и только потом включайте исправление.

Порядок имеет значение: сначала chdbfl (физика), затем тестирование в конфигураторе (логика). Если chdbfl не справилась, попробуйте выгрузку базы в dt и загрузку в новую пустую базу — при загрузке структура пересоздаётся заново, и часть дефектов уходит.

1. 1
   Завершите все сеансы и скопируйте файл 1Cv8.1CD в отдельный каталог
2. 2
   Запустите chdbfl.exe на копии с включённым исправлением ошибок
3. 3
   Откройте базу в конфигураторе и выполните «Тестирование и исправление» сначала в режиме только проверки
4. 4
   При обнаружении логических ошибок повторите с исправлением, без удаления объектов
5. 5
   Проверьте работу базы: открытие списков, проведение документов, построение отчётов

Исправление ошибок в клиент-серверной базе

В клиент-серверном варианте файл 1Cv8.1CD отсутствует, и chdbfl неприменима. Для MS SQL Server базовая проверка — команда DBCC CHECKDB, выполняемая в контексте нужной базы. Она покажет повреждённые страницы и индексы. Начинайте с варианта без исправления, чтобы понять масштаб.

DBCC CHECKDB (N'MyBase') WITH NO_INFOMSGS;

Если повреждён только некластерный индекс, часто достаточно его перестроить командой ALTER INDEX ... REBUILD — это безопасная операция, не затрагивающая данные. Повреждение кластерного индекса или страниц данных серьёзнее: безопасный путь — восстановление из последней целой резервной копии, а не ремонт с потерей данных.

Для PostgreSQL прямого аналога CHECKDB нет. Проверяйте логи сервера на ошибки чтения страниц, при подозрении на повреждённые индексы выполняйте REINDEX, а для диагностики физической целостности существует утилита pg_amcheck (в современных версиях). Полная проверка дампом через pg_dump также косвенно выявляет нечитаемые данные.

Отдельно проверьте версию платформы 1С и её совместимость с версией СУБД. Часть «ошибок СУБД» после обновления SQL Server или PostgreSQL вызвана не повреждением, а несовместимостью — лечится обновлением платформы 1С до актуального релиза.

Ошибки блокировок: когда данные целы, а работать невозможно

Сообщения про таймауты блокировок и взаимоблокировки (deadlock) — самая частая «ошибка СУБД» в многопользовательских базах. Данные при этом не повреждены: один сеанс держит ресурс, другой ждёт и отваливается по таймауту. Типичные источники — зависшие сеансы, длительные регламентные задания, проведение больших документов в часы пик, неоптимальные запросы в доработках.

Найдите виновника через консоль кластера 1С (список сеансов, колонка времени последней активности) или через динамическое представление sys.dm_exec_requests в MS SQL. Завершите зависший сеанс штатно. Если взаимоблокировки повторяются, включите технологический журнал с событием TDEADLOCK и передайте результаты разработчику — обычно требуется переработка кода или индексов.

Профилактика: как не довести до повторной ошибки

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

Для серверных баз настройте регулярные полные резервные копии с проверкой восстановления (копия, которую никто не проверял, может оказаться битой). Следите за свободным местом на дисках с данными и журналом транзакций — переполненный диск является частой причиной остановки СУБД с ошибками. Регулярно обновляйте статистику и перестраивайте индексы: это снижает и нагрузку, и вероятность таймаутов.

Когда самостоятельного исправления недостаточно

Есть ситуации, где самостоятельные действия с высокой вероятностью ухудшат результат: база в статусе suspect на MS SQL, повреждение страниц данных (а не индексов), ошибки ввода-вывода диска в логах, отсутствие ни одной рабочей резервной копии. В этих случаях остановите все работы с базой, снимите посекторную копию диска или скопируйте файлы данных и обращайтесь к специалистам по восстановлению.

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