Стоит ли делать «Тестирование и исправление» в 1С для профилактики и как правильно это выполнять

Механизм «Тестирование и исправление» (ТиИ) является мощным встроенным инструментом платформы 1С:Предприятие для поддержания здоровья базы данных. Однако среди администраторов и разработчиков не утихают споры: нужно ли запускать его регулярно «для профилактики» или использовать только тогда, когда в системе уже начались явные сбои? Разберем по шагам все нюансы этого процесса, проанализируем риски и выясним, как правильно обслуживать базы разных типов.

Понятие целостности данных: физический и логический уровни

Прежде чем переходить к практике, давайте разберем, на что именно влияет ТиИ. Важно разделять два вида целостности, которые проверяет этот механизм:

1. Физическая целостность: Это состояние самих файлов (для файловой базы 1Cv8.1CD) или таблиц в СУБД. На этом уровне проверяется отсутствие «битых» страниц памяти и корректность структуры таблиц. Проанализируем ситуацию: если у вас файловая база, ТиИ выполняет проверку физики, но делает это менее эффективно, чем специализированная утилита chdbfl.exe. Поэтому при серьезных сбоях (например, после отключения электроэнергии) мы сначала рекомендуем использовать внешнюю утилиту, а уже потом переходить к штатному тестированию.
2. Логическая целостность: Это проверка корректности связей между объектами 1С. Например, в документе «Реализация» указан «Склад», но сам элемент справочника «Склады» был удален напрямую. В этом случае возникает «битая ссылка». Средства SQL (Maintenance Plans) не видят логику метаданных 1С, они видят только строки и индексы. Поэтому для исправления логических ошибок ТиИ остается безальтернативным инструментом даже для клиент-серверных баз.

Различия в обслуживании файловых и SQL-баз

Рассмотрим, как меняется подход к тестированию в зависимости от архитектуры хранения данных. Выясним причину, по которой для больших баз профилактическое ТиИ может стать проблемой.

Для файловых баз ТиИ является основным средством профилактики. В условиях отсутствия продвинутых инструментов СУБД, регулярное (например, раз в месяц) тестирование помогает «поджать» базу и перестроить индексы. Однако помните: любая работа в этом режиме требует монопольного доступа, что останавливает работу пользователей.

Для SQL-баз (client-server) ситуация иная. Большинство функций ТиИ, таких как «Реиндексация» или «Сжатие», гораздо эффективнее выполняются средствами самого SQL-сервера (через планы обслуживания: Rebuild Index, Update Statistics). SQL делает это быстрее и зачастую без блокировки всей базы. Поэтому на крупных внедрениях профилактическое ТиИ «со всеми галками» практически не используется из-за огромных временных затрат и нагрузки на дисковую подсистему.

Разбор настроек «Тестирования и исправления»

Рассмотрим подробно каждый пункт настройки ТиИ, чтобы понимать, какие галочки действительно нужны именно вам:

1. Реиндексация таблиц: Полная перестройка индексов. Помогает при замедлении работы отчетов и поиска. Для SQL-баз лучше делать средствами СУБД.
2. Проверка целостности логической и физической: Основной пункт для поиска ошибок в данных.
3. Пересчет итогов: Крайне важная процедура. В 1С итоги хранятся отдельно от самих документов для быстродействия. Если вы заметили, что отчет за прошлый месяц «вдруг» показывает другие цифры, а расшифровка по документам дает верный результат — значит, итоги разошлись. Пересчет итогов синхронизирует эти данные.
4. Сжатие таблиц: Удаление «дырок» в базе данных, которые образуются при удалении объектов. Актуально только для файловых баз.
5. Реструктуризация таблиц: Платформа пересоздает таблицы базы данных. Это самый долгий процесс, который фактически пересобирает структуру данных с нуля. Помогает при критических ошибках метаданных.

Опасность режимов «Очищать объекты» и «Создавать объекты»

Проанализируем ситуацию с обработкой «битых» ссылок. Это самый опасный момент в работе ТиИ. Когда система находит ссылку на несуществующий объект, у вас есть два пути:

Очищать ссылки: 1С просто сотрет упоминание об объекте. Представьте, что в регистре накопления была запись о продаже, но документ-регистратор потерян. При выборе «Очищать» система может удалить запись, и ваш остаток товара изменится непредсказуемо. Внимание: это может привести к необратимой потере аналитики!

Создавать объекты: Это более безопасный путь. Вместо пустого места система создаст элемент справочника или документ с пометкой <Объект не найден>.... Это позволит вам позже по GUID (уникальному идентификатору) понять, что это был за объект, и, возможно, восстановить его из архивной копии.

Рекомендованная методика профилактики

Вместо того чтобы рисковать рабочей базой, разберем надежную схему, которую используют профессиональные администраторы:

1. Создаем резервную копию (это аксиома).
2. Разворачиваем копию на тестовом сервере.
3. Запускаем ТиИ в пакетном режиме (через командную строку) именно на копии.
4. Анализируем лог-файл. Если ошибок нет — рабочую базу не трогаем.
5. Если найдены ошибки — оцениваем их критичность и только тогда планируем технологическое окно для исправления рабочей базы.

Пример скрипта для запуска тестирования из командной строки:

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Bases\Trade" /N "Admin" /P "Password" /IBCheckAndRepair -Reindex -Log "D:\Logs\repair_log.txt"

Проблема расширений и ТиИ

Выясним причину еще одной опасности, упомянутой опытными специалистами. В версиях платформы до 8.3.15 существовал баг: при запуске ТиИ могли удаляться данные, хранящиеся в расширениях конфигурации. Платформа считала их «лишними», так как в основной конфигурации их нет. Несмотря на то что в свежих релизах это исправлено, мы рекомендуем: перед глобальным тестированием убедитесь, что ваши расширения подключены корректно и не конфликтуют с основной базой.

Выводы и рекомендации

Подведем итоги нашего анализа. Механизм ТиИ — это не «волшебная кнопка», которую нужно нажимать каждый день. Это хирургический инструмент.

Для профилактики:

• В файловых базах делайте ТиИ раз в 1-3 месяца после проверки chdbfl.exe.
• В SQL-базах делайте ставку на регламенты СУБД (обслуживание индексов и статистики). ТиИ делайте только на копии для проверки логики.
• Всегда делайте ТиИ перед крупным обновлением конфигурации, так как процесс обновления сам по себе меняет структуру таблиц, и старые ошибки могут привести к краху всей процедуры.

Для исправления:

• Используйте «Пересчет итогов», если плывут остатки в отчетах.
• Используйте «Логическую целостность» с режимом «Создавать объекты», если видите ссылки вида <Объект не найден>.

Помните, что лучшая профилактика — это исправный источник бесперебойного питания (ИБП) для сервера и ежедневно проверяемые бэкапы. Если данные в порядке и сервер работает стабильно, избыточное использование ТиИ может принести больше вреда (в виде временных затрат и рисков очистки данных), чем реальной пользы.