SQL Server 2005 数据库损坏。建议

Question

我过去遇到过一些数据库损坏，但我知道哪个对象已经上路了。在这种情况下，我针对有问题的 SQL Server 2005 数据库运行 DBCC CHECKDB 并收到以下错误

    Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:2388) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:8807) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
Msg 8929, Level 16, State 1, Line 1
Object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID 281474980642816 (type In-row data): Errors found in off-row data with ID 1454243840 owned by data record identified by RID = (1:728:2)
Msg 8928, Level 16, State 1, Line 1
Object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID 71776119065149440 (type LOB data): Page (1:2388) could not be processed.  See other errors for details.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID 71776119065149440 (type LOB data). The off-row data node at page (1:2388), slot 0, text ID 1454243840 is referenced by page (1:728), slot 2, but was not seen in the scan.
CHECKDB found 0 allocation errors and 3 consistency errors in table 'sys.sysobjvalues' (object ID 60).
Msg 8928, Level 16, State 1, Line 1
Object ID 393768460, index ID 1, partition ID 72057594063421440, alloc unit ID 72057594069647360 (type In-row data): Page (1:8807) could not be processed.  See other errors for details.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 393768460, index ID 1, partition ID 72057594063421440, alloc unit ID 72057594069647360 (type In-row data). Page (1:8807) was not seen in the scan although its parent (1:2862) and previous (1:8806) refer to it. Check any previous errors.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 393768460, index ID 1, partition ID 72057594063421440, alloc unit ID 72057594069647360 (type In-row data). Page (1:10128) is missing a reference from previous page (1:8807). Possible chain linkage problem.
CHECKDB found 0 allocation errors and 3 consistency errors in table 'reservation_packages' (object ID 393768460).
Msg 8928, Level 16, State 1, Line 1
Object ID 1513772450, index ID 0, partition ID 72057594064994304, alloc unit ID 72057594071285760 (type In-row data): Page (1:5211) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 1513772450, index ID 0, partition ID 72057594064994304, alloc unit ID 72057594071285760 (type In-row data), page (1:5211). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 63047689 and -4.
CHECKDB found 0 allocation errors and 2 consistency errors in table 'reservation_services_log' (object ID 1513772450).
CHECKDB found 0 allocation errors and 10 consistency errors in database 'ChJ'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (ChJ).

对象 ID 0?? 索引 ID -1 ?? 分区 ID 0?? 我无法从中看出任何东西

数据库处于简单恢复模式（不幸的是），我有一个月的备份。

我必须让它运行，因为它包含重要数据。

我很感激你能给我的任何帮助。

提前谢谢！

EDIT1：不幸的是，Red Gate 的数据比较在扫描表时无法注册数据库... :(

Answer 1

由于您有一个具有正确架构的旧备份，问题数据库在线并且您已成功查询了多个表，因此我倾向于尝试尽快获取原始数据的转储。

1. 关闭访问数据库的应用程序。
2. BCP 将数据逐表导出到文件。由于磁盘损坏可能是您问题的根源，请将数据导出到便携式驱动器或另一台机器上的文件共享。
3. 将旧备份还原到已知良好的服务器。
4. 根据数据库架构的复杂性，可以从恢复的备份中截断数据，或者编写架构脚本并创建一个新的空数据库。
5. BCP 将数据重新输入。

数据可能包含不准确之处，可能缺少行或包含虚假值。但如果运气好的话，你最终会得到比一个月前的备份更多的东西。

Answer 2

1. 不要使数据库脱机。也不要关闭服务器。两者都可能导致数据库完全无法访问。

2. 进行完整的“仅复制”备份。

3. 尝试使用Red-Gate datacompare读取备份文件

4. 将此查询与 checkdb 输出中的 Allocation_unit_id 值结合使用：

   SELECT o.name,p.index_id,p.partition_number FROM sys.allocation_units a JOIN sys.system_internals_partitions p ON a.container_id = p.partition_id JOIN sys.all_objects o ON p.object_id = o.object_id WHERE a.allocation_unit_id = '281474977103872 '

它应该显示受影响的对象名称。

1. 使用不同的名称恢复数据库（可能会失败）

2. 在恢复时使用修复选项“REPAIR_REBUILD”运行 checkdb。如果恢复失败，请使用原始版本。

3. 如果到目前为止没有任何效果，请使用 DBCC CHECKDB 的“REPAIR_ALLOW_DATA_LOSS”选项。

4. 如果这也不起作用，请聘请一位在腐败追回领域有经验的顾问（例如我）