Basit SİL, ancak karmaşık yürütme planı

Bu silme çalıştırdığınızda:

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

... 39.157 satırı siler. Basit olmalı, çünkü kümelenmiş dizin ve birincil anahtar olan ETLHeaderID'de siliniyor. Ancak (yürütme planına göre) 361.190 satır vuruyor ve diğer dizinleri kullanıyor gibi görünüyor. Tablonun XML veri türüne sahip bir alanı vardır (bu SİL'i etkilemesi durumunda).

Neden ve nasıl bu SİLME hızlandırmak için herhangi bir fikir?

Burada Yürütme Planı: http://sharetext.org/qwDY Burada tablo şeması: http://sharetext.org/Vl9j

Teşekkürler

Planın en üst seviyeleri, satırları temel tablodan (kümelenmiş dizin) kaldırmak ve dört kümelenmemiş dizini korumakla ilgilidir. Bu dizinlerden ikisi, kümelenmiş dizin silme işlemlerinin işlendiği sırada satır satır korunur. Bunlar, aşağıda yeşil renkle vurgulanan "+2 kümelenmemiş dizinler" dir.

Diğer iki kümelenmemiş dizin için, iyileştirici, bu dizinlerin anahtarlarının bir tempdb çalışma masasına (Eager Biriktirme) kaydedilmesinin, ardından makarayı iki kez oynatarak sıralı erişim düzenini teşvik etmek için dizin anahtarlarına göre sıralamanın en iyi olduğuna karar vermiştir.

Son işlem sırası, xmlDDL betiğinizde bulunmayan birincil ve ikincil dizinlerin bakımı ile ilgilidir :

Bu konuda yapılacak çok şey yok. Kümelenmemiş dizinler ve xmldizinler, temel tablodaki verilerle senkronize tutulmalıdır. Bu tür dizinleri korumanın maliyeti, bir tabloda ekstra dizinler oluştururken yaptığınız ödünleşmenin bir parçasıdır.

Bununla birlikte, xmlendeksler özellikle sorunludur. Optimize edicinin bu durumda kaç satırın hak kazanacağını doğru bir şekilde değerlendirmesi çok zordur. Aslında, xmlbu sorgu için çılgınca fazla tahmin ediyor ve bu sorgu için neredeyse 12GB bellek veriliyor (ancak çalışma zamanında sadece 28MB kullanılıyor):

Aşırı bellek yardımının etkisini azaltmayı umarak silme işlemini daha küçük gruplar halinde gerçekleştirmeyi düşünebilirsiniz.

Ayrıca , bir planın performansını kullanarak sıralama yapmadan da test edebilirsiniz OPTION (QUERYTRACEON 8795). Bu belgelenmemiş bir izleme bayrağıdır, bu yüzden onu asla bir geliştirme veya test sisteminde denemelisiniz, asla üretimde değil. Ortaya çıkan plan çok daha hızlıysa, plan XML'sini yakalayabilir ve üretim sorgusu için bir Plan Kılavuzu oluşturmak için kullanabilirsiniz .

Doğru yoldasın - XML ​​dizini sorun. Açıkçası, birincil ve ikincil XML dizini var.

Temel tabloya (ETLHeaders) karşı bir DELETE gerçekleştirirken, verilerin de bu tablonun her dizininden silinmesi gerekir. Bu ek yük özellikle XML dizinleri için önemli olabilir.

Uzun süreye neden olan dizin ikincil XML dizinidir [XML_IX_ETLHeaders_Property]. "İlişkisel tablonuzdaki" 39.157 satır, birincil XML dizinindeki [XML_IX_ETLHeaders] 361.190 satır anlamına gelir. İkincil dizini silmek için kullanılabilmesi için bu 361k satırların sıralanması gerekir. Ve bu sıralama işlemi sorgunun uzun süresine neden oluyor. (Bir yan not olarak, her iki xml dizininin dizin istatistikleri de kapalı gibi görünüyor: birincil xml dizininin 361k satırının gerçek veri boyutu 160 MB, tahmini veri boyutu neredeyse 4 TB (evet, 4 TerraByte !!)) .

Bu sorguyu hızlandırmak için gördüğüm tek seçenek ikincil XML dizinini ortadan kaldırmaktır. Verilere bağlı olarak, XML verilerini ilişkisel bir tabloya parçalamak daha iyi bir seçenek olabilir.