← На главную

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

Стоит ли проводить ТиИ «для профилактики»?

Профилактическое проведение тестирования и исправления зависит от режима работы информационной базы:

1. Файловый вариант (база в формате 1Cv8.1CD). Файловые базы наиболее подвержены логическим и физическим сбоям при некорректном завершении работы, отключении питания или сбоях в сети. В таком режиме регулярная профилактика задействуется оправданно. Однако выполнять все тумблеры подряд без предварительного тестирования на копии не рекомендуется.
2. Клиент-серверный вариант (MS SQL Server, PostgreSQL и др.). Сервер СУБД самостоятельно отвечает за физическую целостность данных. В клиент-серверном режиме регулярное обслуживание (индексацию, обновление статистики, резервное копирование) лучше выполнять средствами самой СУБД через регламентные планы обслуживания, а средства 1С применять только при выявлении логических ошибок.

Подготовка к процедуре: обязательные шаги

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

1. Создание резервной копии. Процесс исправления необратим. Если платформа некорректно обработает поврежденную таблицу, восстановить данные без бэкапа будет невозможно.
2. Проведение процедур на копии базы. Выполним процедуру ТиИ сначала на тестовой копии, оценим результаты и протокол выполнения, и только после этого применим настройки к рабочей базе.
3. Монопольный режим и завершение фоновых заданий. Для работы ТиИ требуется заблокировать базу данных. В файловых и серверных базах обязательно необходимо завершить работу всех пользователей и отключить фоновые и регламентные задания (например, через Консоль кластера или параметр настройки блокировки сеансов), иначе процедура может прерваться из-за блокировки таблиц.

Подробный разбор параметров «Тестирования и исправления»

В конфигураторе 1С в меню Администрирование — Тестирование и исправление... доступен список флажков. Разберем назначение и особенности работы каждого из них:

1. Реиндексация таблиц ИБ
Процедура полностью перестраивает индексы для таблиц базы данных. Это повышает скорость выполнения запросов и проведения документов. В файловом режиме рекомендуется к регулярному выполнению. В серверном режиме реиндексация через 1С выполняется быстро, но эффективнее настраивать её в самом регламентном плане СУБД.

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

3. Проверка ссылочной целостности ИБ
Находит битые ссылки (когда объект ссылается на несуществующую запись в другой таблице). При включении этого флажка становятся доступны варианты действий при обнаружении ошибок:

1. Создавать объекты — платформа создаст пустые элементы справочников или пустые документы взамен удаленных.
2. Очищать ссылки — битые ссылки в документах и справочниках будут очищены (установлено значение Неопределено или пустая ссылка).
3. Не изменять — платформа только зафиксирует наличие битых ссылок в отчете без внесения изменений в базу.

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

5. Сжатие таблиц ИБ
Актуально для файлового режима. При удалении объектов из файловой базы строки не удаляются физически, а помещаются как удаленные. Сжатие таблиц удаляет эти строки и уменьшает физический размер файла 1Cv8.1CD (аналог дефрагментации).

6. Реструктуризация таблиц ИБ
Процедура пересоздает таблицы базы данных: создается новая таблица, в нее переносятся данные из старой, после чего старая таблица удаляется. Это ресурсоемкий процесс. На больших базах реструктуризация может привести к аварийному завершению из-за нехватки памяти (особенно при использовании 32-битного конфигуратора) или критическому росту журнала транзакций .ldf на MS SQL Server.

Особенности работы с распределенными базами (РИБ)

Проанализируем специфику проведения тестирования и исправления в узлах РИБ. Главная опасность заключается в работе проверки ссылочной целостности:

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

Правило для РИБ: При проверке ссылочной целостности в узлах РИБ всегда выбираем вариант «Не изменять». Это позволит получить диагностическое сообщение и найти проблему без риска испортить данные в других узлах.

Альтернативные способы обслуживания и диагностики

Помимо штатного механизма ТиИ в Конфигураторе, существуют дополнительные инструменты для поддержания базы в рабочем состоянии:

1. Автономная утилита chdbfl.exe. Находится в папке bin установленной платформы 1С. Утилита предназначена исключительно для файлового режима. Она проверяет и исправляет физическую структуру файла 1Cv8.1CD на низком уровне. Ее рекомендуется запускать до проведения ТиИ, если база перестала открываться вовсе.
2. Выгрузка и загрузка файла .dt. Выгрузка файловой базы в файл .dt и последующая загрузка в новую пустую информационную базу полностью пересобирает структуру файла 1Cv8.1CD, удаляет внутренний «мусор» и оптимизирует индексы. Обратите внимание: данный метод не следует применять для восстановления периферийных узлов РИБ, так как это может нарушить идентификацию узла обмена.
3. Сокращение журнала регистрации. Ни сжатие таблиц, ни реструктуризация не уменьшают размер журнала регистрации (файлы .lgf / .lgd). Если каталог с базой сильно разрастается, сокращение журнала проводится отдельно через параметры администрирования информационной базы.