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