Tahmini bir Yürütme Planı görüntülemek CXPACKET, PAGELATCH_SH ve LATCH_EX [ACCESS_METHODS_DATASET_PARENT] bekler

Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) 4 vCPU VM'de max degree of parallelismayarlanmış 2ve cost threshold for parallelismayarlanmış olarak çalıştırıyorum 50.

Sabahları, SELECT TOP 100 sorgusu için bir Tahmini Yürütme Planı görüntülemeye çalışırken , büyük beklemelerle karşılaşıyorum ve tahmini planı oluşturma işlemi genellikle 5 - 7 dakikalık aralıklarla dakikalar alıyor. Yine, bu sorgu gerçek yürütme değil, bu sadece bir tahmini yürütme planı görüntüleme işlemidir .

sp_WhoIsActiveya PAGEIOLATCH_SHbekler ya da LATCH_EX [ACCESS_METHODS_DATASET_PARENT]bekler gösterir ve Paul Randal'ın WaitingTasks.sql komut dosyasını işlem sırasında çalıştırdığınızda CXPACKETçalışan iş parçacığı PAGEIOLATCH_SHbeklemeler gösteren bekler gösterir:

* kaynak açıklama alanı = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Çalışan iş parçacıkları tüm statstabloyu belleğe getiriyor gibi görünüyor (bu sayfa numaralarının yanı sıra Paul Randal'ın sorgu noktasından gösterilen sonraki sayfa numaraları statstablo için kümelenmiş anahtara geri döndüğü için ). Plan geri geldiğinde, temelde günün geri kalanı için anlıktır, hatta statssadece çeşitli kayıtlarla önbellekten tablo yıpranmasının çoğunu gördükten sonra bile (benzer sorgulardan işlemler aramak için çekildiğini varsayıyorum).

Sorgu gerçekten SCAN işleçlerini kullanan bir planla yürütüyor olsaydı, bu ilk davranışı bekliyordum, ancak bunu neden yalnızca yukarıdaki bağlantı planında gösterildiği gibi bir SEEK operatörüne ulaşmak için yürütme planlarını değerlendirirken yapıyor? Buradaki performansı artırmak için ne yapabilirim (bu ifadeyi çalışma saatlerinden önce çalıştırmamın yanı sıra verilerim uygun şekilde önbelleğe alınabilir)? Ben bir çift kapsayan endeksleri yararlı olacağını varsayıyorum, ama onlar gerçekten herhangi bir davranış değişikliği garanti eder misiniz? Burada bazı depolama ve bakım penceresi sınırlamaları içinde çalışmak zorunda ve sorguyu kendisi bir satıcı çözüm üretilir, böylece diğer öneriler (yanı sıra daha iyi dizinleme) bu noktada kabul edilir.

Gerçek bir yürütme planı tarafından tetiklenen istatistik güncellemeleri isteğiniz görünüyor. Bunun sabahları gerçekleştiğinden bahsettiğiniz için, ilgili tablolarda birçok değişiklik yapan bir gecede süreç olduğunu hayal ediyorum?

Böylece SQL Server, planı oluşturmak için istatistikleri kullanır, değişiklik eşiğine ulaşır ve işlemin bir parçası olarak otomatik istatistik güncelleştirmelerini yürütür.

Paylaştığınız tahmini planın XML'sinde, bu sabahki istatistikler için bu yakın plan güncelleme tarihlerini görüyorum:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

Bu çok büyük, yoğun tablolar (muhtemelen örnekleme yüzdelere göre görünüyor) ise, o zaman değil de istatistik güncellemeler bir sürü beygir gücü alıyor olması şaşırtıcı.

SSMS'de uzun tahmini plan süreleri gördüğümde, olasılık sırasına göre aşağıdakilerden biri olabilir:

1. Sorgu iyileştirici, istatistik oluşturmaya veya güncellemeye gerek olduğuna karar verdi.
2. Tahmini planın boyutu çok büyük (örneğin,> 10 MB) ve SSMS'nin görüntülenmesi uzun zaman alıyor.
3. Sorgu derlemesinin kendisi, yeterince iyi bir plan ararken CPU kullanımı nedeniyle uzun zaman aldı.
4. Sunucu aşırı baskı altında. Örneğin, bir ağ geçidinin kullanılabilir olmasını beklemem gerekebilir .
5. Çok uzun çalışma derleme sürelerine yol açan çeşitli hatalar.

Durumunuz için cevap neredeyse kesinlikle SQL Server güncelleme veya istatistik oluşturmaktır. Birkaç ipucu vardır: sorgu planının boyutu küçüktür, sorgu planı düşük maliyetle nispeten basittir ve CPU derleme süresinden önemli ölçüde daha düşüktür:

Yeni katkıda bulunan Josh Darnell, XML'deki istatistiklerin son güncellenme süresiyle de iyi bir ipucu verdi.

SQL Server 2019 , sorguların istatistik güncellemelerini beklediği zamanlar için WAIT_ON_SYNC_STATISTICS_REFRESH adlı yeni bir bekleme türü sunar . Bu sorunu bu sürümde teşhis etmek çok daha kolay. O zamana kadar dolaylı tekniklere güvenmeniz gerekecek.

Geçici çözümler arasında, bakım döneminde istatistiklerin güncellenmesi veya veritabanı için Otomatik Güncelleştirme İstatistikleri Zaman Uyumsuzluğu'nun etkinleştirilmesi yer alır. Lütfen değiştirmeden önce bu seçeneğin tüm sonuçlarını anlayın. Sorgu planları, istatistik güncellemelerinden sonra istatistikler güncellenmeden önce oluşturulacaktır. Bazı iş yükleri için bu büyük bir kazanç olabilir. Diğerleri için yarardan çok zarar verebilir.