Problembehandlung bei SQL Server Always On

  • Artikel

Dieser Artikel hilft Ihnen bei der Behebung des häufig auftretenden Problems mit der konfiguration Always On auf SQL Server.

Hinweis

Eine anleitungsgesteuerte Vorgehensweise in diesem Artikel finden Sie unter Problembehandlung SQL Server Always On.

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

Wichtige Hinweise:

Ich benötige Hinweise zum Einrichten und Konfigurieren Always On Verfügbarkeitsgruppen.

Informationen zum Einrichten Always On Konfiguration finden Sie in den folgenden Dokumenten:

Erste Schritte mit Always On Verfügbarkeitsgruppen (SQL Server): Das Dokument enthält Antworten auf viele Fragen zu Verfügbarkeitsgruppen und zur Einrichtung. Wenn Sie alle Schritte in diesem Artikel befolgen und Die Voraussetzungen, Einschränkungen und Empfehlungen für Always On Verfügbarkeitsgruppen (SQL Server) lesen, können Sie viele Probleme vermeiden, die beim Einrichten und Verwalten von Verfügbarkeitsgruppen in Ihrer Umgebung auftreten können.

Zusätzliche Ressourcen

Wenn diese Informationen nicht hilfreich sind, lesen Sie Weitere Informationen zu Always On Verfügbarkeitsgruppen.

Ich habe Probleme beim Konfigurieren Always On Verfügbarkeitsgruppen.

Typische Konfigurationsprobleme sind, Always On Verfügbarkeitsgruppen deaktiviert sind, Konten falsch konfiguriert sind, der Datenbankspiegelungsendpunkt nicht vorhanden ist, auf den Endpunkt nicht zugegriffen werden kann (SQL Server Fehler 1418), kein Netzwerkzugriff vorhanden ist und ein Befehl zum Einbinden einer Datenbank fehlschlägt (SQL Server Fehler 35250). Lesen Sie das folgende Dokument, um Hilfe zur Behandlung dieser Probleme zu erhalten:

Problembehandlung bei der Konfiguration von Always On Verfügbarkeitsgruppen (SQL Server)

Zusätzlicher Link: Behebung: Fehler 41009 beim Versuch, mehrere Verfügbarkeitsgruppen zu erstellen

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Ich habe Probleme mit der Listenerkonfiguration (19471, 19476 und andere Fehler)

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

  • Msg 19471, Ebene 16, Status 0, Zeile 2Der WSFC-Cluster konnte die Netzwerknamenressource mit dem DNS-Namen "" nicht online schalten. Der DNS-Name wurde möglicherweise verwendet oder hat einen Konflikt mit vorhandenen Namendiensten, oder der WSFC-Clusterdienst wird möglicherweise nicht ausgeführt oder ist nicht zugänglich. Verwenden Sie einen anderen DNS-Namen, um Namenskonflikte aufzulösen, oder überprüfen Sie das WSFC-Clusterprotokoll auf weitere Informationen.

  • Msg 19476, Ebene 16, Status 4, Zeile 2Der Versuch, den Netzwerknamen und die IP-Adresse für den Listener zu erstellen, ist fehlgeschlagen. Der WSFC-Dienst wird möglicherweise nicht ausgeführt oder ist im aktuellen Zustand nicht verfügbar, oder die für den Netzwerknamen und die IP-Adresse angegebenen Werte sind möglicherweise falsch. Überprüfen Sie den Status des WSFC-Clusters, und überprüfen Sie den Netzwerknamen und die IP-Adresse mit dem Netzwerkadministrator.

Die meiste Zeit ist ein Fehler bei der Listenererstellung, der zu den vorherigen Meldungen führt, auf fehlende Berechtigungen für das Clusternamenobjekt (Cluster Name Object, CNO) in Active Directory zum Erstellen und Lesen des Listenercomputerobjekts zurückzuführen. Informationen zur Problembehandlung finden Sie in den folgenden Artikeln:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Automatisches Failover funktioniert nicht wie erwartet

Wenn Sie feststellen, dass das automatische Failover während des Tests oder in der Produktion nicht wie erwartet funktioniert, finden Sie weitere Informationen unter Behandeln von Problemen mit automatischem Failover in SQL Server 2012 Always On Umgebungen.

Falsche Konfiguration von Maximale Fehler im angegebenen Zeitraum ist eine der Hauptursachen dafür, dass das primäre Failover nicht automatisch auf das sekundäre Replikat erfolgt. 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 Always On Verfügbarkeitsgruppen.

Ich habe Probleme beim Herstellen einer Verbindung mit Always On Verfügbarkeitsgruppen.

Nachdem Sie den Verfügbarkeitsgruppenlistener für eine Always On Verfügbarkeitsgruppe in SQL Server 2012 konfiguriert haben, können Sie den Listener möglicherweise nicht pingen oder von einer Anwendung aus eine Verbindung mit ihm herstellen. Möglicherweise erhalten Sie einen Fehler, der der folgenden ähnelt:

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

Um diese und ähnliche Fehler zu beheben, lesen Sie folgendes:

Weitere Informationslinks:

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Ich habe Probleme beim Konfigurieren Always On Verfügbarkeitsgruppen auf meinem virtuellen Azure-Computer (IaaS)

  1. Viele Probleme im Zusammenhang mit Always On aufgrund einer unsachgemäßen Konfiguration des Listeners auftreten. Wenn Verbindungsprobleme mit dem Listener auftreten,

    1. Achten Sie darauf, alle Einschränkungen des ILB-Listeners zu lesen und alle schritte im folgenden Artikel zu befolgen, wobei Sie besonders auf die Abhängigkeitskonfiguration, die IP-Adresse und verschiedene andere Parameter im PowerShell-Skript achten.

    2. Wenn Sie sich 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 sich die IP-Adressen geändert haben, müssen Sie den Wert der IP-Adressressource aktualisieren, um die neue Adresse widerzuspiegeln, und Sie müssen den Endpunkt mit Lastenausgleich für Ihre Verfügbarkeitsgruppe neu erstellen. Sie können die IP-Adresse mit den Get Befehlen oder Set wie folgt 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 Always On Verfügbarkeitsgruppen.

Es dauert lange, bis ein Failover vom primären zum sekundären Replikat ausgeführt wird oder umgekehrt.

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

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Änderungen am primären Replikat werden entweder nicht auf dem sekundären Replikat wider oder langsam repliziert.

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

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Verwalten der Größe des Transaktionsprotokolls für datenbanken der Verfügbarkeitsgruppe

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

Weitere Informationen finden Sie in den folgenden Themen:

Wenn diese Informationen nicht hilfreich sind, lesen Sie Weitere Informationen zu Always On Verfügbarkeitsgruppen.

Primäre oder sekundäre Server, die den Status "Auflösen" aufweisen, oder es treten unerwartete Failover auf.

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Ressourcen können nicht online geschaltet werden

Überprüfen Sie, ob die Wiederherstellung der Datenbanken sehr lange dauert, indem Sie die Meldungen im SQL ErrorLog überprüfen.

Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu Always On Verfügbarkeitsgruppen.

Häufig gestellte Fragen

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

    Ja, Sie können mehrere Listener für dieselbe Verfügbarkeitsgruppe einrichten. Weitere Informationen finden Sie unter Erstellen mehrerer Listener für dieselbe Verfügbarkeitsgruppe (Goden Yao).

  2. Ist es möglich, eine separate NIC-Karte für Always On-Datenverkehr und Clientkonnektivität zu verwenden?

    Ja, Sie können dedizierte NIC-Karte für Always On Datenverkehr verwenden. Weitere Informationen finden Sie unter 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-Onlinedokumentation enthält weitere Informationen: Editionen und unterstützte Features für SQL Server 2016.

  4. Wie kann bei einem Ausfall auf allen Knoten Ihres Clusters wiederhergestellt werden?

    Weitere Informationen finden Sie unter WSFC-Notfallwiederherstellung durch erzwungenes Quorum (SQL Server).

  5. Wo finde ich Informationen zur Unterstützung für verteilte Transaktionen in Verfügbarkeitsgruppenkonfigurationen?

    Weitere Informationen finden Sie unter Transaktionen – Verfügbarkeitsgruppen und Datenbankspiegelung.

  6. Aktualisieren von Always On Konfigurationen

    Weitere Informationen finden Sie unter Upgraden Always On Verfügbarkeitsgruppenreplikatinstanzen.

  7. Wie wird eine TDE-fähige Datenbank (Transparent Data Encryption) zur Verfügbarkeitsgruppenkonfiguration hinzugefügt?

    Informationen zum Hinzufügen einer TDE-fähigen Datenbank zur Verfügbarkeitsgruppe finden Sie unter Konfigurieren von Always On für eine TDE-Datenbank.

  8. Konfigurieren von Warnungen zur Überprüfung, ob das sekundäre Replikat hinter dem primären Replikat zurückbleibt?

    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 erhalte ich eine Warnung, 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

    Weitere Methoden zum Überwachen von Always On Gruppen finden Sie unter den folgenden Links:

Weitere Informationen zu Always On Verfügbarkeitsgruppen