Von: Brady Upton | Updated: 2016-07-26 | Comments (2) | Related: Weitere > Datenbankkonsolenbefehle DBCCs

Problem

SQL Server-Datenbankkorruption kann ein Problem sein und ernsthafte Schäden an einer Datenbank verursachen. Wenn Sie ein erfahrener DBA sind, dann haben Sie wahrscheinlich Sicherheitsvorkehrungen getroffen, um dies zu erkennen, aber im Laufe der Jahre habe ich Hunderte von SQL-Servern gesehen, die überhaupt keine Erkennungsmethoden hatten, und das ist ein Problem. Es gibt einige Möglichkeiten, Datenbankbeschädigungen zu erkennen, aber dieser Tipp konzentriert sich mehr auf DBCC CHECKDB.

Lösung

Sie haben vielleicht schon einmal vonDBCC (Datenbankkonsolenbefehle) Anweisungen gehört oder nicht. Diese Anweisungen werden verwendet, um verschiedene Operationen in Ihrer Datenbank durchzuführen und können in vier Kategorien unterteilt werden: Wartung, Verschiedenes, Information und Validierung. Ich verwende einige der DBCC-Anweisungen täglich, aber keine mehr als DBCC CHECKDB.

Was ist SQL Server DBCC CHECKDB

DBCC CHECKDB, aus der Microsoft MSDN Library, prüft die logische und physische Integrität aller Objekte in der angegebenen Datenbank, indem es die folgenden Operationen durchführt:

  • Führt DBCC CHECKALLOC in der Datenbank aus – Prüft die Konsistenz der Speicherplatzzuweisungsstrukturen für eine angegebene Datenbank.
  • Ausführen von DBCC CHECKTABLE für jede Tabelle und jeden View in der Datenbank – Überprüft die Integrität aller Seiten und Strukturen, aus denen die Tabelle oder der indizierte View besteht.
  • Führt DBCC CHECKCATALOG auf der Datenbank aus – Prüft die Konsistenz des Katalogs in der Datenbank.
  • Überprüft den Inhalt jeder indizierten Ansicht in der Datenbank.
  • Überprüft die Konsistenz auf Link-Ebene zwischen Tabellenmetadaten und Dateisystemverzeichnissen und -dateien, wenn varibinäre (maximale) Daten im Dateisystem mitFILESTREAM gespeichert werden.
  • Überprüft die Service Broker-Daten in der Datenbank

Wenn Sie DBCC CHECKDB schon einmal ausgeführt haben, wissen Sie, dass dies bei großen Datenbanken einige Zeit in Anspruch nimmt.

Wie kann mir SQL Server DBCC CHECKDB helfen?

Datenbeschädigung ist schlecht. Sie kann alle möglichen Probleme innerhalb der Datenbank verursachen, die falsche Datenergebnisse, fehlgeschlagene SQL-Anweisungen und in einigen Fällen sogar den Ausfall der gesamten SQL-Instanz zur Folge haben können. DBCC CHECKDB warnt Sie vor Korruption, so dass Sie sie beheben können, bevor sie (hoffentlich) zu schlimm wird.

Wie verwende ich SQL Server DBCC CHECKDB?

DBCC CHECKDB ist ziemlich einfach. Es gibt ein paar Optionen, die Sie mit der Anweisung verwenden können, und wir werden einige davon im nächsten Abschnitt besprechen, aber die Basissyntax sieht so aus:

DBCC CHECKDB ('DatabaseName') 

Sehr einfach.

SQL Server DBCC CHECKDB automatisieren

Natürlich möchten Sie sich nicht jeden Morgen anmelden und diese Anweisung für jede Datenbank ausführen, daher können Sie diesen Prozess mit einigen verschiedenen Methoden automatisieren:

  • SQL Server Wartungspläne -Wartungspläne sind Bestandteil von SQL Server (sofern Sie nicht die ExpressEdition verwenden). Ich verwende Wartungspläne in der Regel nicht gerne, aber für diese Art von Aufgabe ist es kein Problem, sie zu verwenden. In der Toolbox des Wartungsplans müssen Sie die Aufgabe Check Database Integrity verwenden. Die einzige konfigurierbare Option ist die Einbeziehung von Indizes, so dass sie nicht wirklich benutzerfreundlich ist, aber in manchen Fällen ist das alles, was Sie brauchen. Auf die anderen Optionen gehen wir im nächsten Abschnitt ein.
  • Benutzerdefinierte Skripte – Ich verwende in der Regel benutzerdefinierte Skripte, die die größte Flexibilität bieten, was das Hinzufügen der gewünschten Optionen angeht. Meine Go-Skripte sind bereits erstellt und können von Ola Hallengren kostenlos verwendet werden. Er hat sie auf wunderbare Weise erstellt und der Welt zur Verfügung gestellt. DankeOla!
    • Sehen Sie sich die Skripte auf MSSQLTips.com:
    • Wartung von SQL Server-Datenbanken im vollständigen Wiederherstellungsmodus durchführen
    • Wartungspläne für SQL Server-Datenbanken und Verwaltung von Sicherungsdateien
    • Wartung von SQL Server-Datenbanken ohne Wartungsfenster durchführen

SQL Server DBCC CHECKDB-Optionen

Es gibt einige Optionen, die mit DBCC CHECKDB verwendet werden können, und ich gehe hier auf einige der beliebtesten ein:

  • NOINDEX – Legt fest, dass intensive Prüfungen von nicht geclusterten Indizes für Benutzertabellen nicht durchgeführt werden sollen. Dadurch wird die Überausführungszeit verringert. NOINDEX wirkt sich nicht auf Systemtabellen aus, da Integritätsprüfungen immer für Systemtabellenindizes durchgeführt werden.
  • NO_INFOMSGS – Unterdrückt alle Informationsmeldungen.
  • PHYSICAL_ONLY – Beschränkt die Prüfung auf die Integrität der physischen Struktur der Seiten- und Datensatzköpfe und die Zuordnungskonsistenz der Datenbank. Diese Prüfung wurde entwickelt, um eine kleine Overhead-Prüfung der physischen Konsistenz der Datenbank zu bieten, aber sie kann auch zerrissene Seiten, Prüfsummenfehler und allgemeine Hardwarefehler erkennen, die die Daten eines Benutzers gefährden können.
  • TABLOCK – Veranlasst DBCC CHECKDB, Sperren zu erhalten, anstatt einen internen Datenbank-Snapshot zu verwenden. Dies schließt eine kurzfristige exklusive (X)-Sperre für die Datenbank ein. TABLOCK führt dazu, dass DBCC CHECKDB auf einer Datenbank unter hoher Last schneller läuft, verringert aber die auf der Datenbank verfügbare Gleichzeitigkeit, währendDBCC CHECKDB läuft.
  • DATA_PURITY – Veranlasst DBCC CHECKDB, die Datenbank auf Spaltenwerte zu prüfen, die nicht gültig sind oder außerhalb des Bereichs liegen. DBCC CHECKDB erkennt beispielsweise Spalten mit Datums- und Zeitwerten, die größer oder kleiner als der akzeptable Bereich für den Datentyp datetime sind, oder Spalten mit dezimalen oder approximativ-numerischen Daten, deren Skalen- oder Präzisionswerte nicht gültig sind.

Wir werden einige der REPAIR-Optionen in einem anderen Abschnitt weiter unten besprechen.

Wie oft sollte ich auf SQL Server-Korruption prüfen?

Jede Minute eines jeden Tages. Nur ein Scherz.

Wenn Sie ein tägliches Wartungsfenster haben, wäre es gut, täglich auf Datenbeschädigung zu prüfen. Je schneller man sie entdeckt, desto weniger Schaden kann sie anrichten. Ich habe festgestellt, dass viele Leute dies am Wochenende durchführen, besonders bei größeren Datenbanken. Es gibt kein Richtig oder Falsch damit, stellen Sie nur sicher, dass Sie es regelmäßig einplanen.

Muss ich DBCC CHECKDB in meiner Produktionsumgebung ausführen?

Nein, nun ja, ja. So in etwa.

Um zu prüfen, ob die Daten beschädigt sind, bringt es nichts, DBCC CHECKDB in Ihrer Testumgebung auszuführen, es sei denn, Sie stellen eine Kopie Ihrer Produktionsumgebung zum Testen wieder her und führen es dann aus. BRILLIANT!

Sie fragen sich vielleicht, ob einige HA-Optionen wie AlwaysOn, LogShipping, etc. geeignet sind? Nein, Sie müssen Ihre *Live*-Produktionsumgebung überprüfen.

Nun, da DBCC CHECKDB konfiguriert ist und läuft, wonach soll ich suchen?

Glückwunsch! Sie haben DBCC CHECKDB automatisiert und laufen lassen, aber was nun? Wenn Sie einenSQL ServerAgent Job eingerichtet haben, dann stellen Sie sicher, dass Sie Database Mail, einen Operator und eine Benachrichtigung für den Job einrichten. Wenn der Job erfolgreich ist, können Sie mit Ihrem schönen Tag weitermachen. Wenn der Auftrag fehlschlägt, haben wir noch etwas zu tun.

Es kann sein, dass Sie einen Fehler wie diesen sehen:

Die In-Row-Daten USED page count für das Objekt „tablename“, index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (Typ In-Row-Daten) ist falsch.Führen Sie DBCC UPDATEUSAGE. (Fehler 2508) Der RSVD-Seitenzähler für das Objekt „tablename“, Index-ID 2, par… Der Schritt ist fehlgeschlagen.

oder so:

Objekt-ID 2088535921, Index-ID 0, Partitions-ID 72345201021503994, alloc unitID 72345201051571606 (Typ In-Row-Daten): Seite (1:94299) konnte nicht verarbeitet werden, siehe andere Fehler für Details. Msg 8939, Level 16, State 98, Line 1 Tabellenfehler:Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data), page (1:94299). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) ist fehlgeschlagen. CHECKDB fand 0 Zuordnungsfehler und 2 Konsistenzfehler in der Tabelle ‚tablename‘ (Objekt-ID 2088535921). CHECKDB hat 0 Zuordnungsfehler und 2 Konsistenzfehler in der Datenbank ‚tablename‘ gefunden. repair_allow_data_lossist der minimale Reparaturlevel für die von DBCC CHECKDB (Database) gefundenen Fehler.

Erstens, keine Panik. Zweitens: Überprüfen Sie Backups. DBCC CHECKDB-Fehler sagen Ihnen normalerweise, was getan werden muss.

Beim ersten Fehler korrigiert ein DBCC UPDATEUSAGE die Ungenauigkeiten bei der Seiten- und Zeilenzahl in den Katalogansichten. Ziemlich harmlos.

Der zweite Fehler meldet eine Datenbeschädigung. Der Fehler erwähnt die Verwendung von repair_allow_data_loss als minimale Reparaturstufe. Das bedeutet, dass Sie die Anweisung mit diesem Argument ausführen können, aber Sie könnten Daten verlieren. Aus diesem Grund empfehle ich immer eine Wiederherstellung auf eine Sicherungskopie, wenn Sie es können. Sie müssen sicherstellen, dass die Sicherung keine beschädigten Daten enthält, und Sie wollen sicherstellen, dass es keinen Datenverlust gibt.

Wie man eine SQL Server-Datenbank repariert

Wenn Sie keine Sicherung haben, müssen wir möglicherweise DBCC CHECKDB mit einer Reparaturoption verwenden.Hier sind die Reparaturoptionen, die verwendet werden können. Diese können funktionieren oder auch nicht und sollten nur als letzter Ausweg verwendet werden:

  • REPAIR_ALLOW_DATA_LOSS – Versucht, alle gemeldeten Fehler zu reparieren.
  • REPAIR_REBUILD – Führt Reparaturen durch, bei denen kein Datenverlust möglich ist. Dies kann schnelle Reparaturen umfassen, wie das Reparieren fehlender Zeilen in nicht geclusterten Indizes, und zeitaufwändigere Reparaturen, wie das Wiederherstellen eines Indexes.

Wie ich oben sagte, ist es sehr wichtig, aktuelle Backups zu haben, um sich von einer Beschädigung zu erholen. Der Korruption ist es egal, wie viele Daten Sie haben, welche SQL-Version Sie verwenden oder wie schick Ihr Rechenzentrum ist.

Ich habe ein gutes Gefühl, aber was kann ich sonst noch tun, um meine SQL-Instanzen zu schützen?

DBCC CHECKDB sollte auf jeder SQL-Instanz ausgeführt werden, die Sie haben, aber es gibt ein paar andere Möglichkeiten, die helfen können, Datenbeschädigung zu erkennen/zu verhindern.

  • SQL Server Agent Alerts – Brian Kelley hat hier einen guten Tipp zu diesem Thema geschrieben.
  • Seitenüberprüfung – Stellen Sie sicher, dass Ihre Datenbanken die Seitenüberprüfung mitCHECKSUM verwenden. Wenn Sie noch mit SQL 2005 oder darunter arbeiten, ist dies nicht verfügbar, aber nach einem Upgrade sollten Sie diese Einstellung ändern. Um die Einstellungen für die Seitenverifizierung zu sehen, verwenden Sie die folgende Anweisung:
select name, page_verify_option_desc from sys.databases 
Nächste Schritte
  • Sehen Sie unbedingt in derMSDN Library nach, um mehr über DBCC CHECKDB zu erfahren
  • MSSQLTips.com hat eine schöne Sammlung von Tipps zuDatenbankkonsistenzprüfungen, die ebenfalls hilfreich sein können.

Last Updated: 2016-07-26

Über den Autor
Brady Upton ist ein Datenbankadministrator und SharePoint Superstar in Nashville, TN.
Alle meine Tipps ansehen
Verwandte Ressourcen

  • Weitere SQL Server DBA-Tipps…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.