Database
 sql >> Datenbank >  >> RDS >> Database

Übersicht über die DBCC CheckDB-Funktion

Einführung

Regelmäßige Datenbankwartung ist ein wichtiger Teil der Arbeit eines Datenbankadministrators, der dazu beiträgt sicherzustellen, dass kritisch wichtige Systeme wie gewohnt laufen. Eine der einfachsten Möglichkeiten, dies zu erreichen, besteht darin, Aufgaben im Zusammenhang mit DBCC CheckDB zu automatisieren. Unabhängig davon, welche Version von SQL Server Sie ausführen, es wird nie eine Datenbank geben, die keine Wartung erfordert. Sie müssen die Wartung so planen, dass sie regelmäßig stattfindet, damit Sie sich vor allem im Falle eines echten Katastrophenszenarios absichern können.

DBA ist immer der Übeltäter

Wann immer es ein Datenbankproblem gibt, sind alle Augen auf den DBA gerichtet. Unabhängig davon, ob das Problem durch Regen verursacht wurde oder weil ein Entwickler bösen Code geschrieben hat, der zu einer Verlangsamung der Datenbank geführt hat, wird immer erwartet, dass der DBA das Chaos behebt. Und Sie können sich vorstellen, mit welchem ​​Druck Sie umgehen müssen, wenn Sie gebeten werden, eine Datenbank schnell mit dem letzten verfügbaren Backup wiederherzustellen, das, wie Sie im Prozess feststellen, nicht gültig ist und die Datenbankintegrität bereits vor einigen Monaten kompromittiert war vor. Hier liegt der Unterschied zwischen einem proaktiven DBA und einem reaktiven DBA. In Wirklichkeit ist Ihre Wiederherstellungsstrategie im Vergleich zur Sicherungsstrategie viel kritischer. Welchen Zweck können tägliche Datenbanksicherungen erfüllen, wenn sie zum Zeitpunkt der Wiederherstellung nichts nützen?

Warum ist Wartung wichtig?

Angesichts des beispiellosen Wachstums von Datenbanktechnologien und der mit jeder Version erscheinenden neuen Funktionen ist es für Sie als DBA unerlässlich, den anderen immer einen Schritt voraus zu sein und sicherzustellen, dass Sie die branchenweit besten Praktiken befolgen Datenbankpflege.

DBCC CheckDB und wie wir es ausführen können

DBCC CheckDB – dieser Name beschreibt ziemlich genau die Funktionalität. Vereinfacht gesagt überprüft es Datenbanken. Dies ist wichtig, um sicherzustellen, dass die Datenbank wie erwartet funktioniert. Grundsätzlich überprüft DBCC CheckDB die logische und physische Integrität aller Objekte in der Datenbank. Das ist es, was DBCC CheckDB laut Beamtem unter der Haube macht Microsoft-Dokumentation:

  • Führt DBCC CHECKALLOC auf der Datenbank aus – die Konsistenz der Speicherplatzzuweisungen

  • Führt DBCC CHECKTABLE auf jeder Tabelle und Ansicht in der Datenbank aus – dies ist die Integrität aller Seiten und Strukturen, aus denen die Tabelle oder indizierte Ansicht besteht.

  • Führt DBCC CHECKCATALOG auf der Datenbank aus – dies prüft die Katalogkonsistenz innerhalb der angegebenen Datenbank.

  • Validiert den Inhalt jeder indizierten Ansicht in der Datenbank.

  • Überprüft die Konsistenz auf Verknüpfungsebene zwischen Tabellenmetadaten und Dateisystemverzeichnissen/Dateien beim Speichern von varbinary(max)-Daten im Dateisystem mit FILESTREAM.

  • Validiert die Service Broker-Daten in der Datenbank.

Wenn Sie den Befehl DBCC CheckDB explizit oder über einen Job ausführen, führt er im Grunde alle oben genannten Schritte aus.

DBCC CheckDB direkt auf einer Datenbank ausführen

Sie können den Befehl DBCC CheckDB direkt in einer Datenbank ausführen und die Ergebnisse prüfen. Überprüfen Sie die Ausgabe des Befehls wie im folgenden Screenshot gezeigt. Die Ausgabe zeigt die Details zu Zeilen in den Tabellen und die Anzahl der Seiten, die von diesen Zeilen verwendet werden.

Wenn Sie genau hinsehen, werden Sie weitere Details zu Datenbankobjekten sehen. In der Datenbank „VLDB“ sehe ich beispielsweise die folgende Ausgabe:

“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”

Wie diese Ausgabe zeigt, wird DBCC CheckDB nicht mit speicheroptimierten Tabellen unterstützt. Speicheroptimierte Tabellen wurden erstmals in SQL Server 2014 als reines Enterprise-Feature eingeführt. Im Laufe der Jahre sind sie jedoch zu einer beliebten und weit verbreiteten Funktionalität in SQL Server geworden.

Sie werden auch feststellen, dass DBCC Check die Service Broker-Daten in der Datenbank validiert hat, wie unten gezeigt.

“DBCC results for 'VLDB'.

Service Broker Msg 9675, State 1: Message Types analyzed: 14.

Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.

Service Broker Msg 9667, State 1: Services analyzed: 3.

Service Broker Msg 9668, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.

Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”

Schließlich, sobald der Befehl DBCC CheckDB erfolgreich abgeschlossen ist, sehen Sie die folgende Ausgabe:

Was passiert, wenn nach dem Ausführen von DBCC CheckDB Fehler gemeldet werden?

Im obigen Beispiel konnten Sie sehen, dass DBCC CheckDB ohne Fehler abgeschlossen wurde. Wenn Sie jedoch nicht so viel Glück haben, können Sie auf Konsistenzfehler stoßen – und dann müssen Sie einige wichtige Entscheidungen treffen. Wenn Sie auf Probleme in einer Produktionsdatenbank gestoßen sind, informieren Sie am besten die Geschäftsinhaber oder Ihren Betriebsleiter, um Ihre Karten auf den Tisch zu legen. Sie können ihnen entweder die Möglichkeit geben, die Datenbank aus der letzten verfügbaren Sicherung wiederherzustellen, oder Sie können mit der Ausführung von DBCC CheckDB-Befehlen mit zusätzlichen Optionen experimentieren.

Die DBCC-Fehlermeldungen können etwa wie folgt aussehen:

Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data).

Keys out of order on page (1:107), slots 6 and 9.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'.
repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).

In der Fehlermeldung sehen Sie eine sorgfältig formulierte Fehlermeldung – „repair_rebuild is the Minimum Reparaturstufe für die von DBCC CHECKDB gefundenen Fehler “ – schlägt Ihnen vor, DBCC CheckDB mit der Option repair_rebuild auszuführen. Schauen Sie sich einfach das hervorgehobene Wort an – „Minimum“. Dies bedeutet, dass es mit der Option repair_rebuild keine wirkliche Möglichkeit eines Datenverlusts gibt und SQL Server einige schnelle Korrekturen unter der Haube vornimmt. Bitte beachten Sie den folgenden Befehl, um DBCC CheckDB mit der Option repair_rebuild auszuführen. Stellen Sie sicher, dass Sie die Datenbank in den Einzelbenutzermodus versetzen.

Laut Microsoft-Dokumentation ist die Option REPAIR_REBUILD die harmloseste Variante, da es zu keinem Datenverlust kommen kann. Wenn REPAIR_REBUILD die Konsistenzfehler jedoch immer noch nicht behebt, gibt es eine andere Option – REPAIR_ALLOW_DATA_LOSS zu aktivieren. Wenn wir uns den Namen ansehen, wissen wir, dass die Möglichkeit eines Datenverlusts besteht, wenn wir diese Option aktivieren. Aus diesem Grund warnt uns Microsoft davor, dies mit äußerster Vorsicht zu verwenden, da es unerwartete Folgen haben kann, wenn DBCC CheckDB mit REPAIR_ALLOW_DATA_LOSS ausgeführt wird. Der Befehl DBCC CheckDB sieht in diesem Fall folgendermaßen aus:

Punkte, die Sie berücksichtigen sollten, bevor Sie die Reparaturoption mit DBCC CheckDB verwenden

  • Wie kritisch ist die betreffende Datenbank?

  • Ist die Datenbank in der Produktions- oder Testumgebung?

  • Wie groß ist die Datenbank?

  • Haben Sie eine gute Wiederherstellungsstrategie für den Fall, dass Probleme auftreten?

  • Haben Sie Ihre Datenbank-Backups validiert?

Versuchen Sie basierend auf der Situation und den Antworten auf die obigen Fragen, eine Entscheidung zu treffen und dabei die Interessen des Kunden im Auge zu behalten.

Automatisieren der DBCC CheckDB-Aufgaben auf SQL Server mithilfe von Datenbankwartungsplänen

Nun, Sie müssen nicht alle diese Befehle manuell auf Ihren Servern ausführen. Aus diesem Grund haben wir Wartungspläne erstellt. Planen Sie mithilfe der Datenbankwartungspläne einen regelmäßigen Wartungszyklus für alle Ihre Datenbanken ein. Es ist eine ziemlich einfache und unkomplizierte Aufgabe. Wählen Sie unter „Aufgaben des Wartungsplans“ die Aufgabe „Datenbankintegrität prüfen“ aus.

Dadurch wird Ihrem Wartungsplan eine Unteraufgabe hinzugefügt, um Integritätsprüfungen für Ihre Datenbanken zu planen. Stellen Sie sicher, dass Sie die erforderlichen Datenbanken wie gezeigt auswählen.

Bitte achten Sie darauf, alle Datenbankprüfungen außerhalb der Spitzenzeiten der Woche durchzuführen. Normalerweise liegen die Wartungsfenster an den Wochenenden, wenn der Server im Vergleich zu den anderen Wochentagen weniger ausgelastet ist. Dies ist jedoch von Server zu Server unterschiedlich und hängt von der Anwendung ab. Auf kritischen Datenbanksystemen werden im Allgemeinen Warnungen angezeigt, wenn DBCC CheckDB oder Integritätsprüfungen ausgelassen wurden. Auf diese Weise können die DBAs proaktiv prüfen und sicherstellen, dass sie die Integritätsprüfungen abgeschlossen bekommen, um spätere Überraschungen zu vermeiden.

Automatisieren von DBCC CheckDB-Aufgaben auf SQL Server mithilfe benutzerdefinierter Skripts oder anderer beliebter Skripts

SQL Server-Wartungspläne müssen nicht ständig zum Ausführen von Wartungsaufgaben auf Ihrer SQL Server-Instanz verwendet werden. Es gibt andere verfügbare benutzerdefinierte Skripts, die Sie verwenden können. Eines der beliebtesten kostenlosen Wartungstools ist die Wartungslösung von Ola Hallengren. Sie können die gesamte Wartungslösung installieren, die Aufgaben für Sicherungen, Optimierung usw. enthält, oder Sie können nur die relevanten Skripte für Integritätsprüfungen herunterladen. In dieser Demo werden wir versuchen, die Skripte zu installieren, die für Datenbankintegritätsprüfungen spezifisch sind.

Klicken Sie wie gezeigt auf die Option DatabaseIntegrityCheck.sql, um die gespeicherten Prozeduren herunterzuladen, die die Datenbankintegrität prüfen. Nachdem ich diese gespeicherten Prozeduren in der Master-Datenbank ausgeführt hatte, stieß ich auf diese Warnmeldungen:

“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”

Wenn Sie die gespeicherte Prozedur zum Durchführen von Integritätsprüfungen ausführen, erhalten Sie die folgende Fehlermeldung:

Wie der Fehler besagt, können Sie den fehlenden Code hier herunterladen. Sobald dies erledigt ist, können Sie damit beginnen, die Datenbank-Integritätsprüfungen auszuprobieren.

Sie können verschiedene Optionen mit den zusätzlichen DBCC-Befehlsparametern anpassen. Weitere Einzelheiten und Beispiele dazu finden Sie hier.

In dieser Demo werden wir jedoch einige Beispiele überprüfen, um zu sehen, wie einfach und benutzerfreundlich diese Skripte wirklich sind.

Zum Ausführen von DBCC CheckDB auf allen Benutzerdatenbanken , müssen Sie Folgendes ausführen:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'USER_DATABASES',

@CheckCommands = 'CHECKDB'

Sie können den ausgeführten Befehl und den Ergebnisstatus sehen, der bestätigt, dass DBCC CheckDB erfolgreich abgeschlossen wurde.

Um DBCC Check nur für die Systemdatenbanken auszuführen, Führen Sie diesen Befehl aus:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'SYSTEM_DATABASES',

@CheckCommands = 'CHECKDB'

Auf dem Screenshot sehen Sie, dass die DBCC CheckDB für die Systemdatenbanken erfolgreich abgeschlossen wurde.

Zum Ausführen von DBCC CheckDB nur für eine bestimmte Datenbank Führen Sie Folgendes aus:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'VLDB', -- your specific DB Name

@CheckCommands = 'CHECKDB'

Im obigen Beispiel haben Sie einige Möglichkeiten gesehen, wie wir Parameter verwenden können. Es gibt jedoch eine Reihe anderer Filter, die Sie je nach Ihren Vorlieben auswählen können. Außerdem können Sie, wie bereits erwähnt, auf diesen Link verweisen zum weiteren Verständnis der Drehbücher von Ola Hallengren. Um es noch einmal zu wiederholen, ich verwende die Skripte von Ola Hallengren auf den Servern, die ich verwalte, und sie werden in der SQL Server-Community sehr empfohlen und anerkannt. Sie können die gespeicherten Prozeduren basierend auf Ihren bevorzugten Parametern planen und sie als SQL-Job außerhalb der Spitzenzeiten ausführen. Auf diese Weise müssen Sie keines dieser Skripte wirklich manuell ausführen, sodass Sie sich auf andere wichtige Aufgaben konzentrieren können.

Schlussfolgerung

  • In diesem Artikel haben Sie mehr über DBCC CheckDB und seine Verwendung erfahren
  • Sie haben auch verstanden, wie wichtig es ist, DBCC CheckDB regelmäßig auf all Ihren wichtigen Datenbanken auszuführen
  • Sie haben auch gelernt, wie wichtig eine getestete Sicherungsstrategie ist – es wird empfohlen, Ihre Datenbanken mit einer guten Sicherung wiederherzustellen, anstatt Konsistenzfehler mit den DBCC-Reparaturoptionen zu beheben
  • Sie haben auch gesehen, wie einfach es ist, Skripte zu konfigurieren und zu automatisieren, entweder mit SQL Server-Wartungsplänen oder benutzerdefinierten Skripten, z. B. dem von Ola Hallengren
  • Sie haben auch die Risiken kennengelernt, die entstehen, wenn DBCC CheckDB nicht auf Ihrer unterstützten Infrastruktur geplant wird
  • Sie haben auch gelernt, dass es keine Datenbank geben kann, die keine Wartung erfordert, ganz gleich, auf welchem ​​Server Sie sich befinden oder welche Infrastruktur Sie betreiben.
  • Stellen Sie schließlich sicher, dass Ihre Datenbanken gesund bleiben und bereiten Sie sich in jedem Fall auf die AUS-Tage vor, die möglicherweise nicht unter Ihrer Kontrolle stehen