К статье
Практический материал

Администрирование · 10 мин

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

Как протестировать базу 1С: запуск тестирования и исправления, проверка логической и ссылочной целостности, копия базы, ошибки и способы их устранения.

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

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

Главное правило перед любым тестированием — сделать резервную копию. Режимы с включённым исправлением изменяют данные безвозвратно: удаляют объекты с битыми ссылками, пересчитывают итоги, перестраивают таблицы. Без копии откатить результат невозможно.

Когда базу нужно тестировать

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

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

«Объект не найден» в отчётахБитые ссылки

Ссылочная целостность нарушена — нужна проверка с исправлением

Ошибка СУБД при открытииПовреждение файла

Проверить chdbfl.exe для файловой базы или средствами СУБД

Итоги не сходятся с документамиРассинхронизация итогов

Поможет пересчёт итогов в режиме тестирования

База работает медленно и растётФрагментация таблиц

Нужна реиндексация и сжатие таблиц

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

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

Резервную копию файловой базы проще всего сделать копированием файла 1Cv8.1CD в отдельную папку или через выгрузку в dt (меню «Администрирование» → «Выгрузить информационную базу»). Для клиент-серверной базы используйте средства СУБД — например, штатный backup в 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 на уровне ниже, чем конфигуратор.

Запустите утилиту, укажите путь к файлу базы, отметьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Перед запуском обязательно скопируйте файл 1Cv8.1CD — утилита работает напрямую с файлом и изменяет его. После успешной проверки откройте базу в конфигураторе и дополнительно прогоните штатное тестирование логической целостности.

text
C:\Program Files\1cv8\<версия платформы>\bin\chdbfl.exe

Особенности клиент-серверных баз

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

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

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

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

База файловая и не открывается вообщеСкопируйте файл и запустите chdbfl.exe, затем тестирование в конфигураторе
База открывается, но есть ошибки в данныхТестирование и исправление в конфигураторе с нужными режимами
База клиент-серверная, подозрение на повреждениеПроверка средствами СУБД плюс тестирование в конфигураторе
Просто расходятся остатки в отчётахДостаточно пересчёта итогов без полного тестирования

Проверка результата и типичные ошибки

После завершения исправления не ограничивайтесь сообщением «ошибок не обнаружено». Откройте документы и отчёты, в которых ранее наблюдалась проблема, сверьте ключевые итоги с данными до сбоя (если есть распечатки или выгрузки), проверьте, что пользователи могут войти и работать в обычном режиме.

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

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

Журнал тестирования
Норма

Список ошибок пуст или все исправлены

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

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

Проблемные документы
Норма

Открываются и проводятся без ошибок

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

Ошибка воспроизводится — нужен анализ конкретного объекта

Итоги регистров
Норма

Остатки сходятся с данными документов

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

Расхождения сохраняются — требуется пересчёт итогов

Вход пользователей
Норма

Все сеансы стартуют штатно

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

Часть пользователей не может войти — проверить права и соединения

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

Типичные ошибки
01
Запуск исправления без копии — повреждённые данные удаляются безвозвратно
02
Прерывание процесса тестирования — можно получить базу в худшем состоянии, чем до запуска
03
Включение всех режимов сразу на большой базе — проверка растягивается на часы в рабочее время
04
Игнорирование регулярных проверок — мелкие ошибки накапливаются и превращаются в серьёзный сбой
05
Тестирование при активных сеансах — конфигуратор либо не запустится, либо результат будет недостоверным
Итог

Что важно запомнить

Всегда начинайте с резервной копии и монопольного доступа, сначала запускайте проверку без исправления, выбирайте только нужные режимы, а для неоткрывающихся файловых баз используйте chdbfl.exe. После исправления обязательно проверьте работу базы вручную.

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

Сколько времени занимает тестирование базы 1С?

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

Можно ли прервать процесс тестирования?

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

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

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

Что делать, если chdbfl.exe не исправила базу?

Попробуйте загрузить базу из последней рабочей выгрузки dt или восстановить из резервной копии. Если копий нет, иногда помогает выгрузка данных из повреждённой базы через конфигуратор (если он хотя бы частично её открывает) в новую чистую базу. В сложных случаях привлекайте специалистов по восстановлению данных.

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

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

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

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