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

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

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

Ниже разобраны все рабочие сценарии: стандартная переиндексация через «Тестирование и исправление», отдельная переиндексация таблиц в режиме предприятия, восстановление индексов утилитой chdbfl при физическом повреждении файла, а также особенности работы с серверными базами на MS SQL или PostgreSQL.

Когда переиндексация действительно нужна

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

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

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

Первый шаг — резервная копия. Для файловой базы достаточно скопировать файл 1Cv8.1CD в отдельный каталог при остановленной работе пользователей, либо выполнить выгрузку в файл .dt через конфигуратор (Администрирование → Выгрузить информационную базу). Копирование файла надёжнее, потому что выгрузка .dt из повреждённой базы может сама завершиться ошибкой. Для клиент-серверной базы делается бэкап средствами СУБД.

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

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

Переиндексация через конфигуратор: тестирование и исправление

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

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

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

Точечная переиндексация в режиме «Предприятие»

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

Откройте «Все функции» (включается через Сервис → Параметры → отображать команду «Все функции»), найдите в дереве раздел «Стандартные» → «Управление итогами» или используйте обработку переиндексации таблиц. Точечная операция выполняется за секунды или минуты и часто не требует монопольного режима, хотя при активной работе пользователей с этими таблицами возможны блокировки.

Восстановление индексов утилитой chdbfl.exe

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

Порядок работы: скопируйте файл базы в отдельный каталог, запустите chdbfl.exe, укажите путь к копии файла, отметьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита проверит физическую структуру, включая индексные страницы, и попытается восстановить повреждённые участки. После успешной проверки файл возвращается на место (с сохранением старого повреждённого файла как страховки), и базу дополнительно прогоняют через тестирование и исправление в конфигураторе.

Особенности клиент-серверных баз

В клиент-серверном варианте индексы физически хранятся в СУБД, поэтому есть два уровня задач. Логическая переиндексация через «Тестирование и исправление» в конфигураторе работает так же, как для файловой базы, и требует монопольного доступа. А вот фрагментация индексов — естественный процесс при активной записи — устраняется средствами самой СУБД: в MS SQL это перестроение (rebuild) или реорганизация (reorganize) индексов, в PostgreSQL — команды REINDEX и регламентный VACUUM.

Для серверных баз рекомендуется настроить регулярное регламентное обслуживание индексов на стороне СУБД, а не ждать симптомов. Пороги выбора между reorganize и rebuild зависят от процента фрагментации — общепринятая практика: реорганизация при умеренной фрагментации, полное перестроение при высокой. Конкретные скрипты должен согласовать администратор СУБД с учётом редакции SQL Server и окна обслуживания.

-- Пример для MS SQL: перестроение всех индексов таблицы
ALTER INDEX ALL ON _Document123 REBUILD WITH (ONLINE = OFF);

-- Пример для PostgreSQL: переиндексация таблицы
REINDEX TABLE _document123;

Проверка результата и типичные ошибки

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

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

FAQ: частые вопросы о переиндексации 1С