Pertama, penting untuk mempertimbangkan apakah fragmentasi itu penting.
Jika permintaan Anda hanya melakukan pencarian baris tunggal, Anda mungkin tidak melihat fragmentasi sama sekali. Pada SAN modern, caching level SAN dapat membuat IO phyiscal cukup cepat sehingga fragmentasi tidak penting. Pada SSD, pola IO acak yang disebabkan oleh pemindaian indeks terfragmentasi sebenarnya dapat menghasilkan kinerja yang lebih baik daripada data yang tidak terfragmentasi.
Sering kali, orang-orang memperhatikan bahwa rebuiliding indeks memperbaiki masalah kinerja. Membangun kembali indeks juga membangun statistik baru. Ini mungkin kasus yang memperbaiki sebenarnya adalah statistik baru, bukan membangun kembali indeks. UPDATE STATISTICS...WITH FULLSCAN
mungkin cara yang lebih murah, lebih cepat, dan tidak terlalu mengganggu untuk menyelesaikan masalah kinerja yang sama.
Jika Anda tidak mengalami masalah yang disebabkan oleh fragmentasi, maka Anda bisa menghabiskan waktu & upaya yang signifikan tanpa keuntungan yang sebenarnya.
Kedua, ada dua jenis fragmentasi:
Fragmentasi fisik. Inilah yang kebanyakan orang pikirkan ketika mereka berpikir tentang fragmentasi. Halaman rusak, dan perlu dipesan ulang. Saat memindai indeks, jenis fragmentasi ini terkadang bisa menjadi masalah. Saya biasanya memperhatikan ini memiliki dampak terbesar pada kinerja dengan pembacaan fisik . Jika Anda melihat hasil dari sys.dm_db_index_physical_stats
, angka ini adalah avg_fragmentation_in_percent
kolom.
Fragmentasi kepadatan rendah. Fragmentasi ini disebabkan oleh halaman yang hanya diisi sebagian dengan data. Anda memiliki kepadatan data yang rendah karena data Anda tersebar di lebih dari halaman yang diperlukan. Akibatnya, membaca data memerlukan lebih banyak IO karena data tersebar di lebih banyak halaman daripada yang diperlukan. Ini dapat mempengaruhi bacaan logis dan fisik. Jika Anda melihat hasil dari sys.dm_db_index_physical_stats
, angka ini adalah avg_page_space_used_in_percent
kolom. Kolom ini hanya diisi ketika menggunakan SAMPLED
atau DETAILED
mode.
Jadi apa yang Anda lakukan tentang itu:
Fragmentasi Fisik : Jika Anda hanya mengejar angka tinggi avg_fragmentation_in_percent
, benar-benar mempertimbangkan jika Anda membuang-buang waktu. Pastikan Anda memiliki kueri aktual yang berkinerja buruk, dan gunakan lingkungan pengujian untuk mengonfirmasi bahwa Anda memperbaiki masalah dengan menghilangkan fragmentasi.
Anda dapat mengatasi fragmentasi fisik dengan melakukan ALTER INDEX...REORGANIZE
. The REORGANIZE
operasi online, bergerak halaman satu per satu untuk membenahi mereka kembali ke tatanan fisik. Jika Anda membunuh sebagian REORGANIZE
pernyataan melalui jalan, pekerjaan apa pun yang sudah dilakukan dipertahankan - hanya satu halaman saat ini sedang dipindahkan akan dibatalkan. Melakukan REORGANIZE
pada tabel besar yang sangat terfragmentasi dapat memerlukan lebih banyak ruang log transaksi total, dan dalam mode pemulihan penuh dapat menghasilkan sejumlah besar cadangan log transaksi. Mungkin juga membutuhkan waktu lebih lama untuk REORGANIZE
indeks yang sangat terfragmentasi daripada untuk REBUILD
itu.
Anda akan sering melihat saran untuk melakukan REBUILD
pada indeks yang sangat terfragmentasi, daripada a REORGANIZE
- Ini karena membangun kembali dari awal dapat lebih efisien. Namun, reorganisasi dapat menjadi operasi "lebih online" dan kadang-kadang lebih disukai, bahkan untuk indeks yang sangat terfragmentasi.
Fragmentasi kepadatan rendah tidak dapat diperbaiki oleh REORGANIZE
. Itu hanya dapat diperbaiki dengan melakukan ALTER INDEX...REBUILD
. Dengan melakukan indeks dengan ONLINE=ON
, Anda harus dapat meminimalkan pemblokiran. Namun, REBUILD
masih perlu mengambil kunci sejenak untuk menukar indeks lama dengan indeks baru. Pada sistem yang sangat sibuk, mendapatkan kunci eksklusif ini terkadang bisa menjadi masalah. Anda harus dapat mengonfirmasi jika Anda mengalami masalah ini dengan menggunakan sesuatu seperti sp_whoisactive untuk memeriksa pemblokiran selama Anda membangun kembali, dan melihat detail kunci & menunggu. Menggunakan WAIT_AT_LOW_PRIORITY
opsi ini mungkin berguna jika Anda tahu bahwa ada periode pemanfaatan rendah yang akan datang, dan pembangunan kembali Anda dapat "menyelinap" untuk swap ini ketika aktivitas turun cukup rendah untuk mencapai kunci itu. Perhatikan bahwa jangka panjangREBUILD
Operasi juga akan menjadi transaksi terbuka yang sudah berjalan lama. Transaksi terbuka jangka panjang dapat memiliki masalah sendiri, terkait dengan penggunaan / penggunaan kembali log transaksi. Jika Anda menggunakan mirroring atau Grup Ketersediaan, ada juga pertimbangan untuk transaksi log mengulang pada replika sekunder.
REORGANIZE
akan mengurangi fragmentasi halaman daun dan ruang yang kompakREBUILD
, hanya kurang efisien. Apakah Anda yakin ukuran besar disebabkan oleh fragmentasi? Apa faktor isi?