Automatische Seitenreparatur (Verfügbarkeitsgruppen: Datenbankspiegelung)

Gilt für:SQL Server

Die automatische Seitenreparatur wird durch die Datenbankspiegelung und die Always On-Verfügbarkeitsgruppen unterstützt. Wenn bestimmte Fehlertypen eine Seite beschädigen und sie unlesbar machen, versucht ein Datenbank-Spiegelungspartner (Prinzipal oder Spiegel) oder ein Verfügbarkeitsreplikat (primär oder sekundär), die Seite automatisch wiederherzustellen. Der Partner/das Replikat, der/das die Seite nicht lesen kann, fordert eine neue Kopie der Seite von seinem Partner oder einem anderen Replikat an. Wenn die Anforderung erfolgreich ist, wird die nicht lesbare Seite durch die lesbare Kopie ersetzt. Dadurch wird der Fehler normalerweise behoben.

Im Allgemeinen behandeln Datenbankspiegelung und Always On-Verfügbarkeitsgruppen E/A-Fehler auf dieselbe Weise. Die wenigen Unterschiede werden hier explizit beschrieben.

• Fehlertypen, die zu einem automatischen Seitenreparaturversuch führen

• Seitentypen, die nicht automatisch repariert werden können

• Umgang mit E/A-Fehlern in der primären Datenbank

• Behandlung von E/A-Fehlern in der Spiegel- bzw. Sekundärdatenbank

• Bewährte Methode für Entwickler

• Vorgehensweise: Anzeigen von automatischen Seitenreparatur-Versuchen

Fehlertypen, die zu einem automatischen Seitenreparaturversuch führen

Bei der automatischen Seitenreparatur bei einer Datenbankspiegelung werden nur Seiten in einer Datendatei repariert, bei denen bei einem Vorgang einer der in der folgenden Tabelle aufgeführten Fehler aufgetreten ist.

Um aktuelle CRC-Fehler vom Typ 823 und Fehler vom Typ 824 anzuzeigen, rufen Sie die Tabelle suspect_pages in der msdb -Datenbank auf.

Seitentypen, die nicht automatisch repariert werden können

Die automatische Seitenreparatur kann die folgenden Steuerelementseitentypen nicht reparieren:

• Dateiheaderseite (Seiten-ID 0).

• Seite 9 (die Startseite der Datenbank)

• Zuordnungsseiten: GAM-Seiten (Global Allocation Map), SGAM-Seiten (Shared Global Allocation Map) und PFS-Seiten (Page Free Space).

Behandeln von E/A-Fehlern in der Prinzipal-/Primärdatenbank

In der Prinzipaldatenbank/primären Datenbank wird die automatische Seitenreparatur nur ausgeführt, wenn sich die Datenbank im Status SYNCHRONIZED befindet und der Prinzipalserver/primäre Server noch Protokolldatensätze für die Datenbank an den Spiegelserver/sekundären Server sendet. Im Prinzip werden bei einer automatischen Seitenreparatur die folgenden Aktionen in dieser Reihenfolge ausgeführt:

1. Wenn auf einer Datenseite in der Prinzipal-/Primärdatenbank ein Lesefehler auftritt, fügt die Prinzipal-/Primärdatenbank der Tabelle suspect_pages eine Zeile mit dem entsprechenden Fehlerstatus hinzu. Bei der Datenbankspiegelung fordert der Prinzipal dann beim Spiegel eine Kopie der Seite an. Für Always On-Verfügbarkeitsgruppenüberträgt der primäre Server die Anforderung an alle sekundären Server und ruft die Seite vom Server ab, der als Erster antwortet. In der Anforderung werden die Seiten-ID und die LSN angegeben, die sich derzeit am Ende des geleerten Protokolls befindet. Die Seite ist als Wiederherstellung ausstehend markiert. Das bedeutet, dass während der automatischen Seitenreparatur kein Zugriff auf die Seite möglich ist. Versuche, während des Reparaturversuchs auf diese Seite zuzugreifen, schlagen mit Fehler 829 (Wiederherstellung steht aus) fehl.

2. Nach Erhalt der Seitenanforderung wartet der Spiegelserver bzw. der sekundäre Server, bis er das Protokoll bis zu der in der Anforderung angegebenen LSN erneut angewendet hat. Dann versucht der Spiegelserver/sekundäre Server die Seite in seiner Kopie der Datenbank aufzurufen. Wenn der Zugriff möglich ist, sendet der Spiegelserver/sekundäre Server die Kopie der Seite an den Prinzipalserver/primären Server. Andernfalls gibt der Spiegel-/Sekundärserver einen Fehler an den Prinzipal-/Primärserver zurück, und der automatische Seitenreparaturversuch schlägt fehl.

3. Der primäre/Hauptserver verarbeitet die Antwort, die die aktuelle Kopie der Seite enthält.

4. Nachdem mithilfe der automatischen Seitenreparatur eine fehlerverdächtige Seite repariert werden konnte, wird die Seite in der Tabelle suspect_pages als wiederhergestellt (event_type = 5) gekennzeichnet.

5. Wenn der Seiten-E/A-Fehler zurückgestellte Transaktionen verursacht hat, versucht der Prinzipalserver bzw. Primärserver nach der Reparatur der Seite, diese Transaktionen zu bereinigen.

Umgang mit E/A-Fehlern auf der Spiegel- bzw. Sekundärdatenbank

E/A-Fehler auf Datenseiten, die auf der Spiegeldatenbank/sekundären Datenbank auftreten, werden von der Datenbankspiegelung und von Always On-Verfügbarkeitsgruppen im Allgemeinen auf die gleiche Weise behandelt.

1. Falls der Spiegel bei der Datenbankspiegelung beim Wiederholen eines Protokolldatensatzes einen oder mehrere Seiten-E/A-Fehler feststellt, wird die Spiegelungssitzung in den Status SUSPENDED versetzt. Bei Always On-Verfügbarkeitsgruppen wechselt die sekundäre Datenbank in den Status SUSPENDED, wenn ein sekundäres Replikat beim erneuten Ausführen eines Protokolldatensatzes auf einen oder mehrere Seiten-E/A-Fehler stößt. Zu diesem Zeitpunkt fügt der Spiegelserver/sekundäre Server in die Tabelle suspect_pages eine Zeile mit dem entsprechenden Fehlerstatus ein. Der Spiegelserver/sekundäre Server fordert dann eine Kopie der Seite vom Prinzipalserver/primären Server an.

2. Der Prinzipal-/Primärserver versucht, auf die Seite in seiner Kopie der Datenbank zuzugreifen. Wenn der Zugriff auf die Seite möglich ist, sendet der Prinzipalserver/primäre Server die Kopie der Seite an den Spiegelserver/sekundären Server.

3. Wenn der Spiegel-/Sekundärserver Kopien aller von ihm angeforderten Seiten erhält, versucht er, die Spiegelungssitzung fortzusetzen. Wenn mithilfe der automatischen Seitenreparatur eine fehlerverdächtige Seite repariert werden konnte, wird die Seite in der Tabelle suspect_pages als wiederhergestellt (event_type = 4) gekennzeichnet.

   Wenn ein Spiegelserver/sekundärer Server eine vom Prinzipalserver/primären Server angeforderte Seite nicht erhält, tritt bei der automatischen Seitenreparatur ein Fehler auf. Bei der Datenbankspiegelung bleibt die Spiegelungssitzung angehalten. Bei Always On-Verfügbarkeitsgruppen bleibt die sekundäre Datenbank angehalten. Wenn die Datenbankspiegelungssitzung oder die sekundäre Datenbank manuell fortgesetzt wird, wird während der Synchronisierungsphase erneut auf die beschädigten Seiten gestoßen.

Bewährte Methode für Entwickler

Eine automatische Seitenreparatur ist ein asynchroner Prozess, der im Hintergrund ausgeführt wird. Daher tritt bei einem Datenbankvorgang, bei dem eine nicht lesbare Seite angefordert wird, ein Fehler auf, und der Fehlercode für den Zustand wird zurückgegeben, der den Fehler ausgelöst hat. Beim Entwickeln einer Anwendung für eine gespiegelte Datenbank oder eine Verfügbarkeitsdatenbank sollten Sie Ausnahmen für fehlerhafte Vorgänge abfangen. Wenn der SQL Server -Fehlercode 823, 824 oder 829 lautet, sollten Sie den Vorgang später wiederholen.

Vorgehensweise: Anzeigen von automatischen Seitenreparatur-Versuchen

Die folgenden dynamischen Verwaltungssichten geben Zeilen für die letzten automatischen Seitenreparatur-Versuche auf einer angegebenen Verfügbarkeitsdatenbank oder gespiegelten Datenbank mit einem Maximum von 100 Zeilen pro Datenbank zurück.

• Always On-Verfügbarkeitsgruppen:

  sys.dm_hadr_auto_page_repair (Transact-SQL)

  Gibt eine Zeile für jede versuchte automatische Seitenreparatur in einer beliebigen Verfügbarkeitsdatenbank auf einem Verfügbarkeitsreplikat zurück, das von der Serverinstanz für eine beliebige Verfügbarkeitsgruppe gehostet wird.

• Datenbankspiegelung:

  sys.dm_db_mirroring_auto_page_repair (Transact-SQL)

  Gibt für jeden Versuch einer automatischen Seitenreparatur in einer beliebigen gespiegelten Datenbank auf der Serverinstanz eine Zeile zurück.

Verwandte Inhalte

• Verwalten der suspect_pages-Tabelle (SQL Server)
• Was ist eine Always On-Verfügbarkeitsgruppe?
• Datenbankspiegelung (SQL Server)