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