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