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

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

Хорошая новость в том, что платформа 1С содержит встроенные средства диагностики, а для файловых баз существует отдельная утилита проверки физической целостности. Большинство типовых повреждений устраняется штатными инструментами без привлечения сторонних программ. Главное — действовать в правильной последовательности и обязательно иметь резервную копию до начала любых исправлений.

Ниже разобран практический порядок проверки: от анализа симптомов и журнала регистрации до тестирования и исправления, работы с утилитой chdbfl.exe и контроля результатов. Материал подходит для файловых и клиент-серверных баз на платформе 1С:Предприятие 8.

Признаки, что базу нужно проверить

Не каждый сбой говорит о повреждении базы, но ряд симптомов — прямое указание на диагностику. К ним относятся аварийное завершение работы с сообщением «Ошибка формата потока», «Ошибка СУБД» или «Файл базы данных поврежден», невозможность провести конкретный документ при корректном заполнении, пропажа записей из списков, неверные остатки в отчётах при правильных документах.

Косвенные признаки — резкое замедление работы при неизменном объёме данных, ошибки при обмене данными, сообщения о нарушении уникальности индексов. Такие симптомы часто возникают после внезапного отключения электропитания, разрыва сетевого соединения с сервером СУБД, сбоя жёсткого диска или принудительного завершения процесса 1С.

Сделайте резервную копию до любых проверок

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

Для файловой базы достаточно скопировать файл 1Cv8.1CD в отдельный каталог при закрытых сеансах пользователей. Надёжнее — выгрузка в dt через конфигуратор («Администрирование → Выгрузить информационную базу»), так как выгрузка дополнительно проверяет читаемость данных. Для клиент-серверной базы используйте штатные средства СУБД (например, резервное копирование в MS SQL Server или PostgreSQL) плюс выгрузку dt как дополнительный слой защиты.

Анализ журнала регистрации

Журнал регистрации — первый источник информации о том, что именно происходит с базой. Откройте его через «Администрирование → Журнал регистрации» в режиме предприятия или через конфигуратор. Отфильтруйте события по уровню «Ошибка» за период, когда появились сбои.

Обращайте внимание на повторяющиеся ошибки, привязанные к конкретному объекту метаданных, пользователю или фоновому заданию. Если ошибки возникают при обращении к одной и той же таблице или документу — вероятна локальная проблема с данными. Если ошибки разрозненные и сопровождаются сообщениями СУБД о вводе-выводе — проверяйте дисковую подсистему и сеть.

Полезно сопоставить время появления ошибок с внешними событиями: отключением электричества, перезагрузкой сервера, обновлением платформы или конфигурации. Это помогает понять природу сбоя и выбрать правильный инструмент проверки.

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

Основной штатный инструмент — «Администрирование → Тестирование и исправление» в конфигураторе. Перед запуском завершите все сеансы пользователей: проверка требует монопольного доступа. Утилита предлагает несколько независимых проверок, которые можно комбинировать.

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

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

1. 1
   Сделайте резервную копию и завершите сеансы пользователей
2. 2
   Откройте конфигуратор: Администрирование → Тестирование и исправление
3. 3
   Выберите проверки: реиндексация, логическая целостность, ссылочная целостность, пересчёт итогов
4. 4
   Установите режим «Тестирование» (без исправления) и запустите
5. 5
   Изучите протокол: список найденных ошибок и затронутых объектов
6. 6
   При наличии ошибок запустите режим «Тестирование и исправление»
7. 7
   Проверьте результат: повторите проверку и убедитесь, что ошибок нет

Рекомендуемая тактика — сначала запустить проверку в режиме только тестирования, чтобы увидеть перечень проблем без изменения данных. Затем, оценив масштаб, запустить исправление. Для больших баз проверка занимает часы, поэтому планируйте её на нерабочее время.

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

Для файловых баз при сообщении «Файл базы данных поврежден» или при ошибках, которые тестирование и исправление не устраняет, используется утилита chdbfl.exe. Она находится в каталоге bin установленной платформы и проверяет физическую структуру файла 1Cv8.1CD на низком уровне.

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

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

Утилита не применима к клиент-серверным базам — там физической структурой управляет СУБД, и проверку выполняют её штатными средствами (DBCC CHECKDB для MS SQL Server, pg_amcheck и аналоги для PostgreSQL).

Проверка логических ошибок в данных

Физическая целостность не гарантирует корректность учёта. Логические ошибки — неверные остатки, отрицательные остатки на складах, расхождения между взаиморасчётами и платёжными документами — выявляются другими средствами.

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

Контрольные точки

Как проверить результат

Повторное тестирование после исправления

Норма

Протокол не содержит ошибок

Тревожный признак

Ошибки остались или появились новые

Открытие проблемных документов и отчётов

Норма

Объекты открываются, итоги сходятся

Тревожный признак

Ошибки формата потока, неверные суммы

Журнал регистрации за день после проверки

Норма

Нет повторяющихся ошибок СУБД

Тревожный признак

Ошибки возникают снова

Выгрузка базы в dt

Норма

Выгрузка завершается без ошибок

Тревожный признак

Выгрузка прерывается с ошибкой чтения

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

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

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

Когда привлекать специалиста

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

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

Маршрут решения

Как выбрать действие

Ошибка формата потока у одного пользователяОчистите кэш клиента и проверьте повторно

Сообщение «Файл базы данных поврежден» в файловой базеСкопируйте файл и запустите chdbfl.exe с исправлением

Неверные итоги в отчётах без сообщений об ошибкахВыполните пересчёт итогов через тестирование и исправление

Массовые ошибки СУБД у всех пользователейПроверьте диски, сеть и журналы СУБД, привлеките администратора

Ошибки остались после chdbfl и тестированияВосстановите базу из резервной копии и перенесите недостающие данные

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

Можно ли запускать тестирование и исправление при работающих пользователях?

Нет. Процедура требует монопольного доступа к базе, иначе она просто не запустится. Кроме того, исправление данных во время активной работы пользователей привело бы к конфликтам транзакций и новым повреждениям. Планируйте проверку на нерабочее время и принудительно завершайте сеансы через консоль кластера или список активных пользователей.

Чем отличается выгрузка в dt от копирования файла базы?

Выгрузка в dt создаёт логический снимок данных через механизмы платформы и заодно проверяет их читаемость: если база частично повреждена, выгрузка об этом сообщит. Копирование файла 1Cv8.1CD — физическая копия «как есть», включая повреждения. Оптимально делать оба варианта: файл копируется быстро, а dt гарантирует целостный перенос данных.

Исправит ли тестирование ошибки в учёте, например неверные остатки по складу?

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

Как часто нужно проверять базу, если ошибок нет?

Для активно используемых баз разумный регламент — тестирование без исправления ежемесячно или ежеквартально, плюс внеплановая проверка после любого аварийного завершения работы сервера или сбоя питания. Ежедневные резервные копии при этом обязательны независимо от частоты проверок.

Что делать, если chdbfl сообщает, что ошибки не исправимы?

Если утилита не может восстановить часть таблиц, основной путь — восстановление из последней работоспособной резервной копии с последующим ручным переносом данных за потерянный период. Данные из повреждённой базы иногда удаётся частично выгрузить обработками или запросами к уцелевшим таблицам, но эту работу лучше поручить специалисту.

Подходят ли эти методы для клиент-серверной базы на SQL?

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