Deskripsi SQL Server menghalangi disebabkan oleh mengkompilasi kunci

ID Artikel: 263889 - Melihat produk di mana artikel ini berlaku.
Penerjemahan MesinPeringatan: artikel ini adalah terjemahan oleh mesin
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

Di Microsoft SQL Server, hanya satu salinan dari rencana disimpan prosedur adalah umumnya dalam cache pada suatu waktu. Menegakkan ini memerlukan serialisasi dari beberapa bagian dari proses kompilasi, dan sinkronisasi ini dicapai sebagian dengan menggunakan kunci kompilasi. Jika banyak koneksi secara bersamaan berjalan sama disimpan prosedur dan kompilasi kunci harus diperoleh untuk prosedur yang tersimpan setiap waktu yang berjalan, sistem proses ID (SPIDs) mungkin mulai memblokir satu sama lain ketika mereka masing-masing mencoba untuk mendapatkan kunci eksklusif kompilasi pada objek.
Kembali ke atas | Berikan Masukan

INFORMASI LEBIH LANJUT

Disimpan prosedur recompilation adalah salah satu penjelasannya untuk mengkompilasi kunci pada prosedur yang disimpan atau memicu. Solusi dalam hal mengurangi atau menghilangkan recompiles. Untuk penjelasan tentang alasan paling umum yang disimpan prosedur mungkin harus menjadi recompiled dan beberapa informasi yang berguna pada mengurangi frekuensi recompiles, lihat artikel Basis Pengetahuan Microsoft berikut:
243586
(http://support.microsoft.com/kb/243586/ )
Pemecahan masalah disimpan prosedur recompilation
Skenario lain di mana kompilasi kunci terjadi adalah ketika kondisi berikut ini benar:
  • Pengguna yang menjalankan prosedur yang tersimpan bukanlah pemilik prosedur.
  • Nama disimpan prosedur ini tidak memenuhi syarat dengan nama pemilik objek.
Misalnya, jika pengguna "dbo" memiliki objek dbo.mystoredproc dan pengguna lain, "Harry," menjalankan prosedur ini disimpan dengan menggunakan perintah "exec mystoredproc," awal cache lookup oleh nama objek gagal karena objek bukan pemilik yang memenuhi syarat. (Itu masih belum diketahui apakah ada lain disimpan prosedur yang bernama Harry.mystoredproc. Oleh karena itu, SQL Server tidak bisa yakin bahwa rencana cache untuk dbo.mystoredproc yang benar untuk mengeksekusi.) SQL Server kemudian memperoleh kunci eksklusif kompilasi pada prosedur dan membuat persiapan untuk mengkompilasi prosedur. Ini termasuk menyelesaikan nama objek ke objek ID. Sebelum SQL Server mengkompilasi rencana, SQL Server menggunakan ID objek ini untuk melakukan pencarian lebih tepat cache prosedur dan dapat menemukan rencana sebelumnya dikompilasi bahkan tanpa pemilik kualifikasi.

Jika ada rencana ditemukan, SQL Server reuses rencana cache dan tidak benar-benar menyusun prosedur yang tersimpan. Namun, kurangnya pemilik-kualifikasi pasukan SQL Server untuk melakukan pencarian cache kedua dan mendapatkan kunci eksklusif kompilasi sebelum program menentukan bahwa ada rencana pelaksanaan cache dapat digunakan kembali. Mendapatkan kunci dan melakukan pencarian dan pekerjaan lain yang diperlukan untuk mencapai titik ini dapat memperkenalkan penundaan untuk mengkompilasi kunci yang mengarah ke menghalangi. Hal ini terutama berlaku jika banyak pengguna yang bukan pemilik prosedur yang tersimpan secara bersamaan menjalankan prosedur tanpa menyediakan nama pemilik. Sadarilah bahwa bahkan jika Anda tidak melihat SPIDs menunggu kompilasi kunci, kurangnya kualifikasi pemilik dapat memperkenalkan penundaan eksekusi order disimpan prosedur dan menyebabkan utilisasi CPU tidak perlu tinggi.

Berikut urutan peristiwa akan tercatat dalam jejak SQL Server Profiler ketika masalah ini terjadi. (Untuk melacak kegiatan yang berhubungan dengan cache, Anda harus mengaktifkan kegiatan canggih. Untuk melakukannya, klikOpsi pada Alat menu, dan kemudian pilih Semua peristiwa kelas.)

Perkecil tabel iniPerbesar tabel ini
Acara kelasTeks
RPC: mulaimystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: mulaimystoredproc
......

SP:CacheMissterjadi ketika lookup cache dengan nama gagal. Berikut SP:ExecContextHit menunjukkan bahwa rencana cache pencocokan akhirnya ditemukan dalam cache setelah nama objek ambigu itu diselesaikan untuk objek ID. Tergantung pada keadaan, SP:CacheHitmungkin muncul bukannyaSP:ExecContextHit.

Solusi untuk masalah ini kompilasi penguncian adalah untuk memastikan bahwa referensi untuk disimpan prosedur pemilik yang memenuhi syarat. (Bukan dari exec mystoredproc, menggunakan exec dbo.mystoredproc.) Sementara pemilik-kualifikasi penting untuk kinerja alasan, Anda tidak harus memenuhi syarat proc disimpan dengan nama database untuk mencegah lookup tambahan cache.

Menghalangi yang disebabkan oleh kompilasi kunci dapat dideteksi dengan menggunakan memblokir skrip seperti yang didefinisikan dalam artikel Basis Pengetahuan Microsoft berikut:
251004
(http://support.microsoft.com/kb/251004/ )
INF: Bagaimana untuk memantau menghalangi SQL Server 7.0
271509
(http://support.microsoft.com/kb/271509/ )
INF: Bagaimana untuk memantau menghalangi SQL Server 2000
Berikut adalah beberapa karakteristik khas kompilasi menghalangi yang diamati dalam memblokir skrip output:
  • lastwaittype untuk diblokir dan (biasanya) memblokir SPIDs adalah LCK_M_X (eksklusif) dan waitresource merupakan bentuk dari "TAB: dbid:object_id [[MENGKOMPILASI]],"di mana"object_id"adalah ID objek disimpan prosedur.
  • Blocker memiliki waittype 0x0000, status runnable. Blockees memiliki waittype 0x000e (kunci eksklusif), status tidur.
  • Meskipun durasi insiden memblokir panjang, ada tidak ada satu SPID yang menghalangi SPIDs lain untuk waktu yang lama. Ada yang menghalangi bergulir. Segera setelah satu kompilasi lengkap, SPID lain mengambil alih peran kepala Pemblokir selama beberapa detik atau kurang, dan seterusnya.
Informasi berikut ini dari sebuah snapshot dari sysprocesses selama ini dari memblokir:
   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
Dalam waitresourcekolom ("6:834102"), 6 database ID dan 834102 ID objek. Sadarilah bahwa ID objek ini milik stored procedure, tidak untuk meja (walaupun jenis kunci "TAB").

Catatan
  • Jika Anda menggunakan SQL Server 2005, banyak sistem tabel SQL Server 2000 sekarang diimplementasikan sebagai satu set dilihat. Pandangan-pandangan ini dikenal sebagai kompatibilitas pandangan, dan mereka dimaksudkan untuk kompatibilitas hanya. Kompatibilitas dilihat mengekspos sama metadata yang tersedia dalam SQL Server 2000. Untuk informasi lebih lanjut tentang pemetaan antara tabel SQL Server 2000 sistem dan SQL Server 2005 dilihat sistem, baca topik "Pemetaan SQL Server 2000 sistem tabel untuk SQL Server 2005 sistem tampilan" dalam SQL Server 2005 buku Online.
  • Jika nama disimpan prosedur dimulai dengan awalan "sp_" dan tidak dalam master database, Anda melihatSP:CacheMisssebelum cache hit untuk setiap pelaksanaan bahkan jika Anda pemilik-lolos prosedur yang tersimpan. Hal ini karena awalan sp_ memberitahu SQL Server disimpan prosedur adalah sistem disimpan prosedur, dan sistem disimpan prosedur memiliki aturan resolusi nama yang berbeda. ("" Lokasi adalah dalam master database.) Nama pengguna-dibuat disimpan prosedur harus dimulai dengan "sp_".
  • Jika memenuhi syarat pemilik prosedur dijalankan dengan kasus berbeda daripada memenuhi syarat pemilik prosedur diciptakan sebagai, prosedur pemilik yang memenuhi syarat dapat memperolehCacheMiss atau meminta kunci KOMPILASI tapi akhirnya menggunakan rencana cache. Oleh karena itu, ini mengkompilasi akan tidak benar-benar ulang prosedur dan tidak harus menyebabkan banyak overhead. Tetapi dalam situasi tertentu, permintaan untuk MENGKOMPILASI kunci dapat menyebabkan situasi "menghalangi rantai" jika ada banyak SPIDs mencoba untuk menjalankan prosedur yang sama dengan kasus berbeda daripada prosedur diciptakan sebagai. Hal ini benar terlepas dari urutan atau pemeriksaan yang sedang digunakan pada server atau database. Alasan untuk perilaku ini adalah bahwa algoritma yang sedang digunakan untuk menemukan prosedur dalam cache berdasarkan nilai hash (untuk alasan kinerja), yang dapat mengubah jika kasus berbeda.

    Solusi adalah untuk drop dan membuat prosedur dengan kasus yang sama dengan prosedur yang dilaksanakan oleh aplikasi. Anda juga dapat memastikan bahwa prosedur dijalankan dari semua aplikasi yang menggunakan kasus yang sama.
  • Jika Anda mencoba untuk menjalankan prosedur yang disimpan sebagai bahasa peristiwa bukan sebagai RPC, SQL Server harus memilah dan mengkompilasi bahasa acara permintaan, menentukan query sedang mencoba untuk melaksanakan prosedur tertentu, dan kemudian mencoba untuk menemukan rencana dalam cache untuk prosedur. Untuk menghindari situasi di mana SQL Server harus memilah dan mengkompilasi acara bahasa, pastikan bahwa permintaan dikirim ke SQL sebagai RPC.

    Untuk informasi lebih lanjut, lihat bagian "Sistem disimpan prosedur" dalam buku Online artikel "Membuat prosedur Stored."


Masalah yang dikenal

Berikut adalah beberapa masalah yang diketahui yang dapat mencegah rencana cache:
  • Anda menggunakan variabel GUMPALAN sebagai parameter disimpan prosedur. Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
    2380435
    (http://support.microsoft.com/kb/2380435/ )
    FIX: Rencana permintaan untuk prosedur yang disimpan tidak di-cache jika disimpan prosedur menggunakan variabel GUMPALAN dan variabel digunakan dalam string fungsi dalam Microsoft SQL Server 2008
  • Anda menggunakan kunci SIMETRIK yang terbuka di disimpan prosedur/permintaan Batch. Untuk informasi lebih lanjut, lihat entri blog MSDN berikut:
    http://Blogs.msdn.com/b/sqlserverfaq/Archive/2010/09/08/Open-Symmetric-Key-Command-prevents-query-Plan-caching.aspx
    (http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx)

Kembali ke atas | Berikan Masukan

Properti

ID Artikel: 263889 - Kajian Terakhir: 22 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Kata kunci: 
kbinfo kbmt KB263889 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini:263889
(http://support.microsoft.com/kb/263889/en-us/ )
Kembali ke atas | Berikan Masukan

Berikan Masukan

 
Kembali ke atasKembali ke atas