Meldung 2534: DBCC CHECKDB-Zuordnungsfehler

Wir haben kürzlich unsere Intranet-Produktionsdatenbank von einem SQL Server 2008 auf einen brandneuen SQL Server 2008 R2-Server verschoben.

Der Sicherungsjob ist seit der Migration aufgrund von DBCC-Fehlern fehlgeschlagen (Datenbankintegritätsaufgabe überprüfen).

Ich habe gestern versucht, eine DBCC-CHECKDB mit der Option reparate_rebuild in der Produktionsdatenbank auszuführen, und die nachfolgende DBCC-CHECKDB zeigte keine Fehler. Die DBCC CHECKDB für die Produktionsdatenbanken zeigt erneut Fehlermeldungen an, die Sicherung ist abgeschlossen, aber der Wartungsplan schlägt natürlich fehl: Ich habe (eine lange Liste von) die folgenden Fehlermeldungen:

Table error: page (1:1100029), whose header indicates that it is allocated to object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data), is allocated by another object.
Msg 2534, Level 16, State 2, Line 1
Table error: page (1:1100030), whose header indicates that it is allocated to object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data), is allocated by another object.
Msg 7965, Level 16, State 1, Line 1
Table error: Could not check object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data) due to invalid allocation (IAM) page(s).
Msg 2534, Level 16, State 2, Line 1
Table error: page (1:1100031), whose header indicates that it is allocated to object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data), is allocated by another object.
Msg 2534, Level 16, State 2, Line 1
Table error: page (1:1100200), whose header indicates that it is allocated to object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data), is allocated by another object.
Msg 2534, Level 16, State 2, Line 1
Table error: page (1:1100201), whose header indicates that it is allocated to object ID 373210913, index ID 1, partition ID 72057701886525440, alloc unit ID 72057702118457344 (type In-row data), is allocated by another object.
There are 14 rows in 3 pages for object "searchfull_dummy_1049".
CHECKDB found 0 allocation errors and 6 consistency errors in table 'searchfull_dummy_1049' (object ID 373210913).
DBCC results for 'foldersRecherche'.
There are 0 rows in 0 pages for object "foldersRecherche".
DBCC results for 'wf'.
There are 0 rows in 0 pages for object "wf".
DBCC results for 'searchfull_dummy_1663'.

Ich habe versucht, die gestrige Sicherung zu verwenden, die Datenbank auf demselben Server mit einem neuen Datenbanknamen wiederhergestellt und eine DBCC-Update-Verwendung (0) für die Datenbank ausgeführt. Anschließend hat DBCC CHECKDB keine Fehler mehr in der neu wiederhergestellten Datenbank angezeigt.

Ich habe das gleiche Verfahren auf die Produktionsdatenbank angewendet, aber dies hat das Problem in der Produktionsdatenbank nicht behoben. Ich erhalte die gleichen Fehler wie oben.

Wenn die Reihenfolge ist:

1. DBCC CHECKDB hat Fehler gemeldet.
2. REPAIR_REBUILD hat die Datenbank repariert, es wurden keine Fehler gemeldet.
3. DBCC CHECKDB meldet erneut Fehler.

Wahrscheinlich sind Festplatten in einem Array oder einer anderen Komponente des E / A-Subsystems ausgefallen oder ausgefallen. Persönlich möchte ich den Problemserver so schnell wie möglich ausschalten!

• Erstellen Sie ein Tail-Log-Backup .
• Stellen Sie die letzte bekannte gute vollständige Sicherungs- und Diff / Log-Sequenz auf einem anderen Server wieder her.
• Wechseln Sie den Dienst zum zweiten Server.
• Holen Sie sich eine frische Tasse Kaffee und starten Sie die Diagnose auf dem Problemserver.

Nachtrag: Grundursache des Problems:

Wie sich herausstellte, stellte ich fest, dass wir bei der Verwendung von Diskeeper (aus geschäftlichen Gründen) immer noch eine alte Version verwenden: 14.0.896. Mit dieser Version stoßen wir auf Nachrichten wie:

The operating system returned error 1784(failed to retrieve text for this error. Reason: 15100) to SQL Server during a write at offset 0x000000010a4000 in file 'D:\Application-Data\MSSQL\Data\<Database>.mdf:MSSQL_DBCC17'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Msg 3313, Level 21, State 2, Server <Server>, Line 1
During redoing of a logged operation in database '<Database>', an error occurred at log record ID (2349664:1503:4). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Msg 1823, Level 16, State 1, Server <Server>, Line 1
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 2, Server <Server>, Line 1
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Server <Server>, Line 1
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
Msg 5030, Level 16, State 12, Server <Server>, Line 1
The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Server <Server>, Line 1
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details

Eine Erklärung finden Sie in Paul Randals Blog hier

Link zu DiskKeeper Fix finden Sie hier

Interessantes Diskeeper-Whitepaper zur Datenbankdefragmentierung hier