Как проверить базу данных 1С на ошибки

Ошибки в базе 1С проявляются по-разному: программа вылетает при открытии документа, отчёт показывает неверные итоги, проведение завершается с сообщением о нарушении целостности. Игнорировать такие симптомы нельзя — со временем повреждение распространяется, и база может перестать открываться совсем. Проверка и исправление ошибок — штатная процедура, которую администратор может выполнить встроенными средствами платформы.

Инструмент зависит от формата базы. Для файловых баз используются утилита chdbfl.exe и режим «Тестирование и исправление» в конфигураторе. Для клиент-серверных баз (MS SQL, PostgreSQL) основная проверка выполняется средствами СУБД, а конфигуратор дополняет её логическими тестами. Ниже разобраны оба сценария с конкретными действиями и ограничениями.

Перед любыми действиями с исправлением обязательно сделайте резервную копию. Тестирование в режиме исправления изменяет данные безвозвратно: битые записи могут быть удалены, а не восстановлены. Копия — единственный способ откатиться, если результат исправления окажется хуже исходной проблемы.

Какие ошибки бывают в базе 1С и как их распознать

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

Логические ошибки — это нарушения целостности данных при физически исправном хранилище: «битые» ссылки на удалённые объекты, дубли записей в регистрах, рассинхронизация итогов, некорректные значения в служебных полях. Часто появляются после нештатного завершения обменов, прямого редактирования данных, ошибок в самописных доработках.

Подготовка: резервная копия и монопольный доступ

Первый шаг — выгрузка базы через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Полученный файл .dt — полноценная копия, из которой базу можно развернуть заново. Для файловой базы дополнительно можно скопировать сам файл 1Cv8.1CD на другой носитель. Для клиент-серверной — сделать backup средствами СУБД.

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

Проверка файловой базы утилитой chdbfl.exe

Утилита chdbfl.exe входит в состав платформы и лежит в каталоге bin установленной версии (например, C:\Program Files\1cv8\<номер версии>\bin\). Она проверяет физическую целостность файла 1Cv8.1CD — то, что конфигуратор проверить не может, потому что сам пользуется этим файлом.

Порядок работы: закройте все сеансы 1С, запустите chdbfl.exe, укажите путь к файлу базы, установите флаг «Исправлять обнаруженные ошибки» только если уверены в наличии копии, и нажмите «Выполнить». По завершении утилита покажет список найденных и исправленных повреждений.

1. 1
   Сделайте копию файла 1Cv8.1CD в отдельную папку
2. 2
   Завершите все сеансы работы с базой
3. 3
   Запустите chdbfl.exe из каталога bin платформы
4. 4
   Укажите путь к файлу базы и запустите проверку
5. 5
   Изучите отчёт: какие таблицы повреждены и исправлены
6. 6
   Откройте базу в конфигураторе и выполните тестирование и исправление

Важно понимать ограничение: chdbfl исправляет физическую структуру, но не логику данных. После неё обязательно выполните «Тестирование и исправление» в конфигураторе — только связка двух инструментов даёт полную проверку файловой базы.

Тестирование и исправление в конфигураторе

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

Какие проверки выбрать

«Реиндексация таблиц» перестраивает индексы — помогает при ошибках вида «Ошибка формата потока» и при падении производительности. «Проверка логической целостности» находит битые ссылки, дубли и нарушения внутренних связей — основной тест при логических ошибках. «Проверка ссылочной целостности» ищет объекты с несуществующими ссылками; при исправлении такие объекты могут быть очищены или удалены.

«Пересчёт итогов» восстанавливает итоги регистров — нужен при расхождениях в отчётах. «Сжатие таблиц» уменьшает размер файла после массовых удалений. «Реструктуризация таблиц» пересоздаёт таблицы заново — самый тяжёлый и долгий тест, применяется при серьёзных повреждениях отдельных таблиц.

Как оценить результат

По завершении конфигуратор выводит протокол: какие ошибки найдены, какие исправлены, какие требуют вмешательства. Не все сообщения критичны — например, записи о частично удалённых объектах часто означают, что платформа уже очистила мусор. Тревожный признак — повторное появление тех же ошибок при повторном тестировании: это указывает на аппаратную проблему диска или сети.

Проверка клиент-серверной базы

В клиент-серверном варианте физическую целостность проверяют средствами СУБД. Для MS SQL Server это команда DBCC CHECKDB, выполняемая в контексте нужной базы. Она проверяет страницы данных, индексы и служебные структуры. Для PostgreSQL используются средства диагностики кластера и анализ логов на предмет ошибок чтения страниц.

DBCC CHECKDB (N'ИмяБазы') WITH NO_INFOMSGS;

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

Если стандартные средства не помогли

Когда тестирование зависает, падает с ошибкой или ошибки возвращаются после исправления, остаются три пути. Первый — выгрузка базы в .dt и загрузка в новую пустую базу: при загрузке структуры пересоздаются, и часть повреждений уходит. Второй — восстановление из последней рабочей резервной копии с последующим ручным внесением данных за потерянный период. Третий — проверка оборудования: памяти сервера, диска, сетевого пути к файловой базе.

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

Профилактика: как реже сталкиваться с повреждениями

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

Для файловых баз с несколькими пользователями используйте веб-сервер или сервер 1С вместо доступа по сетевой папке — это резко снижает риск повреждений. Обеспечьте бесперебойное питание серверов и достаточный запас места на диске. Раз в несколько месяцев запускайте тестирование в режиме диагностики — так вы обнаружите проблему до того, как она станет критичной.

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