Az SQL Server olyan VPN-címhez kötődik, amely indításkor nincs jelen

Olvasson el egy SQL Server-naplósort egy sikertelen kötésről, miközben a szolgáltatás még fut, és Ön indítási sorrendtől való függőséget talált, nem összeomlást. Ez a kombináció a nyom: a motor azelőtt indult el, hogy a cím, amelyen hallgatnia kellett volna, létezett volna a gépen. A bejelentkezés után feljövő VPN-adapter rossz előfeltétel a felügyelet nélküli adatbázis-szolgáltatás számára, ezért kövesse a hibát abban a sorrendben, ahogy a motor látja.

Az indítási naplónál kezdje, ne az ügyfélnél

Nyissa meg a példány hibanaplóját, és olvassa el a hálózat inicializálása körüli bejegyzéseket, ne csak az utolsó sort. A motor jelenti, mely címeket próbált és mely protokollokat engedélyezett, és ez a bejegyzés még azelőtt keletkezett, hogy bármely ügyfél csatlakozott volna. Most nézze meg, mi létezik a gazdagépen éppen most. Ha a beállított cím tulajdonosa felület csak akkor jelenik meg, miután egy felhasználó bejelentkezik és elindít egy ügyfelet, a cím hiányzott indításkor, és a kötési hiba teljesen megmagyarázható.

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

Igazítsa a példány útvonalát a telepítéséhez, és olvassa el a felületlistát, mielőtt következtetéseket von le. Az a cím, amely létezik, de a rossz adapterhez tartozik, más probléma, mint az a cím, amely még nem létezik.

Járja végig a kötési sorrendet, amelyet a motor valóban követ

A motor beolvassa a figyelő konfigurációját, majd megkéri az operációs rendszert a kötésre. Ha a cím abban a pillanatban nem helyi, a kötés meghiúsul arra a címre, miközben a példány többi része normálisan folytatódhat. Ezért működhetnek továbbra is más protokollok vagy más címek, és ezért a „leállt az SQL Server“ a rossz összefoglaló. Őrizze meg a naplóból a pontos végpontot: cím, port és protokoll, mert a javítás attól függ, melyik a három közül a hibás.

A szolgáltatás újraindítása az adapter megjelenése után általában sikerre viszi a figyelőt, és pontosan ez a csapda. Bizonyítja a függőséget ahelyett, hogy megszüntetné, és minden csatlakozott felhasználót megszakít minden alkalommal, amikor az alagút újracsatlakozik.

Úgy olvassa a figyelőt, ahogy a motor olvassa

Az SQL Server Configuration Managerben nyissa meg a példány TCP/IP-tulajdonságait, és az egyes címek szerkesztése előtt jegyezze fel a Listen All beállítást. Ha a Listen All Yes értékű, a címenkénti Enabled értékeket figyelmen kívül hagyja, így azok szerkesztése semmit sem változtat azon, amit a figyelő használ. Jegyezzen fel hármat sorrendben: a kiszolgálni kívánt címet, a portot, és hogy a figyelő minden címet vagy csak egyet fedjen-e le. Ezután alkalmazza a változtatást a támogatott újraindítási eljárással, és olvassa el a következő indítási naplót annak megerősítésére, hogy a motor azt kötötte, amit kért.

Minden címen figyelni nem hozzáférés-vezérlés. Ha egy széles figyelő valóban szükséges, minden elérhető felületnek saját tűzfal- és adatbázis-engedélyezési döntésre van szüksége, beleértve az internet felé néző felületeket is.

Adjon az ügyfélnek stabil célpontot

Az ügyfélnek nincs szüksége arra, hogy az adatbázis-gazdagép készletcímet viseljen. Az útvonalválasztott kialakítás úgy működik, hogy a kiszolgáló a stabil privát címén figyel, miközben a VPN-átjáró továbbítja az ügyfél forgalmát felé, és visszahozza a választ.

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

Ha az ügyfél eléri a 10.80.0.15 címet, az útvonal bizonyított, és az adatbázisnak már csak engedélyeznie kell azt az ügyfelet. Ha nem, javítsa az útvonalválasztást és a DNS-t, mielőtt újra hozzányúlna a figyelőhöz, mert a kiszolgálón lévő kötési probléma soha nem volt az oka annak, hogy egy ügyfél nem találja. Hamis készletcím hozzáadása a kiszolgálóhoz, vagy egy második alapértelmezett átjáró a figyelő kedvéért új hálózati problémát teremt a régi tetején. Tartsa a kiszolgáló címzését statikusan, és hagyja, hogy az alagút vigye hozzá az ügyfeleket.

Ellenőrizze az ügyfél által használt végpontot

Fejezze be alkalmazásszintű ellenőrzéssel, ne portteszttel. Csatlakozzon az ügyfélről azzal a fiókkal, amelyet az alkalmazás használ, és olvassa el a kiszolgáló oldali kapcsolat részleteit, amelyek megmutatják, melyik helyi címre érkezett a munkamenet.

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"

Hasonlítsa össze ezt a címet a beállított figyelővel. Az eltérés második figyelőt vagy váratlan helyen feloldódó nevet jelent, és mindkettőt érdemes tudni, mielőtt a következő újraindítás Ön helyett teszteli a javítást. Ezután indítsa újra a gazdagépet bejelentkezett felhasználó nélkül, és erősítse meg, hogy a kötés sikerül. Az az egyetlen teszt a különbség a megjavított figyelő és a következő javítási éjszakán elbukó kerülő megoldás között.