Inilah yang saya pelajari sejauh ini dari penelitian saya.
.NET mengirimkan pengaturan koneksi yang tidak sama dengan yang Anda dapatkan saat masuk ke studio manajemen. Inilah yang Anda lihat jika Anda mengendus koneksi dengan Sql Profiler:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Saya sekarang menempelkan pengaturan tersebut di atas setiap kueri yang saya jalankan saat masuk ke server sql, untuk memastikan pengaturannya sama.
Untuk kasus ini, saya mencoba setiap pengaturan satu per satu, setelah memutuskan dan menghubungkan kembali, dan menemukan bahwa mengubah arithabort dari mati ke aktif mengurangi kueri masalah dari 90 detik menjadi 1 detik.
Penjelasan yang paling mungkin terkait dengan parameter sniffing, yang merupakan teknik yang digunakan Sql Server untuk memilih apa yang dianggapnya sebagai rencana kueri yang paling efektif. Saat Anda mengubah salah satu setelan koneksi, pengoptimal kueri mungkin memilih paket yang berbeda, dan dalam kasus ini, tampaknya memilih paket yang buruk.
Tapi saya tidak sepenuhnya yakin akan hal ini. Saya telah mencoba membandingkan rencana kueri yang sebenarnya setelah mengubah pengaturan ini dan saya belum melihat perbedaan yang menunjukkan perubahan apa pun.
Apakah ada hal lain tentang pengaturan arithabort yang mungkin menyebabkan kueri berjalan lambat dalam beberapa kasus?
Solusinya tampak sederhana:Letakkan saja set arithabort di bagian atas prosedur tersimpan. Tapi ini bisa menyebabkan masalah sebaliknya:mengubah parameter kueri dan tiba-tiba berjalan lebih cepat dengan 'mati' daripada 'aktif'.
Untuk saat ini saya menjalankan prosedur 'dengan kompilasi ulang' untuk memastikan paket dibuat ulang setiap kali. Tidak masalah untuk laporan khusus ini, karena mungkin perlu satu detik untuk mengkompilasi ulang, dan ini tidak terlalu terlihat pada laporan yang membutuhkan 1-10 detik untuk kembali (ini monster).
Namun ini bukan opsi untuk kueri lain yang berjalan lebih sering dan harus kembali secepat mungkin, hanya dalam beberapa milidetik.
