होइन, जडान स्ट्रिङले तपाईंको 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 वा लगइन हरेक फरक सन्देशसँग असफल हुन्छ।

चरण टिकटमा लेख्नुहोस्। नत्र अर्को व्यक्तिले यो सबै सुरु गर्ने त्यही जडान-स्ट्रिङ खोज दोहोर्‍याउनेछ।