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"

Համեմատեք այդ հասցեն ձեր կարգավորած լսողի հետ։ Անհամապատասխանությունը նշանակում է երկրորդ լսող կամ անսպասելի տեղում լուծվող անուն, և երկուսն էլ արժե իմանալ նախքան հաջորդ վերագործարկումը ձեր փոխարեն կփորձարկի ձեր ուղղումը։ Ապա վերագործարկեք հոսթը առանց մուտք գործած օգտատիրոջ և հաստատեք, որ կապը հաջողվում է։ Այդ մեկ թեստն է տարբերությունը վերանորոգված լսողի և հաջորդ կարկատման գիշերը ձախողվող ժամանակավոր լուծման միջև։