Hallo, mein Name ist Kirk. Ich bin Senior Principal Engineer und arbeite im GSE-Team. Dieses Video befasst sich mit dem Microsoft SQL Server TSQL-Datenbanktool DBCC CHECKDB. Es wird erläutert, warum und wann DBCC CHECKDB ausgeführt werden sollte, sowie Befehlsoptionen, die den Grad der Datenbanküberprüfung und die Laufzeit bestimmen.
Ich möchte auf einige Punkte eingehen, bevor wir zum Demo kommen. DBCC CHECKDB ist ein TSQL-Tool, das die logische und physische Integrität aller Objekte in einer bestimmten SQL Server-Datenbank untersucht. Wir haben einige Reparaturoptionen, die ebenfalls verfügbar sind, und wir haben auch etwas namens "TABLOCK" als Option, das die Verwendung oder Nichtverwendung eines Snapshots der Datenbank beinhaltet. Wir werden uns die Option "ESTIMATEONLY" ansehen, warum wir sie verwenden sollten, und das ist relativ zur Verwendung von "TEMPDB" während eines CHECKDB-Prozesses.
Außerdem sehen wir uns "PHYSICAL_ONLY" an und erklären, warum wir diese Option verwenden sollten und wann. Und wir werden uns auch ansehen, wie wir die Anzahl der Prozessoren, die am CHECKDB-Prozess beteiligt sind, mit etwas namens "MAXDOP" steuern können. An diesem Punkt sehen wir uns einige Beispiele dafür an, was wir sehen würden, wenn wir DBCC CHECKDB ausführen. Der erste Befehl selbst überprüft also buchstäblich alles, was von DBCC CHECKDB in einer bestimmten Datenbank angezeigt werden kann.
Hier sind die Ergebnisse. Die Rückgabelinie, an der wir beim Ausführen am meisten interessiert sind, ist die Anzahl der in der Datenbank gefundenen "Zuordnungsfehler" und "Konsistenzfehler". Ich habe also eine fehlerfreie "AdventureWorks2019"-Datenbank, sodass alles ohne Fehler zurückgegeben wird. Da es sich um eine kleine Datenbank handelt, ist die Ausführung sehr schnell abgeschlossen. Wenn wir eine viel größere Datenbank haben, eine Datenbank beispielsweise, die 100-mal so groß ist wie diese, dauert die Ausführung viel länger.
Und viele Leute fragen sich, wie oft wir versuchen sollten, DBCC CHECKDB auszuführen, und in der Regel sagen Ihnen die SQL-Master, dass Sie versuchen sollten, es so schnell wie möglich auszuführen. Wenn es Inkonsistenzen oder irgendeine Art von Softwareschäden in der Datenbank gibt, möchten Sie diese so schnell wie möglich entdecken und sich darum kümmern. Die nächste Option, die wir uns ansehen werden, ist die Option "MIT PHYSICAL_ONLY".
Es ist derselbe Befehl, außer dass er in diesem Fall buchstäblich nur die physische Entität oder die Struktur der Datenbank selbst überprüft. Er läuft in der Regel viel schneller als eine vollständige Prüfung, weshalb wir ihn in Produktionsumgebungen ausführen möchten, in denen die Wartungszeiten begrenzt sind. Wir haben auch eine andere Option namens "WITH TABLOCK", also eine Sache, die wir über DBCC CHECKDB wissen müssen. Eines der ersten Dinge, die es tut, ist, dass es eine Momentaufnahmedatei erstellt, die in der "TEMPDB"-Datenbank enthalten ist, und es gibt Zeiten, in denen wir "TEMPDB" möglicherweise nicht für so etwas mit einem CHECKDB-Prozess verwenden können.
Unabhängig davon, was wir als "WITH TABLOCK" bezeichnen, weisen wir DBCC CHECKDB an, keine Momentaufnahmedatei zu erstellen, sodass sie diesen Platz in "TEMPDB" nicht belegt und daher in der Regel schneller ausgeführt wird. Eines der anderen Dinge, die wir als Option ausführen können, ist "WITH ESTIMATEONLY". Dieser spezielle Befehl teilt uns mit, wie viel Speicherplatz wir in unserer "TEMPDB"-Datenbank erwarten würden, wenn wir CHECKDB ausführen.
Hier ist ein Beispiel für die Ausgabe, die in Kilobyte zurückgegeben wird, also etwa 230 Megabyte. Eine weitere Option ist „WITH MAXDOP“. Unabhängig davon, was DBCC CHECKDB ausführt, wird versucht, so viele Prozessoren zu verwenden, wie für die parallele Ausführung erforderlich sind. Es sollen mehrere Threads ausgeführt werden, um zu versuchen, sie so schnell wie möglich auszuführen. Es kann also Einschränkungen hinsichtlich der Anzahl der Prozessoren geben, die in diesem Prozess ausgeführt werden sollen. Daher können wir dies mit der Anweisung "WITH MAXDOP" begrenzen.
In diesem Fall weise ich SQL an, nur einen Prozessor für unsere CHECKDB-Ausführung zu verwenden. Und wenn wir das tun, sind das weniger Prozessoren, die dafür dediziert sind, aber es dauert in der Regel länger, DBCC CHECKDB auszuführen. Sehen wir jetzt die Reparaturoptionen an. Es gibt verschiedene Reparaturoptionen. Die drastischste Option ist „REPAIR_ALLOW_DATA_LOSS“. Sie können buchstäblich Daten verlieren, wenn wir diese Option verwenden, um zu versuchen, eine Datenbank zu reparieren, die mit Fehlern zurückgegeben wird. Wir können auch „REPAIR_REBUILD“ verwenden.
REPAIR_REBUILD wird als Soft-Repair-Option betrachtet. Damit ist die Sicherheit gemeint, dass die verfügbaren Daten in der Datenbank nicht verloren gehen, wenn wir diesen Vorgang ausführen. In der Art und Weise, wie dieser Befehl aufgebaut ist, verwenden wir den Kontext der "Master"-Datenbank. Wann immer wir so etwas tun, müssen wir die Datenbank in den "SINGLE_USER"-Modus versetzen, um einen Reparaturvorgang zu ermöglichen. In diesem Fall führen wir also diese Option aus.
Jetzt haben wir hier die Option "ESTIMATEONLY", und auch hier wird uns "ESTIMATEONLY" mitteilen, wie viel Speicherplatz wir in "TEMPDB" dafür aufgeben werden. Unsere Snapshot-Datei belegt nach unserer Rückkehr hier rund 230 MB. Nach der Reparatur möchten wir das Gerät wieder in den "MULTI_USER"-Modus versetzen. Mit "ESTIMATEONLY" haben wir die Reparatur nicht wirklich durchgeführt, sondern nur die Schätzung. Sehen wir uns nun an, wie der Befehl mit dem "REPAIR_REBUILD" ausgeführt wird.
Nochmals, klicken Sie auf "Execute", wir setzen es wieder in "MULTI_USER". Im Kontext der "Master"-Datenbank versetzen wir sie in den "SINGLE_USER"-Modus. Wir führen jetzt eine Reparatur durch. Dies ist der sanfte Reparaturvorgang. Und was Sie sehen werden, ist viel von dem, was wir bei einer normalen DB-Prüfung sehen würden, und natürlich möchten wir wieder nach gemeldeten Fehlern suchen. In diesem Fall gibt es wieder keine.
Ich habe hier eine fehlerfreie Datenbank. Der letzte Teil dieses Vorgangs besteht darin, ihn wieder in den "MULTI_USER"-Modus zu versetzen. Der Reparaturbefehl "REPAIR_ALLOW_DATA_LOSS" entspricht genau dem REPAIR_REBUILD, nur dass wir das REPAIR_ALLOW_DATA_LOSS verwenden. Normalerweise führen wir dies aus, wenn wir versucht haben, die "REPAIR_REBUILD" auszuführen, und die "REPAIR_REBUILD" zurückkommt und uns mitteilt, dass die Reparatur der Datenbank nicht abgeschlossen werden konnte.
Also unser letzter Ausweg ohne ein gutes Backup, und ja, wir sollten ein gutes Backup verwenden, bevor wir gezwungen sind, ein "REPAIR_ALLOW_DATA_LOSS" zu machen. Wenn kein Backup vorhanden ist, ist dies unsere einzige Option, um die Datenbank wieder online und verfügbar zu machen. Damit ist unser Demo zur Erörterung von DBCC CHECKDB, der Überlegung, wann CHECKDB verwendet werden sollte, und einiger der am häufigsten verfügbaren Befehlsoptionen abgeschlossen. Ich hoffe, dieses Video hat Ihnen geholfen, den Wert der Verwendung von DBCC CHECKDB zu verstehen, wenn Sie versuchen, eine konsistente, stabile SQL Server-Datenbankinstallation aufrechtzuerhalten.
Vielen Dank für Ihre Aufmerksamkeit.
