Das Folgende ist eine Zusammenstellung der Ergebnisse, die ich gelesen habe. In den verlinkten Blogs und Dokumenten finden Sie weitaus mehr Informationen.
Erstens kann es vorkommen, dass DBCC CHECKDBInkonsistenzen nicht erkannt werden, wenn Sie die Prüfsumme oder die Überprüfung von torn_page deaktivieren. Ein Zitat von Paul Randal in diesem Beitrag :
Sie haben Recht - wenn die Option "Seite zerrissen" oder "Prüfsumme nicht aktiviert ist, kann in Bezug auf die Seitenschutzoptionen nichts erkannt werden. CHECKDB kann nach wie vor auf Fehler stoßen, die es bei allen von ihm durchgeführten Konsistenzprüfungen festgestellt hat. Es werden jedoch beispielsweise keine Fehler in der Mitte von Datenwerten festgestellt.
Ha - das ist der Fehler beim Aktivieren von Seitenprüfsummen - nichts passiert, bis eine Seite eingelesen, geändert und wieder ausgeschrieben wurde. Die einzige Möglichkeit, Seiten zum Abrufen von Prüfsummen zu zwingen, besteht darin, sie zu ändern - z. B. indem Sie alle Ihre Indizes neu erstellen, was möglicherweise unangenehm ist -, es gibt überhaupt kein 'Touch'-Tool.
Die obige Situation kann Sie treffen, wenn Sie eine Datenbank von SQL Server 2000 oder früher auf 2005 oder später aktualisiert haben. Sie müssen dann die Seitenprüfsummen manuell mit ALTER DATABASE aktivieren, um sie zu aktivieren. Aber dann setzt der zweite Absatz des obigen Zitats ein und könnte Sie beunruhigen.
BACKUP WITH CHECKSUMerkennt Prüfsummeninkonsistenzen, jedoch nur, wenn auf der Seite bereits eine Prüfsumme geschrieben wurde, wenn sie gesichert wird. DBCC CHECKDBErkennt normalerweise auch diese Fehler, daher ist es keine gute Idee, BACKUP WITH CHECKSUM zu verwenden, um DBCC CHECKDB zu ersetzen .
Jetzt gibt es eine zweite Möglichkeit DBCC CHECKDB, um keine Inkonsistenzen zu zeigen, auch wenn es einige gibt. Dazu zitiere ich nur noch einmal Paul Randal in Missverständnissen über Korruption: Können sie verschwinden? :
Was ist also mit den verschwundenen Verfälschungen? Hier erfahren Sie, wie Konsistenzprüfungen funktionieren. Konsistenzprüfungen werden nur für die Seiten in der Datenbank ausgeführt, die zugeordnet sind. Wenn eine Seite zu nichts zugeordnet ist, sind die 8192 Bytes davon bedeutungslos und können nicht interpretiert werden. Verwechsle nicht zwischen reserviert und zugeteilt - das erkläre ich im ersten Missverständnis-Post hier. Solange eine Seite zugeordnet ist, wird sie von DBCC CHECKDB auf Konsistenz überprüft, einschließlich des Testens der Seitenprüfsumme, falls vorhanden. Eine Beschädigung kann "verschwinden" scheinen, wenn eine beschädigte Seite zum Zeitpunkt der Ausführung einer DBCC CHECKDB zugeordnet ist, die Zuordnung dann jedoch zum Zeitpunkt der nächsten Ausführung der DBCC CHECKDB aufgehoben wird. Beim ersten Mal wird es als beschädigt gemeldet, beim zweiten Mal wird es jedoch nicht zugewiesen. Daher wird es nicht auf Konsistenz überprüft und nicht als beschädigt gemeldet. Die Korruption scheint auf mysteriöse Weise verschwunden zu sein. Dies ist jedoch nicht der Fall - lediglich, dass die beschädigte Seite nicht mehr zugewiesen wird. Es hält SQL Server nicht davon ab, die Zuordnung einer beschädigten Seite aufzuheben. Tatsächlich führen viele Reparaturen von DBCC CHECKDB die Aufhebung der Zuordnung von Fehlern durch und reparieren alle Verknüpfungen.
Ich habe keine endgültige Antwort auf Ihre Frage, aber da DBCC CHECKDBnur zugewiesene Seiten überprüft werden, werden auf freigegebenen Seiten keine Inkonsistenzen angezeigt. Die einzige Situation, die ich mir jetzt vorstellen kann, ist, dass BACKUP auch die freigegebenen Seiten sichert, die potenzielle Prüfsummenfehler aufweisen, die übersprungen wurden DBCC CHECKDB.