Freigeben über

Behandeln von Problemen mit Always On für SQL Server

  • Artikel

Dieser Artikel hilft Ihnen, das häufige Problem bei der Always On-Konfiguration auf SQL Server zu beheben.

Notiz

Eine geführte exemplarische Vorgehensweise in diesem Artikel finden Sie unter "Behandeln von SQL Server Always On-Problemen".

Originalproduktversion: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Ursprüngliche KB-Nummer: 10179

Wichtige Hinweise

Ich benötige Zeiger zum Einrichten und Konfigurieren von AlwaysOn-Verfügbarkeitsgruppen

Wenn Sie nach Dokumentation zum Einrichten der AlwaysOn-Konfiguration suchen, lesen Sie die folgenden Dokumente:

Erste Schritte mit Always On Availability Groups (SQL Server) – Das Dokument enthält Antworten auf viele Fragen, die Sie möglicherweise über Verfügbarkeitsgruppen und Setup haben. Wenn Sie alle Schritte in diesem Artikel ausführen und Voraussetzungen, Einschränkungen und Empfehlungen für Always On Availability Groups (SQL Server) überprüfen, können Sie viele Probleme verhindern, die beim Einrichten und Verwalten von Verfügbarkeitsgruppen in Ihrer Umgebung auftreten können.

Zusätzliche Ressourcen

Wenn diese Informationen nicht hilfreich sind, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Ich habe Probleme beim Konfigurieren von Always On-Verfügbarkeitsgruppen

Typische Konfigurationsprobleme umfassen AlwaysOn-Verfügbarkeitsgruppen sind deaktiviert, Konten sind falsch konfiguriert, der Endpunkt für die Datenbankspiegelung ist nicht vorhanden, auf den Endpunkt kann nicht zugegriffen werden (SQL Server-Fehler 1418), Netzwerkzugriff ist nicht vorhanden, und ein Verknüpfungsdatenbankbefehl schlägt fehl (SQL Server-Fehler 35250). Lesen Sie das folgende Dokument, um Hilfe zur Problembehandlung dieser Probleme zu finden:

Problembehandlung für die AlwaysOn-Verfügbarkeitsgruppenkonfiguration (SQL Server)

Zusätzlicher Link: Beheben: Fehler 41009, wenn Sie versuchen, mehrere Verfügbarkeitsgruppen zu erstellen

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Ich habe Probleme mit der Listener-Konfiguration (19471, 19476 und andere Fehler)

Eines der häufigsten Konfigurationsprobleme, auf die Kunden stoßen, ist die Erstellung von Verfügbarkeitsgruppenlistener. Die Fehler ähneln den folgenden:

  • Msg 19471, Level 16, State 0, Line 2The WSFC cluster could not bring the Network Name resource with DNS name '' online. Möglicherweise wurde der DNS-Name übernommen oder hat einen Konflikt mit vorhandenen Namendiensten, oder der WSFC-Clusterdienst wird nicht ausgeführt oder kann nicht darauf zugreifen. Verwenden Sie einen anderen DNS-Namen, um Namenskonflikte aufzulösen, oder überprüfen Sie das WSFC-Clusterprotokoll auf weitere Informationen.

  • Msg 19476, Level 16, State 4, Line 2Die Versuche, den Netzwerknamen und die IP-Adresse für den Listener zu erstellen, ist fehlgeschlagen. Möglicherweise wird der WSFC-Dienst nicht ausgeführt oder kann im aktuellen Zustand nicht darauf zugreifen, oder die für den Netzwerknamen und die IP-Adresse bereitgestellten Werte sind falsch. Überprüfen Sie den Status des WSFC-Clusters, und überprüfen Sie den Netzwerknamen und die IP-Adresse mit dem Netzwerkadministrator.

Der Großteil der Zeit führt zu einem Fehler bei der Listenererstellung, der zu den vorherigen Nachrichten führt, aufgrund fehlender Berechtigungen für das Clustername-Objekt (Cluster Name Object, CNO) in Active Directory, um das Listenercomputerobjekt zu erstellen und zu lesen. Informationen zur Problembehandlung finden Sie in den folgenden Artikeln:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Automatisches Failover funktioniert nicht wie erwartet

Wenn Sie feststellen, dass das automatische Failover nicht wie erwartet funktioniert, entweder während des Tests oder in der Produktion, lesen Sie: Problembehandlung bei automatischen Failoverproblemen in SQL Server 2012 AlwaysOn-Umgebungen.

Falsche Konfiguration der maximalen Fehler im angegebenen Zeitraum ist eine der führenden Ursachen für primäre Fehler, die nicht automatisch auf die sekundäre. Der Standardwert für diese Einstellung ist N-1, wobei N die Anzahl der Replikate ist. Weitere Informationen finden Sie unter "Maximale Fehlergrenze für Failovercluster (Gruppe)".

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Ich habe Probleme beim Herstellen einer Verbindung mit AlwaysOn-Verfügbarkeitsgruppen

Nachdem Sie den Verfügbarkeitsgruppenlistener für eine AlwaysOn-Verfügbarkeitsgruppe in SQL Server 2012 konfiguriert haben, können Sie den Listener möglicherweise nicht pingen oder über eine Anwendung eine Verbindung damit herstellen. Möglicherweise erhalten Sie einen Fehler, der den folgenden ähnelt:

Sqlcmd: Fehler: Microsoft SQL Native Client : Anmeldetimeout abgelaufen.

Gehen Sie wie folgt vor, um diese und ähnliche Fehler zu beheben:

Weitere Informationslinks:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Ich habe Probleme beim Konfigurieren von Always On-Verfügbarkeitsgruppen in meiner Azure-VM (IaaS)

  1. Viele Probleme im Zusammenhang mit Always On treten aufgrund einer fehlerhaften Konfiguration des Listeners auf. Wenn Verbindungsprobleme mit dem Listener auftreten,

    1. Stellen Sie sicher, dass Sie alle Einschränkungen des ILB-Listeners lesen und alle schritte befolgt haben, die im folgenden Artikel dokumentiert sind, wobei sie besonders auf abhängigkeitskonfiguration, IP-Adresse und verschiedene andere Parameter im PowerShell-Skript achten.

    2. Wenn Sie nicht sicher sind, können Sie den Listener gemäß dem obigen Dokument löschen und neu erstellen.

  2. Wenn Sie Ihren virtuellen Computer kürzlich in einen anderen Dienst verschoben haben oder die IP-Adressen geändert wurden, müssen Sie den Wert der IP-Adressressource aktualisieren, um die neue Adresse widerzuspiegeln, und Sie müssen den Lastenausgleichsendpunkt für Ihre AG neu erstellen. Sie können die IP-Adresse mit den Get folgenden Befehlen Set aktualisieren:

    Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"

Empfohlene Dokumente:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Es dauert lange, bis ein Failover von primär auf sekundär oder umgekehrt erfolgt.

Nach einem automatischen Failover oder einem geplanten manuellen Failover ohne Datenverlust für eine Verfügbarkeitsgruppe stellen Sie möglicherweise fest, dass die Failoverzeit Ihre Recovery Time Objective (RTO) überschritten hat. Informationen zur Problembehandlung der Ursachen und potenziellen Lösungen finden Sie unter "Problembehandlung: Verfügbarkeitsgruppe überschrittenE RTO".

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Änderungen am primären Replikat werden entweder nicht angezeigt oder langsam in das sekundäre Replikat repliziert.

Möglicherweise stellen Sie fest, dass Änderungen am primären Replikat nicht zeitnah an sekundäre Replikate weitergegeben werden. Um diese Probleme zu beheben und zu beheben, versuchen Sie Folgendes:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Verwalten der Größe des Transaktionsprotokolls für meine AG-Datenbanken

Sie können die Transaktionsprotokollgrößen reduzieren, indem Sie regelmäßige Sicherungen auf primären oder sekundären Servern konfigurieren.

Weitere Informationen finden Sie in den folgenden Themen:

Wenn diese Informationen nicht hilfreich sind, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Primäre oder sekundäre Server, die beim Auflösen des Zustands getroffen wurden oder unerwartete Failover auftreten

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Ressourcen nicht online übertragen können

Überprüfen Sie, ob die Datenbanken eine lange Zeit in Anspruch nehmen, indem Sie die Nachrichten im SQL ErrorLog überprüfen.

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.

Häufig gestellte Fragen

  1. Ist es möglich, zwei Listener für eine Verfügbarkeitsgruppe zu haben?

    Ja, Sie können mehrere Listener für dieselbe Verfügbarkeitsgruppe einrichten. Erfahren Sie , wie Sie mehrere Listener für dieselbe Verfügbarkeitsgruppe (Goden Yao) erstellen.

  2. Ist es möglich, eine separate NIC-Karte für immer auf Datenverkehr und Clientkonnektivität zu haben?

    Ja, Sie können eine dedizierte NIC-Karte für Always On-Datenverkehr haben. Siehe Konfigurieren der Verfügbarkeitsgruppe für die Kommunikation in einem dedizierten Netzwerk.

  3. Welche Editionen unterstützen Always On-Failoverclusterinstanzen?

    Dieses Thema in SQL Server Books Online enthält weitere Informationen: Editionen und unterstützte Features für SQL Server 2016.

  4. Wie kann ich bei einem Fehler auf allen Knoten des Clusters wiederherstellen?

    Siehe WSFC Disaster Recovery durch erzwungenes Quorum (SQL Server).

  5. Wo finde ich Informationen zur Unterstützung von verteilten Transaktionen in AG-Konfigurationen?

    Siehe Transaktionen – Verfügbarkeitsgruppen und Datenbankspiegelung.

  6. Wie aktualisieren Sie AlwaysOn-Konfigurationen?

    Siehe Upgrade always On Availability Group Replica Instances.

  7. Wie kann TDE (Transparente Datenverschlüsselung) aktivierte Datenbank zur AG-Konfiguration hinzugefügt werden?

    Informationen zum Hinzufügen von TDE-aktivierten DB zu AG finden Sie unter "Konfigurieren von Always On" für eine TDE-Datenbank.

  8. Wie konfigurieren Sie Warnungen für die Überprüfung, ob die sekundäre Verzögerung hinter dem primären liegt?

    Sie können das folgende Skript verwenden:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

  9. Wie wird benachrichtigt, wenn der Status der Datenbank nicht synchronisiert ist?

    Sie können das folgende Skript verwenden:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

    Sie können auch die folgenden Links überprüfen, um weitere Methoden zum Überwachen von AlwaysOn-Gruppen zu erhalten:

Weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen