Pertanyaan Bagaimana Anda menangani kesalahan tingkat transportasi di SqlConnection?


Sesekali dalam aplikasi .NET volume tinggi, Anda mungkin melihat pengecualian ini saat Anda mencoba mengeksekusi kueri:

System.Data.SqlClient.SqlException: Kesalahan tingkat transportasi   terjadi saat mengirim permintaan ke server.

Menurut penelitian saya, ini adalah sesuatu yang "terjadi begitu saja" dan tidak banyak yang bisa dilakukan untuk mencegahnya. Itu tidak terjadi sebagai hasil dari permintaan yang buruk, dan umumnya tidak dapat diduplikasi. Ini hanya terjadi mungkin sekali setiap beberapa hari dalam sistem OLTP yang sibuk ketika koneksi TCP ke database memburuk karena suatu alasan.

Saya dipaksa untuk mendeteksi kesalahan ini dengan menguraikan pesan pengecualian, dan kemudian mencoba kembali seluruh operasi dari awal, untuk memasukkan menggunakan koneksi baru. Tidak ada yang cantik.

Ada yang punya solusi alternatif?


32
2017-08-19 17:36


asal


Jawaban:


Saya memposting jawaban atas pertanyaan lain pada topik lain yang mungkin ada gunanya di sini. Jawaban itu melibatkan koneksi SMB, bukan SQL. Namun itu identik karena melibatkan kesalahan transportasi tingkat rendah.

Apa yang kami temukan adalah bahwa dalam situasi beban berat, cukup mudah bagi server jarak jauh untuk mengakhiri koneksi di lapisan TCP hanya karena server sedang sibuk. Sebagian alasannya adalah default untuk berapa kali TCP akan mengirim ulang data pada Windows tidak sesuai untuk situasi kita.

Lihatlah di pengaturan registri untuk tuning TCP / IP di Windows. Khususnya Anda ingin melihat TcpMaxDataRetransmissions dan mungkin TcpMaxConnectRetransmissions. Ini default untuk 5 dan 2 masing-masing, cobalah menaikkan mereka sedikit pada sistem klien dan duplikat situasi beban.

Jangan gila! TCP menggandakan batas waktu dengan setiap transmisi ulang berturut-turut, sehingga perilaku timeout untuk koneksi yang buruk dapat menjadi eksponensial pada Anda jika Anda meningkatkannya terlalu banyak. Seperti yang saya ingat TcpMaxDataRetransmissions untuk 6 atau 7 memecahkan masalah kami di sebagian besar kasus.


8
2017-10-16 07:50



Ini posting blog oleh Michael Aspengren menjelaskan pesan kesalahan "Kesalahan tingkat transportasi terjadi ketika mengirim permintaan ke server."


3
2018-01-29 07:20



Untuk menjawab pertanyaan asli Anda:

Cara yang lebih elegan untuk mendeteksi kesalahan khusus ini, tanpa menguraikan pesan kesalahan, adalah dengan memeriksa Number milik dari SqlException.

(Ini sebenarnya mengembalikan nomor kesalahan dari yang pertama SqlError dalam Errors koleksi, tetapi dalam kasus Anda kesalahan transportasi harus menjadi satu-satunya dalam koleksi.)


2
2017-10-01 05:57



menggunakan Layanan Perusahaan dengan komponen transaksional


1
2017-07-23 15:24



Saya telah melihat ini terjadi di lingkungan saya sendiri beberapa kali. Aplikasi klien dalam kasus ini diinstal pada banyak mesin. Beberapa mesin itu kebetulan laptop orang meninggalkan aplikasi terbuka memutuskan itu dan kemudian memasukkannya kembali dan mencoba untuk menggunakannya. Ini kemudian akan menyebabkan kesalahan yang telah Anda sebutkan.

Poin pertama saya adalah melihat jaringan dan memastikan bahwa server tidak ada di DHCP dan memperbarui Alamat IP yang menyebabkan kesalahan ini. Jika itu tidak terjadi maka Anda harus mulai menarik melalui log peristiwa Anda mencari jaringan lain yang terkait.

Sayangnya itu seperti yang dinyatakan di atas kesalahan jaringan. Hal utama yang dapat Anda lakukan hanyalah memantau koneksi menggunakan alat seperti netmon dan bekerja kembali dari sana.

Semoga berhasil.


1
2017-10-31 06:30



Anda juga harus memeriksa konektivitas perangkat keras ke database.

Mungkin utas ini akan membantu: http://channel9.msdn.com/forums/TechOff/234271-Komentikasi-terlurus- tertutup-SQL-2005/


0
2017-08-19 18:02



Saya menggunakan lapisan keandalan di sekitar perintah DB saya (diabstraksikan dalam interfaece repositori). Pada dasarnya itu hanya kode yang memotong pengecualian yang diharapkan (DbException dan juga InvalidOperationException, yang terjadi untuk dilemparkan pada masalah konektivitas), log, menangkap statistik dan mencoba lagi semuanya.

Dengan adanya lapisan keandalan ini, layanan ini telah mampu bertahan dari stress-testing dengan lancar (dead-lock yang konstan, kegagalan jaringan, dll). Produksi jauh lebih tidak bersahabat dari itu.

PS: Ada lebih banyak di sini (bersama dengan cara sederhana untuk menentukan keandalan dengan DSL intersepsi)


0
2017-10-01 04:53



Saya memiliki masalah yang sama. Saya bertanya kepada teman-teman geek jaringan saya, dan semua mengatakan apa yang telah dijawab orang di sini: Ini adalah koneksi antara komputer dan server basis data. Dalam kasus saya, itu adalah Penyedia Layanan Internet saya, atau router di sana yang menjadi masalah. Setelah pembaruan Router, masalahnya hilang. Tetapi apakah Anda memiliki koneksi internet putus-putus lainnya dari komputer atau server Anda? Aku punya ...


0
2017-10-01 06:05