Dari apa yang saya tahu Rasio Hit Prosedur Cache di bawah 95% adalah masalah. Di kotak saya, nilai berkisar dari 85 hingga 95%.
Bagaimana saya memperbaiki masalah ini? Server tampaknya memiliki banyak RAM sehingga seharusnya tidak menjadi masalah. apa lagi yang bisa terjadi?
Jawaban:
Biarkan saya meringkas (dan bulat!) Poin data penting dalam spreadsheet Anda:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527Jadi baris pertama menunjukkan hal-hal buruk, mengambil sekitar 2/3 dari cache paket Anda (hal-hal yang sebagian besar hanya pernah digunakan sekali, dengan beberapa pengecualian sangat kecil). Anda perlu mencoba dan menyingkirkan sebanyak mungkin dari ini. Baris kedua menunjukkan hal-hal yang baik. Ini adalah hal-hal yang Anda inginkan dalam cache paket Anda (paket dengan jumlah penggunaan kembali yang tinggi). Sisa data IMHO sebagian besar tidak relevan. Namun satu poin lain: Anda mengatakan bahwa akses secara eksklusif melalui prosedur tersimpan, tetapi jika prosedur tersebut menggunakan SQL dinamis, pernyataan itu di-cache sebagai AdHocrencana, bukan Procrencana.
Pada tahun 2008 atau lebih, saya akan mengatakan nyalakan optimize for ad hoc workloadsdan beralih ke masalah berikutnya - ini akan membuat jumlah MB yang digunakan oleh paket sekali pakai Anda saat ini hampir tidak ada. Sayangnya, pada tahun 2005, opsi Anda sangat terbatas, selain dari refactoring prosedur yang tersimpan untuk menggunakan tingkat pernyataan OPTION (RECOMPILE)dan / atau SQL dinamis kurang, atau mengaktifkan parameterisasi paksa di tingkat database - yang mencoba untuk mendapatkan rencana penggunaan kembali yang lebih baik dari pertanyaan serupa dengan memperlakukan literal sebagai parameter untuk tujuan pencocokan rencana. Saya ragu untuk menyebutkan panduan paket karena itu bukan untuk pemalu dan - seperti yang akan saya bahas nanti dalam jawaban ini - saya tidak yakin layak mengikuti jalan itu kecuali jika Anda tahu cache rencana Anda jelas merupakan sumber kinerja Anda isu.
Saya bertanya tentang @@VERSIONkarena, sebelum SP2, algoritma untuk jumlah memori yang dapat dialokasikan ke cache rencana relatif longgar. Pada SP2 mereka memperketat itu sedikit (perubahan didokumentasikan dan dijelaskan dalam posting ini dan posting ini ). Dalam kasus Anda, cache rencana relatif penuh, sehingga tidak mengherankan jika Anda kehilangan cache. 26 GB = batas atas 5,8 GB; Saya melihat ~ 4,5 GB dalam spreadsheet tetapi mungkin ada beberapa perbedaan perhitungan atau konfigurasi di sini yang tidak saya ketahui.
Artikel MSDN ini berbicara tentang optimize for ad hoc workloadspengaturan server yang ditambahkan pada 2008, dan menyebutkan jejak 8032, yang akan memungkinkan Anda untuk mengalokasikan lebih banyak memori ke cache Anda (mungkin karena tidak ada pengaturan pengaturan ini di tingkat server, yang sekarang saya sarankan untuk semua pelanggan kami, atau setidaknya 99% yang tidak lagi pada 2005). Saya belum pernah menguji jejak bendera ini pada 2005 SP3 atau SP4, dan jujur bahkan tidak yakin kapan itu diperkenalkan. Saya juga tidak tahu apakah itu akan menyelesaikan masalah Anda atau hanya menggesernya, karena saya pikir bahkan jika Anda memiliki beberapa% lebih banyak RAM yang dialokasikan untuk cache, Anda masih akan mengisinya dan memiliki banyak cache yang meleset karena sifat dari prosedur tersimpan Anda.
Atau, tentu saja, jika ada masalah yang harus dipecahkan yang berhubungan langsung dengan cache rencana sama sekali. Hanya karena rasio hit cache Anda tidak setinggi yang Anda harapkan tidak berarti itu menyebabkan masalah Anda, dan tentu saja yang sebaliknya adalah bahkan pada rasio hit cache 100% - yang tampaknya tidak realistis mengingat begitu banyak rencana Anda adalah sekali pakai dan ad hoc - pengguna Anda mungkin masih menderita masalah kinerja yang disebabkan oleh hal lain sama sekali.
Saran saya adalah untuk mencari senjata merokok yang lebih baik daripada rencana rasio hit cache. Dapatkan lebih spesifik tentang keluhan kinerja pengguna Anda. Apakah semua pertanyaan selalu lambat? Pertanyaan tertentu? Waktu tertentu dalam siklus hari / minggu / bisnis? Apakah hanya melaporkan permintaan lambat? Bacalah dengan serius dokumen yang diakui kering dan panjang ini tentang praktik terbaik SQL Server - khususnya, bagian menunggu dan antrian, yang dapat membantu Anda merumuskan pendekatan logis untuk mengidentifikasi, mendiagnosis, dan menyelesaikan masalah kinerja. Membuat angka di dasbor terlihat lebih baik - angka yang bahkan tidak Anda ketahui secara langsung berkontribusi pada masalah - mungkin sangat memuaskan, tetapi jika itu tidak menyelesaikan masalah kinerja pengguna Anda, maka angka itu tidak benar-benar membuat Anda dimana saja.
Ini juga berguna untuk membaca tentang kompilasi / kompilasi dan rencana penggunaan kembali cache. Beberapa di antaranya difokuskan pada 2008 (terutama yang berkaitan dengan pengaturan beban kerja sementara), tetapi sebagian besar informasi masih berguna untuk tahun 2005 dan / atau untuk lebih memahami manfaat peningkatan (petunjuk, petunjuk).