Paket eksekusi tidak ada untuk prosedur tersimpan

12

Apa alasan hilangnya paket dari cache untuk prosedur tersimpan?

  1. WITH RECOMPILE
  2. SQL dinamis
  3. Kode terenkripsi
  4. Perubahan data yang signifikan
  5. Perbarui statistik
  6. Apa lagi?

Saya telah bekerja pada 2 server (SQL Server 2008 R2 dan SQL Server 2012) baru-baru ini yang tidak memiliki rencana dalam cache untuk prosedur tersimpan yang sangat sumber daya. Banyak, mungkin semua, pernyataan di dalam prosedur tersimpan juga tidak memiliki rencana dalam cache. Beberapa prosedur tersimpan dijalankan cukup sering seperti beberapa kali per detik.

Tidak ada tekanan memori sama sekali. Salah satu server memiliki lebih banyak perangkat keras daripada yang dibutuhkan.

Saya pikir rencana yang hilang adalah karena pembuatan tabel sementara di tengah-tengah prosedur yang tersimpan, tetapi itu tampaknya informasi lama dari SQL Server 2000 atau sebelumnya. Dimulai dengan SQL Server 2005, kompilasi terjadi di tingkat pernyataan untuk pernyataan setelah DDL. Apakah itu benar dalam semua kasus atau apakah masih dapat terjadi pada versi yang lebih baru?

Apa lagi yang bisa menjadi penyebab rencana yang hilang? Saya telah membaca beberapa artikel tentang topik ini, tetapi sepertinya tidak ada yang cocok.

Optimalkan untuk beban kerja adhoc diaktifkan di server yang saya lihat minggu ini. Salah satu prosedur tersimpan hanya dilakukan sekali sehari. Saya punya kode untuk itu. Saya tidak memiliki kode untuk kode yang mengeksekusi lebih dari 100 kali per menit, tetapi saya bisa mendapatkannya. Saya tidak akan dapat memposting kode, tetapi saya dapat menjelaskannya sehubungan dengan pertanyaan saya.

Saya tidak percaya ada yang membebaskan cache prosedur atau menjatuhkan buffer bersih. Klien ini menggunakan Solarwinds DPA sebagai salah satu alat pemantauan mereka. DPA memang menangkap salah satu rencana eksekusi untuk pernyataan dalam proc yang disimpan yang dipanggil sekali sehari. Pernyataan itu memiliki sejumlah besar bacaan karena WHEREklausa yang tidak dapat ditagih . Jika DPA menangkap pernyataan itu, maka itu merupakan rencana yang diperkirakan dan berada di cache rencana pada satu waktu. Tidak ada di sana saat kita memecahkan masalah. Saya akan minta mereka mulai masuk sp_WhoIsActiveke tabel.

Saya menggunakan sp_BlitzCache. (Saya bekerja untuk Brent Ozar Unlimited) Ini akan menunjukkan rencana untuk seluruh prosedur tersimpan serta rencana untuk pernyataan individual, jika ada. Jika tidak ada, ini memiliki peringatan "Kami tidak dapat menemukan rencana untuk permintaan ini. Kemungkinan alasan untuk ini termasuk SQL dinamis, RECOMPILEpetunjuk, dan kode terenkripsi." Dan peringatan itu ada di pernyataan juga.

TF 2371 tidak ada di tempat. Saya melihat statistik tunggu. Servernya cukup bosan. PLE lebih dari 130.000.

Saya sekarang memiliki kode untuk 2 prosedur tersimpan lainnya. Salah satunya menggunakan SQL dinamis dengan exec (@sql)yang kita tahu mengapa tidak ada rencana untuk itu. Tetapi yang lain, dan ini adalah yang berjalan lebih dari 100 kali per menit, tidak memiliki sesuatu yang luar biasa. Satu-satunya hal yang menonjol dalam itu adalah bahwa tabel sementara sedang dibuat di tengah lebih dari 1000 baris kode. Itu memang memanggil banyak prosedur yang tersimpan anak juga.

Mengenai Plan Caching di SQL Server 2008 , saya tidak melihat literal> = 8k, tetapi salah satu prosedur tersimpan memiliki komentar tentang sisipan massal tepat sebelum memanggil prosedur tersimpan lainnya. Tetapi sisipan massal tidak muncul dalam prosedur tersimpan yang saya lihat. Bagian "Ambang Ulang Kompilasi" dari artikel ini menarik. Yang saya lihat untuk tabel sementara adalah banyak INSERT (yang dapat menghasilkan jutaan baris), beberapa pembaruan dan penghapusan. Jadi banyak perubahan data ke tabel sementara. Jutaan.

sql-server plan-cache Tara Kizer
sumber
Karena Anda memiliki procs tersimpan yang mem-repro masalah ini, dapatkah Anda membuat contoh minimal yang mengulanginya dan dengan demikian mencari tahu masalahnya?
Martin Smith

Jawaban:

3

Ada dua DMF tembolok paket:

sys.dm_exec_query_plan - mengembalikan paket cache dalam format XML, tetapi hanya sampai ukuran tertentu (dan hanya selama mereka dapat diformat sebagai XML dalam SQL Server, yang berarti hingga 128 level bersarang.)

sys.dm_exec_text_query_plan - mengembalikan paket yang di-cache dalam format teks, berapa pun ukurannya. Tetapi kekurangannya adalah bahwa ketika paket besar, Anda tidak dapat mengubahnya menjadi XML di dalam SQL Server, dan bahkan TRY_CONVERT karena XML mengembalikan nol.

sp_BlitzCache hanya mengenai DMV yang lama (karena itu perlu menganalisis rencana permintaan sebagai XML untuk melakukan semua jenis slicing dan dicing.) Saya membuat masalah Github # 838 untuk meningkatkan ini sehingga setidaknya kita bisa memperingatkan pengguna untuk pergi memeriksa sys.dm_exec_text_query_plan untuk mereka pertanyaan lebih besar. Meskipun demikian, kami masih tidak dapat melakukan analisis XML.

Brent Ozar
sumber
Dan juga alasan yang sama sys.query_store_plan.query_planadalah nvarchar(MAX), bukan XML (SQL trivia).
Remus Rusanu
@RemusRusanu ooo, rencana besar muncul di sana! Bagus.
Brent Ozar
Kami sedang memeriksa apakah rencana yang hilang adalah karena apa yang Anda temukan. Segera setelah saya mendengar kembali, saya akan memposting pembaruan.
Tara Kizer
Saya menandai ini sebagai jawaban meskipun saya belum mendengar kabar dari klien. Ini adalah satu-satunya hal yang tersisa dan masuk akal mengingat pertanyaan besar. Saya akan memposting pembaruan jika ada perubahan.
Tara Kizer
@TaraKizer Anda hanya melakukan ini karena ulasan kuartalan Anda akan datang, kan? Saya melihat apa yang Anda lakukan di sana. BONUS TERKUNCI.
Brent Ozar
0

Mungkin Anda perlu menyesuaikan ukuran maksimum XML yang dapat dikembalikan oleh SSMS ke kotak?

Stephen MORRIS
sumber
Tidak, karena seperti yang dicatat Tara, bahkan jika Anda menulisnya di atas meja dan memeriksa panjangnya di sana, tidak ada data yang kembali.
Brent Ozar