Apakah waktu yang diperlukan untuk membangun kembali indeks tergantung pada tingkat fragmentasi?
Apakah pembangunan kembali indeks terfragmentasi 80% kira-kira memakan waktu 2 menit jika pembangunan kembali indeks yang sama terfragmentasi 40% membutuhkan waktu 1 menit?
Saya meminta RUNTIME (misalnya dalam hitungan detik) yang mungkin diperlukan untuk melakukan tindakan yang diperlukan, bukan tentang tindakan apa yang diperlukan dalam situasi tertentu apa. Saya menyadari praktik terbaik dasar ketika indeks reorg atau membangun kembali / pembaruan statistik harus dilakukan.
Pertanyaan ini TIDAK bertanya tentang REORG dan perbedaan antara REORG dan REBUILD.
Latar belakang: Karena pengaturan pekerjaan pemeliharaan indeks yang berbeda (setiap malam, pekerjaan yang lebih berat di akhir pekan ...) Saya bertanya-tanya apakah pekerjaan pemeliharaan indeks OFFLINE "intens cahaya" harian harus lebih baik dilakukan pada indeks terfragmentasi menengah-rendah untuk menjaga agar off-kali kecil - atau bahkan tidak masalah dan pembangunan kembali pada indeks terfragmentasi 80% mungkin mengambil off-waktu yang sama dengan operasi yang sama pada indeks yang sama 40% terfragmentasi.
Saya mengikuti saran dan mencoba mencari tahu sendiri apa yang sedang terjadi. Pengaturan eksperimental saya: Pada server uji yang melakukan TIDAK ADA yang lain dan tidak digunakan oleh siapa pun atau apa pun, saya membuat tabel dengan Indeks Clustered pada kolom kunci primer pengenal unik dengan beberapa kolom tambahan dan tipe data berbeda [2 angka, 9 datetime, dan 2 varchar (1000)] dan cukup menambahkan baris. Untuk tes yang disajikan saya menambahkan sekitar 305.000 baris.
Kemudian saya menggunakan perintah pembaruan dan secara acak memperbarui berbagai baris pemfilteran pada nilai integer dan mengubah salah satu Kolom VarChar dengan nilai string yang berubah untuk membuat fragmentasi. Setelah itu saya memeriksa avg_fragmentation_in_percentlevel saat ini di sys.dm_db_index_physical_stats. Setiap kali saya membuat fragmentasi "baru" untuk tolok ukur saya, saya menambahkan nilai ini termasuk physical_page_countnilai ke rekaman saya yang terbuat dari diagram berikut.
Lalu aku Ran: Alter index ... Rebuild with (online=on);
dan meraihnya CPU timedengan menggunakan STATISTICS TIME ONrekamanku.
Harapan saya: Saya berharap untuk melihat setidaknya indikasi semacam kurva linier yang menunjukkan ketergantungan antara tingkat fragmentasi dan waktu cpu.
Ini bukan kasusnya. Saya tidak yakin apakah prosedur ini benar-benar sesuai untuk hasil yang baik. Mungkin jumlah baris / halaman terlalu rendah?
Namun hasilnya menunjukkan bahwa jawaban atas pertanyaan awal saya pasti adalah TIDAK . Sepertinya waktu cpu yang diperlukan SQL Server perlu membangun kembali indeks tidak tergantung pada tingkat fragmentasi atau tergantung pada Jumlah Halaman dari indeks yang mendasarinya.
Grafik pertama menunjukkan waktu cpu yang diperlukan untuk MEMBANGUN KEMBALI indeks dibandingkan dengan tingkat fragmentasi sebelumnya. Seperti yang Anda lihat garis rata-rata adalah relatif konstan dan sama sekali tidak ada hubungan antara fragmentasi dan waktu cpu yang diperlukan diamati.
Untuk menghormati pengaruh yang mungkin dari perubahan jumlah halaman dalam indeks setelah pembaruan saya yang dapat membutuhkan lebih banyak atau lebih sedikit waktu untuk membangun kembali, saya menghitung TINGKAT FRAGMENTASI * HALAMAN COUNT dan menggunakan nilai ini pada bagan kedua yang menunjukkan hubungan waktu cpu yang diperlukan vs. fragmentasi dan jumlah halaman.
Seperti yang Anda lihat, ini juga tidak menunjukkan bahwa waktu yang diperlukan untuk membangun kembali dipengaruhi oleh fragmentasi bahkan jika jumlah halaman berbeda.
Setelah membuat pernyataan itu, saya kira prosedur saya pasti salah karena waktu cpu diperlukan untuk membangun kembali indeks yang besar dan sangat terfragmentasi maka mungkin hanya dipengaruhi oleh jumlah baris - dan saya tidak benar-benar percaya pada teori ini.
Jadi, karena saya benar-benar dan pasti ingin mengetahui ini sekarang, komentar dan rekomendasi lebih lanjut sangat disambut .
