ના, કનેક્શન સ્ટ્રિંગ તમારું 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 અથવા લોગિન દરેક અલગ સંદેશ સાથે નિષ્ફળ જાય છે.

તબક્કો ટિકિટમાં લખો. નહીંતર આગળની વ્યક્તિ એ જ કનેક્શન-સ્ટ્રિંગ શોધનું પુનરાવર્તન કરશે જેનાથી બધું શરૂ થયું હતું.