Чому б не відновити індекси з кількістю сторінок <1000?

Я використовую сценарій Ola Hallengrens для обслуговування індексу. Перш ніж я це зробив, я використав наступний запит, щоб побачити, які індекси фрагментовані найбільше:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

У моєму випадку avg_fragmentation становив понад 70% для 15 індексів та понад 30% для 28 індексів.

Отже, я відновлюю кожен індекс, використовуючи рішення Ola Hallengren. Коли я знову запустив запит, це був результат:

Фрагментація понад 70% для 12 індексів, понад 30% для 15 індексів.

Я подумав, що причина в тому page_count, що вона була нижчою за 1000 для кожного з індексів, які ще були дуже фрагментарно. Наприклад, один з індексів page_count 967 має відсоток фрагментації 98,98% ! Мені здається, варто відновити цей індекс! Я це зробив, і після цього фрагментація становила 0% . Також індекс зі page_countзначенням 132 пішов від 95% до 0%

Отже, моє запитання полягає в тому, які причини були б не перебудовувати ці індекси? Однією з причин може бути те, що відбудова коштує часу та ресурсів, але оскільки показники невеликі, чи це не означає, що це коштує відносно мало ресурсів, і все одно буде відносно його відновити?

На цьому сайті є декілька пов'язаних запитань, але всі вони відповідають на питання, чому індекс не дефрагментує, або якщо індекси все ще корисні, якщо вони невеликі, і ви не дефрагментуєте їх, тоді як тут твердження НЕ зменшує фрагментацію, питання в тому, чому б це не зробити все одно?

Вказівки щодо мінімальної кількості сторінок дещо довільні . Найбільші переваги зменшення фрагментації:

1. Це може покращити ефективність читання вперед для сканування великого діапазону; і
2. Це може покращити щільність сторінки (кількість рядків на сторінці)

Обидва ці фактори є менш важливими для малих показників, за визначенням.

Контраргумент відновлення малих індексів по суті:

"Чому турбувати? Хіба у вас немає важливіших справ, про які слід турбуватися?".

Однак, відбудова / реорганізація не є безкоштовною. Можливо, варто уникнути додаткових зусиль та створення журналу в деяких випадках (наприклад, якщо журнал надсилається / копіюється через WAN з будь-якої кількості можливих причин - дзеркальне відображення, групи доступності, тиражування ...). Крім того, якщо (або навіть якщо, в деяких випадках) ви перебудовуєтесь в Інтернеті, відновлення може вплинути на інші одночасні процеси через блокування. Нарешті, для невеликих індексів перебудова може взагалі навіть не зменшити фрагментацію через виділення зі змішаних розширень (якщо ви не працюєте із включеним прапором сліду 1118 ).

Якщо ви все ще відчуваєте себе щасливішим, будуючи ці невеликі індекси і не заперечуючи наслідків, то будь-яким чином змініть значення @PageCountLevelпараметра, переданого процедурі Оли.

Дивіться запис програми PASS TV про презентацію Пола Рандала про фрагментацію індексу для всіх деталей.

Ви також можете побачити, як Brent Ozar розповідає про те, чому фрагментація індексу не має значення на SQL Server.