Bagaimana memecahkan masalah kinerja Ad-Hoc query di SQL Server

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 243588 - Melihat produk di mana artikel ini berlaku.
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

Artikel ini menjelaskan bagaimana memecahkan lambat kinerja dari banyak bersamaan ad-hoc queries dalam Microsoft SQL Server. Jika Anda tidak menentukan tepat sumber masalah Anda, lihat artikel berikut di Microsoft Basis Pengetahuan sebelum Anda melanjutkan:
224587 Bagaimana memecahkan masalah kinerja aplikasi dengan SQL Server

Artikel ini mengasumsikan bahwa Anda telah menggunakan KB 224587 untuk mempersempit cakupan masalah dan bahwa Anda telah menangkap Monitor kinerja Windows NT log dan SQL Profiler melacak detail khusus counter, peristiwa, dan data kolom.

Karakteristik dari masalah kinerja

Masalah kinerja memiliki karakteristik sebagai berikut:
  • Pertanyaan singkat ad-hoc yang biasanya memiliki sangat singkat durasi mengakibatkan kinerja sistem keseluruhan lambat ketika sejumlah besar concurrent pengguna menjalankan query.
  • Sangat tinggi atau 100 persen penggunaan CPU.
  • Tidak terkait menghalangi selama periode lambat kinerja.

    Anda dapat dengan cepat melihat untuk memblokir dengan memeriksa BLK kolom dalam output sp_who sistem disimpan prosedur. Jika BLK kolom yang tidak nol untuk sejumlah sistem proses ID (SPIDs), ada yang menghalangi.
  • Dalam beberapa situasi, memori server stres, dan Anda mungkin menerima kesalahan yang mirip dengan kesalahan berikut:
    Kesalahan: 701, tingkat keparahan: 17, negara: 1
    Ada tidak cukup memori sistem untuk menjalankan query ini.
    -atau-
    MSG 8645, Level 17, negara bagian 1, prosedur, jalur 1
    Waktu keluar terjadi sementara menunggu untuk sumber daya memori untuk mengeksekusi query. Kembali menjalankan query.

Peningkatan permintaan kompilasi

Karena dari perbaikan dalam arsitektur sistem mulai di SQL Server 7.0, khususnya query optimizer, Anda dapat melihat perbedaan dalam penggunaan sumber daya sistem oleh aplikasi dibandingkan dengan versi sebelumnya dari SQL Server. Secara khusus, SQL Server 7.0 mungkin menunjukkan peningkatan dalam CPU baik atau penggunaan memori, tetapi versi sebelumnya dari SQL Server yang biasanya IO disk terikat. Perubahan ini dapat ditelusuri ke dua faktor:
  • Hash dan gabungan bergabung
  • Permintaan kompilasi kali
Versi sebelumnya dari SQL Server bergantung sepenuhnya pada loop bersarang pengulangan untuk melakukan bergabung. Loop bersarang bergabung secara inheren menggunakan disk IO. Mulai dengan SQL Server 7.0, hash dan gabungan bergabung diperkenalkan. Hash dan gabungan bergabung melakukan jauh lebih dalam-memori pengolahan daripada bersarang loop bergabung. Hasil logis ini adalah CPU dan penggunaan memori tinggi ketika ini bergabung dengan teknik digunakan. Untuk informasi lebih lanjut tentang hash dan gabungan bergabung, lihat "pemahaman Hash bergabung"dan"Pemahaman menggabungkan bergabung"topik di SQL Server 7.0 buku Online.

Permintaan kompilasi kali yang terpengaruh karena permintaan Pengoptimal memiliki lebih banyak pilihan dan informasi tersedia daripada versi sebelumnya SQL Server, termasuk baru hash dan bergabung dengan gabungan teknik, peningkatan pencarian algoritma, dan kolom statistik. Informasi tambahan ini memungkinkan query optimizer untuk memilih metode yang paling efisien untuk mengambil data permintaan. Namun, analisis dan pertimbangan ini teknik-teknik baru dan informasi memerlukan waktu proses. Penggunaan CPU peningkatan ini dapat mengakibatkan permintaan kompilasi kali yang lebih panjang daripada dalam versi sebelumnya dari SQL Server.

Bagi sebagian besar permintaan, waktu kompilasi peningkatan ini diimbangi dengan penurunan waktu eksekusi. Dampak keseluruhan adalah bahwa permintaan berjalan lebih cepat daripada dalam versi sebelumnya dari SQL Server. Satu pengecualian, namun, terjadi dengan sangat kecil, sederhana, OLTP-jenis pertanyaan yang telah sangat rendah eksekusi kali. Untuk permintaan ini, proses menghasilkan rencana permintaan mungkin memiliki sama atau biaya yang lebih besar daripada eksekusi query. Sebagai hasilnya, query dapat melakukan sedikit lebih lambat daripada dalam versi sebelumnya dari SQL Server. Karena perbedaan adalah biasanya dalam milidetik, efek ini adalah tidak melihat untuk tertentu permintaan jika dijalankan secara individual. Namun, Anda mungkin memperhatikan bahwa secara keseluruhan sistem penggunaan CPU yang lebih tinggi daripada versi sebelumnya SQL Server jika besar jumlah ad-hoc query dijalankan secara bersamaan oleh sejumlah besar pengguna.

Mengembangkan permintaan parameterized

SQL Server 7.0 menggunakan beberapa teknik baru, seperti cache ad-hoc pertanyaan dan parameterization otomatis. Namun, query SQL Server 7,0 secara otomatis parameterizes terbatas. Menggunakan metode berikut untuk membuat yakin bahwa rencana permintaan adalah parameterized dan dapat digunakan kembali lebih efektif:
  • Parameter spidol OLE DB dan ODBC api mengizinkan parameter harus ditentukan dengan tanda tanya ketika pengguna mengirimkan permintaan. Hal ini dapat sangat berguna dalam aplikasi, terutama untuk aplikasi tingkat menengah yang memiliki permintaan generasi modul di mana menggunakan prosedur yang tersimpan ini tidak tersedia. Rencana permintaan yang dihasilkan untuk query yang memiliki parameter spidol dapat digunakan kembali oleh setiap klien yang mengeksekusi query yang sama, bahkan jika nilai parameter yang berbeda ditentukan. Untuk selengkapnya, lihat topik "Parameter spidol" dalam SQL Server 7.0 buku Online.
  • sp_executesql The sp_executesql disimpan prosedur yang disebut oleh penyedia OLE DB atau ODBC driver Ketika tanda-tanda parameter yang digunakan dalam aplikasi. Namun, itu juga mungkin dipanggil langsung oleh aplikasi atau di lain prosedur yang tersimpan secara eksplisit mengukur ad-hoc queries. Hal ini dapat sangat berguna dalam aplikasi atau batch file di mana pernyataan EXECUTE digunakan untuk mengeksekusi pernyataan SQL dinamis. Tidak seperti sp_executesql, MENGEKSEKUSI pernyataan tidak mengizinkan parameterization. Ini membatasi kesempatan permintaan rencana kembali. Untuk informasi lebih lanjut, lihat "sp_executesql (T-SQL)" dan "Menggunakan sp_executesql" topik di SQL Server 7.0 Buku secara Online.
  • Disimpan prosedur Disimpan prosedur memiliki banyak manfaat, termasuk kemampuan untuk mengukur query dan menggunakan kembali rencana eksekusi. Untuk informasi lebih lanjut, lihat "Stored Procedures" dan "Pemrograman disimpan prosedur" topik di SQL Server 7,0 Buku secara Online.

Melihat data kinerja Monitor

Menggunakan log Monitor kinerja untuk menentukan sistem yang sumber daya yang menyebabkan kemacetan. Monitor kinerja log dapat memberikan gambaran keseluruhan sistem dan membantu memusatkan perhatian Anda ketika Anda melihat data SQL Profiler. Meninjau Monitor kinerja data dari waktu ketika kinerja yang baik melalui waktu yang kinerja menurun. Menentukan Counter yang terpengaruh pertama, dan kemudian tentukan berikut isu-isu paling relevan untuk situasi Anda:
  • Objek: proses
    Counter: prosesor
    Contoh: SQL Server
  • Objek: prosesor
    Counter: % waktu prosesor
    Contoh: Memeriksa setiap contoh prosesor
  • Objek: Manajer SQL Server: Buffer
    Counter: gratis Buffer
  • Objek: Manajer SQL Server: Buffer
    Counter: Dicuri Halaman Count
  • Objek: Manajer SQL Server: memori
    Counter: memori Hibah tertunda
  • Objek: SQL Server: SQL Statistik
    Counter: SQL Kompilasi/sec
Jika penggunaan CPU, SQL kompilasi/sec, dan gratis buffer Counter yang tinggi, dan memori hibah tertunda dan dicuri halaman menghitung Counter rendah, hal ini menunjukkan bahwa CPU kemacetan. Fokus pada cara secara efektif mengukur dan menggunakan kembali permintaan rencana untuk menghindari biaya permintaan rencana generasi, dan melihat bagian "Kelompok jejak SQL Profiler oleh acara kelas" Artikel ini. Jika Counter gratis buffer dan SQL kompilasi/sec rendah, dan dicuri halaman menghitung dan memori hibah tertunda Counter tinggi, SQL Server dibatasi memori. Fokus pada menemukan pertanyaan di mana hash bergabung adalah digunakan dan dapat berubah menjadi loop bergabung, dan melihat "grup the SQL Profiler jejak oleh durasi"bagian dari artikel ini. Untuk informasi lebih lanjut tentang ini Counter, menggunakan nama counter untuk mencari SQL Server 7.0 buku Online.

Melihat data SQL Profiler

Ketika Anda menyelesaikan masalah kinerja, itu adalah sangat berharga untuk melihat data SQL Profiler. Anda tidak harus meninjau semua data yang Anda menangkap; selektif. SQL Profiler membantu Anda untuk melihat secara efektif data yang diambil. Pada Properti tab (pada Berkas menu, klik Properti), SQL Profiler memungkinkan Anda untuk membatasi data yang ditampilkan dengan menghapus data kolom atau peristiwa, pengelompokan atau penyortiran oleh kolom data, dan menerapkan penyaring. Kamu bisa mencari jejak seluruh atau hanya kolom khusus untuk nilai-nilai tertentu (pada Mengedit menu, klik Menemukan ). Anda juga dapat menyimpan SQL Profiler data untuk tabel SQL Server (pada Berkas menu, Arahkan ke Simpan sebagai, lalu klik Jejak Tabel), dan kemudian jalankan SQL query terhadap itu.

Catatan Pastikan bahwa Anda hanya menyaring jejak disimpan file. Jika Anda mengikuti langkah-langkah berikut pada jejak aktif, Anda berisiko kehilangan data yang ditangkap sejak jejak dimulai. Menyimpan jejak aktif ke file atau tabel pertama (pada Berkas menu, klik Simpan sebagai ), dan kemudian buka kembali itu (pada Berkas menu, klik Terbuka) sebelum Anda Lanjutkan. Ketika Anda bekerja dengan file disimpan jejak, penyaringan tidak secara permanen menghapus data; data hanya tersembunyi, tidak dihapus. Anda dapat menambahkan dan menghapus peristiwa dan kolom data untuk membantu fokus pencarian Anda.

Anda juga harus fokus pada daerah-daerah di mana Anda menerima yang paling manfaat. The faktor-faktor berikut dapat membantu meningkatkan kinerja aplikasi tetapi tidak harus untuk gelar yang sama. Sebelum Anda menerapkan perubahan, menentukan seberapa efektif perubahan mungkin tergantung pada faktor-faktor berikut:
  • Seberapa sering menjalankan query
  • Berapa banyak perbaikan query dapat ditingkatkan
Sebagai contoh, mengurangi waktu eksekusi query satu dari 1,5 detik untuk 1.2 detik tidak dapat membantu jika pertanyaan tidak dijalankan sering sepanjang hari. Namun, jika pertanyaan sangat dijalankan sering oleh sejumlah besar pengguna bersamaan, peningkatan kinerja dapat menjadi sangat efektif. Sebaliknya, meningkatkan permintaan satu dari 6 menit ke 3 detik tidak dapat menghasilkan peningkatan kinerja keseluruhan terlihat jika jarang digunakan. Menggunakan pengelompokan dan penyaringan teknik dalam SQL Profiler dan Anda Pengetahuan aplikasi untuk memperkirakan efek permintaan tertentu atau prosedur sebelum Anda menerapkan perubahan. Fokus pada perubahan yang paling efektif pertama, dan kemudian lanjutkan dengan iterasi melalui lain pertanyaan dan prosedur sampai Anda mencapai tingkat di mana kinerja telah cukup meningkat.

Setelah Anda menyimpan jejak SQL Profiler ke file atau meja, membuka kembali jejak dalam SQL Profiler dan meninjau isi. Untuk kelompok SQL Profiler melacak, ikuti langkah berikut:
  • Kelompok jejak SQL Profiler oleh durasi:
    1. Pada Berkas menu, klik Properti.
    2. Klik Kolom data tab, dan kemudian di bawah Kelompok, klik UP untuk memindahkan Durasi. Klik TURUN untuk menghapus semua lain kolom.
    3. Klik Peristiwa tab, dan kemudian menghapus semua acara kecuali TSQL SQL:StmtCompleted dan TSQL RPC: selesai. Ini memungkinkan Anda untuk fokus pada hanya permintaan yang sedang dijalankan.
    4. Klik Oke.
    Pengelompokan oleh durasi memungkinkan untuk dengan mudah melihat SQL pernyataan, batch, dan prosedur yang menjalankan selamban. Review jejak ketika masalah ini terjadi, dan membuat dasar dari kinerja yang baik. Anda dapat menyaring oleh awal waktu untuk menembus jejak bagian ketika kinerja adalah baik dan terpisah bagian ketika kinerja miskin. Mencari pertanyaan dengan durasi terpanjang ketika kinerja baik. Ini kemungkinan akar masalah. Ketika kinerja sistem secara keseluruhan menurun, bahkan baik permintaan dapat menampilkan durasi panjang karena mereka sedang menunggu untuk sumber daya sistem.

    Meninjau pelaksanaan rencana untuk pertanyaan yang paling sering memiliki durasi panjang. Jika Anda melihat bahwa hash join sedang digunakan, pertimbangkan untuk menggunakan LOOP JOIN permintaan petunjuk untuk memaksa bergabung bersarang loop untuk permintaan. Jika waktu eksekusi untuk query menggunakan loop bergabung kurang dari, sama dengan, atau bahkan sedikit lebih tinggi daripada waktu eksekusi dengan bergabung hash, bergabung dengan lingkaran mungkin pilihan yang lebih baik jika komputer mengalami tinggi memori dan penggunaan CPU. Oleh mengurangi stres pada sumber daya kemacetan (CPU dan memori), Anda dapat meningkatkan keseluruhan kinerja sistem. Untuk informasi lebih lanjut tentang LOOP bergabung permintaan petunjuk, lihat topik "Pilih (T-SQL)" dalam SQL Server 7.0 buku Online.
  • Kelompok jejak SQL Profiler oleh acara kelas:
    1. Pada Berkas menu, klik Properti.
    2. Klik Kolom data tab, dan kemudian di bawah Kelompok menuju, klik UP untuk memindahkan Acara kelas dan Teks dengan Peristiwa Kelas di atas. Klik TURUN untuk menghapus semua kolom lain di bawah Kelompok judul.
    3. Klik Peristiwa tab, dan kemudian membuat yakin bahwa semua peristiwa disertakan.
    4. Klik Oke.

Jenis peristiwa

Untuk melihat apa jenis peristiwa yang terjadi pada komputer yang menjalankan SQL Server dan seberapa sering terjadi peristiwa-peristiwa, kelompok oleh Peristiwa Kelas kolom. Pencarian ini kolom berikut:
  • MISC: Mempersiapkan SQL dan Exec siap SQL; KURSOR: Cursorprepare A Mempersiapkan SQL acara menunjukkan bahwa pernyataan SQL yang siap untuk digunakan dengan default hasil set (sisi klien kursor) menggunakan SQLPrepare/SQLExecute (untuk ODBC) atau ICommandText::Prepare/ICommandText::Execute (untuk OLE DB) dengan default kursor pilihan: ke depan saja, baca saja, ukuran rowset = 1. A Cursorprepare acara menunjukkan bahwa kursor sisi server sudah siap di SQL pernyataan yang menggunakan SQLPrepare/SQLExecute (untuk ODBC) atau ICommandText::Prepare/ICommandText::Execute (untuk OLE DB) dengan salah satu sebelumnya kursor pilihan menetapkan nilai non-standar. An Exec siap SQL acara menunjukkan bahwa salah satu sebelumnya jenis ada pernyataan siap dieksekusi. Jika Anda melihat sering kejadian ini peristiwa, aplikasi Anda menggunakan model mempersiapkan/menjalankan ketika terbuka Hasilnya menetapkan. Jika demikian, Anda harus menentukan jika Anda mempersiapkan/menjalankan model dengan benar.

    Idealnya, aplikasi mempersiapkan pernyataan SQL sekali dan mengeksekusinya berkali-kali sehingga Pengoptimal tidak harus mengkompilasi rencana baru setiap kali pernyataan dijalankan. Setiap kali Anda menjalankan siap pernyataan, Anda menghemat biaya kompilasi permintaan. Jika Anda hanya berencana untuk mengeksekusi query satu kali, Microsoft merekomendasikan bahwa Anda tidak menyiapkan. Menyiapkan dan kemudian mengeksekusi pernyataan SQL memerlukan tiga jaringan roundtrips: satu untuk mempersiapkan pernyataan, satu untuk melaksanakan pernyataan, dan satu untuk unprepare pernyataan. Menyiapkan server-side kursor memerlukan setidaknya lima putaran perjalanan: satu untuk mempersiapkan kursor, satu untuk menjalankan atau membukanya, salah satu atau lebih untuk mengambil dari itu, satu untuk menutupnya dan satu untuk unprepare itu. Mengeksekusi permintaan hanya membutuhkan satu ulang-alik.

    Untuk melihat seberapa efektif Anda aplikasi menggunakan mempersiapkan/menjalankan model, membandingkan jumlah kali ini dua peristiwa (menyiapkan dan melaksanakan) terjadi. Jumlah Exec siap SQL peristiwa harus lebih besar dari total Mempersiapkan SQL dan CursorPrepare peristiwa (setidaknya tiga sampai lima kali lebih besar adalah perkiraan yang baik). Hal ini menunjukkan bahwa pernyataan siap yang sedang kembali cukup sering untuk mengatasi peningkatan overhead untuk menciptakan mereka. Jika jumlah Mempersiapkan SQL dan CursorPrepare peristiwa kira-kira setara dengan jumlah Exec siap SQL peristiwa, ini dapat menunjukkan bahwa aplikasi yang tidak efektif menggunakan mempersiapkan/menjalankan model. Mencoba untuk menyiapkan sebuah pernyataan sekali dan menggunakan kembali itu sebanyak mungkin. Anda juga dapat mengubah aplikasi Anda untuk mempersiapkan pernyataan satu waktu dan menggunakan kembali pernyataan-pernyataan.

    Aplikasi harus secara khusus ditulis untuk menggunakan mempersiapkan/menjalankan model efisien. The seumur hidup dari pegangan untuk pernyataan siap dikendalikan oleh berapa lama Anda tetap HSTMT terbuka di ODBC atau objek ICommandText di OLE DB. Satu umum praktek ini untuk mendapatkan HSTMT, mempersiapkan pernyataan SQL, mengeksekusi yang siap pernyataan, dan kemudian gratis HSTMT, sehingga kehilangan pegangan untuk siap rencana. Jika Anda melakukan ini, Anda tidak menerima manfaat dari mempersiapkan/menjalankan model. Bahkan, Anda mungkin melihat penurunan kinerja karena ekstra overhead roundtrips jaringan. Aplikasi harus memiliki sebuah metode untuk men-cache HSTMT atau objek dengan pernyataan yang sudah disiapkan menangani dan untuk mengakses mereka untuk menggunakan kembali. Driver atau penyedia tidak melakukan hal ini secara otomatis; aplikasi bertanggung jawab untuk melaksanakan, mempertahankan, dan menggunakan informasi ini. Jika aplikasi tidak dapat melakukannya, pertimbangkan untuk menggunakan spidol parameter bukannya mempersiapkan/menjalankan metode.
  • Menggunakan parameter spidol Aplikasi dapat menggunakan parameter spidol untuk mengoptimalkan penggunaan pernyataan Transact-SQL yang sama beberapa kali dengan masukan yang berbeda dan nilai-nilai output. Pertama kalinya bahwa query dijalankan, disiapkan sebagai permintaan parameterized, dan SQL Server menghasilkan dan cache rencana parameterized untuk permintaan. Untuk panggilan selanjutnya untuk permintaan yang sama menggunakan baik sama atau berbeda parameter, SQL Server tidak harus menghasilkan rencana permintaan baru; SQL Server dapat menggunakan kembali yang ada permintaan rencana dengan menggantikan parameter saat ini.

    Jika aplikasi menggunakan spidol parameter dengan panggilan untuk SQLExecDirect (untuk ODBC) atau ICommandText::Execute (untuk OLE DB), driver atau penyedia secara otomatis paket pernyataan SQL dan mengeksekusinya sebagai sp_executesql panggilan. Pernyataan tidak harus menjadi siap dan dieksekusi secara terpisah. Ketika SQL Server menerima panggilan untuk sp_executesql, secara otomatis memeriksa cache prosedur untuk rencana pencocokan reuses rencana itu dan menghasilkan rencana baru.

    Untuk menentukan apakah Anda aplikasi saat ini menggunakan spidol parameter, Anda dapat mencariTeks kolom dalam SQL Profiler jejak untuk "sp_executesql." Namun, karena sp_executesql dapat dipanggil langsung, tidak semua contoh menunjukkan penggunaan parameter spidol.

    Untuk informasi lebih lanjut tentang mempersiapkan/menjalankan model, lihat topik "Pelaksanaan rencana Caching dan kembali" dalam SQL Server 7.0 buku Online. Untuk informasi lebih lanjut tentang parameter spidol, lihat "Parameter Tanda-tanda"topik dalam SQL Server 7.0 buku Online.
  • SP: selesai Pernyataan SQL dinamis yang dijalankan dengan MENGEKSEKUSI perintah ditampilkan sebagai SP: selesai acara dengan teks "Dinamis SQL." Memperluas SP: selesai acara, dan kemudian mencari kejadian yang memiliki "dinamis SQL"sebagai teks. Jika ada banyak peristiwa ini, Anda dapat meningkatkan kinerja aplikasi dengan menggunakan sp_executesql Alih-alih MENGEKSEKUSI pernyataan. The sp_executesql disimpan prosedur izin SQL Server untuk menggunakan kembali rencana eksekusi jika permintaan yang sama dijalankan lagi menggunakan parameter yang berbeda. Ketika Anda menggunakan MENGEKSEKUSI pernyataan, rencana tidak parameterized, dan tidak kembali kecuali query dijalankan lagi dengan parameter yang sama.

    Untuk menentukan pertanyaan atau prosedur yang menggunakan dinamis SQL peristiwa dengan EXECUTE pernyataan, catatan ID koneksi dan mulai waktu untuk setiap peristiwa. Ungroup jejak (Hapus Acara kelas dan Teks dari Kelompok pos). Setelah Anda ungroup jejak, itu adalah diurutkan dalam urutan kronologis. Anda dapat menyaring jejak oleh koneksi ID (pada Filter tab), dan kemudian menghapus semua kelas acara kecuali SP: mulai dan SP: lengkap peristiwa untuk meningkatkan keterbacaan. Anda kemudian dapat mencari Waktu acara mulai (pada Mengedit menu, klikMenemukan). Hasilnya menunjukkan ketika acara SQL dinamis dimulai. Jika acara terjadi pada prosedur yang disimpan, acara muncul antara SP: mulai dan SP: selesai peristiwa untuk prosedur. Jika acara tidak terjadi pada disimpan prosedur, dieksekusi sebagai permintaan ad-hoc, dan Anda dapat menggunakan data lainnya kolom)Nama aplikasi, NT Nama penggunadan lain-lain) untuk menentukan di mana perintah dieksekusi. Pada menentukan teks perintah dan konteks di mana itu dijalankan, Anda juga dapat menambahkan acara kelas, seperti SQL:BatchCompleted dan SQL:RPCCompleted.

    Setelah Anda menentukan di mana pernyataan EXECUTE sedang digunakan, mempertimbangkan menggantinya dengan panggilan untuk sp_executesql. Sebagai contoh, perhatikan skenario berikut di mana EXECUTE perintah ini digunakan dengan SQL dinamis. Prosedur mengambil nama tabel, ID, dan idValue sebagai input parameter, dan kemudian mengeksekusi pernyataan pilih dari Tabel berdasarkan nilai ID. Menggunakan pernyataan EXECUTE, prosedur terlihat mirip dengan kode berikut:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    Dengan asumsi bahwa permintaan tidak parameterized secara otomatis, jika Anda melaksanakan prosedur ini terhadap judul Tabel di pub Contoh database dua kali dengan nilai-nilai yang berbeda untuk @ idValue parameter, SQL Server harus menghasilkan rencana terpisah permintaan untuk setiap pelaksanaan. Misalnya:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Catatan Dalam contoh ini, permintaan ini cukup sederhana bahwa SQL Server dapat secara otomatis mengukur dan benar-benar menggunakan kembali rencana pelaksanaan. Namun, Jika ini adalah kompleks query SQL Server mungkin tidak secara otomatis mengukur, Menggunakan SQL Server mungkin tidak kembali rencana untuk eksekusi kedua jika @ idValue parameter ini berubah. Batas-batas sederhana permintaan kompleksitas contoh.

    Anda dapat menulis ulang prosedur ini menggunakan sp_executesql Alih-alih MENGEKSEKUSI pernyataan. Dukungan untuk parameter substitusi membuat sp_executesql lebih efisien karena itu menghasilkan rencana eksekusi yang lebih mungkin untuk digunakan kembali oleh SQL Server. Misalnya:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    Dalam contoh ini, pertama kalinya bahwa sp_executesql pernyataan dijalankan, SQL Server menghasilkan rencana parameterized untuk pernyataan pilih dari judul dengan title_id sebagai parameter. Untuk kedua eksekusi, SQL Server reuses rencana dengan nilai parameter baru. Untuk informasi selengkapnya tentang sp_executesql, lihat topik "Menggunakan sp_executesql" dan "sp_executesql (T-SQL)" dalam SQL Server 7.0 buku secara Online.
  • SP:RECOMPILES Acara ini menunjukkan bahwa prosedur yang disimpan recompiled selama eksekusi. Banyak mengkompilasi ulang peristiwa menunjukkan bahwa SQL Server menggunakan sumber daya untuk permintaan kompilasi bukannya eksekusi query.
Jika Anda tidak melihat salah satu peristiwa ini, aplikasi ini mengeksekusi hanya ad-hoc permintaan terhadap SQL Server. Kecuali SQL Server menentukan secara otomatis dapat mengukur query tertentu atau jika sama parameter yang digunakan berulang kali, setiap permintaan yang dijalankan memerlukan SQL Server untuk menghasilkan rencana eksekusi baru. Monitor kinerja SQL Server harus menunjukkan banyak SQL kompilasi/sec. Hal ini dapat CPU-intensif untuk banyak concurrent pengguna. Untuk mengatasi masalah ini, menemukan yang paling sering dieksekusi permintaan, dan Pertimbangkan membuat disimpan prosedur untuk pertanyaan ini, menggunakan parameter spidol, atau menggunakan sp_executesql.

REFERENSI

Untuk informasi lebih lanjut tentang pemantauan dan pemecahan masalah kinerja dalam SQL Server, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
224587Bagaimana memecahkan masalah kinerja aplikasi dengan SQL Server
224453 INF: Memahami dan memecahkan SQL Server 7.0 atau masalah pemblokiran 2000
243586 Pemecahan masalah disimpan prosedur recompilation
243589 Bagaimana memecahkan masalah berjalan lambat query di SQL Server 7.0 atau yang lebih baru
251004 INF: Bagaimana untuk memantau menghalangi SQL Server 7.0

Properti

ID Artikel: 243588 - Kajian Terakhir: 20 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Kata kunci: 
kbhowtomaster kbhowto kbinfo kbmt KB243588 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:243588

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com