Администрирование · 11 мин
Ошибка СУБД в 1С: причины и как исправить
Почему 1С выдаёт ошибку СУБД: повреждение базы, блокировки, диск, сеть. Пошаговая диагностика, chdbfl, тестирование и исправление, восстановление из копии.
Сообщение «Ошибка СУБД» в 1С появляется, когда платформа не может выполнить запрос к базе данных: таблица повреждена, соединение с сервером прервано, закончилось место на диске или запрос заблокирован другой транзакцией. Текст ошибки обычно содержит код и пояснение — именно они указывают настоящую причину, а не сама фраза «Ошибка СУБД».
Порядок действий зависит от типа базы. Файловая база (каталог с файлом 1Cv8.1CD) чаще всего страдает от повреждения файла при отключении питания или сбое сети. Клиент-серверная база (MS SQL, PostgreSQL) чаще падает из-за нехватки места, переполненного журнала транзакций, блокировок или проблем с самим сервером СУБД.
Прежде чем что-либо исправлять, зафиксируйте точный текст ошибки и сделайте резервную копию базы в текущем состоянии. Любые восстановительные операции без копии могут превратить частично читаемую базу в полностью нечитаемую.
Как прочитать текст ошибки и понять её тип
Платформа 1С выводит ошибку СУБД вместе с техническим описанием. Именно вторая часть сообщения — после фразы «по причине» — содержит диагностическую информацию. Сфотографируйте или скопируйте её целиком, включая коды в квадратных скобках.
Типичные варианты формулировок указывают на разные причины:
- «Файл базы данных повреждён» или ссылка на файл 1Cv8.1CD — физическое повреждение файловой базы.
- «Could not continue scan with NOLOCK» или упоминание MS SQL Server — проблема на стороне SQL-сервера: повреждение страниц данных или нехватка ресурсов.
- «Lock request time out period exceeded» — запрос не дождался снятия блокировки, установленной другим сеансом.
- «Transaction log is full» — переполнен журнал транзакций базы на SQL-сервере.
- «Недостаточно места на диске» — закончилось место на диске с базой или с временными файлами.
- «Соединение с сервером разорвано» — сетевой сбой между клиентом и сервером 1С или СУБД.
Проверка диска, сети и доступности сервера
Значительная часть «ошибок СУБД» — это не повреждение данных, а инфраструктурные проблемы. Их нужно исключить в первую очередь, потому что проверка занимает минуты, а лечение несуществующего повреждения базы — часы и риск потери данных.
Проверьте свободное место на всех дисках, участвующих в работе базы: диск с файлом базы или файлами SQL-данных, диск с журналом транзакций, системный диск с временными файлами. Для файловой базы, размещённой на сетевом ресурсе, проверьте стабильность сети: разрывы при копировании больших файлов — тревожный признак.
Для клиент-серверного варианта убедитесь, что служба СУБД запущена, сервер 1С видит её по сети, а в логах СУБД нет критических сообщений. Также проверьте, не перезагружался ли сервер в момент ошибки — аварийная перезагрузка часто совпадает по времени с жалобами пользователей.
Как проверить инфраструктуру
Есть заметный запас свободного места
Диск заполнен почти полностью или место закончилось
Служба запущена, сервер отвечает по сети
Служба остановлена или сервер недоступен
Копирование больших файлов проходит без разрывов
Копирование прерывается, скорость скачет
Нет ошибок диска и аварийных перезагрузок
Есть ошибки контроллера диска или внезапные перезагрузки
Исправление файловой базы: chdbfl и тестирование
Если диагностика подтвердила повреждение файловой базы, сначала сделайте копию всего каталога базы — простым копированием при остановленной работе пользователей. Только после этого переходите к восстановлению.
Первый инструмент — утилита chdbfl.exe из каталога установки платформы 1С (папка bin соответствующей версии). Она проверяет физическую целостность файла 1Cv8.1CD. Запустите утилиту, укажите путь к файлу базы, отметьте опцию исправления обнаруженных ошибок и дождитесь завершения проверки. На больших базах это занимает продолжительное время.
Второй шаг — «Тестирование и исправление» в конфигураторе: меню «Администрирование» → «Тестирование и исправление». Отметьте пункты «Проверка логической целостности информационной базы» и «Проверка ссылочной целостности», выберите вариант «Тестирование и исправление». Этот этап устраняет логические ошибки: битые ссылки, некорректные записи в таблицах.
- 1Завершите работу всех пользователей с базой
- 2Скопируйте каталог базы в резервное место
- 3Запустите chdbfl.exe из каталога платформы и проверьте файл 1Cv8.1CD с исправлением ошибок
- 4Откройте базу в конфигураторе и выполните «Тестирование и исправление»
- 5Проверьте работу базы: откройте проблемные документы, сформируйте отчёты
- 6Если ошибки остались — восстановите базу из последней рабочей резервной копии
Ошибки клиент-серверной базы: SQL и блокировки
В клиент-серверном варианте платформа 1С передаёт запросы в MS SQL Server или PostgreSQL, и ошибка СУБД означает, что запрос не выполнился на стороне сервера. Основные источники проблем: переполненный журнал транзакций, повреждённые страницы данных, длительные блокировки и нехватка ресурсов.
Переполненный журнал транзакций — частая причина на базах с полной моделью восстановления без регулярного резервного копирования журнала. Признак — ошибка вида «The transaction log for database is full». Решение: настроить регулярный бэкап журнала либо, если точечное восстановление не требуется, перевести базу на простую модель восстановления и сжать файл журнала.
Блокировки проявляются как ошибки тайм-аута или взаимоблокировки (deadlock). Один сеанс удерживает ресурс, другой ждёт его освобождения и отваливается по тайм-ауту. Причина обычно в длительных транзакциях: массовые проведения, обмены данными, тяжёлые отчёты во время работы пользователей. Для диагностики используйте технологический журнал 1С и штатные средства мониторинга СУБД.
Когда проблема в оборудовании
Повторяющиеся ошибки СУБД, которые возвращаются после успешного восстановления, почти всегда указывают на неисправное оборудование. Данные портятся не сами по себе — их портит сбойный диск, нестабильная память или сетевое оборудование.
Проверьте состояние дисков штатными средствами диагностики (SMART-показатели, журналы контроллера). Ошибки контроллера диска в системном журнале сервера — прямое указание на замену оборудования. Для файловых баз, размещённых на сетевых папках, источником повреждений часто оказываются сетевые разрывы: базу нельзя держать на нестабильном соединении.
Отдельный сценарий — внезапное отключение питания сервера без источника бесперебойного питания. Незавершённые транзакции в этот момент оставляют базу в неконсистентном состоянии. Если ошибки СУБД начались после аварийного отключения, проверка целостности базы обязательна, даже если внешне всё работает.
Профилактика: как не допустить повторения
Главная защита от ошибок СУБД — регулярные резервные копии и контроль их работоспособности. Копия, которую ни разу не пробовали восстановить, не считается надёжной: периодически разворачивайте бэкап на тестовом сервере и проверяйте, что база открывается.
Для клиент-серверных баз настройте регламентные задания СУБД: резервное копирование, обновление статистики, перестроение индексов, контроль размера журнала транзакций. Для файловых баз — ежедневное копирование файла базы вне рабочего времени и периодическая проверка chdbfl.
Организационные меры не менее важны: источник бесперебойного питания для сервера, мониторинг свободного места на дисках, разнесение тяжёлых операций (обменов, закрытия месяца) на нерабочие часы. Эти шаги устраняют большинство сценариев, приводящих к ошибкам СУБД.
Как выбрать действие
Что важно запомнить
Ошибка СУБД — это симптом: читайте полный текст и определяйте тип причины. Сначала исключите диск, сеть и доступность сервера, затем лечите базу: файловую — через chdbfl и тестирование-исправление, серверную — через логи СУБД, работу с журналом транзакций и блокировками. Любые действия — только после резервной копии, а повторяющиеся ошибки — повод проверить оборудование.
Частые вопросы
Можно ли продолжать работать, если ошибка СУБД появляется редко?
Нежелательно. Редкие ошибки повреждения данных имеют свойство накапливаться: каждая новая запись в повреждённую область усугубляет проблему. При первом же повторяющемся сообщении сделайте копию и проведите проверку целостности базы.
Чем отличается chdbfl от тестирования и исправления в конфигураторе?
chdbfl проверяет физическую структуру файла базы — целостность страниц и таблиц на низком уровне. Тестирование и исправление работает с логикой данных: битыми ссылками, некорректными записями, соответствием таблиц конфигурации. Обычно их применяют последовательно: сначала chdbfl, затем тестирование.
Ошибка появляется только у одного пользователя — база повреждена?
Скорее всего, нет. Если ошибка возникает у конкретного пользователя, проверьте его клиент: версию платформы, кэш метаданных (помогает очистка кэша), сетевое подключение его компьютера и права доступа. Повреждение базы обычно проявляется у всех пользователей или при обращении к конкретным данным.
Поможет ли переустановка платформы 1С при ошибке СУБД?
Почти никогда. Ошибка СУБД относится к данным или инфраструктуре, а не к установленной платформе. Переустановка оправдана только если ошибка вызвана повреждением самих файлов платформы, что встречается редко и имеет другие симптомы — сбои при запуске любых баз.
Как понять, что пора восстанавливать базу из резервной копии?
Если chdbfl и тестирование-исправление завершились с ошибками, которые не устраняются, если база не открывается после восстановительных процедур или если объём повреждений велик — восстановление из копии быстрее и надёжнее дальнейших попыток лечения. После восстановления потребуется ввести данные, созданные после даты копии.
Опасно ли запускать тестирование и исправление на большой базе?
Сама процедура безопасна при наличии резервной копии, но требует монопольного доступа и может длиться несколько часов. Планируйте её на нерабочее время и предупредите пользователей. Опасны лишь режимы с удалением данных — их выбирают осознанно и только понимая последствия.