← На главную

При обслуживании баз данных 1С на платформе MS SQL Server администраторы часто сталкиваются с ситуацией: процедура перестроения индексов (REBUILD) успешно завершается, но при повторной проверке фрагментация десятков или даже сотен индексов остается выше 50%. Более того, пользователи начинают жаловаться на то, что 1С проводит документы дольше обычного. Проанализируем, почему так происходит и какие действия помогут вернуть быструю работу системы.

Причины высокой фрагментации после операции REBUILD

Выясним основные технические причины, по которым отчеты MS SQL Server продолжают показывать высокую фрагментацию даже после выполнения регламентных работ:

1. Небольшой размер таблиц. На маленьких таблицах (занимающих менее 100–1000 страниц данных) MS SQL Server распределяет страницы на смешанных экстентах. Для таких таблиц показатель логической фрагментации в 50–80% является нормальным поведением СУБД, так как оптимизатор все равно считывает их практически мгновенно.
2. Таблицы-кучи (Heap). Если у таблицы отсутствует кластерный индекс, перестроение только некластерных индексов не устраняет фрагментацию самого массива данных (кучи).
3. Специфика GUID в 1С. Платформа 1С активно использует случайные уникальные идентификаторы (GUID) в качестве ключей. При высокой интенсивности записи новых документов происходят постоянные расщепления страниц (page split), из-за чего фрагментация может снова вырасти до 50% и выше буквально за считанные минуты работы пользователей.
4. Ограничения оценки DMV. Системная функция sys.dm_db_index_physical_stats в режиме LIMITED может некорректно оценивать физическое состояние таблиц, имеющих поля неограниченной длины (данные LOB, такие как хранилища значений или длинные строки).

Влияние фрагментации и статистики на проведение документов

Замедление проведения документов в 1С далеко не всегда связано именно с физической фрагментацией страниц на диске, особенно при использовании современных дисковых накопителей (SSD/NVMe). Главной причиной замедления запросов чаще всего является устаревшая статистика MS SQL.

Когда статистика устаревает, оптимизатор запросов SQL Server строит неоптимальные планы выполнения (например, использует медленное соединение Nested Loops вместо быстрого Hash Match). В итоге проведение документа, затрагивающее регистры накопления и сведений, затягивается.

Шаги по решению проблемы и настройке СУБД

Рассмотрим комплекс мероприятий, который поможет устранить проблему и оптимизировать работу базы данных.

1. Исключение мелких таблиц из обслуживания

Настроим скрипты обслуживания так, чтобы операция перестроения выполнилась только для таблиц, размер которых превышает 1000 страниц (около 8 МБ). Это существенно снизит нагрузку на сервер и исключит бессмысленные операции.

2. Явное перестроение таблиц-куч (Heap)

Для таблиц без кластерного индекса выполним явную команду перестроения самой таблицы:

ALTER TABLE ИмяТаблицы REBUILD;

3. Обновление статистики с параметром FULLSCAN

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

UPDATE STATISTICS ИмяТаблицы WITH FULLSCAN;

4. Реструктуризация таблиц средствами 1С

Если фрагментация индексов SQL не устраняется из-за внутренних особенностей структурирования таблиц платформой, выполним реструктуризацию через Конфигуратор 1С. Для этого перейдем в меню Администрирование > Тестирование и исправление, установим флаг Реструктуризация таблиц и запустим процесс. Платформа пересоздаст физические таблицы базы данных SQL и перенесет данные последовательным потоком, что полностью ликвидирует фрагментацию.