Тестирование и исправление 1С: какие галки ставить и когда

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

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

Назначение и принцип работы утилиты

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

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

Важно понимать разницу между физическим восстановлением на уровне СУБД (например, через DBCC CHECKDB для MS SQL) и логическим тестированием средствами платформы. 1С проверяет соответствие данных своим внутренним правилам ссылочной целостности, которые могут быть невидимы для самой системы управления базами данных.

⚠️ Внимание: Перед запуском процедуры с включенной опцией исправления обязательно создайте полную резервную копию базы данных (файловую или выгрузку .dt). Процесс исправления является необратимым и может удалить "битые" объекты, которые вы, возможно, захотите восстановить вручную.

Подготовка к запуску и монопольный режим

Первым шагом перед началом любых манипуляций с целостностью данных является обеспечение монопольного доступа. Для этого все пользователи должны завершить свои сеансы работы с базой. Администратор может использовать консоль администрирования серверов 1С:Предприятие или утилиту rac для принудительного завершения активных соединений, если пользователи не могут выйти самостоятельно.

После освобождения базы необходимо зайти в режим Конфигуратор. Именно в этом режиме, а не в режиме "1С:Предприятие", доступен полный спектр диагностических инструментов. В меню выберите пункт Администрирование, затем перейдите в подпункт Тестирование и исправление.

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

• 🔒 Убедитесь, что в списке активных сеансов нет подключенных пользователей, иначе кнопка запуска будет неактивна.
• 💾 Проверьте наличие свободного места на диске, где расположены файлы базы, так как временные файлы могут занимать значительный объем.
• 📅 Сверьтесь с регламентом работ, чтобы пользователи были предупреждены о простое системы.

Режимы проверки: чтение и пересчет итогов

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

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

Если вы используете файловый вариант базы данных, также доступна опция проверки физического состояния файла. Однако для клиент-серверного варианта эта функция менее актуальна, так как физическую целостность файлов данных должен обеспечивать механизм самой СУБД.

Опция	Влияние на данные	Рекомендуемая частота	Риск потери данных
Проверка логической целостности	Только чтение	Еженедельно	Отсутствует
Пересчет итогов	Изменение таблиц итогов	При расхождении отчетов	Минимальный
Исправление обнаруженных ошибок	Удаление/Изменение объектов	Только при наличии ошибок	Высокий
Проверка ссылочной целостности	Только чтение	Ежемесячно	Отсутствует

Исправление обнаруженных ошибок: когда ставить галку

Опция Исправление обнаруженных ошибок является наиболее агрессивной и требует осознанного подхода. Ее следует активировать только в том случае, если предварительная проверка (без галочки исправления) выявила конкретные нарушения. Слепое включение этой опции "на всякий случай" не рекомендуется.

Что делает эта функция? Она пытается автоматически устранить найденные несоответствия. Например, если документ ссылается на несуществующий элемент справочника, система может разорвать эту ссылку или пометить объект как удаленный. В некоторых случаях это приводит к тому, что документы становятся непроводимыми или теряют часть заполненных реквизитов.

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

⚠️ Внимание: После выполнения исправления обязательно запустите проверку логической целостности повторно. Это позволит убедиться, что все ошибки действительно устранены и база находится в стабильном состоянии.

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

Сжатие таблицы итогов и оптимизация

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

Эта процедура особенно полезна для высоконагруженных систем, где ежедневно проводятся тысячи документов. Регулярное сжатие помогает поддерживать высокую скорость формирования отчетов "Оборотно-сальдовая ведомость" или "Анализ субконто".

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

Технические детали сжатия

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

Последовательность действий и типичные ошибки

Многие администраторы совершают ошибку, пытаясь сразу запустить полный цикл исправлений. Правильный алгоритм действий выглядит иначе и предполагает поэтапное выполнение операций для минимизации рисков.

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

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

• 🚫 Не прерывайте процесс тестирования принудительно (через диспетчер задач), это может привести к полной порче базы данных.
• 🔄 Не запускайте исправление сразу после обновления конфигурации без предварительной проверки работы системы в штатном режиме.
• 📝 Фиксируйте все действия в журнале администратора для возможности отката к предыдущей точке восстановления.

FAQ: Часто задаваемые вопросы

Можно ли запускать тестирование и исправление в рабочем режиме (не в Конфигураторе)?

Нет, полноценное тестирование и исправление доступно только в режиме Конфигуратор. В режиме предприятия доступны лишь некоторые фоновые проверки, которые не обладают полным доступом к структуре данных и не могут выполнить глубокое исправление.

Сколько времени занимает процедура для базы объемом 50 ГБ?

Время выполнения сильно зависит от скорости дисковой подсистемы (SSD или HDD), нагрузки на процессор и типа СУБД. Для базы 50 ГБ на быстрых SSD процесс может занять от 30 минут до 2 часов. На обычных жестких дисках время может увеличиться до 4-6 часов.

Что делать, если после исправления пропали документы?

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

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

Рекомендуется выполнять проверку логической целостности после каждого крупного обновления конфигурации или перехода на новую версию платформы. Это гарантирует, что скрипты обновления не повредили структуру данных.

Отличается ли процедура для файловой и SQL базы?

Интерфейс запуска в Конфигураторе одинаков, но внутренняя реализация differs. Для SQL баз некоторые операции (например, пересчет итогов) выполняются эффективнее благодаря возможностям сервера СУБД, а физическая целостность файлов контролируется самим SQL сервером.