К статье
Практический материал

Администрирование · 12 мин

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

Как перестроить индексы в 1С: тестирование и исправление, конфигуратор, средства СУБД. Признаки проблем с индексами, риски и проверка результата.

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

Способ перестроения зависит от того, какая у вас база: файловая (файл 1Cv8.1CD на диске или сетевом ресурсе) или клиент-серверная (MS SQL Server, PostgreSQL, Oracle). Для файловой базы используется штатная процедура «Тестирование и исправление» в конфигураторе, а для серверной — средства самой СУБД. Подходы различаются принципиально, и путать их нельзя: запуск «Тестирования и исправления» на большой серверной базе может занять часы и заблокировать работу пользователей.

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

Когда нужно перестраивать индексы

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

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

Отчёты строятся в разы медленнееВозможна деградация индексов

Сравните время формирования типового отчёта с прежними значениями

Ошибка формата потокаВозможно повреждение данных или индексов

Запустите тестирование и исправление, проверьте журнал ошибок

База пережила сбой питанияРиск повреждения файла и индексов

Сделайте копию и выполните проверку физической целостности

Массово загружали или удаляли данныеИндексы могли фрагментироваться

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

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

Первый шаг — резервная копия. Для файловой базы достаточно скопировать файл 1Cv8.1CD при закрытых сеансах или воспользоваться выгрузкой в dt через конфигуратор. Для серверной базы делайте копию средствами СУБД — это быстрее и надёжнее выгрузки в dt на больших объёмах.

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

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

Перестройка индексов в файловой базе

Основной инструмент — «Тестирование и исправление информационной базы». Откройте базу в режиме конфигуратора, перейдите в меню «Администрирование» → «Тестирование и исправление». В списке проверок отметьте пункт «Реиндексация таблиц информационной базы». Если задача — только перестроить индексы, остальные проверки можно снять, чтобы не тратить время.

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

Порядок действий для файловой базы
  1. 1
    Сделайте копию файла 1Cv8.1CD или выгрузку в dt
  2. 2
    Завершите все сеансы пользователей и фоновые задания
  3. 3
    Откройте базу в конфигураторе
  4. 4
    Администрирование → Тестирование и исправление
  5. 5
    Отметьте «Реиндексация таблиц информационной базы», снимите лишние проверки
  6. 6
    Выберите режим «Тестирование и исправление», нажмите «Выполнить»
  7. 7
    Дождитесь завершения и изучите протокол
  8. 8
    Проверьте скорость работы типовых операций

Утилита chdbfl.exe для повреждённых баз

Если база не открывается даже в конфигураторе, штатная процедура недоступна. В этом случае используют утилиту chdbfl.exe из каталога bin установленной платформы 1С. Укажите путь к файлу 1Cv8.1CD, отметьте «Исправлять обнаруженные ошибки» и запустите проверку. Утилита работает на уровне физической структуры файла и часто спасает базы после сбоев.

Перестройка индексов в клиент-серверной базе

В клиент-серверном варианте таблицы и индексы хранятся в СУБД, поэтому работа с ними выполняется средствами СУБД. Для MS SQL Server стандартные команды — ALTER INDEX ... REBUILD для перестроения и ALTER INDEX ... REORGANIZE для реорганизации при умеренной фрагментации. Перестроение создаёт индекс заново и обновляет статистику, реорганизация — более лёгкая операция, которую можно выполнять чаще.

sql
ALTER INDEX ALL ON _Document123 REBUILD WITH (ONLINE = ON);

Практичный подход — настроить регулярный план обслуживания: реорганизацию индексов при фрагментации выше порогового значения и перестроение при сильной фрагментации, плюс обновление статистики. Для PostgreSQL аналогичные задачи решают команды REINDEX и плановый VACUUM ANALYZE. Конкретный регламент зависит от нагрузки и размера базы; универсальных порогов нет, ориентируйтесь на динамику производительности.

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

Способы перестройки индексов

Тестирование и исправление (конфигуратор)

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

chdbfl.exe

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

Средства СУБД (REBUILD / REORGANIZE / REINDEX)

Для клиент-серверных баз. Гибкое управление, возможен ONLINE-режим, подходит для регламентного обслуживания.

Проверка результата

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

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

Контрольные точки

Как проверить результат

Протокол тестирования и исправления
Норма

Нет сообщений о неисправимых ошибках

Тревожный признак

Ошибки остались после исправления

Время формирования типового отчёта
Норма

Вернулось к обычным значениям

Тревожный признак

Отчёт строится так же медленно

Открытие базы и вход пользователей
Норма

База открывается штатно, сеансы работают

Тревожный признак

Ошибки при входе, падения сеансов

Фрагментация индексов в СУБД
Норма

Снизилась после rebuild/reorganize

Тревожный признак

Осталась высокой — проверьте, какие таблицы затронуты

Типичные ошибки и ограничения

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

Ещё одна ошибка — применение chdbfl.exe к серверной базе (утилита бесполезна, там нет файла 1CD) или попытка чинить файловую базу, размещённую на сетевом диске, по сети. Работайте с локальной копией файла: сетевые задержки и обрывы в процессе исправления повышают риск повреждения.

Типичные ошибки
01
Запуск без резервной копии — при сбое процедуры базу может быть нечем восстановить
02
Прерывание процедуры кнопкой «снять задачу» — риск оставить базу в повреждённом состоянии
03
Ожидание, что реиндексация ускорит неоптимальные запросы конфигурации — эффект будет кратковременным
04
Использование chdbfl.exe для серверной базы — утилита работает только с файлами 1Cv8.1CD
05
Исправление файловой базы по сети — копируйте файл локально перед обработкой

Плановое обслуживание вместо аварийного

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

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

Итог

Что важно запомнить

Файловые базы обслуживаются через «Тестирование и исправление» с реиндексацией или утилитой chdbfl.exe, серверные — средствами СУБД. Всегда начинайте с резервной копии и монопольного доступа, завершайте проверкой протокола и реальной скорости работы. Регулярное плановое обслуживание надёжнее аварийных восстановлений.

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

Как часто нужно перестраивать индексы в файловой базе 1С?

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

Можно ли перестроить индексы, не заходя в конфигуратор?

Для файловой базы — только через конфигуратор или chdbfl.exe, штатного способа из режима «Предприятие» нет. Для серверной базы конфигуратор вообще не нужен: администратор СУБД выполняет перестроение индексов скриптами или планом обслуживания, не трогая клиентские приложения 1С.

Реиндексация удалит или изменит данные?

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

Что делать, если после тестирования и исправления ошибки остались?

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

Поможет ли перестройка индексов, если тормозит один конкретный отчёт?

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

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

Специально — нет: при реструктуризации платформа сама пересоздаёт затронутые таблицы и индексы. Но если обновление было масштабным и база после него работает медленнее, плановая реиндексация и обновление статистики СУБД — разумный шаг диагностики.