Администрирование · 13 мин
Ошибка СУБД в 1С: в чём причина и как её исправить
Почему возникает ошибка СУБД в 1С: повреждение базы, диски, права, блокировки. Пошаговая диагностика, chdbfl, тестирование и исправление, восстановление из копии.
Ошибка СУБД в 1С — одно из самых неприятных сообщений для пользователя и администратора: работа останавливается, документы не проводятся, а в худшем случае база не открывается вовсе. За этой формулировкой скрывается не одна конкретная неисправность, а целый класс проблем — от банального переполнения диска до физического повреждения файла данных. Правильная диагностика здесь важнее скорости: поспешные действия (например, запуск тестирования без резервной копии) способны усугубить повреждение.
Текст самой ошибки — первый источник информации. Формулировки вроде «Ошибка СУБД: файл базы данных поврежден», «could not continue scan with NOLOCK», «deadlock victim» или «нет свободного места на диске» указывают на разные причины и требуют разных действий. Поэтому первый шаг — зафиксировать полный текст сообщения, скриншот и обстоятельства: что делал пользователь, сколько человек работало, был ли сбой электропитания.
Ниже разобраны типичные причины ошибок СУБД в файловом и клиент-серверном вариантах 1С, безопасный порядок диагностики и способы исправления — от утилиты chdbfl до восстановления из резервной копии.
Что скрывается за формулировкой «Ошибка СУБД»
СУБД — это система управления базой данных, которая физически хранит и обрабатывает данные 1С. В файловом варианте её роль выполняет встроенный движок платформы, работающий с файлом 1Cv8.1CD. В клиент-серверном — внешняя СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2 или Oracle Database. Когда платформа не может выполнить операцию чтения или записи, пользователь видит общее сообщение «Ошибка СУБД» с уточняющим текстом от конкретной СУБД.
Принципиальное различие: в файловом варианте ошибка почти всегда локальна (проблема с файлом, диском или сетевым доступом к нему), а в клиент-серверном источник может находиться на трёх уровнях — сервер 1С, сервер СУБД и сеть между ними. Поэтому диагностика клиент-серверной базы начинается с журналов: технологического журнала 1С, журнала ошибок SQL Server (ERRORLOG) или логов PostgreSQL.
Типичные причины ошибки СУБД
Чаще всего виновником оказывается одна из перечисленных ниже причин. Их стоит проверять в первую очередь, прежде чем запускать ресурсоёмкие процедуры восстановления.
- Повреждение файла базы данных. Возникает при внезапном отключении питания, аварийном завершении процесса 1С, сбоях диска или обрыве сетевого соединения в момент записи. Типичный признак — ошибка «файл базы данных поврежден» со ссылкой на конкретную таблицу.
- Нехватка места на диске. СУБД не может расширить файл данных или журнал транзакций. Для SQL Server характерны ошибки о невозможности выделить место; для файловой базы — сбои записи при полном диске.
- Проблемы сети и прав доступа. Файловая база на сетевом ресурсе чувствительна к обрывам соединения; для клиент-серверной критичны права учётной записи службы СУБД на каталоги данных и доступность сервера по сети.
- Блокировки и взаимоблокировки. Ошибка «Конфликт блокировок при выполнении транзакции» или «deadlock victim» возникает при конкурентной работе пользователей, длительных транзакциях и регламентных заданиях, пересекающихся с работой пользователей.
- Ошибки самой СУБД или драйверов. Несовместимые версии, некорректные настройки, сбои службы SQL Server, повреждение системных баз.
- Антивирусное ПО. Антивирус, сканирующий файлы базы в реальном времени, может блокировать запись и провоцировать повреждения — каталоги баз данных нужно добавлять в исключения.
Проверьте, запущена ли служба СУБД; для файловой базы — доступность и размер файла 1Cv8.1CD
Очистите кэш 1С на проблемном ПК и проверьте сетевое соединение
Проверьте место на диске, журналы СУБД, состояние сервера
Зафиксируйте таблицу из текста ошибки, проверьте блокировки в консоли кластера
Первые действия при появлении ошибки
До любых восстановительных процедур сделайте копию базы в текущем состоянии — даже повреждённой. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей; для клиент-серверной — выполнить backup средствами СУБД или скопировать файлы данных при остановленной службе. Эта копия — страховка на случай, если тестирование и исправление ухудшит ситуацию, и исходный материал для специализированных средств восстановления.
Далее проверьте базовую инфраструктуру: свободное место на всех дисках, где лежат данные и журналы; состояние служб SQL Server / PostgreSQL; доступность сервера по сети; журнал событий Windows на предмет ошибок диска. Немалая доля «ошибок СУБД» на практике оказывается переполненным диском или остановленной службой — и решается за минуты.
Диагностика файловой базы: chdbfl и тестирование
Для файловых баз платформа поставляет утилиту chdbfl.exe — она находится в каталоге bin установленной версии платформы. Утилита проверяет физическую целостность файла 1Cv8.1CD и умеет исправлять ряд повреждений. Запускать её нужно при закрытой базе, указав путь к файлу и включив опцию исправления ошибок. Процесс на больших базах занимает заметное время.
После chdbfl (или вместо него, если повреждений не найдено) выполните «Тестирование и исправление» из конфигуратора: меню Администрирование → Тестирование и исправление. Рекомендуемый порядок — сначала «Проверка физической целостности», затем «Проверка ссылочной целостности» в режиме «Не изменять», чтобы оценить масштаб проблем. Только поняв, какие объекты затронуты, включайте режимы исправления.
- 1Завершите работу всех пользователей и скопируйте файл 1Cv8.1CD в отдельный каталог
- 2Проверьте свободное место на диске и состояние самого диска (chkdsk, SMART)
- 3Запустите chdbfl.exe из каталога платформы, укажите файл базы, включите исправление ошибок
- 4Откройте базу в конфигураторе и выполните тестирование физической целостности
- 5Проверьте ссылочную целостность сначала в режиме «Не изменять», затем исправьте найденные ошибки
- 6Войдите в базу в пользовательском режиме и проверьте критичные данные: обороты, остатки, последние документы
Диагностика клиент-серверной базы
В клиент-серверном варианте начинайте с журналов СУБД. Для MS SQL Server откройте ERRORLOG и журнал ошибок в Management Studio: там видны повреждённые страницы, проблемы с диском и взаимоблокировки. Проверку целостности конкретной базы выполняет команда DBCC CHECKDB — сначала в режиме только чтения, чтобы получить список проблем без риска.
Для PostgreSQL смотрите логи сервера (каталог log или journald) и проверяйте сообщения о corrupted pages и ошибках ввода-вывода. Учтите: восстановительные операции вроде DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS или ручных правок системных каталогов потенциально удаляют данные — их выполняют только после полного backup и при понимании последствий.
DBCC CHECKDB (N'MyBase1C') WITH NO_INFOMSGS, ALL_ERRORMSGS;Отдельный частый случай — блокировки. Если ошибка возникает периодически при одновременной работе пользователей, проверьте консоль кластера серверов 1С (сеансы, соединения, блокировки) и настройки СУБД. Часто помогает включение управляемых блокировок в конфигурации, перевод базы SQL Server в режим READ_COMMITTED_SNAPSHOT и разнесение регламентных заданий по времени с минимальным пересечением с пользовательской активностью.
Когда восстановить нельзя: откат на резервную копию
Если ни chdbfl, ни тестирование, ни средства СУБД не дают работоспособную базу, корректный выход — восстановление из последней резервной копии с последующим переносом данных, введённых после её создания. Для файловой базы это замена файла 1Cv8.1CD копией из архива; для клиент-серверной — RESTORE из backup в SQL Server или pg_restore для PostgreSQL.
Потерянный интервал восстанавливают вручную: по бумажным документам, выгрузкам обмена, данным смежных систем (банк-клиент, касса, сайт). Чтобы минимизировать такие потери, резервные копии должны создаваться ежедневно и автоматически, а их работоспособность — периодически проверяться тестовым восстановлением. Копия, которую ни разу не пытались развернуть, не считается надёжной.
Способы восстановления: что выбрать
Подходит для файловых баз с локальными повреждениями. Ограничение: не помогает при серьёзной порче файла и может удалить повреждённые записи
Для клиент-серверных баз при повреждении страниц данных. Ограничение: режимы с repair допускают потерю данных, требуют backup и квалификации
Самый надёжный вариант при тяжёлых повреждениях. Ограничение: теряются данные, введённые после создания копии
Помогает, когда база открывается, но содержит ошибки. Ограничение: при повреждённых таблицах выгрузка может обрываться
Профилактика: как снизить риск повторения
Большинство повреждений баз предотвратимы организационными мерами. Установите источник бесперебойного питания на сервер и компьютеры с файловыми базами, настройте корректное завершение работы при разряде батареи. Исключите каталоги баз данных и журналов из проверки антивируса в реальном времени. Следите за свободным местом на дисках с запасом — файлам данных и журналам транзакций нужно пространство для роста.
Для файловых баз ограничьте число одновременных пользователей разумным пределом и не размещайте базу на ненадёжных сетевых ресурсах — при росте нагрузки переходите на клиент-серверный вариант. Настройте автоматические резервные копии (ежедневные полные плюс журналы транзакций для SQL Server) и регламентное обслуживание СУБД: обновление статистики, перестроение индексов, контроль целостности по расписанию.
Как проверить, что база восстановлена
База открывается в конфигураторе и пользовательском режиме без ошибок
Ошибка СУБД при входе или при открытии отдельных списков
Физическая и ссылочная проверки завершаются без ошибок
Остались сообщения о битых ссылках или повреждённых таблицах
Обороты и остатки сходятся с последними известными значениями, последние документы на месте
Расхождения в итогах, пропавшие документы за последние дни
Несколько пользователей одновременно проводят документы без ошибок блокировок
Ошибки возвращаются при одновременной работе
Частые вопросы
Можно ли исправить ошибку СУБД без конфигуратора?
Частично. Проверку файловой базы утилитой chdbfl и восстановление из резервной копии можно выполнить без конфигуратора. Но тестирование ссылочной целостности, выгрузка в dt и анализ структуры базы требуют конфигуратора, поэтому для полноценного восстановления он нужен.
Ошибка появляется только у одного пользователя — база повреждена?
Скорее всего, нет. Локальная ошибка у одного рабочего места обычно указывает на повреждённый кэш метаданных на клиенте, проблемы с сетью этого ПК или устаревшую версию платформы. Начните с очистки кэша (удаление базы из списка и повторное добавление) и проверки версии платформы.
Что означает «Конфликт блокировок при выполнении транзакции»?
Это не повреждение данных, а конкуренция за ресурсы: два сеанса пытаются изменить одни и те же записи. Разовая ошибка решается повтором операции. Если конфликты регулярны — проверяйте расписание регламентных заданий, режим управляемых блокировок в конфигурации и настройки изоляции транзакций в СУБД.
Поможет ли переустановка платформы 1С?
Почти никогда. Ошибка СУБД связана с данными или серверной инфраструктурой, а не с клиентскими файлами платформы. Переустановка оправдана только если повреждены сами исполняемые файлы платформы, что проявляется иначе — сбоями при запуске программы, а не ошибками СУБД.
Как понять, что дело именно в диске, а не в базе?
Проверьте журнал событий Windows на ошибки дисковой подсистемы, SMART-статус диска и выполните chkdsk. Косвенный признак — ошибки СУБД появляются на разных базах одного сервера или сопровождаются зависаниями системы. В этом случае сначала переносите данные на исправный носитель, потом восстанавливайте базы.
База после восстановления открывается, но итоги не сходятся — что делать?
Это признак того, что при исправлении были удалены повреждённые записи. Восстановите базу из резервной копии в отдельный каталог, сравните данные и перенесите недостающие документы вручную или через выгрузку. После чего пересчитайте итоги по регистрам штатными средствами.
Что важно запомнить
Ошибка СУБД — это симптом, а не диагноз: причину ищите в тексте сообщения, журналах и состоянии дисков. Перед любыми исправлениями делайте копию базы, действуйте от простого к сложному (диск → службы → chdbfl/тестирование → средства СУБД), а при тяжёлых повреждениях не гонитесь за «лечением» — восстанавливайте резервную копию. Регулярные проверенные бэкапы и профилактика (ИБП, исключения антивируса, контроль дискового пространства) устраняют большинство причин таких ошибок.