Mengapa tidak membangun kembali indeks dengan jumlah halaman <1000?

Saya menggunakan skrip Ola Hallengrens untuk pemeliharaan indeks. Sebelum saya melakukan itu, saya menggunakan kueri berikut untuk melihat indeks mana yang paling terfragmentasi:

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

Dalam kasus saya, avg_fragmentation lebih dari 70% untuk 15 indeks dan lebih dari 30% untuk 28 indeks.

Jadi, saya membangun kembali setiap indeks menggunakan solusi Ola Hallengren. Ketika saya menjalankan kueri lagi, inilah hasilnya:

Fragmentasi lebih dari 70% untuk 12 indeks, lebih dari 30% untuk 15 indeks.

Saya pikir, alasannya adalah karena page_count, yang lebih rendah dari 1000 untuk masing-masing indeks yang masih sangat terfragmentasi. Misalnya, salah satu indeks dengan page_count 967 memiliki persentase fragmentasi 98,98% ! Bagi saya, sepertinya layak membangun kembali indeks itu! Saya lakukan, dan setelah itu, fragmentasi adalah 0% . Juga, indeks dengan page_count132 naik dari 95% menjadi 0%

Jadi, pertanyaan saya adalah, apa alasannya untuk TIDAK membangun kembali indeks itu? Salah satu alasannya mungkin karena membangun kembali membutuhkan waktu dan sumber daya, tetapi karena indeksnya kecil, bukankah ini berarti biayanya relatif sedikit dan tetap bermanfaat untuk membangunnya kembali?

Ada beberapa pertanyaan terkait di situs ini, tetapi semuanya menjawab pertanyaan mengapa indeks tidak akan defragment, atau jika indeks masih berguna jika mereka kecil dan Anda tidak defragment, sedangkan di sini pernyataan TIDAK mengurangi fragmentasi, dengan pertanyaannya adalah, mengapa tidak melakukannya?

Panduan mengenai jumlah minimum halaman agak arbitrer . Manfaat terbesar mengurangi fragmentasi adalah:

1. Ini dapat meningkatkan kinerja baca-depan untuk pemindaian rentang besar ; dan
2. Ini dapat meningkatkan kepadatan halaman (jumlah baris per halaman)

Kedua faktor ini kurang penting untuk indeks kecil, menurut definisi.

Argumen tandingan untuk membangun kembali indeks kecil pada dasarnya:

"Kenapa repot-repot? Apakah kamu tidak memiliki hal-hal yang lebih penting untuk dikhawatirkan?"

Yang mengatakan, membangun kembali / reorganisasi tidak gratis. Mungkin ada baiknya menghindari upaya ekstra dan pembuatan log dalam beberapa kasus (misalnya, jika log dikirimkan / disalin ke seluruh WAN untuk sejumlah alasan yang memungkinkan - mirroring, grup ketersediaan, replikasi ...). Juga, kecuali (atau bahkan jika, dalam beberapa kasus) Anda membangun kembali secara online, pembangunan kembali dapat memengaruhi proses bersamaan lainnya melalui penguncian. Akhirnya, untuk indeks kecil, pembangunan kembali bahkan mungkin tidak mengurangi fragmentasi, karena alokasi dari luasan campuran (kecuali jika Anda menjalankan dengan jejak bendera 1118 diaktifkan).

Jika Anda masih merasa lebih bahagia membangun kembali indeks kecil ini, dan tidak keberatan dengan konsekuensinya, maka tentu saja ubah nilai @PageCountLevelparameter yang diteruskan ke prosedur Ola.

Lihat rekaman PASS TV dari presentasi Paul Randal tentang Indeks Fragmentasi untuk semua detailnya.

Anda mungkin juga ingin menonton Brent Ozar berbicara tentang Mengapa Indeks Fragmentasi tidak masalah di SQL Server.