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

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

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

В этом материале разобран полный порядок запуска исправления ошибок: от подготовки и резервного копирования до выбора нужных проверок и контроля результата. Отдельно рассмотрены ситуации, когда стандартного инструмента недостаточно и требуется загрузка-выгрузка базы или обращение к специалисту.

Когда требуется исправление ошибок базы

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

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

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

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

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

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

Запуск тестирования и исправления: пошаговый порядок

Откройте базу в режиме конфигуратора. Для этого в окне запуска 1С выберите нужную базу и нажмите «Конфигуратор». Если база защищена, потребуются логин и пароль пользователя с правами администратора. Дождитесь полной загрузки конфигуратора — на больших базах это может занять заметное время.

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

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

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

Какие проверки выбрать и что они делают

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

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

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

Проверка итогов пересчитывает итоги регистров. Актуальна, если отчёты по остаткам показывают данные, расходящиеся с движениями документов. Учтите: пересчёт итогов на больших регистрах занимает много времени.

Сравнение режимов

Только тестирование

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

Тестирование и исправление

Ошибки устраняются автоматически по выбранным правилам. Требует обязательной резервной копии и монопольного доступа.

Выгрузка и загрузка .dt

Альтернатива при глубоких повреждениях: полная перезапись структуры базы. Дольше, но иногда срабатывает, когда тестирование не помогает.

Режимы: сначала только тестирование

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

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

Проверка результата после исправления

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

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

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

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

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

Норма

Протокол пуст или содержит только некритичные замечания

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

Те же или новые ошибки целостности

Открытие ранее проблемных объектов

Норма

Документы и справочники открываются без ошибок

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

Вылеты или «Ошибка формата потока» сохраняются

Ключевые отчёты

Норма

Данные согласованы, нет «Объект не найден»

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

Расхождения итогов, битые ссылки

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

Когда штатная процедура не устраняет проблему, следующий шаг — полная выгрузка базы в файл .dt и загрузка в новую пустую базу. При загрузке платформа пересоздаёт все таблицы заново, что устраняет часть повреждений физического уровня, недоступных тестированию. Для файловых баз дополнительно существует утилита chdbfl.exe из каталога платформы — она проверяет физическую целостность файла 1Cv8.1CD на более низком уровне.

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

Если база файловая и размещена в общей сетевой папке, перенесите её на локальный диск перед тестированием — процедура пойдёт заметно быстрее, а риск сбоя из-за сети исчезнет. После завершения базу можно вернуть обратно.

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

Можно ли запустить тестирование и исправление без конфигуратора?

Штатный инструмент доступен только в конфигураторе. Частичная альтернатива — запуск конфигуратора в пакетном режиме из командной строки с параметрами тестирования, что удобно для автоматизации регламентных проверок. Из пользовательского режима процедуру запустить нельзя.

Сколько времени занимает процедура?

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

Удалит ли исправление мои документы?

Сама процедура не удаляет документы. Однако при выборе правила «очищать ссылки» битые ссылки будут очищены, а при обработке некоторых повреждений платформа может удалить физически испорченные записи, которые невозможно восстановить. Именно поэтому резервная копия обязательна.

Что выбрать для битых ссылок: заглушки или очистку?

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

Нужно ли регулярно запускать тестирование для профилактики?

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

Чем отличается chdbfl.exe от тестирования в конфигураторе?

Утилита chdbfl.exe проверяет физическую структуру файла 1Cv8.1CD на низком уровне и применяется только к файловым базам. Тестирование в конфигураторе работает выше — на уровне логики данных платформы. При серьёзных повреждениях файловой базы их часто применяют последовательно.