കണക്ഷൻ സ്ട്രിംഗോ 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 അല്ലെങ്കിൽ ലോഗിൻ എന്നിവ ഓരോന്നും വ്യത്യസ്ത സന്ദേശത്തോടെ പരാജയപ്പെടുന്നു.

ഘട്ടം ടിക്കറ്റിൽ എഴുതുക. അല്ലെങ്കിൽ അടുത്തയാൾ ഇതെല്ലാം ആരംഭിച്ച അതേ കണക്ഷൻ-സ്ട്രിംഗ് തിരച്ചിൽ ആവർത്തിക്കും.

അനുബന്ധ ലേഖനങ്ങൾ