Endeksleri yeniden organize etmek veya yeniden oluşturmaktan endişe duyan DBA veri kaybına neden olabilir mi?

% 95'in üzerinde dizin parçalanması olan bazı veritabanlarımız var. En iyi haliyle, endekslerin hiçbir zaman yeniden inşa edilmediğini söyleyebilirim. Yıllar içinde.

(Adil olmak gerekirse, bu tabloların otomatik olarak güncellenmiş istatistiklerinin etkin olduğu görülüyor. Adil olmak gerekirse, yedeklemeler konusunda da gayretli: günlük olarak tam ve saat başı trx günlükleri.)

Sorduğumda, DBA endeksleri yeniden inşa etmek veya yeniden düzenlemek istemediğini söyledi. Nedenini sorduğumda, bunu gerçekten ifade edemedi. Sonunda potansiyel veri kaybı konusunda endişeli olduğunu söyledi. Örneğin, veritabanlarından biri Great Plains Dynamics muhasebe uygulamamız tarafından kullanılıyor ve bu konuda çok endişeli görünüyordu.

Ben bir DBA değilim ama okuduğumdan endişesi anlaşılıyor ... benim için anlaması zor.

Bundan sonra ne yapacağımdan emin değilim. Öneriler nasıl devam etmeliyim?

sql-server maintenance

— Greg Hendershott
kaynak

Veritabanının 7/24 sert bir şekilde vurulmadığı ve çevrimdışı olduğu takdirde dünya sona ereceği sürece, böyle bir davranış için mazeret yoktur. Her hafta ikinci bir düşünce olmadan 12.000'den fazla veritabanına yeniden yazma ve istatistik yazıyorum. 16 yıl içinde kötü bir kontrolör yüzünden sadece bir tane bozuldum.

— Brain2000

Yanıtlar:

Veritabanı dizinini yeniden oluşturmak veri kaybına neden olmamalıdır. Bununla birlikte, yeniden inşa edilen endeksler normalde yeniden oluşturma tamamlanana kadar kullanılamayacağından muhtemelen önemli bir performans düşüşüne neden olacaktır. Bu nedenle, etkilenen sistemlerin boşta olduğu çalışma saatleri dışında yapılmalıdır.

Paranoia, bir DBA'da İyi Bir Şeydir - Veri kaybı konusunda endişe duyuyorlarsa, yedeklemelerin uygun bir testini yapmasını isterdim (ayrı bir sisteme geri yükleyin ve verilerin orada olduğundan emin olun) ve eğer yine de, endeksleri yeniden oluşturmadan önce tam bir yedekleme yapmak makul bir önlem olacaktır.

— voretaq7
kaynak

Paranoia için +1 İyi DBA Özelliği

— Joel Coel

Sağlıklı paranoyayı tamamen anlıyorum ve takdir ediyorum. İki kez ölçün, bir kez kesin. Ben flummoxed olduğum yer burası gibi görünüyor dikkatli ziyade anlama eksikliği konusunda hiç. Ve "dikkatli bir şekilde denemenin bir yolunu belirleyelim" yerine, "evet olmayacak" dır. Verilerin bir kopyasıyla bir test EC2 örneği biriktirebilir, dizinleri yeniden düzenleyebilir, zamanlayabilir, hiçbir veri bozulmadığını onaylamak için sonuç tablosu satırlarını delta edebiliriz. Bu tür bir plan, eylemsizlik yerine ... dikkatli olur mu?

— Greg Hendershott

Sadece dizinin yeniden düzenlenmesinin her zaman çevrimiçi olduğunu hatırlatmak (tüm dizinler birleştirme sırasında kullanılabilir) ve dizin yeniden oluşturma işlemi de çevrimiçi olarak yapılabilir ( WITH (ONLINE=ON)dizin BLOB sütunları içermediği sürece.

— Remus Rusanu

@Greg Evet, "O kadar parçalı olan indekslere dokunmayalım, muhtemelen HURTING performansları var" zihniyeti de benim kafamı karıştırıyor - Bazen REINDEXendeks içeriğinin çok değiştiği tablolarda "önleyici bakım" benim deneyimimde yaygın (eğer indeks çoğunlukla statik ise daha az bir şey)

— voretaq7

@Remus iyi ipucu - Bu, performans etkisini azaltır (hala sizi yavaşlatacak yüksek disk G / Ç'ye sahip olursunuz, ancak en azından bir dizin kullanacak şeyler sıralı taramalara başvurmak yerine bunu kullanabilir )

— voretaq7

Dizinlerin yeniden oluşturulması veya birleştirilmesi nedeniyle veri kaybı riski yoktur.

— mrdenny
kaynak

Zaten bir dereceye kadar veri bozulması yoksa veya donanım arızası yoksa. Ancak her iki durumda da, dizin parçalanması endişelerinizin en azıdır!

— db2

Ancak bu, bir dizin oluşturma işleminden kaynaklanan yolsuzluk değil, başka bir sorundan kaynaklanır.

— mrdenny

Dizinlerin yeniden düzenlenmesi SQL sunucusundan daha az zaman alacak ve daha az çaba gerektirecek, böylece bir hafta içi örnek türünde yapılabilir. Söylediğiniz şey doğruysa, daha önce hiç yapılmamış dizinleri yeniden düzenlemek sunucu üzerinde de daha büyük bir etkiye neden olabilir. Dizinleri yeniden oluşturmak, bırakıldıklarından ve yeniden oluşturulduklarından bu yana SQL sunucusundan büyük miktarda çaba sarf edecektir. Hafta içi bir yeniden yapılandırma yapmak, sunucunun dizinlerle meşgul olma ve onu kullanan kişilere hizmet etmeme riskine değmez.

Voretaq7 ile hemfikirim, eğer endekslerle çalışmaktan endişe duyuyorsa, nasıl tepki verdiğini görmek için önce geliştirme veya test sunucularında deneyin.

— RateControl
kaynak

Almak için başka bir yaklaşım açıkça DROP INDEXve yeniden olabilir CREATE INDEX- SQL Server hakkında emin değilim, ama biliyorum PostgreSQL bazen daha iyi bir indeks üfleme ve sıfırdan başlamak yerine sıfırdan ( REINDEX) yapmaya çalışıyor .

— voretaq7

SQL Server'da bırakma ve yeniden oluşturma işleminin gereksiz olduğundan eminim.

— Justin Dearing

@Justin haklı olduğunuzdan eminim (aslında Sybase günlerimden sonra, bir reindexing davranışının etkili bir şekilde bir düşüş / oluşturma olduğunu hatırlıyorum, bu yüzden Postgres'de olduğu gibi dizin kilitleme tuhaflığı yok)

— voretaq7

Dizinleri yeniden düzenlemek daha az zaman alabilir. Hangisinin daha uzun süreceği, endeksin parçalanma miktarına bağlı olacaktır.

— mrdenny