Verstehen und Verwalten der suspect_pages-Tabelle
Die Tabelle suspect_pages befindet sich in der msdb-Datenbank und wurde in SQL Server 2005 eingeführt. Die suspect_pages-Tabelle, die zum Verwalten von Informationen über fehlerverdächtige Seiten verwendet wird, ist maßgeblich für die Entscheidung, ob eine Wiederherstellung erforderlich ist.
Eine Seite wird als "fehlerverdächtig" betrachtet , wenn das SQL Server Database Engine (Datenbankmodul) bei dem Versuch, eine Datenseite zu lesen, einen der folgenden Fehler findet:
Einen Fehler vom Typ 823, der durch eine vom Betriebssystem ausgegebene zyklische Redundanzprüfung (CRC) verursacht wurde, beispielsweise ein Datenträgerfehler (bestimmte Hardwarefehler).
Einen Fehler vom Typ 824, z. B. eine zerrissene Seite (logische Fehler).
Die Seiten-ID jeder fehlerverdächtigen Seite wird in der suspect_pages-Tabelle aufgezeichnet. Das Database Engine (Datenbankmodul) zeichnet alle fehlerverdächtigen Seiten auf, die während der regulären Verarbeitung auftreten, z. B. bei folgenden Vorgängen:
Eine Abfrage muss eine Seite lesen.
Während eines DBCC CHECKDB-Vorgangs.
Während eines Sicherungsvorgangs.
Die suspect_pages-Tabelle wird ggf. auch während eines Wiederherstellungsvorgangs, eines DBCC-Reparaturvorgangs oder eines Datenbanklöschvorgangs aktualisiert.
In der suspect_pages-Tabelle aufgezeichnete Fehler
Die suspect_pages-Tabelle enthält eine Zeile für jede Seite mit einem Fehler vom Typ 824 (maximal 1.000 Zeilen). Die folgenden Tabellen enthalten Fehler, die in der event_type-Spalte der suspect_pages-Tabelle protokolliert werden.
Fehlerbeschreibung |
event_type-Wert |
|---|---|
Ein Fehler vom Typ 823, der durch einen vom Betriebssystem ausgegebenen CRC-Fehler verursacht wird, oder ein Fehler vom Typ 824, der außer einer fehlerhaften Prüfsumme oder einer zerrissenen Seite z. B. eine fehlerhafte Seiten-ID anzeigt. |
1 |
Fehlerhafte Prüfsumme |
2 |
Zerrissene Seite |
3 |
Wiederhergestellt (die Seite wurde wiederhergestellt, nachdem sie als beschädigt markiert wurde) |
4 |
Repariert (DBCC hat die Seite repariert) |
5 |
Zuordnung durch DBCC aufgehoben |
7 |
In der suspect_pages-Tabelle werden auch vorübergehende Fehler aufgezeichnet. Ursachen für vorübergehende Fehler sind beispielsweise E/A-Fehler (z. B. eine fehlende Kabelverbindung) oder eine Seite, die einen wiederholten Prüfsummentest vorübergehend nicht besteht.
Vorgehensweise des Datenbankmoduls beim Aktualisieren der "suspect_pages"-Tabelle
Database Engine (Datenbankmodul) führt folgende Aktionen in der suspect_pages-Tabelle aus:
Wenn die Tabelle nicht voll ist, wird sie für jeden Fehler vom Typ 824 aktualisiert, um anzuzeigen, dass ein Fehler aufgetreten ist, und die Fehleranzahl wird erhöht.
Wenn eine Seite einen Fehler aufweist, nachdem sie durch eine Reparatur, eine Wiederherstellung oder das Aufheben einer Zuordnung repariert wurde, wird die zugehörige number_of_errors-Fehleranzahl erhöht, und die zugehörige last_update-Spalte wird aktualisiert.
Nachdem eine aufgelistete Seite durch einen Wiederherstellungs- oder Reparaturvorgang repariert wurde, aktualisiert der Vorgang die suspect_pages-Zeile, um anzuzeigen, dass die Seite repariert (event_type = 5) oder wiederhergestellt (event_type = 4) wurde.
Wenn eine DBCC-Überprüfung ausgeführt wird, markiert die Überprüfung alle fehlerfreien Seiten als repariert (event_type = 5) oder als Seiten, deren Zuordnung aufgehoben wurde (event_type = 7).
Automatische Aktualisierungen der "suspect_pages"-Tabelle
Die suspect_pages-Tabelle wird von einem Datenbank-Spiegelungspartner aktualisiert, nachdem bei einem Versuch, eine Seite aus einer Datendatei zu lesen, aus einem der folgenden Gründe ein Fehler aufgetreten ist:
Fehler vom Typ 823, der von einem durch das Betriebssystem ausgegebenen CRC-Fehler verursacht wird.
Fehler vom Typ 824 (logische Beschädigung, z. B. eine zerrissene Seite).
Die folgenden Aktionen löschen automatisch Zeilen aus der suspect_pages-Tabelle.
ALTER DATABASE REMOVE FILE
DROP DATABASE
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS aktualisiert die suspect_pages-Tabelle, um jede Seite anzugeben, deren Zuordnung aufgehoben wurde oder die repariert wurde.
RESTORE aktualisiert ebenfalls die Liste. Eine vollständige Wiederherstellung oder eine Datei- oder Seitenwiederherstellung markiert die Seiteneinträge als wiederhergestellt.
Verwaltungsrolle des Datenbankadministrators
Datenbankadministratoren sind zuständig für das Verwalten der Tabelle, insbesondere indem sie alte Zeilen löschen. Die Größe der suspect_pages-Tabelle ist beschränkt, und wenn sie voll ist, werden keine neuen Fehler mehr protokolliert. Um zu verhindern, dass sich diese Tabelle füllt, muss der Datenbankadministrator oder Systemadministrator durch das Löschen von Zeilen die alten Einträge manuell aus der Tabelle löschen. Aus diesem Grund wird empfohlen, Zeilen mit einem wiederhergestellten oder reparierten event_type oder Zeilen mit einem alten last_update-Wert regelmäßig zu löschen bzw. zu archivieren.
Sie können die Database Suspect Data Page-Ereignisklasse verwenden, um die Aktivität in der suspect_pages-Tabelle zu überwachen. Der suspect_pages-Tabelle werden aufgrund vorübergehender Fehler manchmal Zeilen hinzugefügt. Wenn der Tabelle viele Zeilen hinzugefügt werden, besteht bei dem E/A-Subsystem jedoch möglicherweise bereits einen Fehler. Wenn Sie feststellen, dass die Anzahl der Tabelle hinzugefügter Zeilen plötzlich ansteigt, sollten Sie die möglichen Ursachen hierfür in Ihrem E/A-Subsystem untersuchen.
Ein Datenbankadministrator kann auch Datensätze einfügen oder aktualisieren. Das Aktualisieren einer Zeile ist z. B. sinnvoll, wenn der Datenbankadministrator weiß, dass eine bestimmte fehlerverdächtige Seite tatsächlich intakt ist, den Datensatz jedoch für eine Weile erhalten möchte.
Beispiele
Im folgenden Beispiel werden einige Zeilen aus der suspect_pages-Tabelle gelöscht.
' Select restored, repaired, or deallocated pages.
DELETE FROM msdb..suspect_pages
WHERE (event_type = 4 OR event_type = 5 OR event_type = 7);
GO
Im folgenden Beispiel werden die fehlerhaften Seiten in der suspect_pages-Tabelle ausgewählt.
' Select nonspecific 824, bad checksum, and torn page errors.
SELECT * FROM msdb..suspect_pages
WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);
GO