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

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

Универсального ответа «реиндексация длится N минут» не существует: на файловой базе объёмом в несколько гигабайт процедура может завершиться за 10–30 минут, а на клиент-серверной базе в сотни гигабайт — занять несколько часов. Длительность определяется объёмом данных, типом СУБД, производительностью дисковой подсистемы и тем, как именно запущена процедура.

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

Что происходит во время реиндексации

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

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

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

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

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

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

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

Ориентировочные сроки для разных сценариев

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

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

Как оценить время до запуска

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

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

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

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

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

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

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

Сравнение вариантов

Реиндексация через конфигуратор

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

Обслуживание индексов средствами СУБД

Гибкое планирование и обработка отдельных таблиц; подходит для крупных клиент-серверных баз. Требует навыков администрирования СУБД.

Полное тестирование и исправление

Включает реиндексацию вместе с проверками целостности; занимает значительно больше времени, запускать только при подозрении на повреждения.

Что делать, если процесс идёт слишком долго

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

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

Признаки нормы и проблемы

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

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

Активность диска во время процедуры

Норма

Диск загружен, процессор периодически нагружен

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

Нулевая активность диска и процессора длительное время

Сообщение в конфигураторе после завершения

Норма

Процедура завершена без сообщений об ошибках

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

Ошибки доступа, сообщения о повреждении таблиц

Работа базы после реиндексации

Норма

Списки и отчёты открываются быстрее, проведение документов ускорилось

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

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

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

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

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

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

Можно ли работать в базе во время реиндексации?

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

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

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

Как понять, что базе нужна реиндексация?

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

Чем реиндексация отличается от пересчёта итогов?

Реиндексация перестраивает индексы таблиц, а пересчёт итогов заново рассчитывает агрегированные значения регистров (остатки и обороты). Это разные операции: пересчёт итогов помогает при неверных остатках в отчётах, реиндексация — при общем замедлении выборок.

Нужно ли делать реиндексацию после загрузки большого объёма данных?

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

Что делать, если после реиндексации база не ускорилась?

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