Menampilkan Estimasi Rencana Eksekusi menghasilkan CXPACKET, PAGELATCH_SH, dan LATCH_EX [ACCESS_METHODS_DATASET_PARENT] menunggu

Saya menjalankan Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) pada VM 4 vCPU dengan max degree of parallelismset ke 2dan cost threshold for parallelismset ke 50.

Di pagi hari, ketika mencoba untuk menampilkan Perkiraan Rencana Eksekusi untuk permintaan SELECT TOP 100 , saya mengalami menunggu besar-besaran dan operasi untuk membuat rencana yang diperkirakan memakan waktu beberapa menit, sering kali dalam kisaran 5 - 7 menit. Sekali lagi, ini bukan eksekusi sebenarnya dari permintaan, ini hanya proses untuk menampilkan Estimasi Rencana Eksekusi .

sp_WhoIsActiveakan menunjukkan PAGEIOLATCH_SHmenunggu atau LATCH_EX [ACCESS_METHODS_DATASET_PARENT]menunggu dan ketika saya menjalankan skrip WaitingTasks.sql karya Paul Randal selama operasi, ia menunjukkan CXPACKETmenunggu dengan utas pekerja yang menunjukkan PAGEIOLATCH_SHmenunggu:

* bidang deskripsi sumber daya = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Utas pekerja tampaknya akan membawa seluruh statstabel ke dalam memori (karena nomor halaman tersebut dan juga nomor halaman berikutnya yang ditunjukkan dari kueri Paul Randal kembali ke kunci yang dikelompokkan untuk statstabel). Setelah rencana itu kembali, pada dasarnya itu instan untuk sisa hari itu, bahkan setelah saya melihat sebagian besar statstabel gesekan dari cache dengan hanya berbagai catatan yang tersisa (yang saya asumsikan ditarik karena mencari operasi dari query yang sama).

Saya akan mengharapkan perilaku awal ini jika kueri benar-benar mengeksekusi dengan rencana yang menggunakan operator SCAN, tetapi mengapa melakukan ini ketika mengevaluasi rencana eksekusi hanya untuk sampai pada operator SEEK seperti yang ditunjukkan dalam rencana yang ditautkan di atas? Apa yang dapat saya lakukan (selain menjalankan pernyataan ini sebelum jam kantor sehingga data saya di-cache dengan tepat) untuk membantu meningkatkan kinerja di sini? Saya berasumsi sepasang indeks penutupan akan bermanfaat, tetapi apakah mereka benar-benar menjamin perubahan perilaku? Saya harus bekerja di dalam beberapa batasan penyimpanan dan pemeliharaan jendela di sini, dan permintaan itu sendiri dihasilkan dari solusi vendor, sehingga saran lain (selain pengindeksan yang lebih baik) akan diterima pada saat ini.

Tampaknya permintaan Anda untuk rencana eksekusi aktual memicu pembaruan statistik. Karena Anda menyebutkan ini terjadi di pagi hari, saya membayangkan ada proses semalam yang melakukan banyak modifikasi pada tabel yang terlibat?

Jadi SQL Server menggunakan statistik untuk membuat rencana, telah mencapai ambang modifikasi, dan menjalankan pembaruan statistik otomatis sebagai bagian dari operasi.

Dalam XML untuk taksiran paket yang Anda bagikan, saya melihat tanggal pembaruan berdekatan ini untuk statistik mulai pagi ini:

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"

Jika tabel ini sangat besar, tabel sibuk (tampaknya kemungkinan berdasarkan persentase sampling), maka tidak terlalu mengejutkan bahwa pembaruan statistik memakan banyak tenaga kuda.

Ketika saya melihat perkiraan waktu rencana dalam SSMS, ini adalah salah satu dari yang berikut ini dalam urutan kemungkinan:

1. Pengoptimal kueri memutuskan bahwa diperlukan untuk membuat atau memperbarui statistik.
2. Ukuran rencana yang diperkirakan sangat besar (katakanlah,> 10 MB) dan hanya membutuhkan waktu lama bagi SSMS untuk menampilkannya.
3. Kompilasi query sendiri sebenarnya memakan waktu lama karena penggunaan CPU dalam mencari paket yang cukup bagus.
4. Server berada di bawah tekanan ekstrim. Misalnya, saya mungkin harus menunggu gateway tersedia.
5. Berbagai bug yang menyebabkan waktu kompilasi berjalan sangat lama.

Untuk situasi Anda jawabannya hampir pasti bahwa SQL Server memperbarui atau membuat statistik. Ada beberapa petunjuk: ukuran rencana kueri kecil, rencana kueri relatif sederhana dengan biaya rendah, dan kompilasi CPU secara signifikan lebih rendah daripada waktu kompilasi:

Kontributor baru Josh Darnell juga menunjukkan petunjuk yang bagus dengan waktu terakhir yang diperbarui untuk statistik dalam XML.

SQL Server 2019 memperkenalkan tipe tunggu baru, WAIT_ON_SYNC_STATISTICS_REFRESH , untuk saat kueri menunggu pembaruan statistik. Jauh lebih mudah untuk mendiagnosis masalah ini pada versi itu. Sampai saat itu Anda hanya perlu mengandalkan teknik tidak langsung.

Pemecahan masalah termasuk memperbarui statistik selama periode pemeliharaan atau mengaktifkan Auto Update Stats Async untuk database. Harap pahami konsekuensi penuh opsi itu sebelum mengubahnya. Paket kueri akan dibuat sebelum statistik diperbarui alih-alih setelah pembaruan statistik. Untuk beberapa beban kerja yang bisa menjadi kemenangan besar. Bagi yang lain itu bisa lebih banyak merusak daripada kebaikan.