Сколько длится тестирование и исправление базы 1С

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

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

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

От чего зависит длительность тестирования и исправления

Главный фактор — объём информационной базы. Проверка читает фактически все таблицы, поэтому время растёт почти линейно с размером данных. База на 2 ГБ и база на 200 ГБ — это разница на порядки, а не «чуть дольше».

Второй фактор — режим работы. Файловая база на локальном диске SSD проверяется заметно быстрее, чем та же база на сетевом диске или на медленном RAID-массиве сервера. Для клиент-серверного варианта (MS SQL, PostgreSQL) скорость зависит от производительности СУБД, загруженности сервера и настроек индексов.

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

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

В конфигураторе (Администрирование → Тестирование и исправление) доступно несколько независимых режимов. Их можно запускать по отдельности — это удобный способ контролировать длительность.

Реиндексация таблиц

Перестраивает индексы таблиц базы. На небольших базах занимает минуты, на крупных — часы. Реиндексацию часто запускают профилактически, так как она ускоряет работу запросов, но в клиент-серверном варианте аналогичную задачу обычно эффективнее выполнять штатными средствами СУБД.

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

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

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

Ищет «битые ссылки» — ссылки на несуществующие объекты. Один из самых длительных режимов, потому что требует перекрёстного анализа таблиц. Именно он чаще всего нужен после сообщений вида «Объект не найден».

Пересчёт итогов и сжатие таблиц

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

Как оценить срок для своей базы

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

Если копию развернуть негде, ориентируйтесь на косвенные признаки: размер файла 1Cv8.1CD (для файлового варианта) или размер базы в СУБД, скорость дисковой подсистемы и опыт прошлых регламентных операций (например, сколько занимает резервное копирование — проверка обычно длится дольше копирования).

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

1. 1
   Сделайте полную резервную копию базы и проверьте, что она восстанавливается
2. 2
   Определите, какие режимы проверки действительно нужны по симптомам
3. 3
   Прогоните проверку на копии базы и замерьте время
4. 4
   Согласуйте окно обслуживания с пользователями с запасом времени
5. 5
   Завершите сеансы пользователей и отключите регламентные задания
6. 6
   Запустите проверку, дождитесь завершения и изучите протокол ошибок
7. 7
   Проверьте работоспособность базы и только потом пустите пользователей

Монопольный режим и простой пользователей

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

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

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

Что делает режим исправления и чем это рискованно

При включённом флаге исправления программа не только находит, но и устраняет ошибки. Для битых ссылок предлагаются варианты: не изменять, создавать объекты-заглушки, очищать ссылки или удалять объекты. Выбор влияет и на сроки, и на последствия.

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

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

Как сократить время проверки

Первый приём — выборочный запуск. Определите по симптомам, какая именно проверка нужна, и не запускайте остальные. Сообщение «Объект не найден» — это ссылочная целостность, а не полный цикл.

Второй приём — перенос проверки на быстрое оборудование. Файловую базу можно скопировать на локальный SSD, проверить там и вернуть обратно. Для клиент-серверной базы — выполнять реиндексацию и обслуживание средствами СУБД, которые обычно быстрее и могут работать параллельно.

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

Маршрут решения

Как выбрать действие

Сообщения «Объект не найден», битые ссылки в документахЗапустите только проверку ссылочной целостности

Отчёты показывают неверные остатки по регистрамВыполните пересчёт итогов

База стала медленно работать, запросы тормозятВыполните реиндексацию (или обслуживание индексов средствами СУБД)

Файл базы сильно разросся после свёртки или удаления данныхВыполните сжатие таблиц в файловом варианте

После сбоя питания база не открывается или падаетСначала chdbfl.exe или проверка физической целостности, затем тестирование и исправление

Частые вопросы

Можно ли прервать тестирование и исправление в середине?

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

Нужно ли запускать проверку регулярно, если ошибок нет?

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

Чем отличается утилита chdbfl от тестирования в конфигураторе?

chdbfl.exe проверяет физическую целостность файла базы — целостность страниц и структуры хранения. Её используют, когда файл повреждён и конфигуратор не открывается. Тестирование и исправление работает на уровне логики данных и запускается уже на открывающейся базе.

Почему проверка на копии прошла за час, а на рабочей базе идёт дольше?

Чаще всего из-за разницы в оборудовании и загрузке: тестовый прогон делали на локальном SSD, а рабочая база лежит на сетевом диске или загруженном сервере. Также рабочая база могла вырасти за время между тестом и реальным запуском.

Удалит ли исправление мои документы и справочники?

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

Можно ли проводить проверку, пока пользователи работают?

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