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