SQL Server બૂટ વખતે ન હોય તેવા VPN સરનામા પર બંધાય છે

સેવા હજી ચાલુ હોય ત્યારે નિષ્ફળ બંધન વિશે SQL Server લોગની એક લાઇન વાંચો, અને તમે ક્રેશ નહીં, બૂટ-ક્રમની અવલંબન શોધી કાઢી છે. તે જ સંયોજન સૂત્ર છે: જે સરનામા પર તેને સાંભળવાનું કહેવાયું હતું તે મશીન પર હાજર થયું તે પહેલાં એન્જિન શરૂ થઈ ગયું હતું. સાઇન-ઇન પછી ઉપર આવતો VPN એડેપ્ટર દેખરેખ વિનાની ડેટાબેઝ સેવા માટે નબળી પૂર્વશરત છે, તેથી એન્જિન જે ક્રમમાં નિષ્ફળતા જુએ તે ક્રમમાં આગળ વધો.

ક્લાયન્ટથી નહીં, સ્ટાર્ટઅપ લોગથી શરૂ કરો

ઇન્સ્ટન્સનો ભૂલ લોગ ખોલો અને ફક્ત છેલ્લી લાઇન નહીં, નેટવર્ક ઇનિશિયલાઇઝેશનની આસપાસની એન્ટ્રીઓ વાંચો. એન્જિન જણાવે છે કે તેણે કયા સરનામાં પ્રયત્ન કર્યા અને કયા પ્રોટોકોલ સક્ષમ કર્યા, અને તે રેકોર્ડ કોઈપણ ક્લાયન્ટ જોડાય તે પહેલાંનો છે. હવે જુઓ કે હોસ્ટ પર આ ક્ષણે શું છે. જો કન્ફિગર કરેલા સરનામાની માલિકી ધરાવતું ઇન્ટરફેસ વપરાશકર્તા સાઇન-ઇન કરીને ક્લાયન્ટ શરૂ કર્યા પછી જ દેખાય, તો બૂટ વખતે સરનામું ગેરહાજર હતું અને બંધનની નિષ્ફળતા સંપૂર્ણ સમજાય છે.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

તમારા ઇન્સ્ટોલેશન મુજબ ઇન્સ્ટન્સનો પાથ ગોઠવો, અને તારણ કાઢતા પહેલાં ઇન્ટરફેસ યાદી વાંચો. જે સરનામું અસ્તિત્વમાં છે પણ ખોટા એડેપ્ટરની માલિકીનું છે, તે હજી અસ્તિત્વમાં ન હોય તેવા સરનામા કરતાં અલગ સમસ્યા છે.

એન્જિન ખરેખર જે બંધન ક્રમ અનુસરે છે તે ચાલો

એન્જિન તેનું શ્રોતા રૂપરેખાંકન વાંચે છે, પછી ઑપરેટિંગ સિસ્ટમને બંધન કરવા કહે છે. જો તે ક્ષણે સરનામું સ્થાનિક ન હોય, તો તે સરનામા માટે બંધન નિષ્ફળ જાય છે જ્યારે ઇન્સ્ટન્સનો બાકીનો ભાગ સામાન્ય રીતે ચાલુ રાખી શકે છે. એટલે જ અન્ય પ્રોટોકોલ કે અન્ય સરનામાં હજી કામ કરી શકે છે, અને એટલે જ „SQL Server ડાઉન છે“ ખોટો સારાંશ છે. લોગમાંથી ચોક્કસ અંતિમ બિંદુ સાચવો: સરનામું, પોર્ટ અને પ્રોટોકોલ, કારણ કે સુધારો ત્રણમાંથી કયું ખોટું છે તેના પર આધાર રાખે છે.

એડેપ્ટર દેખાયા પછી સેવા ફરી શરૂ કરવાથી શ્રોતા સામાન્ય રીતે સફળ થાય, અને તે જ જાળ છે. તે અવલંબન દૂર કરવાને બદલે સાબિત કરે છે, અને ટનલ દર વખતે ફરી જોડાય ત્યારે દરેક જોડાયેલા વપરાશકર્તાને કાપી નાખે છે.

એન્જિન જે રીતે વાંચે છે તે રીતે શ્રોતા વાંચો

SQL Server Configuration Manager માં ઇન્સ્ટન્સના TCP/IP ગુણધર્મો ખોલો અને વ્યક્તિગત સરનામાં સંપાદિત કરતા પહેલાં Listen All સેટિંગ નોંધો. જ્યારે Listen All Yes હોય, ત્યારે પ્રતિ-સરનામું Enabled મૂલ્યો અવગણવામાં આવે છે, તેથી તેમને સંપાદિત કરવાથી શ્રોતા જે વાપરે છે તેમાં કંઈ બદલાતું નથી. ક્રમમાં ત્રણ વસ્તુ નોંધો: તમે સેવા આપવા માંગતા સરનામું, પોર્ટ, અને શ્રોતાએ બધા સરનામાં કે ફક્ત એક આવરી લેવું છે. પછી સમર્થિત રીસ્ટાર્ટ પ્રક્રિયા દ્વારા ફેરફાર લાગુ કરો અને આગલો સ્ટાર્ટઅપ લોગ વાંચીને ખાતરી કરો કે એન્જિને તમે માંગ્યું તે બાંધ્યું છે.

દરેક સરનામા પર સાંભળવું એ ઍક્સેસ નિયંત્રણ નથી. જો પહોળો શ્રોતા ખરેખર જરૂરી હોય, તો દરેક પહોંચી શકાય તેવા ઇન્ટરફેસને પોતાનું ફાયરવોલ અને ડેટાબેઝ ઑથોરાઇઝેશન નિર્ણય જોઈએ, ઇન્ટરનેટ તરફ જોતા કોઈપણ ઇન્ટરફેસ સહિત.

ક્લાયન્ટને સ્થિર ગંતવ્ય આપો

ક્લાયન્ટને જરૂર નથી કે ડેટાબેઝ હોસ્ટ પૂલ સરનામું ધારણ કરે. રૂટેડ ડિઝાઇન ત્યારે કામ કરે છે જ્યારે સર્વર તેના સ્થિર ખાનગી સરનામા પર સાંભળે છે અને VPN ગેટવે ક્લાયન્ટનો ટ્રાફિક તેની તરફ મોકલીને જવાબ પાછો લાવે છે.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

જો ક્લાયન્ટ 10.80.0.15 સુધી પહોંચે, તો માર્ગ સાબિત થાય છે અને ડેટાબેઝે ફક્ત તે ક્લાયન્ટને ઑથોરાઇઝ કરવાનું રહે છે. જો ન પહોંચે, તો શ્રોતાને ફરી સ્પર્શતા પહેલાં રૂટિંગ અને DNS સુધારો, કારણ કે સર્વર પરની બંધન સમસ્યા ક્યારેય એ કારણ ન હતી કે ક્લાયન્ટ તેને શોધી શકતો નથી. સર્વરમાં નકલી પૂલ સરનામું ઉમેરવું, અથવા શ્રોતાને ખુશ કરવા બીજું ડિફૉલ્ટ ગેટવે આપવું, જૂની ઉપર નવી નેટવર્ક સમસ્યા ઊભી કરે છે. સર્વરનું સરનામું સ્થિર રાખો અને ટનલને ક્લાયન્ટને તેની તરફ લાવવા દો.

ક્લાયન્ટે વાપરેલું અંતિમ બિંદુ ચકાસો

પોર્ટ પરીક્ષણને બદલે એપ્લિકેશન-સ્તરની ચકાસણીથી અંત કરો. એપ્લિકેશન જે ખાતું વાપરે છે તેની સાથે ક્લાયન્ટથી જોડાઓ અને સર્વર-બાજુની કનેક્શન વિગતો વાંચો, જે દર્શાવે છે કે તમારું સત્ર કયા સ્થાનિક સરનામા પર ઉતર્યું છે.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

તે સરનામાને તમે કન્ફિગર કરેલા શ્રોતા સાથે સરખાવો. વિસંગતિ એટલે બીજો શ્રોતા અથવા અણધાર્યા સ્થળે ઉકેલાતું નામ, અને બંને જાણવા યોગ્ય છે તે પહેલાં કે આગલું રીબૂટ તમારા સુધારાને તમારા વતી પરખે. પછી કોઈ વપરાશકર્તા સાઇન-ઇન ન હોય તેમ હોસ્ટ રીબૂટ કરો અને બંધન સફળ થાય તેની ખાતરી કરો. તે એક જ પરીક્ષણ સુધારેલા શ્રોતા અને આગલી પેચ રાત્રિએ નિષ્ફળ જતા વૈકલ્પિક ઉપાય વચ્ચેનો ફરક છે.