Индексы базы 1С под нагрузкой: когда их перестраивать и как это делается в Конфигураторе и СУБД

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

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

Почему база 1С замедляется и при чём тут индексы

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

Индекс портится или теряет эффективность по нескольким причинам:

• ⚡ Аварийное завершение работы. Отключение питания, зависший сеанс, снятый процесс 1cv8.exe во время записи. В файловой базе индекс может остаться недописанным.
• 📈 Активная запись. Тысячи проведений, перепроведение месяца, загрузка данных из обмена. Страницы индекса дробятся, появляются «дыры» — это и есть фрагментация.
• 🗑️ Массовое удаление. После удаления помеченных объектов индекс хранит пустые места, которые всё равно приходится читать.
• 🌐 Сетевая файловая база. Если база лежит на общей папке, обрыв связи у одного пользователя может оставить файл 1Cv8.1CD в несогласованном состоянии.

Как это выглядит со стороны пользователя:

• 🐢 списки, журналы и отборы открываются заметно дольше, чем неделю назад;
• 🔍 отбор или поиск по полю не находит объект, который виден в общем списке;
• 📄 отчёт показывает одни цифры, а та же выборка в другом отчёте — другие;
• ⏳ проведение документа «висит» на записи движений.

Реиндексация, реструктуризация, сжатие: чем отличаются процедуры обслуживания

В окне «Тестирование и исправление» флажки стоят рядом, и их часто включают все сразу «на всякий случай». Это лишние часы простоя. Каждая процедура решает свою задачу.

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

Ещё одна путаница — физическая проверка файла. Утилита chdbfl.exe из каталога bin платформы проверяет сам файл 1Cv8.1CD на уровне страниц. Её запускают, когда база не открывается вовсе и до Конфигуратора дело не доходит.

Режимы запуска: файловая база, клиент-серверная и пакетный режим

Как именно перестраивать индексы, зависит от типа базы. Тип виден в окне запуска: выделите базу, и внизу появится строка подключения. File="D:\Bases\Buh" — файловая, Srvr="server";Ref="buh" — серверная.

Файловая база

Здесь вся база — один файл 1Cv8.1CD, и индексы хранятся внутри него. Реиндексацию выполняет сама платформа через Конфигуратор. Это основной и единственный штатный способ.

Клиент-серверная база

Таблицы и индексы живут в СУБД: Microsoft SQL Server, PostgreSQL или другой. В Конфигураторе флажок реиндексации доступен, но для регулярного обслуживания правильнее средства самой СУБД: они работают быстрее, умеют перестраивать индекс без остановки всей базы и запускаются по расписанию.

Для MS SQL Server — план обслуживания (Maintenance Plan) с задачами перестроения индексов и обновления статистики, или скрипт:

-- обновить статистику по всей базе
EXEC sp_updatestats;

-- перестроить все индексы одной таблицы
ALTER INDEX ALL ON dbo._Document123 REBUILD;

Для PostgreSQL:

-- перестроить индексы всей базы (подключившись к ней)
REINDEX DATABASE buh;

-- собрать статистику и освободить «мёртвые» строки
VACUUM ANALYZE;

Пакетный режим без открытия Конфигуратора

Для файловой базы реиндексацию удобно запускать по расписанию из командной строки. Платформа поддерживает параметр /IBCheckAndRepair с ключами операций:

"C:\Program Files\1cv8\8.3.25.1394\bin\1cv8.exe" DESIGNER ^
  /F"D:\Bases\Buh" /N"Администратор" /P"пароль" ^
  /IBCheckAndRepair -ReIndex ^
  /Out"D:\Logs\reindex.log" /DisableStartupMessages

Номер платформы в пути подставьте свой. Другие ключи того же параметра: -LogIntegrity (логическая целостность), -RecalcTotals (пересчёт итогов), -IBCompression (сжатие), -TestOnly (только тестирование без исправлений). Полный список — в справке Конфигуратора по параметрам командной строки.

Реиндексация таблиц информационной базы пошагово

Порядок ниже — для файловой базы через Конфигуратор. Ориентировочное время: от нескольких минут для базы в 1–2 ГБ до часа и больше для 20–30 ГБ, на SSD быстрее.

Шаг 1. Освободите базу

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

1. Предупредите коллег заранее и назначьте время.
2. Проверьте список активных пользователей: в Конфигураторе Администрирование → Активные пользователи.
3. Если кто-то «забыт» в базе — свяжитесь с ним. Принудительное завершение сеанса прервёт его несохранённую работу.

Шаг 2. Сделайте резервную копию

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

• Выгрузка: Администрирование → Выгрузить информационную базу — получите файл .dt.
• Для файловой базы дополнительно скопируйте папку целиком, пока база закрыта. Копия файла 1Cv8.1CD восстанавливается быстрее, чем загрузка .dt.

Шаг 3. Откройте тестирование

1. Запустите базу в режиме Конфигуратор.
2. Откройте Администрирование → Тестирование и исправление.
3. Поставьте флажок «Реиндексация таблиц информационной базы».
4. Остальные флажки снимите, если нет конкретной причины их включать.

Шаг 4. Выберите режим и запустите

В нижней части окна есть переключатель между режимом «Тестирование и исправление» и «Только тестирование». Для реиндексации нужен первый: проверка без исправления индексы не перестроит.

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

Шаг 5. Проверьте результат

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

Диагностика: как понять, что реиндексация помогла

Без замеров «стало быстрее» — это ощущение. Зафиксируйте цифры до и после.

Для файловой базы:

1. Выберите 3–4 эталонные операции: открыть журнал документов за год, сформировать оборотно-сальдовую ведомость за квартал, провести типовой документ.
2. Засеките время каждой до обслуживания и после.
3. Запишите размер файла 1Cv8.1CD. Сама реиндексация его почти не меняет; заметно уменьшает только сжатие таблиц.

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

Для MS SQL Server степень фрагментации видно запросом:

SELECT OBJECT_NAME(ips.object_id) AS tbl,
       i.name AS idx,
       ips.avg_fragmentation_in_percent AS frag
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i
  ON i.object_id = ips.object_id AND i.index_id = ips.index_id
WHERE ips.page_count > 1000
ORDER BY frag DESC;

Привычная практика: при фрагментации 5–30% индекс реорганизуют (REORGANIZE), выше 30% — перестраивают (REBUILD). Маленькие индексы до тысячи страниц можно не трогать — эффекта почти нет.

Для PostgreSQL полезно смотреть, когда таблицы последний раз обрабатывались автоочисткой и сколько в них «мёртвых» строк — это колонки n_dead_tup и last_autovacuum в представлении pg_stat_user_tables.

Регламент обслуживания базы 1С

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

Несколько правил, которые делают регламент рабочим:

• 🕑 Окно обслуживания закреплено. Например, воскресенье с 22:00. Пользователи знают, что в это время база недоступна.
• 🧾 Журнал работ. Дата, что запускали, сколько длилось, что нашлось. Через полгода по этой таблице видно, как растёт база и когда пора менять железо.
• 🔁 Проверка восстановления. Раз в квартал разверните резервную копию в тестовую базу. Бэкап, который никто не пробовал загрузить, — не бэкап.
• 📦 Перед обновлением конфигурации — внеочередная копия и тестирование «без исправления». Обновлять базу с битыми индексами рискованно: ошибка всплывёт посреди обновления.

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