MSSQLSERVER_35250

Artikel
05/23/2023

Details

attribute	Wert
Produktname	SQL Server
Ereignis-ID	35250
Ereignisquelle	MSSQLSERVER
Komponente	SQLEngine
Symbolischer Name	HADR_PRIMARYNOTACTIVE
Meldungstext	Die Verbindung mit dem primären Replikat ist nicht aktiv. Der Befehl kann nicht verarbeitet werden.

Erklärung

Diese Meldung tritt bei dem Versuch auf, sekundäre Datenbanken mit einer Always On-Verfügbarkeitsgruppe zu verknüpfen. In der Regel wird dieser Fehler dadurch verursacht, dass keine Verbindung mit dem Endpunkt hergestellt werden kann.

Benutzeraktion

Option 1: Direktes Ausführen der Schritte in einem Notebook über Azure Data Studio

Notebook in Azure Data Studio öffnen

Informationen zur Installation von Azure Data Studio

Option 2: Manuelles Ausführen des Schritts**

Hinweis

Alle folgenden Schritte müssen sowohl auf dem primären Replikat als auch auf den problematischen sekundären Replikaten ausgeführt werden.

1. Sicherstellen, dass der Endpunkt erstellt und gestartet wurde

Führen Sie die folgende Abfrage aus, um den Endpunkt zu ermitteln:

SELECT
  tep.name as EndPointName,
  sp.name As CreatedBy,
  tep.type_desc,
  tep.state_desc,
  tep.port
FROM
  sys.tcp_endpoints tep
INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE tep.type = 4

Warnung

Seien Sie beim Ausführen des nächsten Befehls vorsichtig, da er zu einer kurzen Ausfallzeit für das Replikat führen kann.

Mithilfe der folgenden Befehle können Sie den ermittelten Endpunkt neu starten:

ALTER ENDPOINT hadr_endpoint STATE = STOPPED
ALTER ENDPOINT hadr_endpoint STATE = STARTED

2. Überprüfen, ob eine Verbindung mit dem Endpunkt hergestellt werden kann

Verwenden Sie telnet oder Test-NetConnection , um die Konnektivität zu überprüfen. Wenn der Endpunkt lauscht und die Verbindung hergestellt wurde, wird von telnet ein leerer Bildschirm mit einem blinkenden Cursor angezeigt. Andernfalls wird von telnet ein Verbindungsfehler ausgegeben. Drücken Sie STRG+], um telnet erfolgreich zu beenden. Wenn Sie Test-NetConnection verwenden, suchen Sie nach TcpTestSucceeded : True oder TcpTestSucceeded : False.
```
telnet ServerName <port_number>
telnet IP_Address <port_number>
```
```
Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>
```

DNS-Probleme:

Wenn die Verbindung telnet/Test-NetConnection mit der IP-Adresse, jedoch nicht mit dem Servernamen hergestellt werden kann, liegt wahrscheinlich ein DNS-Problem oder ein Problem bei der Namensauflösung vor. Weitere Informationen hierzu finden Sie unter Auf Probleme mit der Namensauflösung überprüfen.

Mehrere Prozesse, die am gleichen Port lauschen

Wenn die Verbindung telnet/Test-NetConnection mit dem Servernamen, jedoch nicht mit der IP-Adresse hergestellt werden kann, sind möglicherweise auf dem Server mehrere Endpunkte definiert (eventuell eine andere SQL-Instanz), die an diesem Port lauschen. Obwohl der Status des Endpunkts für die betreffende Instanz „STARTED“ lautet, verfügt möglicherweise eine andere Instanz tatsächlich über die Portbindung und verhindert, dass die richtige Instanz lauscht und TCP-Verbindungen herstellt. Führen Sie den folgenden Befehl aus, um den Besitzprozess von Port 5022 zu finden:
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

Blockierter Endpunkt (Firewall, Virenschutz)

Wenn telnet oder Test-NetConnection keine Verbindung herstellen kann, suchen Sie nach Firewall- und/oder Virenschutzsoftware, die den betreffenden Endpunktport möglicherweise blockiert. Überprüfen Sie die Firewalleinstellung, um zu ermitteln, ob sie die Endpunktportkommunikation zwischen den Serverinstanzen, auf denen das primäre Replikat gehostet wird, und dem sekundären Replikat (standardmäßig Port 5022) zulässt. Wenn Sie SQL Server auf einer Azure-VM ausführen, müssen Sie außerdem sicherstellen, dass die Netzwerksicherheitsgruppe (NSG) den Datenverkehr an den Endpunktport zulässt. Überprüfen Sie die Firewalleinstellung (und NSG, im Falle einer Azure-VM), um zu ermitteln, ob sie die Endpunktportkommunikation zwischen den Serverinstanzen, auf denen das primäre Replikat gehostet wird, und dem sekundären Replikat (standardmäßig Port 5022) zulässt.

Führen Sie das folgende PowerShell-Skript aus, um nach deaktivierten Regeln für eingehenden Datenverkehr zu suchen:
```
Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
```
Erfassen Sie eine Ausgabe von netstat oder Get-NetTCPConnection , und vergewissern Sie sich, dass der Status der IP:Port-Adresse des angegebenen Endpunkts „LISTENING“ oder „ESTABLISHED“ lautet.
```
netstat -a
```
```
Get-NetTCPConnection -LocalPort <port_number>
```

Sie können auch den Portbesitzprozess finden: Führen Sie einen Befehl wie diesen aus (z. B. mit Port 5022).

$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id

3. Überprüfen des Systems auf Fehler

Sie können sys.dm_hadr_availability_replica_states nach „last_connect_error_number“ abfragen, um das Verbindungsproblem zu diagnostizieren. Je nachdem, auf welchem Replikat Kommunikationsprobleme aufgetreten sind, können Sie sowohl das primäre als auch das sekundäre Replikat abfragen:
```
select
  r.replica_server_name,
  r.endpoint_url,
  rs.connected_state_desc,
  rs.last_connect_error_description,
  rs.last_connect_error_number,
  rs.last_connect_error_timestamp
from
  sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r on rs.replica_id = r.replica_id
where
  rs.is_local = 1
```
Wenn beispielsweise das sekundäre Replikat nicht mit dem DNS-Server kommunizieren konnte oder wenn die Endpunkt-URL eines Replikats beim Erstellen der Verfügbarkeitsgruppe falsch konfiguriert wurde, erhalten Sie möglicherweise in „last_connect_error_description“ die folgenden Ergebnisse:

DNS Lookup failed with error '11001(No such host is known)'

4. Sicherstellen, dass der Endpunkt für die richtige Kombination von IP-Adresse und Port konfiguriert ist, für die die Verfügbarkeitsgruppe definiert ist

Führen Sie die folgende Abfrage auf dem primären Replikat und dann auf jedem sekundären Replikat aus, mit dem keine Verbindung hergestellt werden kann. Dadurch können Sie die Endpunkt-URL und den Port ermitteln.
```
select endpoint_url from sys.availability_replicas
```

Führen Sie die folgende Abfrage aus, um die Endpunkte und Ports zu suchen:

SELECT
  tep.name as EndPointName,
  sp.name As CreatedBy,
  tep.type_desc,
  tep.state_desc,
  tep.port
FROM
  sys.tcp_endpoints tep
  INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE
  tep.type = 4

Vergleichen Sie die Endpunkt-URL und den Port jeder Abfrage, und stellen Sie sicher, dass der Port in der Endpunkt-URL mit dem Port übereinstimmt, der für den Endpunkt auf dem jeweiligen Replikat definiert ist.

Hinweis

Wenn Sie bestimmte IP-Adressen für den Endpunkt zum Abhören verwenden, im Gegensatz zum Standard "Alle abhören", müssen Sie möglicherweise URLs definieren, die die spezifische IP-Adresse anstelle des FQDN verwenden.

5. Überprüfen, ob das Netzwerkdienstkonto über CONNECT-Berechtigungen für den Endpunkt verfügt

Führen Sie die folgenden Abfragen aus, um die Konten aufzulisten, die über die Verbindungsberechtigung für den Endpunkt auf den betreffenden Servern verfügen. Außerdem wird hiermit die Berechtigung angezeigt, die jedem relevanten Endpunkt zugewiesen ist.

SELECT 
  perm.class_desc,
  prin.name,
  perm.permission_name,
  perm.state_desc,
  prin.type_desc as PrincipalType,
  prin.is_disabled
FROM sys.server_permissions perm
  LEFT JOIN sys.server_principals prin ON perm.grantee_principal_id = prin.principal_id
  LEFT JOIN sys.tcp_endpoints tep ON perm.major_id = tep.endpoint_id
WHERE 
  perm.class_desc = 'ENDPOINT'
  AND perm.permission_name = 'CONNECT'
  AND tep.type = 4;

SELECT 
  ep.name, 
  sp.state,
  CONVERT(nvarchar(38), suser_name(sp.grantor_principal_id)) AS grantor,
  sp.TYPE AS permission,
  CONVERT(nvarchar(46),suser_name(sp.grantee_principal_id)) AS grantee
FROM sys.server_permissions SP 
  INNER JOIN sys.endpoints ep  ON sp.major_id = ep.endpoint_id
AND EP.type = 4
ORDER BY Permission,grantor, grantee;

6. Überprüfung auf Probleme mit der Namensauflösung

Überprüfen Sie mithilfe von nslookup oder Resolve-DnsName die DNS-Auflösung für die IP-Adresse und den Namen:

nslookup <IP_Address>
nslookup <ServerName>

Resolve-DnsName  -Name <ServerName>
Resolve-DnsName  -Name <IP_address>

Wird der Name in die richtige IP-Adresse aufgelöst? Wird die IP-Adresse in den richtigen Namen aufgelöst?
Suchen Sie auf jedem Knoten, der möglicherweise auf einen falschen Server verweist, nach lokalen HOSTS-Dateieinträgen. Geben Sie an der Eingabeaufforderung mit folgendem Befehl die HOSTS-Datei aus:
```
type C:\WINDOWS\system32\drivers\etc\hosts
```
```
Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
```
Überprüfen Sie, ob auf den Replikaten Serveraliase für die Verwendung durch einen Client definiert sind.

7. Stellen Sie sicher, dass Ihr SQL Server einen aktuellen Build ausführt (vorzugsweise den neuesten Build).

Aktualisieren Sie die SQL Server-Versionen, um Probleme wie KB3213703 zu vermeiden.

Weitere Informationen finden Sie unter Fehler beim Erstellen einer Verfügbarkeitsgruppe mit Fehler 35250 „Fehler beim Verknüpfen der Datenbank“.

Freigeben über