Администрирование · 12 мин
Как протестировать базу 1С 8.3 и исправить ошибки
Как протестировать базу 1С 8.3 через «Тестирование и исправление» и chdbfl.exe: режимы проверки, исправление ошибок, резервные копии и типичные проблемы.
Ошибки в информационной базе 1С 8.3 проявляются по-разному: программа внезапно закрывается, документы не проводятся, отчёты выдают неверные суммы, а при обращении к справочникам возникают сообщения о «битых» ссылках или повреждении данных. Чаще всего причина — аварийное завершение работы, отключение электричества, разрыв сетевого соединения с сервером или сбои жёсткого диска. В таких ситуациях первым инструментом становится штатная процедура «Тестирование и исправление» в конфигураторе.
Процедура проверяет физическую и логическую целостность данных, умеет пересчитывать итоги по регистрам, удалять «битые» ссылки и восстанавливать повреждённые таблицы. Для файловых баз дополнительно существует утилита chdbfl.exe, которая работает на более низком уровне и иногда спасает базу, которую конфигуратор даже не может открыть. Ниже разобраны оба инструмента, порядок их применения и ограничения.
Главное правило перед любыми манипуляциями — сделать резервную копию. Режимы исправления изменяют данные необратимо: удалённые «битые» объекты восстановить штатными средствами уже не получится.
Подготовка: резервная копия и монопольный доступ
Тестирование и исправление требует монопольного доступа к базе: все пользователи должны выйти, фоновые задания — завершиться. В клиент-серверном варианте завершите сеансы через консоль администрирования сервера 1С или дождитесь, пока пользователи выйдут сами, установив блокировку соединений. В файловом варианте достаточно закрыть все запущенные экземпляры 1С, обращающиеся к этой базе.
Резервную копию файловой базы проще всего сделать копированием файла 1Cv8.1CD — при этом база не должна быть открыта ни одним пользователем. Более корректный способ — выгрузка в dt через конфигуратор («Администрирование → Выгрузить информационную базу»), поскольку dt-файл дополнительно проверяет читаемость данных. Для клиент-серверной базы используйте выгрузку в dt или штатные средства СУБД (pg_dump для PostgreSQL, backup для MS SQL Server).
Запуск «Тестирования и исправления» в конфигураторе
Откройте конфигуратор, авторизуйтесь под пользователем с правами администратора и перейдите в меню «Администрирование → Тестирование и исправление». В открывшемся окне выберите проверки и режим. Для большинства случаев достаточно трёх флажков: реиндексация таблиц, проверка логической целостности и проверка ссылочной целостности.
В группе «Проверки и режимы» обратите внимание на переключатель действий при обнаружении ошибок. Вариант «Тестирование» только диагностирует проблемы и ничего не меняет — с него стоит начинать, чтобы оценить масштаб. Вариант «Тестирование и исправление» выполняет реальные исправления согласно выбранным настройкам обработки битых ссылок.
- 1Сделайте резервную копию базы (файл 1Cv8.1CD или выгрузка в dt)
- 2Завершите все сеансы пользователей и фоновые задания
- 3Откройте конфигуратор → Администрирование → Тестирование и исправление
- 4Отметьте реиндексацию, логическую и ссылочную целостность
- 5Сначала запустите режим «Тестирование» и изучите протокол
- 6Если ошибки подтверждены — запустите «Тестирование и исправление»
- 7Проверьте работоспособность базы и ключевые отчёты после процедуры
Режимы проверки: что выбрать и зачем
Реиндексация таблиц
Реиндексация перестраивает индексы таблиц базы данных. Она не исправляет логические ошибки, но ускоряет работу и устраняет проблемы, связанные с повреждёнными индексами — например, когда запись в справочнике «не находится» поиском, хотя видна в списке. Реиндексация безопасна: данные не изменяются, перестраиваются только служебные структуры.
Проверка логической целостности
Эта проверка выявляет расхождения в служебных данных: итогах регистров, служебных таблицах, нумерации. Например, она находит ситуации, когда итоги по регистру накопления не соответствуют движениям документов. Выявленные расхождения в режиме исправления устраняются пересчётом итогов.
Проверка ссылочной целостности
Самая «опасная» и самая полезная проверка. Она находит ссылки на несуществующие объекты — например, документ ссылается на удалённый товар, или в движениях регистра остались записи от физически потерянного регистратора. Для таких случаев предусмотрены три варианта обработки, и выбор между ними определяет, что произойдёт с данными.
| Действие с битыми ссылками | Что происходит | Когда выбирать |
|---|---|---|
| Не изменять | Ошибки только фиксируются в протоколе | Первичная диагностика, когда решение принимает человек |
| Создавать объекты | Создаются пустые объекты-заглушки с нужным идентификатором | Когда важно сохранить связи и разобраться с объектами вручную позже |
| Очищать ссылки | Битые ссылки заменяются пустыми | Когда потерянные объекты не восстановить, а данные нужны |
| Удалять объект | Объект с битыми ссылками удаляется целиком | Крайний случай: объект без потерянных данных бессмыслен |
Утилита chdbfl.exe для файловых баз
Если файловая база не открывается ни в режиме предприятия, ни в конфигураторе и выдаёт ошибку «Файл базы данных повреждён», стандартное тестирование недоступно. На этот случай в составе платформы поставляется утилита chdbfl.exe, расположенная в каталоге bin установленной версии платформы (например, C:\Program Files\1cv8\<номер версии>\bin\).
Утилита работает напрямую с файлом 1Cv8.1CD на физическом уровне: проверяет структуру страниц данных и может удалять повреждённые фрагменты. Запустите chdbfl.exe, укажите путь к файлу базы, установите флажок «Исправлять обнаруженные ошибки» и нажмите «Исполнить». Предварительно скопируйте файл 1Cv8.1CD в отдельный каталог — утилита изменяет файл необратимо.
C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exeПосле успешной проверки chdbfl откройте базу в конфигураторе и дополнительно выполните штатное «Тестирование и исправление»: физическая целостность восстановлена, но логические и ссылочные ошибки могли остаться.
Особенности клиент-серверных баз
Для баз на PostgreSQL, MS SQL Server или Oracle утилита chdbfl неприменима — она работает только с файловым форматом. В клиент-серверном варианте используется то же «Тестирование и исправление» из конфигуратора, но дополнительно стоит задействовать штатные средства СУБД: проверку целостности (DBCC CHECKDB для MS SQL), перестроение индексов, анализ журналов СУБД.
Учтите, что на больших клиент-серверных базах полное тестирование может длиться часами и всё это время база недоступна пользователям. Планируйте процедуру на нерабочее время и оценивайте длительность по размеру базы: десятки гигабайт данных означают многие часы проверки.
Как выбрать действие
Проверка результата после исправления
Завершение процедуры без сообщений об ошибках ещё не означает, что база полностью здорова. Откройте протокол тестирования и изучите список исправленных объектов: там видно, какие ссылки были очищены, какие объекты созданы как заглушки, какие итоги пересчитаны. Эти места стоит проверить вручную в режиме предприятия.
Практическая проверка: сформируйте ключевые отчёты (оборотно-сальдовую ведомость, отчёты по остаткам складов, взаиморасчётам) и сравните итоги с данными до исправления, если у вас сохранились распечатки или выгрузки. Проведите несколько проблемных документов, которые раньше вызывали ошибки. Если использовался вариант «Создавать объекты», найдите созданные заглушки — обычно их видно по пустым наименованиям в списках — и решите, восстанавливать данные или удалять.
Как проверить результат
Перечислены исправленные объекты, повторный запуск показывает отсутствие ошибок
Ошибки остались или появились новые после повторного запуска
Итоги совпадают с ожидаемыми значениями, отчёты формируются без ошибок
Суммы изменились необъяснимо, отчёты падают с ошибкой
Проводятся и открываются штатно
Ошибки воспроизводятся, появляются сообщения о битых ссылках
Типичные ошибки и ограничения процедуры
Частая ошибка — запуск исправления при работающих пользователях. Без монопольного доступа процедура либо не стартует, либо завершится с ошибками, а в худшем случае оставит базу в несогласованном состоянии. Вторая типичная ошибка — выбор «Удалять объект» без анализа: так можно потерять цепочки взаимосвязанных документов.
Важно понимать ограничения: «Тестирование и исправление» не восстанавливает удалённые бизнес-данные и не исправляет ошибки в логике конфигурации. Если отчёт считает неверно из-за ошибки в запросе или модуле, тестирование этого не выявит. Также процедура не поможет при проблемах с оборудованием: если диск продолжает сбоить, ошибки будут возникать снова — сначала устраните причину.
Если ошибки повторяются регулярно, проверьте инфраструктуру: состояние дисков (SMART), стабильность сети между клиентами и сервером, работу антивируса (каталоги 1С должны быть в исключениях), настройки электропитания сервера. Устранение первопричины важнее регулярного «лечения» базы.
Что важно запомнить
Порядок безопасного восстановления: резервная копия → диагностическое тестирование → исправление с осторожным режимом обработки битых ссылок → повторная проверка. Для неоткрывающихся файловых баз сначала применяется chdbfl.exe, затем штатное тестирование. При повторяющихся ошибках ищите и устраняйте первопричину в оборудовании или сети.
Частые вопросы
Сколько времени занимает тестирование и исправление?
Зависит от размера базы, скорости диска и выбранных проверок. Небольшая файловая база в несколько гигабайт обычно обрабатывается за десятки минут, большие клиент-серверные базы — несколько часов. Самая долгая проверка — ссылочная целостность. Планируйте процедуру на нерабочее время с запасом.
Можно ли прервать тестирование, если оно идёт слишком долго?
Кнопка отмены есть, но прерывание в режиме исправления рискованно: база может остаться в частично обработанном состоянии. Если процедуру пришлось прервать, восстановите базу из резервной копии и запустите процесс заново, либо как минимум выполните повторное полное тестирование.
Чем отличается выгрузка в dt от копирования файла базы?
Копирование файла 1Cv8.1CD быстрее, но переносит и возможные повреждения «как есть». Выгрузка в dt читает данные через механизмы платформы: если база читается, полученный dt обычно чище исходника, а сам процесс выгрузки служит дополнительной проверкой целостности. Для сильно повреждённых баз выгрузка может не удаваться — тогда остаётся копирование файла и chdbfl.
Исправит ли тестирование ошибки «Объект не найден» в документах?
Да, это типовой случай битой ссылки. Проверка ссылочной целостности найдёт такие ссылки, а выбранный режим обработки определит результат: создание объекта-заглушки, очистку ссылки или удаление объекта. После исправления проверьте затронутые документы вручную — часть данных могла быть потеряна раньше, ещё при исходном сбое.
Нужно ли запускать тестирование регулярно для профилактики?
Обязательной регулярной процедурой это не является. Разумная практика — периодическая реиндексация и проверка логической целостности на копии базы, а полное тестирование с исправлением — только при появлении симптомов. В клиент-серверном варианте регулярное обслуживание индексов обычно выполняется средствами СУБД.
Что делать, если после всех процедур ошибки остались?
Значит, повреждения глубже штатных возможностей восстановления. Варианты: восстановление из максимально свежей рабочей резервной копии с переносом недостающих данных, выгрузка оставшихся данных обработкой в новую чистую базу, либо обращение к специалистам по восстановлению данных 1С. Параллельно обязательно проверьте оборудование, на котором хранилась база.