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