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