← На главную

При администрировании баз данных 1С на MS SQL Server часто возникает ситуация, когда стандартные планы обслуживания ведут себя непредсказуемо. Одной из самых обсуждаемых проблем является длительное выполнение задачи «Перестроение индекса» (Rebuild Index) даже в тех случаях, когда фактическая фрагментация данных минимальна. Разберем детально, почему так происходит, проанализировав SQL сервер глазами 1С-специалиста, чтобы понять, что скрывается за «разрывом» во времени в логах и как оптимизировать этот процесс.

Анализируем механизм оценки фрагментации

Рассмотрим ситуацию, описанную пользователем: в логах зафиксировано, что само перестроение заняло всего 5 минут, однако между завершением предыдущей задачи и окончанием ребилда прошло более 40 минут. Выясним причину этого временного разрыва. Когда мы устанавливаем в настройках плана обслуживания фильтр, например «Фрагментация > 30%», SQL Server не берет эти данные из готового кэша. Информация о фрагментации нигде не хранится в статичном виде.

Для определения необходимости перестроения система запускает функцию sys.dm_db_index_physical_stats. Проанализируем, как она работает:

1. Сканирование индексов: Чтобы вычислить процент фрагментации, серверу необходимо прочитать страницы индекса. В зависимости от объема базы данных и количества индексов, это чтение может занимать десятки минут.
2. Режимы работы: По умолчанию планы обслуживания могут использовать разные режимы сканирования (LIMITED, SAMPLED или DETAILED). Даже в самом быстром режиме LIMITED сервер сканирует уровни над листовым, что создает серьезную нагрузку на дисковую подсистему.
3. Отсутствие логирования анализа: Важно понимать, что время, затраченное на этот предварительный анализ, не попадает в лог выполнения самой операции перестроения. Лог начинает фиксировать время только тогда, когда сервер уже определил список таблиц и приступил к физическому ALTER INDEX REBUILD.

Таким образом, «разрыв» в 35 минут — это время, в течение которого SQL Server «молча» изучал структуру ваших индексов, чтобы решить, нужно ли их трогать.

Разберем проблему малых таблиц и «правило 1000 страниц»

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

Стандартный «План обслуживания» часто игнорирует этот порог. Рассмотрим последствия: сервер тратит время на анализ сотен мелких системных таблиц 1С (например, таблицы констант, небольшие справочники). Даже если перестроение для них занимает доли секунды, суммарное время на анализ и микро-операции складывается в значительные цифры. К сожалению, штатный конструктор планов в Management Studio не всегда позволяет гибко настроить исключение малых таблиц.

Выясняем причины избыточности задачи «Обновление статистики»

Посмотрим на типичная цепочку задач: «Перестроение индекса» — затем «Обновление статистики». Здесь кроется серьезная ловушка для производительности. Разберем технический нюанс: выполнение команды ALTER INDEX REBUILD автоматически обновляет статистику для этого индекса с параметром FULLSCAN. Это максимально точный вид обновления статистики.

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

• Если в плане стоит Rebuild, то последующее обновление статистики для этих же данных избыточно.
• Обновление статистики имеет смысл запускать только для тех столбцов, которые не входят в индексы, или если вместо перестроения выполнялась реорганизация (Reorganize), так как реорганизация статистику не обновляет.

Сравниваем Rebuild и Reorganize: что быстрее?

Рассмотрим спорный момент: почему реорганизация иногда длится дольше перестроения? Выясним причину в различии подходов:

1. Reorganize (дефрагментация): Это однопоточная операция. Она последовательно переупорядочивает страницы листового уровня. Она потребляет меньше ресурсов и не блокирует таблицу (всегда Online), но при высокой фрагментации может длиться бесконечно долго.
2. Rebuild (перестроение): Это создание индекса «с нуля». SQL Server может использовать MAXDOP, выполняя переиндексацию в несколько потоков, чтобы задействовать все ядра процессора и быстро перестроить всё дерево индекса.

Как отмечают специалисты, при фрагментации выше 30-40% гораздо эффективнее «бабахнуть» индекс заново через Rebuild, чем пытаться перемещать отдельные страницы через Reorganize. Именно поэтому благодаря адаптивному обновлению индексов MS SQL важно правильно выставлять пороги срабатывания.

Как профессионально решить проблему (Скрипты Олы Холленгрена)

Проанализировав все недостатки стандартных планов обслуживания, мы придем к выводу, который разделяет большинство опытных администраторов: стоит отказаться от стандартного конструктора в пользу профессиональных решений, таких как скрипты Олы Холленгрена с доработками под 1С 8.3.22. Рассмотрим их преимущества:

1. Интеллектуальный анализ: Скрипт выполняет проверку фрагментации один раз для всех типов действий. Он сохраняет результаты и на их основе решает: перестраивать, реорганизовывать или оставить как есть.

2. Гибкие фильтры: Мы можем легко задать условие не трогать индексы меньше определенного размера. Например, пример вызова процедуры с ограничением по количеству страниц:

EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @PageCountLevel = 1000 -- Игнорируем таблицы меньше 1000 страниц

3. Детальное логирование: В отличие от стандартного плана, такие скрипты записывают время начала и окончания обработки каждого конкретного индекса в специальную таблицу. Мы всегда сможем точно определить, какая таблица 1С (например, _InfoRg или _Document) вызвала задержку.

Резюме и рекомендации

Подводя итог, отметим: если ваше задание перестроения индексов выполняется долго при малых объемах изменений, это не ошибка программы, а особенность работы стандартных механизмов SQL Server по оценке фрагментации. Чтобы ускорить обслуживание баз 1С, придерживайтесь следующих правил:

• Проверьте, не дублируете ли вы Update Statistics сразу после Rebuild.
• Убедитесь, что объем лога транзакций (.ldf) и скорость диска, где он лежит, позволяют быстро записывать операции перестроения (особенно в модели FULL).
• Рассмотрите возможность перехода на скрипты обслуживания с открытым исходным кодом, которые позволяют пропускать маленькие таблицы и более эффективно анализировать состояние базы данных.