MSSQLSERVER_35250

Gilt für: SQL Server

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 eigenen Prozess 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 Port-owning-Prozess finden: Führen Sie einen Befehl wie folgt aus (z. B. mithilfe von 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 verwenden, um zu lauschen, im Vergleich zum Standard "Alle überwachen", 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. Sicherstellen, dass Ihr SQL Server auf einem aktuellen Build (nach Möglichkeit der neueste Build) ausgeführt wird

• 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“.