DBCC CHECKDB ist von entscheidender Bedeutung für SQL Server - Datenbanken zu 100% sicher sein , dass es keine Korruption. Aufgrund der massiven Größe von Datenbanken ist es jedoch sehr schwierig, ein Wartungsfenster zu finden, wenn Sie behaupten, rund um die Uhr verfügbar zu sein. Im Laufe der Jahre hat das SQL Server-Team verschiedene Mechanismen implementiert, mit denen die häufigsten Formen von Beschädigungen erkannt werden, insbesondere im Zusammenhang mit physischer Beschädigung durch Hardware.
SQL Server 2005 und höher verfügt über PAGE_VERIFY = CHECKSUM, mit dessen Hilfe Sie proaktiv physische Beschädigungen auf Datenbankseiten erkennen können, indem Sie jeder Seite beim Schreiben in das E / A-System eine Prüfsumme hinzufügen und die Prüfsumme beim Lesen von der Festplatte validieren.
Durch die Sicherung (vollständig oder differenziell) mit CHECKSUM wird außerdem garantiert, dass durch Hardware verursachte E / A-Beschädigungen erkannt werden.
Auf der Hardwareseite der Beschädigung kann SQL Server diese daher gut erkennen und melden. (Stellen Sie sicher, dass Sie auch wichtige Warnungen im Zusammenhang mit Korruption festlegen .)
Trotzdem immer noch logische Beschädigung , durch Scribbler verursachte Fehler - bei denen In-Memory-Seiten entweder durch Code von Drittanbietern beschädigt werden, der im SQL Server-Prozess ausgeführt wird, oder durch Treiber oder andere Software mit ausreichenden Berechtigungen, die im Windows-Kernelmodus und / oder in SQL Server ausgeführt werden Bugs , etc. sind nicht nachweisbar über Methoden und damit CHECKDB kommt ins Bild.
DBCC CHECKDB führt eine gründlichere Überprüfung durch, einschließlich der Überprüfung der Seitenkopfzeilen auf mögliche Beschädigungen, die auf keine andere Weise erkennbar sind.
Gibt es da draußen vorhandene Skripte?
Anstatt das Rad neu zu erfinden, würde ich Ihnen dringend empfehlen, sich die SQL Server Integrity Check-Lösung von Ola anzusehen
Effizientes Ausführen von DBCC CHECKDB:
Sie müssen nur kreativ sein, wenn Sie ein enges Wartungsfenster mit riesigen Datenbanken oder einer hohen Anzahl von Datenbanken haben, auf denen CHECKDB ausgeführt werden soll.
Nach dem Besuch der SQLSkills-Schulung habe ich Folgendes in meiner Umgebung implementiert:
- Priorisieren Sie, welche Tabellen zu überprüfen sind.
- Trennen Sie die Tabellen in Gruppen mit unterschiedlichen Prioritäten und führen Sie sie
DBCC CHECKTABLEzusammen mit DBCC CHECKALLOCund ausDBCC CHECKCATALOG
- Erstellen Sie eine Arbeitertabelle, in der die Tabellennamen mit Prioritäten gespeichert werden. Stellen Sie einfach sicher, dass alle Tabellen mit hoher Priorität (die sehr groß sind) nicht zu einer Gruppe gehören, da Ihre CHECKDB sonst überhaupt nicht vollständig wird.
- Sie können sogar eine Timeout-Spalte in Ihrer Worker-Tabelle haben, die koordiniert, wann Ihre CHECKDB beendet wird, sobald sie das Wartungsfenster passiert hat
- Fügen Sie hinzu, wie lange die Ausführung pro Tabelle gedauert hat
DBCC CHECKTABLE, DBCC CHECKALLOCund DBCC CHECKCATALOG. Damit Sie ein Gefühl dafür bekommen, wie lange es normalerweise dauert, bis Ihre Schecks ausgeführt werden.
- Sie können sogar mit
NOINDEXOption ausführen, da dies den Vorgang beschleunigt, da die nicht gruppierten Indizes in Benutzertabellen nicht überprüft werden. Dies hat einige Vorteile, da es als Datenbeschädigung nicht so kritisch ist, da keine Daten verloren gehen und Sie den Index bei Bedarf löschen und neu erstellen können.
Natürlich kann die Enterprise Edition die parallele Ausführung von DBCC-Anweisungen nutzen. Achten Sie jedoch auf die MAXDOP-Einstellung, da dies möglicherweise Ihre gesamte CPU beansprucht. Dies kann vom Resource Governor stark eingeschränkt werden.
Hinweis: Wenn Sie die Spalte SPARSE haben, ist Ihre CHECKDB wie hier beschrieben absolut langsam .
Schließlich erfahren Sie, wie Sie eine Beschädigung der Datenbank verhindern können, indem Sie alle verfügbaren Tools + Ihr Vertrauen in Ihr Datenbankserver-Hardwaresystem und vor allem den Wert Ihrer Daten nutzen.
Einige ausgezeichnete Referenzen: