Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge aus, um die neuesten Funktionen, Sicherheitsupdates und technischen Support zu nutzen.
Dieser Artikel hilft Ihnen, das häufige Problem bei der Always On-Konfiguration auf SQL Server zu beheben.
Hinweis
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
Microsoft CSS-Daten deuten darauf hin, dass ein erheblicher Prozentsatz der Kundenprobleme häufig in einem freigegebenen CU behandelt wird, aber nicht proaktiv angewendet wird und daher eine fortlaufende, proaktive Installation von CUs empfiehlt, sobald sie verfügbar werden. Weitere Informationen finden Sie unter Ankündigung von Updates für das inkrementelle SQL Server-Wartungsmodell (ISM).
Informationen zum Überprüfen der neuesten CUs, die möglicherweise für Ihre Version verfügbar sind, finden Sie unter Ermitteln der Version, Der Edition- und Updateebene von SQL Server und der zugehörigen Komponenten.
Nützliche Tools für die Problembehandlung und Überwachung von AlwaysOn-Verfügbarkeitsgruppen finden Sie im Handbuch zur Problembehandlung und Überwachung von Always On-Verfügbarkeitsgruppen, um mehr über die Tools zu erfahren, die Sie für die Diagnose verschiedener Arten von Problemen und für die Überwachung von Verfügbarkeitsgruppen verwenden können. Der Leitfaden enthält auch zusätzliche Szenarien, die in diesem geführten Rundgang möglicherweise nicht behandelt werden.
Der übergeordnete Knoten für die Dokumentation zu Always On-Verfügbarkeitsgruppen und stellt einen Einzigen Stoppverweis für verschiedene Fragen bereit, siehe AlwaysOn-Verfügbarkeitsgruppen (SQL Server).
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.
Wenn diese Informationen nicht hilfreich sind, finden Sie weitere Informationen zu AlwaysOn-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.
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:
Problembehandlung bei der Erstellung von Always On-Verfügbarkeitsgruppenlistener in SQL Server 2012
Konfigurieren eines Listeners für Always On-Verfügbarkeitsgruppen
Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.
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.
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.
Viele Probleme im Zusammenhang mit Always On treten aufgrund einer fehlerhaften Konfiguration des Listeners auf. Wenn Verbindungsprobleme mit dem Listener auftreten,
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.
Wenn Sie nicht sicher sind, können Sie den Listener gemäß dem obigen Dokument löschen und neu erstellen.
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.
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.
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:
Informationen zu SQL Server 2012- und SQL Server 2014-Umgebungen finden Sie unter FIX: Langsame Synchronisierung, wenn Datenträger unterschiedliche Branchengrößen für primäre und sekundäre Replikatprotokolldateien in SQL Server AG- und Logshippingumgebungen aufweisen.
Überprüfen Sie, ob sich die sekundären Knoten im Clusteradministrator in einem angehaltenen Zustand befinden.
Siehe Problembehandlung: Änderungen am primären Replikat werden nicht im sekundären Replikat wiedergegeben.
Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.
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.
Überprüfen Sie System- und Anwendungsereignisprotokolle auf Hardwareprobleme und andere Fehler, und arbeiten Sie mit dem Anbieter zusammen, um sie zu beheben.
Wenn Sie virtuelle Computer verwenden, überprüfen Sie deren Wissensdatenbank, um festzustellen, ob kürzlich gemeldete Probleme auftreten, die zu dem Problem beitragen können. Beispielsweise verursachten große Paketverluste auf Gastbetriebssystemebene auf der VMXNET3 vNIC in ESXi (2039495) in einigen Fällen Probleme mit der AG-Konfiguration.
Weitere Informationen:
Wenn das Problem weiterhin besteht, finden Sie weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen.
Ü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.
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.
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.
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.
Wie kann ich bei einem Fehler auf allen Knoten des Clusters wiederherstellen?
Siehe WSFC Disaster Recovery durch erzwungenes Quorum (SQL Server).
Wo finde ich Informationen zur Unterstützung von verteilten Transaktionen in AG-Konfigurationen?
Siehe Transaktionen – Verfügbarkeitsgruppen und Datenbankspiegelung.
Wie aktualisieren Sie AlwaysOn-Konfigurationen?
Siehe Upgrade always On Availability Group Replica Instances.
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.
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
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:
Schulung
Modul
Erkunden der IaaS- und PaaS-Lösungen für Hochverfügbarkeit und Notfallwiederherstellung - Training
Erkunden der IaaS- und PaaS-Lösungen für Hochverfügbarkeit und Notfallwiederherstellung
Zertifizierung
Microsoft Certified: Azure Database Administrator Associate - Certifications
Verwalten einer SQL Server-Datenbankinfrastruktur für Cloud-, lokale und hybride relationale Datenbanken auf Grundlage der Microsoft PaaS-Angebote für relationale Datenbanken.