Переиндексация в 1С: что это такое и когда её выполнять

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

Чаще всего о переиндексации вспоминают, когда база начинает «тормозить», отчёты формируются в разы дольше обычного, а при открытии списков документов возникают ошибки вида «Ошибка СУБД» или неверные итоги по регистрам. Это типичные признаки того, что индексы перестали соответствовать фактическим данным.

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

Что такое индексы и почему они «ломаются»

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

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

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

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

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

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

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

Файловая база, медленные отчёты, ошибок нетВыполните ТиИ с включённой переиндексацией в нерабочее время

Клиент-серверная база на MS SQL, рост времени запросовИспользуйте планы обслуживания SQL Server (перестроение/реорганизация индексов)

Ошибки СУБД и расхождение итогов после сбояСделайте копию, затем полное ТиИ с реиндексацией и проверкой ссылочной целостности

База работает нормальноПереиндексация не требуется — ограничьтесь регламентными копиями

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

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

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

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

Чем переиндексация отличается от других проверок ТиИ

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

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

Переиндексация в клиент-серверных базах

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

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

Способы переиндексации

ТиИ в конфигураторе

Подходит для файловых баз и восстановления после сбоев; требует монопольного доступа

Планы обслуживания MS SQL

Оптимально для клиент-серверных баз; гибкое расписание, меньше блокировок

Скрипты DBA (PostgreSQL и др.)

Для опытных администраторов; точечное перестроение конкретных индексов

Типичные ошибки и риски

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

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

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

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

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

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

Контрольные точки после переиндексации

Протокол ТиИ

Норма

Нет сообщений об ошибках

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

Есть ошибки чтения или записи таблиц

Скорость отчётов

Норма

Время вернулось к обычному уровню

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

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

Итоги по регистрам

Норма

Остатки совпадают с контрольными значениями

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

Итоги расходятся или сброшены

Журналы документов

Норма

Все документы отображаются и открываются

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

Записи пропадают или не открываются

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

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

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

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

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

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

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

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

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

ТиИ «зависло» — что делать?

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

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

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