एसक्यूएलकनेक्शन में परिवहन-स्तर की त्रुटियों से आप कैसे निपटते हैं?

Question

हर अब और फिर एक उच्च मात्रा .NET अनुप्रयोग में, तो आप इस अपवाद जब आप कोई क्वेरी को निष्पादित करने की कोशिश देख सकते हैं:

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server.

मेरे शोध के अनुसार, यह कुछ ऐसा है ज्यादा नहीं "सिर्फ होता है" और है इसे रोकने के लिए किया जा सकता है। यह एक बुरी क्वेरी के परिणामस्वरूप नहीं होता है, और आमतौर पर डुप्लिकेट नहीं किया जा सकता है। यह व्यस्त ओएलटीपी सिस्टम में हर कुछ दिनों में एक बार हो सकता है जब किसी कारण से डेटाबेस में टीसीपी कनेक्शन खराब हो जाता है।

मुझे अपवाद संदेश को पार्स करके इस त्रुटि का पता लगाने के लिए मजबूर किया गया है, और उसके बाद एक नया कनेक्शन उपयोग करने के लिए पूरे ऑपरेशन को स्क्रैच से पुनः प्रयास कर रहा है। इनमें से कोई भी सुंदर नहीं है।

किसी के पास कोई वैकल्पिक समाधान है?

Answer 1

आपको डेटाबेस से हार्डवेयर कनेक्टिविटी भी जांचनी चाहिए।

शायद यह धागा सहायक होगा: http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/

Answer 2

मैं अपने डीबी आदेशों के आसपास विश्वसनीयता परत (भंडार interfaece में दूर निकाला) का उपयोग कर रहा हूँ। असल में यह केवल वह कोड है जो किसी भी अपेक्षित अपवाद को रोकता है (डीबीएक्सप्शन और अमान्य ओपेरेशन अपवाद, जो कनेक्टिविटी समस्याओं पर फेंकने वाला होता है), इसे लॉग करता है, आंकड़ों को कैप्चर करता है और सबकुछ फिर से पुनः प्राप्त करता है।

उस विश्वसनीयता परत के साथ, सेवा तनाव परीक्षण को लगातार (लगातार मृत-ताले, नेटवर्क विफलताओं इत्यादि) में जीवित रहने में सक्षम रही है। उत्पादन उससे कहीं कम विरोधी है।

पुनश्च: There is more on that here अपने मूल प्रश्न का उत्तर देने

Answer 3

(एक सरल अवरोधन डीएसएल के साथ विश्वसनीयता परिभाषित करने के लिए जिस तरह से साथ साथ): त्रुटि संदेश पार्स करने के बिना, इस विशेष त्रुटि का पता लगाने के

एक और अधिक सुरुचिपूर्ण तरीका SqlException की Number संपत्ति का निरीक्षण करना है।

(यह वास्तव में पहले SqlErrorErrors संग्रह में से त्रुटि संख्या देता है, लेकिन आपके मामले में परिवहन त्रुटि संग्रह में केवल एक ही होना चाहिए।)

Answer 4

मैं एक ही समस्या थी। मैंने अपने नेटवर्क गीक दोस्तों से पूछा, और सभी ने कहा कि लोगों ने यहां क्या जवाब दिया है: यह कंप्यूटर और डेटाबेस सर्वर के बीच कनेक्शन है। मेरे मामले में यह मेरा इंटरनेट सेवा प्रदाता था, या वहां राउटर था जो समस्या थी। राउटर अपडेट के बाद, समस्या चली गई। लेकिन क्या आपके पास कंप्यूटर या सर्वर से इंटरनेट कनेक्शन का कोई अन्य ड्रॉप-आउट है? मेरे पास था ...

Answer 5

मैंने an answer on another question पर एक और विषय पर पोस्ट किया है जिसका यहां कुछ उपयोग हो सकता है। उस उत्तर में एसएमबी कनेक्शन शामिल थे, एसक्यूएल नहीं। हालांकि यह समान था कि इसमें निम्न स्तर की परिवहन त्रुटि शामिल थी।

हमें जो मिला वह भारी लोड स्थिति में था, रिमोट सर्वर के लिए टीसीपी परत पर कनेक्शन कनेक्शन के समय के लिए काफी आसान था क्योंकि सर्वर व्यस्त था। कारणों का एक हिस्सा यह था कि टीसीपी कितनी बार विंडोज़ पर डेटा पुन: प्रेषित करेगा, हमारी स्थिति के लिए उपयुक्त नहीं था।

विंडोज पर registry settings for tuning TCP/IP पर एक नज़र डालें।विशेष रूप से आप TcpMaxDataRetransmissions और शायद TcpMaxConnectRetransmissions पर देखना चाहते हैं। ये क्रमशः 5 और 2 के लिए डिफ़ॉल्ट हैं, उन्हें क्लाइंट सिस्टम पर थोड़ा सा अपनाने और लोड स्थिति को डुप्लिकेट करने का प्रयास करें।

पागल मत बनो! टीसीपी प्रत्येक क्रमिक पुन: ट्रांसमिशन के साथ टाइमआउट को दोगुना करता है, इसलिए यदि आप इन्हें बहुत अधिक बढ़ाते हैं तो खराब कनेक्शन के लिए टाइमआउट व्यवहार आपके लिए घातीय हो सकता है। जैसा कि मुझे लगता है कि टीसीपीएमएक्सडेटा रीट्रांसमिशन से 6 या 7 को याद करते हुए, अधिकांश मामलों में हमारी समस्या हल हो गई।

Answer 6

मैंने देखा है कि यह मेरे अपने पर्यावरण में कई बार होता है। इस मामले में क्लाइंट एप्लिकेशन कई मशीनों पर स्थापित है। उनमें से कुछ मशीनें लैपटॉप होती हैं, जो लोग एप्लिकेशन को डिस्कनेक्ट करने के लिए खुली जगह छोड़ रहे थे और फिर इसे वापस प्लग करने और इसका उपयोग करने का प्रयास कर रहे थे। इसके बाद आपके द्वारा उल्लिखित त्रुटि का कारण बन जाएगा।

मेरा पहला बिंदु नेटवर्क को देखना होगा और यह सुनिश्चित करना होगा कि सर्वर DHCP पर नहीं हैं और इस त्रुटि के कारण आईपी पते नवीनीकृत कर रहे हैं। यदि ऐसा नहीं है तो आपको अपने कार्यक्रम लॉग के माध्यम से अन्य नेटवर्क से संबंधित ट्रैवलिंग शुरू करना होगा।

दुर्भाग्यवश यह नेटवर्क त्रुटि से ऊपर बताए गए अनुसार है। मुख्य बात यह है कि आप नेटमोन जैसे टूल का उपयोग करके कनेक्शन की निगरानी कर सकते हैं और वहां से वापस काम कर सकते हैं।

गुड लक।

Answer 7

blog postMichael Aspengren त्रुटि संदेश बताता है "सर्वर पर अनुरोध भेजते समय एक परिवहन-स्तर त्रुटि आई है।"

Answer 8

मुझे एक ही समस्या थी हालांकि यह एक एसक्यूएल डीबी के लिए सेवा अनुरोधों के साथ था।

यह वही है मैं अपने सेवा त्रुटि लॉग में पड़ा है:

---

System.Data.SqlClient.SqlException: जब सर्वर से अनुरोध भेजने के एक परिवहन स्तरीय त्रुटि हुई है। (प्रदाता: टीसीपी प्रदाता, त्रुटि:। 0 - एक मौजूदा कनेक्शन बलपूर्वक दूरस्थ होस्ट द्वारा बंद कर दिया गया था)

---

मैं एक सी # टेस्ट स्वीट है कि एक सेवा का परीक्षण करती है। सेवा और डीबी बाहरी सर्वर पर दोनों थे इसलिए मैंने सोचा कि यह मुद्दा हो सकता है। इसलिए मैंने बिना किसी लाभ के सेवा और डीबी को स्थानीय रूप से तैनात किया। मुद्दा जारी रखा। टेस्ट सूट भी एक कठिन दबाव प्रदर्शन परीक्षण नहीं है, इसलिए मुझे नहीं पता था कि क्या हो रहा था। एक ही परीक्षण हर बार विफल रहा था, लेकिन जब मैंने उस परीक्षण को अक्षम कर दिया, तो दूसरा लगातार असफल हो जाएगा।

• TcpMaxDataRetransmissions और TcpMaxConnectRetransmissions की रजिस्ट्री मान बढ़ाएँ:

  मैं अन्य तरीकों इंटरनेट पर सुझाव दिया है कि या तो काम नहीं किया की कोशिश की।

• "क्लाइंट प्रोटोकॉल" के अंतर्गत SQL सर्वर कॉन्फ़िगरेशन प्रबंधक के भीतर "साझा मेमोरी" विकल्प अक्षम करें और सूची में पहले से टीसीपी/आईपी को सॉर्ट करें।
• यह तब हो सकता है जब आप बड़ी संख्या में क्लाइंट कनेक्शन प्रयासों के साथ स्केलेबिलिटी का परीक्षण कर रहे हों। इस समस्या को हल करने के लिए, 00000000 के मान डेटा के साथ रजिस्ट्री कुंजी HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ पैरामीटर \ के लिए SynAttackProtect नाम का एक नया DWORD मान जोड़ने के लिए regedit.exe उपयोगिता का उपयोग करें।

मेरा आखिरी उपाय पुरानी उम्र का उपयोग करना था "कोशिश करें और पुनः प्रयास करें"। तो मैंने यह सुनिश्चित करने के लिए प्रयास किया है कि कम संचार प्रोटोकॉल में टीसीपी/आईपी कनेक्शन खो गया है, लेकिन यह वहां छोड़ देता है लेकिन फिर कोशिश करता है। यह अब मेरे लिए काम कर रहा है, हालांकि यह एक बहुत ही सुरुचिपूर्ण समाधान नहीं है।

Answer 9

उपयोग व्यवहार घटकों

Answer 10

साथ एंटरप्राइज सर्विसेज जहां तक ​​मेरा बता सकते हैं, वर्ग 20 परिवहन स्तर पर है।

Answer 11

एसक्यूएल 2008 आर 2 एक्सप्रेस से जुड़े हुए एसएसएमएस में आज सुबह परिवहन त्रुटि का अनुभव हुआ।

मैं \ r \ n के साथ एक CSV आयात करने का प्रयास कर रहा था। मैंने 0x0d0x0a के लिए अपनी पंक्ति टर्मिनेटर को कोड किया। जब मैंने इसे 0x0a में बदल दिया, तो त्रुटि बंद हो गई। मैं इसे आगे और आगे बदल सकता हूं और देख सकता हूं कि ऐसा नहीं होता है।

BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH 
     (FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a') 

मुझे लगता है मैं अपने पंक्ति टर्मिनेटर सही ढंग से नहीं लिख रहा हूँ क्योंकि एसक्यूएल एक सही समय जब मैं दो अक्षर पारित करने के लिए कोशिश कर रहा हूँ में एक चरित्र पार्स करता है।

किसी भी तरह, यह त्रुटि अब 4 साल पुरानी है, लेकिन यह अगले उपयोगकर्ता के लिए थोड़ी सी जानकारी प्रदान कर सकती है।

Answer 12

मैं सिर्फ एक फिक्स पोस्ट करना चाहता था जो हमारे द्वारा स्थापित नए सॉफ्टवेयर पर हमारी कंपनी के लिए काम करता है। क्लाइंट लॉग फ़ाइल पर हमें 1 दिन से निम्न त्रुटि मिल रही थी: सर्वर अनुरोध संसाधित करने में असमर्थ था। ---> सर्वर से परिणाम प्राप्त करते समय एक परिवहन-स्तर त्रुटि आई है। (प्रदाता: टीसीपी प्रदाता, त्रुटि: 0 - सेमफोर टाइमआउट अवधि समाप्त हो गई है।) ---> सेमफोर टाइमआउट अवधि समाप्त हो गई है।

हमारे स्विच पर एक लिंक कुल (एलएजी) स्थापित करने के लिए समस्या को पूरी तरह से ठीक किया गया था। हमारे डेल एफएक्स 1 सर्वर के पीछे से बाहर आने वाली अनावश्यक फाइबर लाइनें हैं। हमें एहसास नहीं हुआ कि स्विच को उन दो बंदरगाहों पर एक एलएजी कॉन्फ़िगर करने के लिए प्लग इन किया गया है। यहां विवरण देखें: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation