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