नाही, कनेक्शन स्ट्रिंग तुमचा 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 किंवा लॉगिन प्रत्येकजण वेगळ्या संदेशाने अयशस्वी होतो.

टप्पा तिकिटात लिहा. नाहीतर पुढची व्यक्ती हे सर्व सुरू करणाराच तोच कनेक्शन-स्ट्रिंग शोध पुन्हा करेल.