Тестирование и исправление конфигурации 1С 8.3: когда и как применять без потери данных

Режим «Тестирование и исправление» в 1С:Предприятие 8.3 открывается в Конфигураторе через меню «Администрирование» → «Тестирование и исправление». Это встроенный инструмент обслуживания информационной базы: он проверяет логическую и ссылочную целостность данных, пересчитывает итоги, переиндексирует таблицы, сжимает и реструктурирует их, а также удаляет объекты, помеченные на удаление.

Запускать его имеет смысл в четырёх случаях: после обновления конфигурации, при подозрении на повреждение данных или битые ссылки, перед выгрузкой конфигурации в хранилище и как плановую процедуру в нерабочее время. Без монопольного режима и свежей резервной копии включать исправление нельзя: часть операций меняет базу необратимо.

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

Что такое режим «Тестирование и исправление» в 1С 8.3

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

Режим доступен и для файловой, и для клиент-серверной базы на MS SQL или PostgreSQL. В файловом варианте все операции выполняются в одном процессе над тем же файлом 1Cv8.1CD, где лежат данные, поэтому во время работ база занята полностью. В клиент-серверном варианте часть проверок выполняет сервер 1С, а часть ложится на СУБД, и время работы зависит от мощности сервера и объёма таблиц.

Запускается инструмент из Конфигуратора: пункт «Администрирование» → «Тестирование и исправление» находится в меню Конфигуратора. В режиме предприятия этот пункт недоступен.

Чем тестирование отличается от исправления

Галка «Только проверка» переводит режим в отчётный: платформа ищет ошибки и складывает результат в отчёт, ничего не меняя в базе. Снимаете галку, и найденные проблемы платформа устраняет сама: убирает битые ссылки, пересчитывает итоги, перестраивает таблицы, удаляет помеченное.

Исправление на базе в десятки и сотни гигабайт идёт часами и меняет данные необратимо. Рабочая последовательность выглядит так: «Только проверка», разбор отчёта, резервная копия, и только потом исправление.

Когда режим обязателен, а когда бесполезен

Обязательные случаи:

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

Бесполезен инструмент при физическом повреждении файлов базы, ошибках на уровне СУБД и сбоях оборудования. Битый файл 1Cv8.1CD, повреждённые страницы в PostgreSQL или MS SQL, сбои диска, контроллера RAID и памяти лежат вне логики 1С: платформа просто не сможет прочитать данные. Здесь помогает восстановление из резервной копии и работа администратора СУБД, а не тестирование.

Какие проверки выполняет режим и что делает каждая опция

Набор галок в окне фиксирован, но проверки зависят друг от друга и идут в определённом порядке. Сводка по опциям:

Опция	Что делает	Риск и время
Проверка логической целостности	Контролирует структурную и логическую целостность базы данных, при необходимости исправляет ошибки	Безопасна в режиме «Только проверка», при исправлении меняет объекты
Проверка ссылочной целостности	Проверяет ссылки на объекты, которые могут быть разрушены или не существовать	Исправление может удалить проблемные объекты
Пересчёт итогов	Запускает пересчёт итогов регистров за всё время	Занимает часы на больших базах, пользователи отключены
Реиндексация таблиц	Перестраивает индексы таблиц, ускоряя поиск и работу с базой	Долгая блокировка базы, ощутимая нагрузка на диск
Сжатие таблиц	Окончательно удаляет помеченные данные и освобождает занимаемое ими пространство	Доступно для файлового варианта базы; долго, нагружает диск
Реструктуризация таблиц	Создаёт для каждой таблицы идентичную и переносит в неё информацию из старой	Самый длительный режим; прерывание чревато ошибками
Удаление помеченных объектов	Физически удаляет всё, что помечено на удаление	Необратимо, возможна потеря связанных данных

Проверка логической и ссылочной целостности

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

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

Пересчёт итогов и реиндексация таблиц

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

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

Сжатие и реструктуризация таблиц

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

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

Удаление помеченных объектов и проверка ссылок

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

Безопасный порядок такой: проверка ссылок, анализ отчёта, снятие пометки с нужных объектов, и только после этого удаление. На продуктивной базе удаление без проверки ссылок относят к самым дорогим ошибкам администрирования.

Как запустить тестирование и исправление: пошаговая инструкция

Согласуйте окно обслуживания и предупредите пользователей о недоступности базы.
Отключите всех от базы и включите монопольный режим.
Сделайте резервную копию и проверьте, что она читается.
Запустите Конфигуратор под административной учётной записью.
Откройте «Администрирование» → «Тестирование и исправление».
Установите галки нужных проверок, для первого прохода оставьте «Только проверка».
Нажмите «Выполнить» и дождитесь завершения, не закрывая окно.
Проанализируйте отчёт: что найдено, каким объектам грозит правка.
При необходимости запустите инструмент повторно, уже с исправлением.
Снимите монопольный режим и верните пользователей в базу.

Как включить монопольный режим и завершить сеансы пользователей

Монопольный режим не пускает в базу другие сеансы, пока идут работы. Для обслуживания базы — обновления конфигурации, реструктуризации, выгрузки — монопольный режим обязателен; включить его можно и через кластер, даже не входя пользователем базы. Конкретный путь включения монопольного режима в интерфейсе зависит от версии платформы и конфигурации, поэтому сверяйтесь с документацией для своей версии.

Если сеансы не отпускают базу, их завершают принудительно: через консоль кластера серверов 1С или через список активных пользователей в Конфигураторе. Предупредите людей заранее: принудительное завершение приводит к потере несохранённых данных в открытых формах.

Блокировку сеансов можно устанавливать и средствами встроенного языка: для этого используется объект БлокировкаСеансов, метод глобального контекста УстановитьБлокировкуСеансов() устанавливает созданную блокировку, а метод ПолучитьБлокировкуСеансов() возвращает установленную. Если блокировка начала сеансов установлена с кодом разрешения 123, для входа в обход блокировки в командной строке запуска клиентского приложения указывают строку /UC123.

Обязательное резервное копирование перед запуском

Копия делается до исправления, а не после. Для файловой базы достаточно остановить сеансы, закрыть Конфигуратор и скопировать файл 1Cv8.1CD на другой носитель. Для клиент-серверной базы копию снимают средствами СУБД.

pg_dump -U postgres -F c -f /backup/base1c.dump base1c

Для MS SQL используется полное копирование BACKUP DATABASE в отдельный файл. После снятия копии убедитесь, что архив открывается, а размер совпадает с ожидаемым. Восстановиться после неудачного исправления можно только при рабочем бэкапе: откат «назад» внутри самой платформы не предусмотрен.

Практические сценарии применения

После обновления конфигурации

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

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

При подозрении на повреждение базы

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

Если база не открывается вовсе или СУБД сообщает о повреждённых страницах, тестирование и исправление не помогут: нужен бэкап и вмешательство на уровне СУБД. Разбор диагностики по журналам при ошибках чтения данных приведён в материале о блочном хранении двоичных данных в 1С.

Перед выгрузкой в хранилище конфигурации

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

Автоматическое тестирование в регламентных работах администратора

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

Как выстроить такие работы в команде, чтобы они не зависели от памяти одного человека, описано в статье о регламентах технического обслуживания.

Настройка регламентного задания для проверки

Шаги: в Конфигураторе откройте «Общие» → «Регламентные задания», создайте новое задание, задайте расписание вроде «каждое воскресенье в 3:00», выберите метод и оставьте включённой опцию «Только проверка». Для клиент-серверной базы задание выполняет сервер 1С, клиент Конфигуратора при этом закрывают.

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

Мониторинг результатов и оповещения

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

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

Типичные ошибки и как их избежать

Запуск исправления без резервной копии. Копия снимается первым шагом, до открытия окна тестирования.
Работа без монопольного режима. Пользовательские сеансы мешают операциям и искажают результат, поэтому базу освобождают полностью.
Удаление помеченных объектов без проверки ссылок. Сначала отчёт по ссылкам, потом удаление.
Игнорирование отчёта. Если не разобрать вывод «Только проверки», исправление пойдёт по неверному сценарию.
Запуск в рабочее время. Реиндексация и пересчёт итогов держат базу закрытой часами.
Включение всех галок сразу «на всякий случай». Каждая опция увеличивает время и риск, набор подбирают под задачу.
Эксперименты сразу на продуктивной базе. Первый прогон делают на копии.

Чек-лист безопасного запуска: бэкап → монопольный режим → только проверка → анализ отчёта → исправление в нерабочее время. Другие сценарии, которые чаще всего приводят к простоям и потере данных, собраны в разборе четырёх ошибок системных администраторов.

Ограничения режима и когда он не поможет

Физическое повреждение файлов базы инструмент не лечит. Если файл 1Cv8.1CD повреждён или СУБД сообщает о битых страницах, платформа не сможет прочитать данные, и проверка просто не запустится либо завершится ошибкой.

Ошибки на уровне СУБД, некорректные настройки, нехватка места в журнале транзакций, рассинхронизация реплик решаются средствами самой СУБД. Проблемы с оборудованием, сбои диска, памяти и контроллера также вне зоны ответственности режима: сначала железо, потом данные.

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