Viele Fehlerfunde bei DBCC CHECKDB

Question

Sql Server: 2012

Datenbank läuft im Kompatibilitätsmodus (2005er)

Nachdem immer wieder Fehler bei dem Restore von Log Dateien aufgetreten sind, habe ich eine Datenbanküberprüfung via DBCC CHECKDB durchgeführt. Dabei wurde mir mitgeteilt, das insgesamt 711  "consistency errors" in der Datenbank gefunden worden sind.

Die älteren Sicherungen der Datenbank enthalten ebefalls diese Fehler. Diese Datenbank wird produktiv verwendet und ein Verlust von Daten ist inakzeptabel. Es sind 3 Tabellen betroffen, die sehr viele Daten halten.

Was wäre das richtige Vorgehen um einen fehlerfreien Zustand wiederherzustellen?

Als Zusatzinformation nach dem Check habe ich folgende Zeile bekommen:

"repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB"

Gibt es andere Möglichkeiten um die Tabellen zu übertragen und dabei die Feher zu bereinigen?

Mit freundlich Grüßen,

Waldemar

Answer 1

Hallo Waldemar,

als erstes würde ich mir mit einem aktuellen Backup der DB ein Kopie der Datenbank erstellen, um die nächsten Schritt zu testen. Dort könntest Du dann DBCC CHECKDB (Transact-SQL) mit Option REPAIR_ALLOW_DATA_LOSS durchführen um zu sehen, ob das überhaupt zum Erfolg führt. Wenn es funktioniert hat, kannst Du anschließend Original/Kopie miteinander vergleichen, ob es zu einem Datenverlust kam.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 2

Um zu beurteilen, ob Datenverlust und in welchem Umfang auftritt, wäre ein Ausdruck der Ergebnisse (nur der Fehlermeldungen) hilfreich.

Wenn die Option bereits angeboten wird, ist sehr wahrscheinlich, das Datenverlust auftritt.

Wie viel man mit welchem Aufwand manuell retten kann, lässt sich so, ohne den genauen Aufbau der Datenbank zu kennen, nicht sagen.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 3

Vielen Dank für das schnelle Antworten!

Ich habe DBCC CHECKDB mit Option REPAIR_ALLOW_DATA_LOSS und konnte damit alle Fehler beseitigen. Leider habe ich kein Programm gefuden, womit sich einfach vergleichen lässt inwiefern sich jetzt die Reparierte Datenbank von der Ursprünglichen unterscheidet.

Kennt ihr ein gutes Programm dafür?

Answer 4

Hallo Waldemar,

an der Struktur der Datenbank wird sich nichts geändert haben, es könnte höchstens sein, das Datensätze verloren gegangen sind, d.h. Du brauchst nur die Anzahl Datensätze in den Tabellen (und Indizes) vergleichen; das kannst Du sehr einfach & effizient für die ganze Datenbank / alle Tabellen über die DMV sys.dm_db_partition_stats abfragen:

-- Detailsicht auf alle Datenobjekte mit Aufteilung der Partitionen
-- mit Anzahl Zeilen und den verwendeten + reservierten 
-- Speicherplatz in KiloByte
SELECT SCH.name AS SchemaName, 
       OBJ.name AS ObjName, OBJ.type_desc AS ObjType,
       INDX.name AS IndexName, INDX.type_desc AS IndexType,
       PART.partition_number AS PartitionNumber,
       PART.rows AS PartitionRows, 
       STAT.row_count AS StatRowCount,
       STAT.used_page_count * 8 AS UsedSizeKB,
       STAT.reserved_page_count * 8 AS RevervedSizeKB
FROM sys.partitions AS PART
     INNER JOIN sys.dm_db_partition_stats AS STAT
         ON PART.partition_id = STAT.partition_id
            AND PART.partition_number = STAT.partition_number
     INNER JOIN sys.objects AS OBJ
         ON STAT.object_id = OBJ.object_id
     INNER JOIN sys.schemas AS SCH
         ON OBJ.schema_id = SCH.schema_id
     INNER JOIN sys.indexes AS INDX
         ON STAT.object_id = INDX.object_id
            AND STAT.index_id = INDX.index_id
ORDER BY SCH.name, OBJ.name, INDX.name, PART.partition_number

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 5

...

Ich habe DBCC CHECKDB mit Option REPAIR_ALLOW_DATA_LOSS und konnte damit alle Fehler beseitigen....

DBCC CHECKDB liefert Informationen darüber zurück, was es getan hat. Daraus müsste klar hervorgehen ob er Daten gelöscht hat. Das Output sollte man sich also wirklich ansehen. Es sollte auch noch im SQL Server Errorlog sein. Notfalls kann man die Operation mit einer vorher sicher erstellten Sicherung wiederholen, und diesmal darauf achten/ das output speichern. Das könnten wir uns hier auch gemeinsam ansehen.

Zum Vergleichen von Daten kann man tablediff.exe verwenden, welches mit SQL Server mitgeliefert wird. (liegt im COM-Verzeichnis der Installation)

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 6

Die Ausgabe ist ziemlich lang und ich habe hier keine Funktion gefunden um Dateien einzubinden.

Hier die Message nach dem "DBCC CHECKDB ('comwork_mitfehler',  REPAIR_ALLOW_DATA_LOSS)" Befehl. Es wurden nicht alle Fehler behoben, aber die meisten:

DB-Repair Message

Answer 7

Die Ausgabe ist ziemlich lang und ich habe hier keine Funktion gefunden um Dateien einzubinden.

Hier die Message nach dem "DBCC CHECKDB ('comwork_mitfehler',  REPAIR_ALLOW_DATA_LOSS)" Befehl. Es wurden nicht alle Fehler behoben, aber die meisten:

DB-Repair Message

Das Statement kann man getrost als Untertreibung bezeichnen ;-)

Aber jetzt mal im Ernst: Ihr habt ein ernstes Problem ->

> CHECKDB found 0 allocation errors and 2084 consistency errors in database 'TestDB_mitfehler'.
> CHECKDB fixed 0 allocation errors and 1992 consistency errors in database 'TestDB_mitfehler'.

Die Datenbank ist hochgradig korrupt, und auch Systemtabellen sind betroffen. Das lässt sich nicht automatisch fixen. Auf jeden Fall sind die nächsten Schritte:

• Die Datenbank sichern (MIT den Fehlern)
• CHECKDB ausführen
• möglicherweise die Daten manuell auf "verschmerzbare Verluste" prüfen
• bei Bedarf einen Fachmann hinzuziehen, der die Daten verschen kann, manuell zu retten, oder weitere Schritte empfehlen kann
• über das Forum sehe ich hier jedenfalls die Grenze - zumal man sicher auch gerne eine Form von Gewissheit haben möchte.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 8

PS: und unbedingt jeden (schreibenden) Zugriff auf die Datenbank verhindern, um weitere Korruption auch in neuen Daten zu verhindern. Am besten Single-User mode. Nicht aber abhängen.

Gerne das Subsystem prüfen, aber ERST die Datenbank sichern.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 9

Die Datenbank wird bei uns täglich gesichert. Das automatische  Wiederherstellen auf dem Ausfallserver ist in  unregelmäßigen Abständen schief gelaufen. Daraufhin habe ich ja erst die Datenbankprüfung via DBCC CHECKDB gemacht. Es ist interessant, das eine erneute Prüfung der (jetzt aktuelleren) DB, die keine automatische Reperatur bekommen hat, "nur noch" 435 Fehler aufweist. Die Fehler beschrenken sich auch fast ausschließlich auf eine Tabelle (415 Fehler in Tabelle Attachments). Das ist aber auch die größte Tabelle (enthält viele LOB daten). Systemtabellen waren jetzt gar nicht betroffen. Woran kann das liegen?

Message nach Reperatur der Datenbank

Answer 10

Die Datenbank wird bei uns täglich gesichert. Das automatische  Wiederherstellen auf dem Ausfallserver ist in  unregelmäßigen Abständen schief gelaufen. Daraufhin habe ich ja erst die Datenbankprüfung via DBCC CHECKDB gemacht. Es ist interessant, das eine erneute Prüfung der (jetzt aktuelleren) DB, die keine automatische Reperatur bekommen hat, "nur noch" 435 Fehler aufweist. Die Fehler beschrenken sich auch fast ausschließlich auf eine Tabelle (415 Fehler in Tabelle Attachments). Das ist aber auch die größte Tabelle (enthält viele LOB daten). Systemtabellen waren jetzt gar nicht betroffen. Woran kann das liegen?

Message nach Reperatur der Datenbank

Was woran genau liegt, kann ich nicht aufgrund von 2 Postings ermitteln. Das wäre lediglich raten. Die Reihenfolge erschließt sich mir nicht vollständig. Es wäre mir auch zu riskant hier etwas übersehen zu haben.

Fakt ist, die Datenbank enthält noch immer korrupte Seiten. - Ja, Systemobjekte sind wohl nicht betroffen, das hatte ich wohl mit den unzugeordnetetn LOB-Columns verwechselt. - Die "Bereinigung" hat teilweise durch einfaches Löschen von Nonclustered Indexes funktioniert. Auch LOB Daten, die OFF-Row liegen, sind betroffen, und deren Zuordnung verloren.

Auf jeden Fall sollte man das Storage prüfen.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 11

Die Datenbank wird bei uns täglich gesichert. ..

PS:

ich habe mich schon gewundert, dass diese Fehler dann nicht eher entdeckt wurden. Aber vermutlich läuft die Sicherung ohne Checksumme :-/

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 12

**************************************************************************************************
Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.
Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.
**************************************************************************************************

---

Ionut Duma, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.