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

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

Проверка логической целостности в 1С: что это и как правильно выполнить

Что такое проверка логической целостности в 1С, когда её запускать, какие ошибки она находит и как безопасно исправить базу через тестирование и исправление.

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

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

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

Что именно проверяет режим логической целостности

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

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

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

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

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

  • после аварийного завершения работы сервера или клиента 1С;
  • при появлении сообщений «Объект не найден» в документах и отчётах;
  • при ошибках проведения документов со ссылками на несуществующие записи;
  • после сбоев обмена данными, когда часть объектов не выгрузилась или не загрузилась;
  • перед регламентными операциями вроде обновления конфигурации, если есть подозрение на повреждения.
Маршрут решения

Как выбрать действие

В документах появились записи «Объект не найден»Запустите тестирование и исправление с проверкой логической целостности в режиме исправления
База работает стабильно, ошибок нетПлановая проверка не обязательна — достаточно регулярного резервного копирования
Ошибка возникла на клиент-серверной базе после сбоя СУБДСначала проверьте базу средствами СУБД, затем при необходимости — средствами 1С
Требуется проверить физическую целостность файловой базыИспользуйте утилиту chdbfl.exe из каталога платформы — это другой уровень проверки

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

Как запустить проверку: пошаговый порядок

Проверка выполняется через конфигуратор и требует, чтобы с базой не работал ни один пользователь. Для файловой базы достаточно закрыть все сеансы, для клиент-серверной — установить блокировку сеансов в консоли кластера или через параметры базы.

Порядок действий
  1. 1
    Сделайте резервную копию базы: выгрузку в dt через конфигуратор или копию средствами СУБД
  2. 2
    Завершите все сеансы пользователей и фоновые задания, установите блокировку соединений
  3. 3
    Откройте базу в конфигураторе под учётной записью с полными правами
  4. 4
    Перейдите в меню «Администрирование» → «Тестирование и исправление»
  5. 5
    Отметьте пункт «Проверка логической целостности информационной базы» и при необходимости «Проверка ссылочной целостности»
  6. 6
    Выберите режим «Тестирование» для диагностики без изменений или «Тестирование и исправление» для устранения ошибок
  7. 7
    Нажмите «Выполнить» и дождитесь окончания, не прерывая процесс
  8. 8
    Проанализируйте список сообщений и проверьте исправленные объекты в пользовательском режиме

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

Режимы исправления: что выбрать при обнаружении ошибок

При включённом исправлении платформа предлагает три варианта обработки объектов с нарушенными ссылками. Выбор зависит от того, насколько критичны данные:

РежимЧто делает платформаКогда подходит
Не изменятьТолько фиксирует ошибки в сообщенияхДиагностика, оценка масштаба проблем
Создавать объектыСоздаёт пустые объекты-заглушки вместо отсутствующихКогда важно сохранить ссылки и историю, а данные восстановят вручную
Очищать ссылкиУдаляет битые ссылки из документов и записейКогда потерянные объекты не нужны и ссылка просто мешает
Удалять данныеУдаляет записи, содержащие битые ссылкиДля записей регистров без регистратора — потерянные данные всё равно бесполезны

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

Отличие от других проверок: реиндексация, ссылочная целостность, chdbfl

В окне «Тестирование и исправление» рядом с логической целостностью есть и другие пункты, которые часто путают:

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

Отдельно стоит утилита chdbfl.exe из каталога установки платформы. Она проверяет физическую целостность файловой базы (файла 1Cv8.1CD) — структуру страниц и таблиц на уровне файла. Если база вообще не открывается или конфигуратор падает с ошибкой формата, сначала используют chdbfl, а уже потом тестирование и исправление.

Сравнение вариантов проверки

Проверка логической целостности

Проверяет согласованность данных и ссылок. Подходит после сбоев и при «битых» ссылках. Требует монопольного доступа

chdbfl.exe

Проверяет физическую структуру файловой базы. Нужна, когда база не открывается. Не работает с клиент-серверными базами

Средства СУБД (DBCC, pg_dump)

Для клиент-серверных баз на MS SQL или PostgreSQL проверку физической целостности выполняют штатными средствами СУБД

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

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

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

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

Окно сообщений конфигуратора
Норма

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

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

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

Документы с бывшими битыми ссылками
Норма

Открываются, проводятся, ссылки ведут на реальные объекты

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

Появились пустые заглушки «Объект не найден» в полях

Отчёты по ключевым разделам учёта
Норма

Формируются без ошибок, итоги сходятся с данными до сбоя

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

Ошибки при построении, расхождения итогов

Обмены данными
Норма

Синхронизация проходит без ошибок выгрузки объектов

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

Обмен падает на конкретных объектах

Если автоматическое исправление создало объекты-заглушки, найдите их поиском по подстроке «Объект не найден» в соответствующих справочниках и замените реальными данными из резервной копии. После этого полезно повторно провести затронутые документы.

Частые ошибки администраторов

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

Отдельная ошибка — воспринимать проверку как замену регламентного обслуживания. Логическая целостность исправляет последствия, но не предотвращает повреждения. Если сбои повторяются, нужно диагностировать инфраструктуру: дисковую подсистему, сеть, источники бесперебойного питания, настройки СУБД.

FAQ: частые вопросы о проверке логической целостности

Сколько времени занимает проверка?

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

Можно ли запускать проверку, пока пользователи работают?

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

Чем отличается логическая целостность от ссылочной?

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

Проверка исправит ошибки в проводках и отчётах?

Нет. Она работает на уровне структуры данных, а не бухгалтерского смысла. Ошибки в суммах, счетах учёта, неверно заполненных реквизитах она не находит и не исправляет — для этого используются прикладные механизмы: закрытие месяца, экспресс-проверка учёта, перепроведение документов.

Что делать, если проверка не смогла исправить часть ошибок?

Ошибки, которые платформа не устраняет автоматически, требуют ручной работы: восстановления объектов из резервной копии, удаления проблемных записей через обработку или обращения к специалисту по 1С. Если повреждений много, часто быстрее восстановить базу из последней рабочей копии и повторно ввести данные за потерянный период.

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

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

Итог

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

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