Failover-Option für die Zustandserkennung auf Datenbankebene der Verfügbarkeitsgruppe

Gilt für:SQL Server

Ab SQL Server 2016 ist die Option „Integritätserkennung auf Datenbankebene“ (DB_FAILOVER) verfügbar, wenn eine Always On-Verfügbarkeitsgruppe konfiguriert wird. Die Integritätserkennung auf Datenbankebene erkennt, wenn eine Datenbank sich nicht mehr im Onlinestatus befindet oder ein Fehler auftritt und löst ein automatisches Failover der Verfügbarkeitsgruppe aus. Beispiele, die die Zustandserkennung auslösen können, sind: die Datenbank befindet sich im Suspect-Modus, die Datenbank ist offline, die Datenbank befindet sich in der Wiederherstellung (Wiederherstellung fehlgeschlagen). Weitere Informationen finden Sie in der Spalte „State“ in sys.databases.

Die Integritätserkennung auf Datenbankebene ist für die gesamte Verfügbarkeitsgruppe aktiviert, wodurch die Datenbank-Integritätserkennung jede Datenbank in der Verfügbarkeitsgruppe überwacht. Sie kann nicht selektiv für bestimmte Datenbanken in der Verfügbarkeitsgruppe aktiviert werden.

Vorteile der Option zur Erkennung des Zustands auf Datenbankebene

Die Option zur Integritätserkennung auf Datenbankebene für Verfügbarkeitsgruppen gilt weithin als empfehlenswerte Option, die zur Gewährleistung der hohen Verfügbarkeit Ihrer Datenbanken beiträgt. Sie sollten erwägen, es für alle Verfügbarkeitsgruppen zu aktivieren. Wenn Ihre Anwendung von mehreren Datenbanken abhängig ist, um hoch verfügbar zu sein, gruppieren Sie diese in einer Verfügbarkeitsgruppe mit der aktivierten Option für die Datenbank-Integritätserkennung.

Wenn beispielsweise bei aktivierter Integritätsprüfung auf Datenbankebene SQL Server für eine der Datenbanken nicht in die Transaktionsprotokolldatei schreiben kann, würde sich der Status dieser Datenbank so ändern, dass ein Fehler angezeigt wird, und es würde bald ein Failover der Verfügbarkeitsgruppe erfolgen. Ihre Anwendung könnte sich erneut verbinden und mit minimaler Unterbrechung weiterarbeiten, sobald die Datenbanken wieder online sind.

Aktivieren der Datenbank-Zustandserkennung auf Datenbankebene

Obwohl sie allgemein empfohlen wird, ist die Option für die Datenbank-Integritätserkennung standardmäßig ausgeschaltet, um die Abwärtskompatibilität mit den Standardeinstellungen von früheren Versionen zu gewährleisten.

Es gibt mehrere einfache Möglichkeiten, die Einstellung zur Erkennung des Datenbankzustands auf Datenbankebene zu aktivieren:

1. Stellen Sie in SQL Server Management Studio eine Verbindung mit der SQL Server-Datenbank-Engine her. Verwenden Sie das Fenster „Objekt-Explorer“, klicken Sie mit der rechten Maustaste auf den Knoten „Always On-Hochverfügbarkeit“, und starten Sie den Assistenten für neue Verfügbarkeitsgruppe. Aktivieren Sie auf der Seite „Namen angeben“ das Kontrollkästchen Zustandserkennung auf Datenbankebene. Schließen Sie anschließend die restlichen Seiten des Assistenten ab.

   

2. Zeigen Sie die Eigenschaften einer bestehenden Verfügbarkeitsgruppe in SQL Server Management Studio an. Stellen Sie eine Verbindung mit Ihrem SQL Server her. Erweitern Sie im Objekt-Explorerfenster den Knoten „Always On-Hochverfügbarkeit“. Erweitern Sie „Verfügbarkeitsgruppen“. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, und wählen Sie Eigenschaften aus. Aktivieren Sie die Option Integritätserkennung auf Datenbankebene, und klicken Sie dann auf OK oder legen Sie die Änderung als Skript fest.

   

3. Transact-SQL-Syntax für CREATE AVAILABILITY GROUP. Der Parameter „DB_FAILOVER“ akzeptiert die Werte „ON“ oder „OFF“.

   CREATE AVAILABILITY GROUP [Contoso-ag]
   WITH (DB_FAILOVER=ON)
   FOR DATABASE [AutoHa-Sample]
   REPLICA ON
       N'SQLSERVER-0' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-0.DOMAIN.COM:5022',
         FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
       N'SQLSERVER-1' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-1.DOMAIN.COM:5022',
        FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

4. Transact-SQL-Syntax für ALTER AVAILABILITY GROUP. Der Parameter „DB_FAILOVER“ akzeptiert die Werte „ON“ oder „OFF“.

   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = ON);
   
   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = OFF);
   

Vorbehalte

Bitte beachten Sie, dass die Option „Integritätsprüfung auf Datenbankebene“ derzeit nicht dazu führt, dass SQL Server die Datenträgerverfügbarkeit überwacht, und dass SQL Server die Verfügbarkeit von Datenbankdateien nicht direkt überwacht. Sollte ein Laufwerk ausfallen oder nicht mehr verfügbar sein, löst dies allein nicht unbedingt ein automatisches Failover der Verfügbarkeitsgruppe aus.

Wenn sich eine Datenbank beispielsweise im Leerlauf ohne aktive Transaktionen befindet und keine physischen Schreibvorgänge stattfinden, kann auf einige Datenbankdateien nicht mehr zugegriffen werden. SQL Server führt keine E/A-Lese- oder Schreibvorgänge für die Dateien aus und ändert den Status dieser Datenbank nicht sofort, sodass kein Failover ausgelöst werden würde. Wenn dann ein Datenbankprüfpunkt auftritt oder ein physischer Lese- oder Schreibvorgang ausgeführt wird, um eine Abfrage auszuführen, erkennt SQL Server das Dateiproblem und reagiert darauf mit einer Statusänderung der Datenbank. Anschließend würde die Verfügbarkeitsgruppe mit der aktivierten Integritätserkennung auf Datenbankebene wegen der Änderung des Datenbankstatus ein Failover auslösen.

Wenn die SQL-Server-Datenbank-Engine beispielsweise eine Datenseite lesen muss, um eine Abfrage auszuführen und die Datenseite im Pufferpoolspeicher zwischengespeichert ist, ist keine Festplatte nötig, die über physischen Zugriff gelesen wird, um die Abfrageanforderung auszuführen. Deshalb löst eine fehlende oder nicht verfügbare Datendatei nicht sofort ein automatisches Failover aus, auch wenn die Option für die Datenbank-Integritätserkennung aktiviert ist, da der Datenbankstatus nicht sofort aktualisiert wird.

Das Datenbank-Failover ist von der flexiblen Failoverrichtlinie getrennt

Durch die Integritätserkennung auf Datenbankebene wird eine flexible Failoverrichtlinie implementiert, die die Schwellenwerte des SQL Server-Prozesszustands für die Failoverrichtlinie konfiguriert. Die Integritätsüberwachung auf Datenbankebene wird mithilfe des Parameters „DB_FAILOVER“ konfiguriert, während die Option „FAILURE_CONDITION_LEVEL“ der Verfügbarkeitsgruppe davon getrennt ist und zur Konfiguration der Erkennung des Integritätszustands des SQL Server-Prozesses dient. Die beiden Optionen sind unabhängig voneinander.

Verwalten und Überwachen der Zustandserkennung auf Datenbankebene

Dynamische Verwaltungssichten

Die System-DMV „sys.availability_groups“ enthält eine Spalte namens „db_failover“, die angibt, ob die Option zur Integritätserkennung auf Datenbankebene deaktiviert (0) bzw. aktiviert (1) ist.

select name, db_failover from sys.availability_groups

Beispielausgabe von dmv:

ErrorLog

Im SQL Server-Fehlerprotokoll (oder im Text aus „sp_readerrorlog“) wird die Fehlermeldung 41653 angezeigt, wenn bei einer Verfügbarkeitsgruppe aufgrund der Integritätsprüfungen auf Datenbankebene ein Failover erfolgt ist.

Dieser Auszug aus dem Fehlerprotokoll zeigt beispielsweise, dass das Schreiben eines Transaktionsprotokolls wegen eines Laufwerkproblems fehlgeschlagen ist und daraufhin die Datenbank namens „AutoHa-Sample“ heruntergefahren wurde, wodurch die Integritätserkennung auf Datenbankebene ein Failover der Verfügbarkeitsgruppe ausgelöst hat.

2016-04-25 12:20:21.08 spid1s Fehler: 17053, Schweregrad: 16, Status: 1.

2016-04-25 12:20:21.08 spid1s SQLServerLogMgr::LogWriter: Ein Betriebssystemfehler 21(Das Gerät ist nicht bereit) ist aufgetreten. 2016-04-25 12:20:21.08 spid1s Schreibfehler während der Protokollleerung.

2016-04-25 12:20:21.08 spid79 Fehler: 9001, Schweregrad: 21, Status: 4.

2016-04-25 12:20:21.08 spid79 Das Protokoll für die Datenbank „AutoHa-Sample“ ist nicht verfügbar. Überprüfen Sie das Ereignisprotokoll auf verwandte Fehlermeldungen. Beheben Sie ggf. alle Fehler, und starten Sie die Datenbank neu.

2016-04-25 12:20:21.15 spid79 Fehler: 41653, Schweregrad: 21, Status: 1.

2016-04-25 12:20:21.15 spid79 In der Datenbank „AutoHa-Sample“ ist ein Fehler aufgetreten (Fehlertyp: 2 „DB_SHUTDOWN“), der zum Ausfall der Verfügbarkeitsgruppe „Contoso-ag“ führte. Informationen zu den aufgetretenen Fehlern finden Sie im SQL Server-Fehlerprotokoll. Falls das Problem weiterhin besteht, wenden Sie sich an den Systemadministrator.

2016-04-25 12:20:21.17 spid79 Zustandsinformationen der Datenbank „AutoHa-Sample“ - Festgeschriebene LSN: „(34:664:1)“ Commit-LSN: „(34:656:1)“ Commitzeit: „Apr 25 2016 12:19PM“

2016-04-25 12:20:21.19 spid15s Die Verbindung der Always On-Verfügbarkeitsgruppen mit der sekundären Datenbank wurde für die primäre Datenbank „AutoHa-Sample“ auf dem Verfügbarkeitsreplikat „SQLServer-0“ mit der Replikat-ID {c4ad5ea4-8a99-41fa-893e-189154c24b49} beendet. Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.

2016-04-25 12:20:21.21 spid75 Always On: Das lokale Replikat der Verfügbarkeitsgruppe „Contoso-ag“ bereitet sich als Reaktion auf eine Anforderung des WSFC-Clusters (Windows Server Failover Clustering) auf den Übergang in die Auflösungsrolle vor. Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.

2016-04-25 12:20:21.21 spid75 Der Status des lokalen Verfügbarkeitsreplikats in der Verfügbarkeitsgruppe „ag“ wurde von „PRIMARY_NORMAL“ in „RESOLVING_NORMAL“ geändert. Der Status hat sich geändert, weil die Verfügbarkeitsgruppe offline geschaltet wird. Das Replikat wird offline geschaltet, weil die zugeordnete Verfügbarkeitsgruppe gelöscht wurde, der Benutzer die zugeordnete Verfügbarkeitsgruppe in der WSFC (Windows Server Failover Clustering)-Verwaltungskonsole offline geschaltet hat, oder die Verfügbarkeitsgruppe einen Failover auf eine andere Instanz von SQL Server ausführt. Weitere Informationen finden Sie im SQL Server-Fehlerprotokoll, in der WSFC-Verwaltungskonsole (Windows Server Failover Clustering) oder im WSFC-Protokoll.

Erweitertes Ereignis sqlserver.availability_replica_database_fault_reporting

Ab SQL Server 2016 ist ein neues erweitertes Ereignis definiert, das von der Integritätserkennung auf Datenbankebene ausgelöst wird. Der Ereignisname lautet sqlserver.availability_replica_database_fault_reporting

Dieses XEvent wird nur auf dem primären Replikat ausgelöst. Dieses XEvent wird ausgelöst, wenn ein Integritätsproblem auf Datenbankebene auf einer Datenbank erkannt wird, die in einer Verfügbarkeitsgruppe gehostet ist.

Hier finden Sie ein Beispiel zum Erstellen einer XEvent-Sitzung, das dieses Ereignis erfasst. Da kein Pfad angegeben ist, sollte die XEvent-Ausgabedatei im Standardpfad für SQL-Fehlerprotokolle gespeichert sein. Führen Sie folgendes Skript auf dem primären Replikat Ihrer Verfügbarkeitsgruppe aus:

Beispielskript für eine Sitzung für erweiterte Ereignisse

CREATE EVENT SESSION [AlwaysOn_dbfault] ON SERVER
ADD EVENT sqlserver.availability_replica_database_fault_reporting
ADD TARGET package0.event_file(SET filename=N'dbfault.xel',max_file_size=(5),max_rollover_files=(4))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO
ALTER EVENT SESSION AlwaysOn_dbfault ON SERVER STATE=START
GO

Erweiterte Ereignisausgabe

Wenn Sie SQL Server Management Studio verwenden, stellen Sie eine Verbindung mit dem primären SQL Server her, erweitern Sie den Knoten „Verwaltung“ und dann „Erweiterte Ereignisse“. Suchen Sie die Sitzung („AlwaysOn_dbfault“ hieß sie im obigen Beispiel) und erweitern Sie sie, um die Ausgabedateien anzuzeigen. Wählen Sie die Ausgabedatei aus, damit die Ereignisdatei auf einer neuen Registerkarte geöffnet wird.

Eine Erläuterung der Felder finden Sie im Folgenden:

In dieser Beispielausgabe zeigt fault_type, dass in der Verfügbarkeitsgruppe „Contoso-ag“ auf dem Replikat namens „SQLSERVER-1“ aufgrund der Datenbank namens „AutoHa-Sample2“ ein kritisches Ereignis mit dem Fehlertyp 2 – Herunterfahren aufgetreten ist.

Verwandte Verweise

• CREATE AVAILABILITY GROUP

• ALTER AVAILABILITY GROUP

• Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server) (Flexible Failoverrichtlinien für automatisches Failover in einer Verfügbarkeitsgruppe (SQL Server))

• Verbessern Sie die Always On Failover-Richtlinie, um SQL Server-Datenbankdaten und -Protokolllaufwerke zu testen

• Erweiterte Ereignisse

• Konfigurieren einer Always On-Verfügbarkeitsgruppe zum Ausführen eines Failovers, wenn die Datenbankdatendatei nicht verfügbar ist