Администрирование · 11 мин
Ошибка СУБД в 1С: что делать и как восстановить базу
Разбираем ошибку СУБД в 1С: типичные причины, диагностика по тексту ошибки, восстановление базы через chdbfl, тестирование и исправление, работа с SQL Server и PostgreSQL.
Ошибка СУБД в 1С — одно из самых неприятных сообщений для пользователя и администратора: работа останавливается, документы не проводятся, а иногда база не открывается вовсе. Аббревиатура СУБД означает «система управления базами данных», и ошибка сигнализирует о том, что платформа 1С не смогла корректно выполнить операцию с данными — прочитать, записать или изменить их.
Причины бывают разными: повреждение файла базы, разрыв соединения с сервером, нехватка дискового пространства, конфликт блокировок, сбой оборудования или ошибка в коде конфигурации. Универсального «волшебного» исправления не существует — правильное действие зависит от точного текста ошибки и типа развёртывания (файловая база или клиент-серверная на MS SQL, PostgreSQL, Oracle).
Главное правило при любой ошибке СУБД — не паниковать и не запускать подряд все найденные в интернете «лечилки». Непродуманные действия, особенно с ключом «игнорировать ошибки», способны превратить частично повреждённую базу в полностью нечитаемую. Ниже — безопасный порядок диагностики и восстановления.
Что означает ошибка СУБД и как читать её текст
Сообщение об ошибке СУБД почти всегда содержит ключ к решению. Платформа 1С выводит описание, полученное от движка базы данных, и по нему можно понять категорию проблемы. Не закрывайте окно ошибки, не переписав текст — сделайте скриншот или скопируйте сообщение, а также загляните в технологический журнал и журнал регистрации.
Типичные фрагменты и их смысл: «Could not continue scan with NOLOCK» — повреждение данных в таблице MS SQL; «database is locked» — файл базы заблокирован другим процессом; «недопустимая длина поля» — повреждение структуры файловой базы; «out of memory» или ошибки с упоминанием tempdb — нехватка памяти или места на диске сервера СУБД.
Проверьте кэш 1С на его компьютере и перезапустите сеанс
Проверяйте диск, службу СУБД и целостность данных
Делайте копию и запускайте chdbfl или проверку средствами СУБД
Проверьте журнал регистрации и попробуйте перепровести документ
Первые действия: что сделать до любого лечения
Прежде чем запускать инструменты восстановления, обезопасьте данные. Скопируйте файл 1Cv8.1CD (для файловой базы) вместе со вспомогательными файлами в отдельную папку или сделайте полный бэкап средствами СУБД, если база клиент-серверная. Все дальнейшие операции выполняйте над копией, а не над рабочей базой.
Далее выполните простые проверки, которые решают заметную часть проблем без всякого восстановления: убедитесь, что на диске с базой есть свободное место (для файловой базы — минимум объём самой базы), перезагрузите сервер 1С и сервер СУБД, проверьте сетевую доступность между серверами, убедитесь, что службы SQL Server или PostgreSQL запущены.
Если ошибка возникает только у одного пользователя, очистите кэш метаданных на его компьютере: завершите сеанс, удалите содержимое папок кэша в профиле пользователя (каталоги вида %APPDATA%\1C\1cv8 с длинными именами-идентификаторами базы) и запустите 1С заново. Повреждённый кэш — частая причина странных ошибок, которые выглядят как сбой СУБД.
Восстановление файловой базы: chdbfl и тестирование
Для файловых баз основной инструмент низкоуровневой проверки — утилита chdbfl.exe, которая поставляется вместе с платформой и лежит в папке bin установленной версии 1С. Она проверяет физическую целостность файла 1Cv8.1CD и может исправить повреждения, при которых база вообще не открывается в конфигураторе.
Порядок работы: закройте все сеансы с базой, запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, поставьте флаг «Исправлять обнаруженные ошибки» и запустите проверку. Утилита выведет список найденных повреждений и результат исправления. Работайте с копией файла — chdbfl изменяет данные напрямую, и в тяжёлых случаях часть записей может быть удалена.
После chdbfl откройте базу в конфигураторе и выполните «Администрирование — Тестирование и исправление». Начинайте с проверок «Реиндексация таблиц» и «Проверка ссылочной целостности» в режиме «Только тестирование» — так вы увидите масштаб проблем без изменения данных. Режимы «Тестирование и исправление» с автоматическим удалением битых ссылок включайте осознанно: объекты с потерянными ссылками могут быть удалены.
- 1Завершите все сеансы и скопируйте папку базы целиком
- 2Проверьте свободное место на диске и целостность диска (chkdsk)
- 3Запустите chdbfl.exe с флагом исправления на копии базы
- 4Откройте базу в конфигураторе, выполните тестирование без исправления
- 5Оцените отчёт, затем при необходимости включите режимы исправления
- 6Проверьте работу базы: открытие документов, проведение, отчёты
Ошибки в клиент-серверном варианте: SQL Server и PostgreSQL
В клиент-серверной архитектуре ошибка СУБД означает, что проблему вернул сервер баз данных, и лечить её нужно средствами самой СУБД, а не утилитами 1С. Начните с журналов: в MS SQL Server смотрите ERRORLOG и журнал событий Windows, в PostgreSQL — лог-файлы сервера. Там видно, что происходило в момент сбоя: разрывы соединений, нехватку памяти, повреждения страниц данных.
Для MS SQL Server проверку целостности конкретной базы выполняет команда DBCC CHECKDB. Запускайте её сначала без параметров исправления, чтобы получить диагноз. Вариант с REPAIR_ALLOW_DATA_LOSS — крайняя мера: он физически вырезает повреждённые страницы вместе с данными, и после него база 1С почти наверняка потребует доразбора. При серьёзных повреждениях надёжнее восстановить базу из последней рабочей резервной копии.
Частые прикладные причины ошибок на сервере СУБД: переполнение журнала транзакций (проверьте модель восстановления базы и настройте регулярное усечение лога), нехватка места под tempdb, слишком малое время ожидания блокировок при высокой нагрузке, антивирус, сканирующий файлы данных в реальном времени. Каталоги с данными СУБД и файловыми базами 1С следует добавить в исключения антивируса.
DBCC CHECKDB (N'ИмяБазы') WITH NO_INFOMSGS;Когда ошибка вызвана блокировками и конкурентным доступом
Отдельный класс ошибок СУБД — не повреждения, а конфликты доступа: «Конфликт блокировок при выполнении транзакции», «Превышено максимальное время ожидания предоставления блокировки». Они возникают, когда несколько пользователей или фоновых заданий одновременно меняют одни и те же данные, и сами по себе не означают поломку базы.
Что делать: повторите операцию через некоторое время, проверьте, не выполняются ли параллельно тяжёлые процессы (закрытие месяца, обмены данными, перепроведение документов), и разнесите их по времени. Если конфликты регулярны — проблема в архитектуре: включите управляемые блокировки в свойствах конфигурации, проверьте код на транзакции с чтением всей таблицы, рассмотрите оптимизацию запросов.
Типичные ошибки при самостоятельном восстановлении
Практика показывает, что значительная часть необратимых потерь данных связана не с самой ошибкой СУБД, а с неправильными действиями при её устранении. Знание этих ловушек экономит часы восстановления и нервы.
Отдельно стоит сказать о файловых базах, размещённых в сетевой папке. Этот режим допустим, но чувствителен к качеству сети: обрыв соединения в момент записи — классическая причина повреждения 1Cv8.1CD. Если база регулярно «падает» с ошибками СУБД, рассмотрите переход на клиент-серверный вариант или публикацию через веб-сервер.
Проверка результата и профилактика
После восстановления не ограничивайтесь тем, что база открылась. Проверьте ключевые сценарии: проведение документов, формирование регламентированных отчётов, обмены данными, работу типовых отчётов за разные периоды. Сверьте итоги по оборотно-сальтовой ведомости с данными, известными до сбоя, — это лучший способ убедиться, что данные не потеряны.
Как проверить результат
База открывается, пользователи входят без ошибок
Ошибки при входе или при открытии списков
Документы проводятся, движения формируются
Ошибки СУБД при проведении отдельных видов документов
ОСВ и отчёты сходятся с данными до сбоя
Расхождения в суммах, пропавшие документы
Проверки завершаются без ошибок
Остаются ошибки целостности или ссылок
Профилактика сводится к нескольким обязательным практикам: настроенное регулярное резервное копирование с проверкой восстановления, мониторинг свободного места на дисках, исключения для антивируса, своевременные обновления платформы и СУБД, источник бесперебойного питания для сервера. Большинство катастрофических сценариев с ошибками СУБД предотвращаются именно этим набором мер.
Что важно запомнить
Зафиксируйте текст ошибки, сделайте копию базы и только потом лечите: файловую — через chdbfl и тестирование, клиент-серверную — средствами СУБД или восстановлением из бэкапа. Ошибки блокировок — не поломка, а повод разобраться с нагрузкой и кодом.
Частые вопросы
Можно ли продолжать работать, если ошибка СУБД появляется редко?
Если ошибка связана с блокировками и повторная попытка успешна — работать можно, но стоит выяснить причину конфликтов. Если же появляются сообщения о повреждении данных или чтении страниц, работу лучше приостановить: каждая новая запись в повреждённую базу усугубляет проблему и усложняет восстановление.
База не открывается ни в конфигураторе, ни в режиме предприятия. Что делать?
Для файловой базы сделайте копию файла 1Cv8.1CD и прогоните его через chdbfl.exe — утилита работает на уровне файла и не требует запуска 1С. Если и это не помогло, восстанавливайте базу из резервной копии или обращайтесь к специалистам по восстановлению данных, имея на руках нетронутую копию повреждённого файла.
Удаление битых ссылок при тестировании — это опасно?
Да, потенциально. Режим «Очищать ссылки» или «Удалять объект» при обнаружении ссылок на несуществующие объекты может удалить реальные документы и элементы справочников. Сначала запустите тестирование без исправления, изучите список проблемных объектов и решите по каждому случаю — иногда правильнее восстановить потерянный объект, а не удалять ссылающийся.
Поможет ли переустановка платформы 1С при ошибке СУБД?
Почти никогда. Ошибка СУБД связана с данными, сервером баз данных или окружением, а не с исполняемыми файлами платформы. Переустановка оправдана только в редких случаях повреждения самой установки, что обычно проявляется ошибками запуска, а не ошибками работы с данными.
Как понять, что виноват жёсткий диск или оборудование?
Косвенные признаки: ошибки СУБД появляются в разных базах и в разное время, в журнале событий Windows есть записи об ошибках диска, chkdsk находит повреждения, SMART диска показывает переназначенные сектора. В этом случае сначала переносите базы на исправное оборудование — лечить данные на умирающем диске бессмысленно.
Нужно ли делать выгрузку в dt после исправления базы?
Желательно. Выгрузка в dt и загрузка в новую чистую базу — хороший способ «переупаковать» данные и убедиться, что структура читается целиком. Если выгрузка проходит без ошибок, это дополнительное подтверждение целостности. Кроме того, dt-файл послужит свежей резервной копией после всех работ.