नहीं, कनेक्शन स्ट्रिंग आपका VPN टनल शुरू नहीं कर सकती

डेवलपर अब भी वह जगह खोजते हैं जहाँ कोई कनेक्शन स्ट्रिंग, JDBC URL या tnsnames.ora प्रविष्टि VPN चुनती है। ऐसी जगह नहीं है। टनल ऑपरेटिंग सिस्टम या विक्रेता के क्लाइंट द्वारा बनाई जाती है जो एक वर्चुअल एडाप्टर पंजीकृत करता है, और उसके ऊपर की हर डेटाबेस लाइब्रेरी उसी सॉकेट परत का उपयोग करती है जो इससे बनती है। कनेक्शन स्ट्रिंग होस्ट, पोर्ट और क्रेडेंशियल का नाम बताती है, और पूरी शब्दावली इतनी ही है।

मिथक: कनेक्शन स्ट्रिंग टनल चुन सकती है

ड्राइवर होस्ट और पोर्ट पर TCP सॉकेट खोलता है। उसके पास टनल ऊपर उठाने का कोई API नहीं है, टनल प्रोफ़ाइल के लिए कोई फ़ील्ड नहीं है, और VPN गेटवे पर प्रमाणित होने का कोई तरीका नहीं है।

इसीलिए रूट बन जाने के बाद टूल एक जैसा व्यवहार करते हैं। SSMS, DBeaver, Eclipse Data Tools और सामान्य sqlcmd सब ऐसे काम करते हैं जैसे सर्वर स्थानीय नेटवर्क पर हो, क्योंकि सॉकेट की दृष्टि से वह वहाँ है। वर्चुअल एडाप्टर ने डेटाबेस सबनेट को पहुँच योग्य बनाया, और ड्राइवर को कभी पता नहीं चलता कैसे।

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

ड्राइवर चलने से पहले टनल ऊपर उठाएँ

VPN को ऑपरेटिंग सिस्टम स्तर पर जोड़ें, प्रदाता या नेटवर्क टीम के निर्देशों का पालन करते हुए, और उसके बाद ही टूल खोलें। व्यवहार में इसका अर्थ है कि ड्राइवर के होस्ट नाम हल करने से पहले डेटाबेस सबनेट तक रूट मौजूद होता है।

टनल की निगरानी एप्लिकेशन से बाहर रखें. PHP या Java सेवा जो स्वयं लिंक उठाने की कोशिश करती है, एक प्रदाता का व्यवहार व्यावसायिक कोड में लिख देती है, और हर फ़ेलओवर एप्लिकेशन रिलीज़ बन जाता है। जो सुपरवाइज़र टनल का मालिक है, उसे देखता है और पुनः आरंभ करता है, वह क्वेरी पथ से अलग विषय है।

ड्राइवर पर दोष डालने से पहले रूट जाँचें: यदि होस्ट हल नहीं होता या शेल से पोर्ट उत्तर नहीं देता, तो कोई भी कनेक्शन स्ट्रिंग इसे नहीं बदलेगी।

मिथक: Windows प्रमाणीकरण विफलता का अर्थ है रूट टूटा है

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

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly स्विच उन क्रेडेंशियल को केवल दूरस्थ प्रमाणीकरण के लिए रखता है। कनेक्शन संवाद पर भरोसा करने के बजाय SELECT SUSER_SNAME() से पुष्टि करें कि सर्वर को वास्तव में क्या मिला। बताया जाता है कि सर्वर पते का क्रेडेंशियल Windows Credential Manager में संग्रहीत करना SSMS के लिए काम करता है पर किसी दूसरे खाते के अंतर्गत चलने वाली सेवा के लिए हमेशा नहीं, इसलिए लॉगिन बदलने से पहले देखें कि प्रक्रिया कौन-सी पहचान उपयोग करती है।

विलंब सर्वर-साइड कर्सर को टाइमआउट में बदल देता है

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

क्लाइंट-साइड कर्सर पर जाएँ, या fetch size बढ़ाएँ और पंक्तियों को बैच करें, तो राउंड ट्रिप की संख्या घट जाती है। अवरोध बदलावों की संख्या है, नाममात्र लिंक गति नहीं, इसलिए थ्रूपुट मापना आपको भ्रमित करेगा जबकि राउंड ट्रिप मापना नहीं करेगा। उस सबसे बड़े परिणाम सेट से परीक्षण करें जो आपके उपयोगकर्ता वास्तव में खींचते हैं, तुरंत लौटने वाली एक-पंक्ति की क्वेरी से नहीं। यदि टाइमआउट खिसकता है पर गायब नहीं होता, तो कमांड टाइमआउट और fetch size एक साथ बढ़ाएँ और फिर मापें।

यही गणित बातूनी ORM और हर उस क्लाइंट पर लागू होता है जो प्रति पंक्ति एक कथन जारी करता है। यदि क्वेरी योजना ठीक है और स्थानांतरण छोटा है, तो डेटाबेस ट्यून करने से पहले नेटवर्क बदलाव गिनें।

पोर्ट, इंस्टेंस और स्थानीय फ़िल्टर जाँचें

नामित इंस्टेंस गतिशील पोर्ट पर सुनता है, इसलिए 1433 मान लेने के बजाय पोर्ट की पुष्टि करें। डिफ़ॉल्ट इंस्टेंस पर मान इंस्टेंस की SuperSocketNetLib कुंजी के अंतर्गत TcpPort रजिस्ट्री मान से पढ़ा जा सकता है। Oracle के लिए, जाँचें कि tnsnames.ora में होस्ट हल होता है, पता उत्तर देता है और listener पोर्ट अनुमत है; 1521 एक सामान्य डिफ़ॉल्ट है, गारंटी नहीं।

फिर टनल की अपनी एक्सेस सूची और अंत में एक स्थानीय एंटीवायरस या होस्ट फ़ायरवॉल को बाहर करें जो क्लाइंट और सर्वर एक ही मशीन होने पर भी कनेक्शन रोकता है। कॉन्फ़िगरेशन बदलने से पहले विफल होने वाला चरण दर्ज करें, क्योंकि नाम हल करना, TCP पहुँच और TLS या लॉगिन में से हर एक अलग संदेश के साथ विफल होता है।

चरण को टिकट में लिखें। वरना अगला व्यक्ति वही कनेक्शन-स्ट्रिंग खोज दोहराएगा जिससे यह सब शुरू हुआ था।