Администрирование · 12 мин
Ошибка СУБД в 1С: как найти причину и исправить
Разбираем типичные ошибки СУБД в 1С: повреждение таблиц, конфликты блокировок, сбои PostgreSQL и MS SQL. Пошаговые инструкции по диагностике и восстановлению.
Ошибка СУБД в 1С — одно из самых тревожных сообщений для бухгалтера и администратора: работа базы внезапно останавливается, документы не проводятся, а пользователи не могут войти в систему. За общей формулировкой «Ошибка СУБД» скрываются десятки разных проблем — от повреждённой таблицы до переполненного диска на сервере баз данных.
Хорошая новость: большинство таких ошибок диагностируются и устраняются без потери данных, если действовать последовательно и не спешить с радикальными мерами. Плохая новость: безрезервное восстановление некоторых повреждений невозможно, поэтому первое действие при любой ошибке СУБД — проверить наличие свежей копии базы.
Материал ориентирован на типичные ситуации в файловых и клиент-серверных базах 1С (MS SQL Server, PostgreSQL). Отдельно разобраны блокировки, повреждения файлов и ошибки на уровне самой СУБД.
Как распознать тип ошибки СУБД по её тексту
Формулировка сообщения — главный ключ к диагностике. «Ошибка СУБД: файл базы данных повреждён» со ссылкой на путь к 1Cv8.1CD указывает на файловый вариант и физическое повреждение таблицы. Сообщения с упоминанием Microsoft SQL Server, PostgreSQL или кодов вроде «could not read block» говорят о проблеме на стороне сервера баз данных.
Отдельная группа — ошибки блокировок: «Конфликт блокировок при выполнении транзакции», «Превышено время ожидания блокировки». Здесь данные не повреждены, просто одна транзакция мешает другой. Путать это с разрушением базы нельзя: восстановление из копии тут не поможет и не нужно.
Третья группа — ошибки доступа и окружения: недостаток прав у службы сервера 1С, переполненный диск, разрыв сети между сервером 1С и сервером СУБД, сбой службы СУБД после обновления Windows. Такие проблемы решаются настройкой инфраструктуры, а не лечением базы.
Путь к 1Cv8.1CD в тексте ошибки
Повторяемость ошибки, время её возникновения
Доступность сервера, журналы СУБД
Свободное место на всех томах сервера
Первые действия до начала восстановления
Главное правило: любые восстановительные операции выполняются только после создания копии текущего состояния базы — даже если она повреждена. Утилиты исправления изменяют данные необратимо, и при неудаче откатиться будет не к чему. Для файловой базы достаточно скопировать файл 1Cv8.1CD средствами ОС, для клиент-серверной — сделать backup средствами СУБД.
Перед копированием завершите все сеансы пользователей и остановите фоновые задания. Копирование файла 1Cv8.1CD при открытых соединениях может дать нецелостную копию. В клиент-серверном варианте проверьте, что регламентные задания сервера 1С отключены на время работ.
Зафиксируйте точный текст ошибки, время её появления и действия, которые ей предшествовали: отключение электричества, аварийное завершение сервера, обновление платформы, заполнение диска. Эта информация сильно сужает круг причин и помогает не лечить симптом вместо причины.
Исправление файловой базы: chdbfl и тестирование в конфигураторе
Для файловых баз первый инструмент — утилита chdbfl.exe из каталога bin установленной платформы 1С. Запустите её, укажите путь к файлу 1Cv8.1CD, включите флаг «Исправлять обнаруженные ошибки» и нажмите «Исполнить». Утилита проверяет физическую целостность таблиц и исправляет повреждения на низком уровне, не затрагивая логику данных.
После chdbfl откройте базу в конфигураторе и выполните «Администрирование → Тестирование и исправление». Рекомендуемый стартовый набор: реиндексация таблиц, проверка логической целостности, проверка ссылочной целостности. Пункты «Очистка ссылок» и «Удаление объектов» при обнаружении битых ссылок включайте осознанно: очистка обнуляет ссылки, удаление убирает сами объекты.
Если база не открывается даже в конфигураторе, остаётся вариант выгрузки через конфигуратор (если открывается), восстановление из резервной копии или перенос данных в чистую базу обработкой «Выгрузка и загрузка данных XML». При тяжёлых повреждениях chdbfl, когда не читается заголовок файла, самостоятельное восстановление обычно невозможно — нужна копия.
- 1Завершите все сеансы и скопируйте файл 1Cv8.1CD в отдельный каталог
- 2Запустите chdbfl.exe из каталога bin платформы, укажите файл базы, включите исправление ошибок
- 3Откройте базу в конфигураторе и выполните тестирование и исправление с реиндексацией и проверкой целостности
- 4Войдите в режиме предприятия и проверьте проведение документов, построение отчётов и журналы
- 5Включите регулярное резервное копирование и проверку копий, если оно не было настроено
Ошибки на стороне сервера СУБД: MS SQL и PostgreSQL
В клиент-серверном варианте диагностика начинается с журналов: журнал регистрации 1С, технологический журнал, журнал ошибок самой СУБД (ERRORLOG у MS SQL, лог PostgreSQL). По ним видно, что именно произошло: обрыв соединения, нехватка памяти, повреждение страниц данных, переполнение журнала транзакций.
Типичные сценарии для MS SQL: переполнение файла журнала транзакций при полной модели восстановления без регулярного бэкапа журнала, повреждение страниц (проверяется командой DBCC CHECKDB), нехватка места под tempdb. Для PostgreSQL распространены ошибки чтения блоков после аварийного выключения сервера, переполнение диска с WAL-файлами и проблемы, вызванные несовместимой сборкой СУБД.
Важно: для 1С требуются специально подготовленные сборки PostgreSQL. Установка «ванильного» PostgreSQL с официального сайта часто приводит к ошибкам при создании или работе базы. Используйте сборку, рекомендованную для работы с 1С, и проверяйте параметры её конфигурации.
DBCC CHECKDB (N'ИмяБазы') WITH NO_INFOMSGS;Если проверка целостности на уровне СУБД показывает повреждения, варианты такие: восстановление из последнего исправного backup, ремонт с допустимой потерей данных (REPAIR_ALLOW_DATA_LOSS — крайняя мера, ведущая к утрате части данных) или создание новой базы и перенос данных выгрузкой из конфигуратора. Выбор зависит от свежести копий и объёма повреждений.
Конфликты блокировок и таймауты транзакций
Ошибка «Конфликт блокировок при выполнении транзакции» означает, что два сеанса пытаются изменить одни и те же данные одновременно, и один из них прерван по таймауту. Данные при этом не портятся — это штатный защитный механизм. Проблемой она становится, когда повторяется систематически и мешает работе.
Частые причины: массовая загрузка данных обменами в рабочее время, длительные отчёты, блокирующие таблицы, неоптимальный код проведения документов, работа большого числа пользователей с одним набором данных (например, все менеджеры бьют по одному регистру остатков). В файловых базах блокировки особенно ощутимы из-за ограниченной параллельности.
Что делать: определить взаимоблокирующие процессы (в MS SQL — через Activity Monitor или системные представления, в 1С — через консоль кластера и технологический журнал с событием TDEADLOCK), развести конфликтующие операции по времени, сократить длительность транзакций, при необходимости включить управляемые блокировки и версионирование чтения на уровне СУБД (для MS SQL — read committed snapshot).
Как выбрать действие
Профилактика: как снизить риск повторения ошибки
Большинство повреждений файловых баз связано с внешними факторами: отключение питания, сбои дисковой подсистемы, работа базы по сети через нестабильное соединение, антивирус, проверяющий файл 1Cv8.1CD «на лету». Исключите каталог базы из сканирования антивируса, обеспечьте бесперебойное питание сервера и не размещайте файл базы на сетевых дисках с нестабильным доступом.
Настройте автоматическое резервное копирование с регулярной проверкой восстановления: копия, которую никогда не проверяли, может оказаться нерабочей. Для клиент-серверных баз контролируйте свободное место на дисках с данными и журналами, следите за ростом базы и выполняйте регламентное обслуживание СУБД — обновление статистики, перестроение индексов, очистку журналов.
Своевременно обновляйте платформу 1С: часть ошибок СУБД вызвана известными дефектами платформы, исправленными в свежих релизах. Перед обновлением проверяйте совместимость версий платформы и СУБД.
Проверка результата после восстановления
После исправления недостаточно того, что база просто открывается. Проверьте ключевые операции: проведение документов за последний рабочий период, формирование основных отчётов (оборотно-сальдовая ведомость, отчёты по остаткам), работу обменов и регламентных заданий. Сверьте итоговые остатки с данными до сбоя, если есть чем сверить.
Просмотрите журнал регистрации на предмет новых ошибок и повторите тестирование и исправление без включённого исправления — оно должно завершиться без выявленных проблем. Если логические ошибки остались, но база работает, зафиксируйте их перечень и план устранения, не оставляйте это «на потом».
Как проверить результат
Завершается без сообщений об ошибках
Повторно находятся те же повреждения
Документы проводятся без ошибок СУБД
Ошибка возвращается на тех же операциях
Остатки сходятся с данными до сбоя
Расхождения в итогах, пустые регистры
Нет новых ошибок СУБД за период наблюдения
Ошибки повторяются с той же причиной
Частые вопросы
Можно ли исправить ошибку СУБД без конфигуратора?
Частично да: chdbfl запускается отдельно от конфигуратора и исправляет физические повреждения файловой базы. Но проверка логической и ссылочной целостности возможна только через тестирование и исправление в конфигураторе, поэтому полноценное восстановление без него не выполнить.
Файловая база повреждается регулярно — в чём причина?
Почти всегда это внешние факторы: работа базы по сети с обрывами соединения, отключения питания, антивирус, блокирующий файл во время записи, неисправный диск. Если база активно используется несколькими пользователями, разумное решение — переход на клиент-серверный вариант, где целостность обеспечивает СУБД.
Чем отличается восстановление из копии от тестирования и исправления?
Тестирование и исправление лечит текущую базу, изменяя данные, и не гарантирует результат. Восстановление из копии возвращает базу к состоянию на момент копирования — надёжно, но данные, введённые после копии, будут потеряны и их придётся вносить заново.
Что делать, если резервной копии нет, а база не открывается?
Сохраните файл базы как есть и попробуйте chdbfl — иногда это единственный шанс. Если не помогло, остаются специализированные средства восстановления формата 1CD или обращение к специалистам по восстановлению данных. Гарантий здесь нет, поэтому после инцидента обязательно настройте копирование.
Ошибка блокировок мешает работе каждый день — это повреждение базы?
Нет, блокировки не связаны с повреждением данных. Это конкуренция транзакций, которую решают настройкой: разнесение обменов и тяжёлых отчётов по времени, оптимизация кода, включение версионирования чтения на уровне СУБД. Восстановление из копии здесь бесполезно.
Нужно ли после восстановления что-то менять в настройках?
Да, иначе ситуация повторится. Как минимум: настройте автоматические копии с проверкой восстановления, исключите каталог базы из антивируса, устраните причину сбоя (питание, диск, сеть), контролируйте свободное место на сервере СУБД.
Что важно запомнить
Ошибка СУБД — это симптом, а не диагноз: сначала определите её тип по тексту и журналам. Перед любым исправлением сделайте копию базы. Файловые базы лечатся chdbfl и тестированием в конфигураторе, клиент-серверные — средствами СУБД и восстановлением из backup. Блокировки устраняются настройкой, а не восстановлением. После инцидента обязательно настройте регулярное резервное копирование и устраните первопричину сбоя.