Администрирование · 11 мин
Как тестировать базу 1С: пошаговая инструкция по проверке и восстановлению
Практическое руководство по тестированию базы 1С: запуск проверки в конфигураторе и chdbfl, виды проверок, исправление ошибок, бэкапы и типичные ошибки.
Тестирование и исправление информационной базы — штатная процедура платформы 1С:Предприятие, которая проверяет физическую и логическую целостность данных и устраняет часть повреждений автоматически. Она нужна после аварийного завершения работы, при ошибках формата потока, при подозрительном поведении базы (документы не проводятся, записи «пропадают», отчёты выдают разные суммы) и как профилактическая мера перед обновлением конфигурации.
Процедура доступна в двух вариантах: встроенное тестирование через конфигуратор и отдельная утилита chdbfl для файловых баз. Первый способ подходит и для клиент-серверных баз, второй — только для файловых, но работает быстрее и не требует запуска конфигуратора. Выбор зависит от типа базы и характера повреждения.
Главное правило, которое нельзя нарушать: любое тестирование с исправлением выполняется только на копии базы или после создания резервной копии. Процедура может удалять повреждённые объекты целиком — вместе с данными, которые теоретически ещё можно было спасти.
Когда базу нужно тестировать
Явный повод для проверки — аварийное завершение работы: отключение электричества, разрыв сетевого соединения при работе с файловой базой по сети, принудительное завершение процесса, сбой диска. В таких ситуациях таблицы базы могут остаться в несогласованном состоянии, даже если внешне всё открывается.
Второй класс признаков — ошибки при работе: сообщения вида «Ошибка формата потока», «Ошибка СУБД», «Поле объекта не обнаружено» там, где раньше всё работало, зависания при открытии конкретных документов или справочников. Третий повод — плановая профилактика: перед обновлением конфигурации, перед свёрткой базы, перед переносом данных. Обновление на повреждённой базе может завершиться неудачей на середине и оставить базу в нерабочем состоянии.
Появляется при открытии объектов или запуске базы
Было отключение питания или разрыв соединения
Документы или элементы справочников не отображаются
Один и тот же отчёт даёт разные итоги
Подготовка: резервная копия и монопольный доступ
Перед запуском тестирования сделайте резервную копию. Для файловой базы достаточно скопировать файл 1Cv8.1CD в другое место — при этом база должна быть закрыта у всех пользователей, иначе копия получится несогласованной. Для клиент-серверной базы используйте выгрузку в dt через конфигуратор или штатные средства СУБД.
Тестирование и исправление требует монопольного доступа: все сеансы пользователей должны быть завершены. В конфигураторе это можно проверить через «Администрирование → Активные пользователи». Если база клиент-серверная, удобнее заблокировать соединения через консоль кластера, установив дату начала блокировки, — иначе пользователи успеют зайти снова между вашей проверкой и запуском процедуры.
Тестирование через конфигуратор
Откройте конфигуратор, перейдите в меню «Администрирование → Тестирование и исправление». В появившемся окне выберите проверки и режим. Набор проверок определяет глубину анализа, а режим — что будет происходить с найденными ошибками.
Доступные проверки различаются по назначению. Реиндексация перестраивает индексы таблиц — это безопасная операция, ускоряющая работу и устраняющая часть сбоев. Проверка логической целостности сопоставляет данные с учётом ограничений конфигурации. Проверка ссылочной целостности ищет «битые ссылки» — ссылки на несуществующие объекты. Проверка физической целостности (для файловых баз) анализирует структуру файла на низком уровне. Пересчёт итогов восстанавливает итоговые данные регистров.
- 1Сделайте резервную копию базы (выгрузка в dt или копия файла 1Cv8.1CD)
- 2Завершите все сеансы пользователей и убедитесь в монопольном доступе
- 3Откройте Администрирование → Тестирование и исправление
- 4Отметьте нужные проверки: для начала реиндексацию и логическую целостность
- 5Выберите режим «Тестирование» (без исправления) и запустите
- 6Изучите журнал: если ошибок нет, процедура завершена
- 7Если ошибки найдены — убедитесь в наличии копии и запустите режим «Тестирование и исправление»
- 8Проверьте работоспособность базы: откройте проблемные объекты и ключевые отчёты
Какой режим исправления выбрать
Для битых ссылок предлагаются три варианта обработки: создавать объекты (платформа создаст пустые объекты-заглушки, которые потом можно заполнить), очищать ссылки (ссылки будут удалены, объекты останутся) и не изменять (только зафиксировать факт). Для объектов с потерянными данными действия жёстче: удаление объекта целиком. Вариант «создавать объекты» обычно безопаснее, так как сохраняет структуру данных и позволяет восстановить содержимое вручную.
Проверка файловой базы утилитой chdbfl
Утилита chdbfl.exe находится в каталоге установки платформы, в папке bin конкретной версии. Она работает непосредственно с файлом 1Cv8.1CD и проверяет физическую целостность таблиц — то, что конфигуратор иногда не может сделать, если база не открывается.
Запустите утилиту, укажите путь к файлу базы, отметьте флаг «Исправлять обнаруженные ошибки» только после того, как сделали копию файла. Утилита последовательно проверит все таблицы и выведет протокол. Процесс может занять значительное время на больших базах — не прерывайте его, прерывание оставит файл в промежуточном состоянии.
Конфигуратор или chdbfl
Подходит для файловых и клиент-серверных баз, проверяет логику и ссылки. Требует, чтобы база открывалась в конфигураторе.
Только файловые базы. Проверяет физическую структуру файла, работает даже когда конфигуратор базу не открывает. Не проверяет логическую целостность.
Для клиент-серверных баз: штатные проверки целостности MS SQL или PostgreSQL дополняют проверку платформы, но не заменяют её.
Особенности клиент-серверных баз
В клиент-серверном варианте проверка физической целостности средствами конфигуратора недоступна — структурой таблиц управляет СУБД. Здесь тестирование в конфигураторе ограничивается реиндексацией, логической и ссылочной целостностью, пересчётом итогов. Физическую целостность проверяют средствами самой СУБД: для MS SQL это команда DBCC CHECKDB, для PostgreSQL — контроль через pg_amcheck или анализ логов.
Учитывайте, что тестирование большой серверной базы создаёт нагрузку на СУБД и может занять часы. Планируйте процедуру на нерабочее время и заранее оцените объём базы. Прерывание процесса на клиент-серверной базе менее опасно, чем на файловой, благодаря транзакционности СУБД, но всё равно нежелательно.
Как проверить результат и что делать дальше
После завершения процедуры изучите протокол: конфигуратор выводит список обнаруженных и исправленных проблем в окно сообщений. Сохраните этот текст — он понадобится, чтобы понять, какие объекты были удалены или изменены, и восстановить данные по ним из копии.
Затем выполните контрольную проверку: откройте объекты, которые раньше вызывали ошибки, сформируйте ключевые отчёты (оборотно-сальдовую ведомость, отчёты по складу) и сравните итоги с данными до тестирования. Если исправление удаляло объекты, сверьте по протоколу, что именно пропало, и восстановите эти данные вручную из резервной копии.
Как проверить результат
База открывается, объекты доступны без ошибок
Ошибки формата потока или СУБД сохраняются
Список ошибок пуст или все ошибки исправлены
Остались ошибки, которые процедура не смогла устранить
Суммы совпадают с данными до тестирования
Итоги изменились без объяснимой причины
Повторный прогон не находит ошибок
Ошибки появляются снова — возможен сбой диска или сети
Типичные ошибки и профилактика
Большинство повреждений файловых баз связано с инфраструктурой, а не с платформой: работа по нестабильной сети, антивирус, сканирующий файл базы в реальном времени, переполнение диска, жёсткие отключения питания. Если тестирование регулярно находит ошибки, искать причину нужно именно там — иначе проверки превратятся в бесконечную борьбу со следствиями.
Профилактика проста: настройте регулярное резервное копирование с хранением копий на отдельном носителе, исключите каталог базы из сканирования антивируса, используйте источник бесперебойного питания на сервере, а для файловых баз избегайте работы по Wi-Fi и нестабильным сетям. Плановое тестирование без исправления раз в месяц позволит обнаружить проблему раньше, чем она проявится в работе.
Что важно запомнить
Тестирование запускают через конфигуратор для любых баз и через chdbfl для файловых. Всегда делайте копию перед исправлением, работайте в монопольном режиме и проверяйте результат по протоколу и отчётам. Повторяющиеся ошибки — сигнал искать причину в диске, сети или антивирусе.
Частые вопросы
Сколько времени занимает тестирование базы?
Зависит от объёма базы, типа проверок и скорости диска. Небольшая файловая база проверяется за минуты, большая клиент-серверная с полным набором проверок — часами. Реиндексация обычно самая быстрая операция, проверка физической целостности — самая долгая. Планируйте процедуру на нерабочее время.
Можно ли тестировать базу, пока в ней работают пользователи?
Нет. Тестирование и исправление требует монопольного доступа — все сеансы должны быть завершены. В клиент-серверном варианте дополнительно установите блокировку соединений в консоли кластера, чтобы пользователи не заходили во время процедуры.
База не открывается даже в конфигураторе. Что делать?
Для файловой базы скопируйте файл 1Cv8.1CD и прогоните его через chdbfl с исправлением. Если и это не помогло, остаётся восстановление из резервной копии или обращение к специалистам по восстановлению данных. Для клиент-серверной базы проверяйте целостность средствами СУБД.
Чем отличается выгрузка в dt от копирования файла базы?
Выгрузка в dt — логическая копия, которую платформа создаёт штатными средствами; она подходит для переноса между файловым и клиент-серверным вариантами. Копирование файла 1Cv8.1CD — физическая копия, быстрее и надёжнее для отката при тестировании, но требует закрытой базы и работает только для файлового варианта.
Тестирование нашло и удалило повреждённые документы. Как их вернуть?
Автоматически — никак, удаление необратимо. Откройте резервную копию базы рядом, найдите удалённые документы по протоколу тестирования и перенесите их вручную или через обработку выгрузки-загрузки данных. Поэтому режим «создавать объекты» предпочтительнее удаления.
Как часто нужно проводить профилактическое тестирование?
Для стабильно работающей базы достаточно плановой проверки без исправления раз в месяц и обязательного прогона перед обновлением конфигурации. Внепланово — после любого аварийного завершения и при появлении ошибок формата потока или СУБД.