Rabu, 16 November 2011

Memecahkan masalah lambat query di SQL Server

Bagaimana memecahkan masalah berjalan lambat query di SQL Server 7.0 atau versi yang lebih baru



Artikel ini menjelaskan cara untuk menangani masalah kinerja yang aplikasi mungkin mengalami dalam hubungannya dengan Microsoft SQL Server: memperlambat kinerja pencarian tertentu atau kelompok queries. Jika Anda memecahkan masalah kinerja, tapi Anda tidak terisolasi masalah untuk pencarian tertentu atau kelompok kecil dari query yang melakukan lebih lambat dari yang diharapkan, lihat artikel berikut pada Basis Pengetahuan Microsoft sebelum Anda melanjutkan:
224587  (http://support.microsoft.com/kb/224587/ ) CARA: Memecahkan masalah kinerja aplikasi dengan SQL Server
Artikel ini didasarkan pada asumsi bahwa Anda telah menggunakan artikel 224587 untuk mempersempit cakupan masalahnya, dan bahwa Anda telah menangkap jejak SQL Profiler dengan khusus kolom peristiwa dan data yang rinci dalam artikel 224587.

Tuning database queries dapat menjadi usaha yang beraneka ragam. Bagian berikut membahas item yang umum untuk memeriksa ketika Anda sedang menyelidiki performa query.

Catatan Jika Anda menggunakan SQL Server 2005, menggunakan SQL Server Management Studio bukan SQL Query Analyzer, dan menggunakan Database Engine Tuning Advisor bukan indeks Tuning Wizard.

Memverifikasi keberadaan indeks benar

Salah satu cek pertama untuk melakukan ketika Anda mengalami eksekusi query lambat kali adalah analisis indeks. Jika Anda sedang menyelidiki permintaan satu, Anda dapat menggunakan Melakukan analisis indeks pilihan dalam SQL Query Analyzer; Jika Anda memiliki jejak SQL Profiler beban kerja yang besar, Anda dapat menggunakan Wisaya Tuning indeks. Metode kedua menggunakan query SQL Server optimizer untuk menentukan indeks yang akan sangat membantu untuk query tertentu. Ini adalah metode yang sangat efisien untuk menentukan apakah indeks benar ada di database Anda.

Untuk informasi tentang cara menggunakan Wisaya Tuning indeks, lihat topik "Indeks Tuning Wizard" dalam SQL Server 7.0 buku Online.

Jika Anda telah mengupgrade aplikasi Anda dari versi sebelumnya dari SQL Server, indeks yang berbeda mungkin lebih efisien dalam SQL Server 7.0 karena optimizer dan penyimpanan mesin perubahan. Indeks Tuning Wizard membantu Anda untuk menentukan jika perubahan dalam indeks strategi akan meningkatkan kinerja.

Untuk informasi lebih lanjut tentang bagaimana menggunakan Database Engine Tuning Advisor bukannya indeks Tuning Wizard di SQL Server 2005, lihat topik berikut dalam SQL Server 2005 buku Online:
  • Perbedaan antara Database Engine Tuning Advisor dan indeks Tuning Wizard
  • Database Engine Tuning Advisor tutorial

Menghapus semua permintaan, meja, dan bergabung dengan petunjuk

Petunjuk mengabaikan permintaan optimasi dan dapat mencegah query optimizer memilih rencana pelaksanaan tercepat. Karena dari Pengoptimal perubahan, petunjuk bahwa peningkatan kinerja di versi sebelumnya dari SQL Server mungkin tidak memiliki efek atau mungkin benar-benar negatif mempengaruhi kinerja dalam SQL Server 7.0. Selain itu, bergabung dengan petunjuk dapat menyebabkan penurunan kinerja berdasarkan alasan berikut:
  • Bergabung dengan petunjuk mencegah permintaan ad hoc dari yang memenuhi syarat untuk auto-parameterization dan caching query rencana.
  • Ketika Anda menggunakan petunjuk bergabung, ini menyiratkan bahwa Anda ingin memaksa agar bergabung semua tabel dalam query, bahkan jika mereka bergabung secara eksplisit tidak menggunakan petunjuk.
Jika permintaan yang Anda menganalisis mencakup setiap petunjuk, Hapus mereka, dan kemudian kembali mengevaluasi kinerja.

Memeriksa rencana pelaksanaan

Setelah Anda mengkonfirmasi bahwa indeks benar ada, dan bahwa tidak ada petunjuk membatasi Pengoptimal kemampuan untuk menghasilkan rencana efisien, Anda dapat memeriksa rencana eksekusi query. Anda dapat menggunakan salah satu metode berikut untuk melihat pelaksanaan rencana untuk permintaan:
  • SQL Profiler

    Jika Anda tertangkap Misc:Execution rencana acara di SQL Profiler, hal itu akan terjadi segera sebelum StmtCompleted acara untuk permintaan untuk sistem tertentu proses ID (SPID).
  • SQL Query Analyzer: Grafis Showplan

    Dengan permintaan yang dipilih di jendela permintaan, klik Permintaan menu, dan kemudian klik Tampilan diperkirakan rencana pelaksanaan.

    CATATAN: Jika disimpan prosedur atau batch menciptakan dan referensi temporary tables, Anda harus menggunakan pernyataan MENETAPKAN profil statistik ON atau secara eksplisit membuat tabel sementara sebelum Anda menampilkan rencana pelaksanaan.
  • SHOWPLAN_ALL dan SHOWPLAN_TEXT

    Untuk menerima versi teks rencana pelaksanaan perkiraan, Anda dapat menggunakan opsi MENETAPKAN SHOWPLAN_ALL dan MENGATUR SHOWPLAN_TEXT. Lihat "SET SHOWPLAN_ALL (T-SQL)" dan "SET SHOWPLAN_TEXT (T-SQL)" topik di SQL Server 7.0 buku Online untuk rincian lebih lanjut.

    CATATAN: Jika disimpan prosedur atau batch menciptakan dan referensi temporary tables, Anda harus menggunakan opsi SET statistik profil ON atau secara eksplisit membuat tabel sementara sebelum menampilkan rencana pelaksanaan.
  • PROFIL STATISTIK

    Ketika Anda menampilkan rencana pelaksanaan perkiraan, baik grafis atau dengan menggunakan SHOWPLAN, query tidak benar-benar dijalankan. Oleh karena itu, jika Anda membuat tabel sementara dalam batch atau prosedur yang disimpan, Anda tidak dapat menampilkan rencana pelaksanaan perkiraan karena tabel sementara tidak akan ada. Profil statistik mengeksekusi query pertama, dan kemudian menampilkan rencana pelaksanaan sebenarnya. Lihat topik "SET statistik profil (T-SQL)" dalam SQL Server 7.0 buku Online untuk rincian lebih lanjut. Ketika berjalan di SQL Query Analyzer, ini muncul dalam format grafis pada Rencana pelaksanaan tab di jendela hasil.
Untuk informasi lebih lanjut tentang bagaimana untuk menampilkan rencana pelaksanaan perkiraan dalam SQL Server 2005, lihat topik "Bagaimana untuk menampilkan rencana pelaksanaan perkiraan" dalam SQL Server 2005 buku Online.

Memeriksa Showplan Output

Showplan output menyediakan banyak informasi tentang rencana pelaksanaan yang SQL Server menggunakan untuk query tertentu. Rincian informasi dan peristiwa yang dihasilkan dibahas secara rinci dalam bab "Mengoptimalkan Database kinerja" SQL Server 7.0 buku online. Berikut ini adalah beberapa aspek dasar rencana eksekusi yang Anda dapat untuk menentukan apakah Anda menggunakan rencana terbaik:
  • Benar indeks penggunaan

    Showplan output menampilkan setiap tabel yang terlibat dalam query dan jalur akses yang digunakan untuk memperoleh data dari itu. Dengan grafis showplan, menggerakkan pointer di atas meja untuk melihat rincian untuk setiap tabel. Jika indeks ini digunakan, Anda melihat "Indeks mencari"; Jika indeks tidak digunakan, Anda melihat baik "Tabel Scan" untuk tumpukan atau "Berkerumun indeks memindai" meja yang memiliki indeks berkerumun. "Berkumpul indeks Scan" menunjukkan bahwa tabel yang dipindai melalui indeks berkerumun, tidak bahwa indeks berkerumun sedang digunakan untuk langsung mengakses individu baris.

    Jika Anda menentukan bahwa indeks berguna ada dan itu tidak digunakan untuk permintaan, Anda dapat mencoba memaksa indeks dengan menggunakan indeks petunjuk. Lihat "Dari (T-SQL)" topik dalam SQL Server buku Online untuk rincian lebih lanjut tentang indeks petunjuk.
  • Urutan bergabung dengan benar

    Showplan output menunjukkan dalam rangka apa tabel yang terlibat dalam permintaan yang bergabung. Untuk bersarang loop bergabung, atas meja yang tercantum adalah meja luar dan harus lebih kecil dari dua tabel. Untuk bergabung hash, tabel atas menjadi masukan membangun dan juga harus lebih kecil dari dua tabel. Namun, perhatikan bahwa urutan kurang kritis karena prosesor permintaan dapat membalikkan membangun dan menyelidiki input pada jangka waktu jika menemukan bahwa Pengoptimal membuat keputusan yang salah. Anda dapat menentukan tabel yang kembali lebih sedikit baris dengan memeriksa perhitungan baris memperkirakan dalam showplan output.

    Jika Anda menentukan bahwa permintaan mungkin mendapat manfaat dari urutan berbeda bergabung, Anda dapat mencoba memaksa urutan bergabung dengan sedikit bergabung. Lihat "Dari (T-SQL)" topik dalam SQL Server 7.0 buku Online untuk rincian lebih lanjut tentang petunjuk bergabung.

    CATATAN: Menggunakan petunjuk bergabung dalam permintaan besar secara implisit memaksa agar bergabung meja lain dalam permintaan seolah-olah FORCEPLAN ditetapkan.
  • Benar bergabung jenis

    SQL Server menggunakan bersarang loop, hash, dan bergabung bergabung. Jika permintaan lambat-melakukan menggunakan teknik bergabung satu atas yang lain, Anda dapat mencoba memaksa tipe berbeda bergabung. Sebagai contoh, jika query menggunakan bergabung hash, Anda dapat memaksa bersarang loop bergabung dengan menggunakan LOOP bergabung dengan petunjuk. Lihat "Dari (T-SQL)" topik dalam SQL Server 7.0 buku Online untuk rincian lebih lanjut bergabung dengan petunjuk.

    CATATAN: Menggunakan petunjuk bergabung dalam permintaan besar secara implisit pasukan jenis bergabung meja lain dalam permintaan seolah-olah FORCEPLAN ditetapkan.
  • Pelaksanaan paralel

    Jika Anda menggunakan komputer multiprosesor, Anda dapat juga menyelidiki apakah rencana paralel yang digunakan. Jika paralelisme digunakan, Anda melihat PARALELISME (Mengumpulkan Stream) acara. Jika permintaan tertentu lambat ketika menggunakan rencana paralel, Anda dapat mencoba memaksa rencana non-paralel dengan menggunakan opsi (MAXDOP 1) petunjuk. Lihat topik "Pilih (T-SQL)" dalam SQL Server 7.0 buku Online untuk rincian lebih lanjut.
Untuk informasi lebih lanjut tentang cara menggunakan Showplan pelaksanaan rencana output dalam SQL Server 2005, lihat topik berikut dalam SQL Server 2005 buku Online:
  • Bagaimana cara menyimpan pelaksanaan rencana dalam XML format
  • XML Showplans
  • Showplan keamanan
HATI-HATI: Karena query optimizer biasanya memilih rencana pelaksanaan terbaik untuk permintaan, Microsoft merekomendasikan Anda menggunakan bergabung dengan petunjuk, petunjuk permintaan dan petunjuk meja hanya sebagai pilihan terakhir, dan hanya jika Anda berpengalaman database administrator.