DBA yang khawatir reorganisasi atau rebuidling indeks dapat menyebabkan kehilangan data?

14

Kami memiliki beberapa database dengan fragmentasi indeks> 95%. Yang terbaik yang bisa saya katakan adalah indeks tidak pernah dibangun kembali apalagi direorganisasi. Bertahun-tahun.

(Dalam keadilan, tabel ini tampaknya memiliki statistik yang diperbarui secara otomatis diaktifkan. Juga dalam keadilan, ia rajin tentang cadangan: harian penuh dan trx log setiap jam.)

Ketika saya bertanya, DBA mengatakan dia enggan untuk membangun kembali atau memperbarui indeks. Ketika saya bertanya mengapa, dia tidak bisa mengartikulasikannya. Akhirnya dia berkata dia khawatir tentang kehilangan data potensial. Misalnya salah satu database digunakan oleh aplikasi akuntansi Great Plains Dynamics kami, dan dia tampak sangat cemas tentang itu.

Saya bukan seorang DBA tetapi dari apa yang saya baca, kegelisahannya tampaknya ... sulit untuk saya pahami.

Saya tidak yakin apa yang harus dilakukan selanjutnya. Saran bagaimana saya harus melanjutkan?

sql-server maintenance Greg Hendershott
sumber
Kecuali jika basis data terpukul 24/7, dan dunia akan berakhir jika offline, tidak ada alasan untuk perilaku tersebut. Saya menulis ulang reorg dan statistik setiap minggu di lebih dari 12.000 basis data tanpa pikir panjang. Dalam 16 tahun saya hanya punya satu korup karena pengontrol yang buruk.
Brain2000

Jawaban:

22

Membangun kembali indeks database tidak boleh menyebabkan kehilangan data. Namun itu mungkin akan menyebabkan penurunan kinerja yang substansial karena indeks yang dibangun kembali biasanya tidak akan tersedia untuk digunakan sampai pembangunan kembali selesai. Untuk alasan itu harus dilakukan selama jam-jam ketika sistem yang terpengaruh menganggur.

Paranoia adalah Hal yang Baik dalam DBA - Jika mereka khawatir tentang kehilangan data, saya ingin mereka melakukan tes cadangan yang benar (kembalikan ke sistem yang terpisah dan pastikan semua data ada di sana), dan jika mereka masih khawatir kemudian melakukan pencadangan penuh sebelum membangun kembali indeks akan menjadi tindakan pencegahan yang wajar untuk dilakukan.

voretaq7
sumber
11
+1 untuk Paranoia Baik DBA Trait
Joel Coel
Saya benar-benar mengerti dan menghargai paranoia yang sehat. Ukur dua kali, potong sekali. Di mana saya bingung adalah ini tampaknya tentang kurangnya pemahaman daripada kehati-hatian. Dan alih-alih "mari kita tentukan cara untuk mencobanya, hati-hati", ini "ya tidak akan terjadi". Kita dapat (katakan) mengumpulkan contoh uji EC2 dengan salinan data, memeriksa kembali indeks, menghitung waktu, menghapus baris tabel hasil untuk mengonfirmasi tidak ada data yang rusak. Rencana semacam itu akan menjadi peringatan ... sebagai lawan dari tidak bertindak?
Greg Hendershott
1
Hanya pengingat bahwa indeks direorganisasi selalu online (semua indeks tersedia selama defrag) dan indeks membangun kembali dapat dilakukan secara online ( WITH (ONLINE=ON)selama indeks tidak mengandung kolom BLOB.
Remus Rusanu
@Greg Ya, mentalitas "Mari kita tidak menyentuh indeks yang begitu terfragmentasi, mereka mungkin MELAKUKAN kinerja" membingungkan mental saya juga - Kadang-kadang REINDEXsebagai "pemeliharaan preventif" pada tabel di mana isi indeks banyak berubah cukup cantik umum dalam pengalaman saya (jika sebagian besar indeks statis itu kurang dari satu hal)
voretaq7
@Remus good tip - Ini mengurangi dampak kinerja (Anda masih akan memiliki I / O disk tinggi, yang akan memperlambat Anda, tetapi setidaknya hal-hal yang akan menggunakan indeks masih dapat menggunakannya daripada beralih ke pemindaian berurutan )
voretaq7
6

Tidak ada risiko kehilangan data dari pembangunan kembali atau defragging indeks.

mrdenny
sumber
Kecuali Anda sudah memiliki beberapa tingkat kerusakan data, atau ada perangkat keras yang rusak. Namun dalam salah satu kasus tersebut, indeks fragmentasi adalah yang paling tidak Anda khawatirkan!
db2
Tetapi itu bukan korupsi dari pembangunan kembali indeks, tetapi dari beberapa masalah lain.
mrdenny
4

Mengatur ulang indeks akan memakan waktu lebih sedikit, dan lebih sedikit upaya dari server SQL sehingga mereka dapat dilakukan dalam jenis contoh hari kerja. Jika apa yang Anda katakan itu benar, bahkan mengatur ulang indeks yang belum pernah ada, dapat menyebabkan dampak yang lebih besar pada server juga. Membangun kembali indeks akan mengambil banyak upaya dari server SQL sejak mereka dijatuhkan dan dibangun kembali. Melakukan pembangunan kembali pada hari kerja tidak sebanding dengan risiko server sibuk dengan indeks dan tidak melayani orang yang menggunakannya.

Saya setuju dengan voretaq7, jika dia khawatir bekerja dengan indeks, coba pada pengembangan atau uji server terlebih dahulu untuk melihat bagaimana reaksinya.

RateControl
sumber
Pendekatan lain untuk mengambil mungkin untuk secara eksplisit DROP INDEXdan ulang CREATE INDEX- Saya tidak yakin tentang SQL Server, tapi saya tahu PostgreSQL kadang-kadang lebih baik meniup indeks dan mulai dari awal daripada mencoba membangun kembali ( REINDEX) itu.
voretaq7
Saya cukup yakin menjatuhkan dan membuat ulang tidak perlu di SQL Server.
Justin Dearing
@Justin Saya cukup yakin Anda benar (sebenarnya dari hari-hari Sybase saya, saya ingat bahwa perilaku pengindeksan ulang secara efektif adalah drop / create sehingga tidak ada keanehan penguncian indeks seperti di Postgres)
voretaq7
Pengorganisasian ulang indeks bisa memakan waktu lebih sedikit. Yang mana yang membutuhkan waktu lebih lama akan tergantung pada jumlah fragmentasi indeks.
mrdenny