Wenn SQL Server Daten auf Ihre Laufwerke schreibt, nimmt er einfach an, dass alles in Ordnung ist, bis er die Daten wieder zurücklesen muss.
Unglücklicherweise ist der Speicher im Falle einer Beschädigung nicht so freundlich, SQL Server zu alarmieren. Und manchmal ist SQL Server sogar dafür bekannt, sich selbst zu beschädigen.
Wir müssen regelmäßig überprüfen, ob die Daten auf der Festplatte noch sinnvoll sind, und hier kommt DBCC CHECKDB ins Spiel. Es prüft sowohl auf Zuordnungsfehler als auch auf Konsistenzfehler. Wenn es Probleme gibt, werden die Fehlermeldungen mit Informationen darüber zurückgegeben, wo die Fehler vorhanden sind, wie schwerwiegend der Fehler ist und welche Reparaturoption vorgeschlagen wird.
Es ist wichtig, CHECKDB regelmäßig auszuführen, um Fehler zu finden, wenn sie vorhanden sind, denn wenn es eine Beschädigung gibt, müssen wir sie beheben, bevor unsere letzten guten Backups verschwinden.
Um das Problem zu finden, überprüfen wir jede Datenbank, um sicherzustellen, dass DBCC CHECKDB in den letzten zwei Wochen eine erfolgreiche Prüfung durchgeführt hat.
Don’t Believe It?
„Aber ich lasse doch ständig CHECKDB laufen“, werden Sie vielleicht sagen – nun, finden wir es heraus:
|
1
|
DBCC DBINFO(‚StackOverflow‘) WITH TABLERESULTS
|
Das ist es. Aber die Ausgabe ist ein Alptraum. Es sind etwa 80 Zeilen mit Dingen, die Sie wahrscheinlich nie interessieren werden. Um Zeile 50 herum ist das, wonach Sie suchen.
Hallo, ich bin Unsinn.
Und das ist wahrscheinlich das, was Sie sehen werden! Ein Datum von 1900-01-01 usw. Das bedeutet: nie. Wenn Sie DBCC CHECKDB auf der Datenbank ausführen, vielleicht so:
|
1
|
DBCC CHECKDB(‚StackOverflow‘) WITH NO_INFOMSGS, ALL_ERRORMSGS
|
Und dann führen Sie den Befehl DBCC DBINFO erneut aus, unser Datum ist jetzt auf aktuell aktualisiert:
Sieh dir an, wie viel Spaß wir haben
Wenn das Datum nicht aktualisiert wird, bedeutet das eines von zwei Dingen: SQL Server kann nicht in die Datenbank schreiben (als ob sie schreibgeschützt wäre), oder er findet Fehler (hoowee, nicht gut.)
Um das Problem zu beheben
Entscheiden Sie, ob Sie eingebaute Wartungspläne oder ein kostenloses Tool wie Ola Hallengrens kostenlose CHECKDB-Skripte verwenden möchten. Ein paar Überlegungen:
- Wartungspläne haben eine grafische Oberfläche, falls Sie keine T-SQL-Kenntnisse haben.
- Ola Hallengrens kostenlose Skripte kümmern sich um die Feinabstimmung der Optionen, wie z.B. die automatische Durchführung von data_purity checks (was eine gute Sache ist).
Wie Sie eine regelmäßige Wartung einrichten, um auf Korruption zu prüfen
Option 1: Verwenden Sie einen Wartungsplan, um DBCC CHECKDB auszuführen
Wenn Sie Wartungspläne verwenden, können Sie diese im SQL Server Management Studio unter Verwaltung, Wartungspläne bearbeiten. Ihr Server kann mehrere Wartungspläne haben, die CHECKDB für verschiedene Arten von Datenbanken ausführen, z.B. einen für Systemdatenbanken und einen für Benutzerdatenbanken.
Erweitern Sie den Knoten Verwaltung in SSMS, klicken Sie mit der rechten Maustaste auf Wartungspläne und wählen Sie Neuer Plan.
Ziehen Sie aus dem Toolbox-Fenster, das manchmal auf der linken Seite ausgeblendet wird, die Aufgabe „Datenbankintegrität prüfen“ auf die Registerkarte „Wartungsplan“.
Wenn Sie auf der Registerkarte „Wartungsplan“ auf das Feld „Datenbankintegrität prüfen“ doppelklicken, können Sie auswählen, welche Datenbanken während des Prozesses geprüft werden sollen.
Danach müssen Sie nur noch die Aufgabe planen, was genau wie die Planung eines Agentenauftrags funktioniert.
Nach dem Speichern und Schließen des Wartungsplans müssen Sie den entsprechenden Auftrag im SQL Server-Agenten finden und die Benachrichtigungseigenschaften so einstellen, dass ein Bediener informiert wird, wenn er fehlschlägt.
Option 2: Einrichten von SQL Agent-Jobs zur Ausführung von DBCC CHECKDB mit Hilfe der kostenlosen Skripte von Ola Hallengren
Wenn Sie zum ersten Mal Integritätsprüfungen implementieren, sollten Sie die kostenlosen Wartungsskripte von Ola Hallengren verwenden. Sie sind nicht ganz so einfach wie Wartungspläne, aber viel flexibler. Sie bieten auch die Möglichkeit, DBCC-Operationen bei großen Datenbanken in kleinere Teile aufzuteilen. Bei sehr großen Datenbanken kann CHECKDB eine beträchtliche Menge an Zeit und Ressourcen beanspruchen – die Option WITH PHYSICAL_ONLY ist schneller, lässt aber die logischen Prüfungen aus.
Sobald die Agent-Jobs eingerichtet sind, können Sie sie so einfach wie Wartungspläne einplanen oder sie mit den hier dokumentierten zusätzlichen Optionen feinabstimmen.