Kapan saya harus membangun kembali indeks?


Jawaban:


41

Dengan risiko terlalu umum dalam jawaban saya, saya akan mengatakan bahwa Anda harus menjalankan proses pemeliharaan indeks secara teratur. Namun, proses pemeliharaan indeks Anda hanya akan membangun kembali / mengatur ulang indeks yang secara spesifik memerlukannya.

Ini menimbulkan pertanyaan: kapan indeks perlu dibangun kembali atau ditata ulang? Rolando menyentuh ini dengan baik. Sekali lagi, saya berisiko menjadi sangat luas. Indeks memerlukan pemeliharaan ketika tingkat fragmentasi mempengaruhi kinerja. Tingkat fragmentasi ini dapat bervariasi berdasarkan ukuran dan komposisi indeks.

Berbicara untuk SQL Server, saya cenderung memilih ukuran indeks dan tingkat indeks fragmentasi di mana saya mulai melakukan pemeliharaan indeks. Jika indeks berisi kurang dari 100 halaman, saya tidak akan melakukan pemeliharaan.

Jika indeks antara 10% dan 30% terfragmentasi, saya akan REORGANIZEindeks dan UPDATEstatistik. Jika indeks lebih dari 30% terfragmentasi, saya akan REBUILDindeks - tanpa UPDATE STATISTICS, karena ini diurus oleh REBUILD. Ingat juga bahwa pembangunan kembali hanya memperbarui objek statistik yang secara langsung terkait dengan indeks. Statistik kolom lainnya perlu dipelihara secara terpisah.

Jawaban ini benar-benar hanya jauh untuk mengatakan: Ya, Anda harus melakukan pemeliharaan indeks rutin, tetapi hanya pada indeks yang membutuhkannya.


19

Kapan saya harus membangun kembali indeks dalam basis data relasional saya (mis. SQL Server)?

Anda harus membangun kembali indeks ketika mereka menjadi sangat terfragmentasi oleh acara khusus. Misalnya, Anda melakukan beban data yang besar dan besar ke dalam tabel yang diindeks.

Apakah ada kasus untuk membangun kembali indeks secara teratur?

Jadi bagaimana jika indeks Anda menjadi terfragmentasi secara teratur karena aktivitas rutin? Haruskah Anda menjadwalkan pembangunan kembali reguler? Seberapa sering mereka harus berlari?

Tom Kyte , dalam utas Ask Tom klasik ini , merekomendasikan:

Jeda waktu antara pembuatan indeks kembali harus kira-kira SELAMANYA.

...

Tidak tahu bagaimana mengatakannya lebih baik - indeks ingin menjadi besar dan gemuk dengan ruang ekstra. Itu ada di kolom yang Anda perbarui - memindahkan entri indeks dari satu tempat ke tempat lain dalam indeks. Suatu hari baris memiliki kode "A", hari berikutnya kode itu adalah "G", lalu "Z" lalu "H" dan seterusnya. Jadi entri indeks untuk baris bergerak dari satu tempat ke tempat lain dalam indeks. Saat melakukannya, diperlukan ruang - akan, jika ruang tidak ada, kami membagi blok menjadi dua - dan membuat ruang. Sekarang indeks semakin gemuk. Seiring waktu indeksnya 2-3x ukurannya ketika Anda mulai dan "setengah atau lebih kosong" Tapi itu tidak masalah karena Anda memindahkan baris. Sekarang ketika kita memindahkan baris, kita tidak lagi harus membagi blok untuk memberi ruang - ruangan sudah tersedia.

Kemudian Anda datang dan membangun kembali atau menjatuhkan dan menciptakan kembali indeks (yang memiliki efek yang sama - hanya membangun kembali itu "lebih aman" - tidak memiliki peluang kehilangan indeks dan bisa lebih cepat karena indeks dapat dibangun kembali oleh memindai indeks yang sudah ada alih-alih memindai tabel dan menyortir dan membangun indeks baru). Sekarang, semua ruang yang bagus itu hilang. Kami memulai proses pemisahan blok lagi - membawa kami kembali ke tempat kami mulai.

Anda tidak menghemat ruang.

Indeks segera kembali seperti semula.

Anda hanya akan membuang-buang waktu untuk membangunnya kembali sehingga siklus setan ini terulang kembali.

Logikanya di sini adalah suara, tetapi bias terhadap profil beban baca-berat.

Indeks "gemuk" (yaitu indeks dengan banyak celah) memang menyimpan cukup banyak ruang untuk baris baru dan yang dipindahkan, sehingga mengurangi pemisahan halaman dan menjaga kecepatan penulisan Anda. Namun, ketika Anda membaca dari indeks lemak itu Anda harus membaca lebih banyak halaman untuk mendapatkan data yang sama karena Anda sekarang menyaring lebih banyak ruang kosong. Ini memperlambat bacaan Anda.

Jadi, dalam basis data baca-berat Anda ingin membangun kembali secara teratur atau mengatur ulang indeks Anda. (Seberapa sering dan dalam kondisi apa? Matt M sudah memiliki jawaban konkret untuk pertanyaan ini.) Dalam database yang mengalami aktivitas membaca dan menulis yang kira-kira setara, atau dalam database yang berat, Anda mungkin merusak kinerja database Anda dengan membangun kembali indeks. secara teratur.


11

Kebanyakan orang membangunnya kembali secara teratur sehingga mereka tidak pernah terpecah-pecah. Ketika Anda perlu membangunnya kembali didasarkan pada seberapa cepat mereka terfragmentasi. Beberapa indeks perlu sering dibangun kembali, yang lain pada dasarnya tidak pernah. Lihatlah skrip yang SQLFool kumpulkan yang menangani banyak hal untuk Anda.


Hanya FYI bagi pembaca yang budiman bahwa skrip SQLFool belum diperbarui dalam> 5 tahun sehingga mungkin tidak memasukkan lonceng dan peluit terbaru ketika melakukan hal tersebut.
LowlyDBA

Bahkan, saya percaya terakhir kali saya memeriksa situs (tidak dapat mencapainya sekarang (mungkin bukan pertanda baik)), Michelle tidak lagi aktif bekerja di SQL Server, dan tidak memiliki maksud aktif untuk mengerjakan skrip lebih lanjut . Jika itu berhasil untuk Anda, bagus! Untuk instalasi baru, pertimbangkan skrip Ola Hallengren : Saya telah menggunakan keduanya, dan ini bukan transisi yang sulit.
RDFozz

7

Seperti dicatat dalam jawaban yang diterima dari Matt M, aturan umum adalah bahwa indeks yang lebih dari 30% terfragmentasi harus dibangun kembali.

Kueri ini akan membantu Anda menemukan berapa banyak indeks yang Anda miliki yang lebih dari 30% terfragmentasi (ketika Anda memilikinya, Anda harus membangunnya kembali):

SELECT DB_NAME() AS DBName,
       OBJECT_NAME(ind.object_id) AS TableName,
       ind.name AS IndexName,
       indexstats.index_type_desc AS IndexType,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages,
       SUM(p.rows) AS Rows 
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
         INNER JOIN sys.indexes AS ind ON (    ind.object_id = indexstats.object_id
                                           AND ind.index_id = indexstats.index_id)
         INNER JOIN sys.partitions AS p ON (    ind.object_id = p.object_id
                                            AND ind.index_id = p.index_id)
 WHERE indexstats.avg_fragmentation_in_percent > 30
 GROUP BY
       OBJECT_NAME(ind.object_id),
       ind.name,
       indexstats.index_type_desc,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages 
 ORDER BY indexstats.avg_fragmentation_in_percent DESC

1
Ini tidak memberikan jawaban. Pertanyaannya bukan bagaimana saya menemukan indeks dengan kompresi "x", itu adalah "kapan saya harus membangun kembali indeks".
Max Vernon

1
Ini tidak memberikan jawaban untuk pertanyaan itu. Setelah memiliki reputasi yang cukup, Anda dapat mengomentari setiap pos ; alih-alih, berikan jawaban yang tidak memerlukan klarifikasi dari penanya . - Dari Ulasan
LowlyDBA

2
@ LowlyDBA - Mungkin agak ringkas, tapi saya pikir itu menjawab pertanyaan, dan memberikan sesuatu yang berguna untuk diskusi. Saya telah sedikit mengembangkannya untuk menjelaskan caranya. Amanda - jika hasil edit saya sepertinya berlebihan, jangan ragu untuk mengembalikannya!
RDFozz

Terima kasih, RDFozz. Kelihatan bagus. Ya, lebih dari 30% terfragmentasi adalah waktu untuk membangun kembali.
amandamaddox3

5

Kapan saya harus membangun kembali indeks?

Ketika persentase indeks fragmentasi lebih dari 30%.

Apakah ada kasus untuk membangun kembali indeks secara teratur?

Tidak ada kasus seperti itu, tetapi secara umum, melakukan Pemeliharaan Indeks seminggu sekali, selama akhir pekan adalah praktik terbaik untuk menjaga stabilitas lingkungan.

Saya akan merekomendasikan menggunakan skrip pemeliharaan dari Ola Hallengren (skrip pemeliharaan terbaik), menyesuaikan skrip berdasarkan lingkungan Anda dan menjadwalkannya untuk dijalankan selama akhir pekan.

https://ola.hallengren.com/

Catatan: Jangan lupa memperbarui statistik setelah membangun kembali indeks, karena indeks pembangunan kembali tidak memperbarui semua statistik.


Saya cukup yakin catatan Anda salah. Pembangunan kembali indeks memperbarui statistik. Indeks mengatur ulang tidak. Meskipun hanya memperbarui statistik untuk objek yang terkait dengan indeks, tidak semua statistik. Yang sedang berkata, saya sarankan memperbarui statistik sering juga untuk mengurangi kemungkinan perlambatan karena sniffing parameter dan rencana kueri yang buruk karena statistik yang ketinggalan zaman.
bmg002

1

Seperti kebanyakan hal di TI, itu tergantung. Masalah apa yang Anda coba perbaiki dengan melakukan indeks pembangunan kembali? Dapatkah Anda menunjukkan bahwa itu benar-benar memperbaiki masalah? Jika demikian, maka sesuaikan angka hingga Anda menemukan jumlah perawatan paling sedikit yang perlu Anda lakukan untuk memperbaiki masalah.

Jika itu tidak memperbaiki masalah, atau alasan Anda melakukannya adalah hanya untuk menenangkan beberapa metrik yang Anda pantau karena mungkin membuat segalanya lebih baik, maka semua yang Anda lakukan adalah membakar CPU dan IO dan mungkin membuat masalah Anda lebih buruk.

Ada argumen bahwa memperbaiki fragmentasi tidak akan membuat perbedaan pada server Anda, jadi apakah itu layak dilakukan secara teratur?

https://www.brentozar.com/archive/2017/12/index-maintenance-madness/

http://brentozar.com/go/defrag

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.