SQL数据库损坏,数据库数据恢复！

        数据恢复论坛,中国数据恢复联盟！ 原文来自：http://www.intodata.org/read-htm-tid-132.html

 

SQL数据库损坏及恢复分析

SQL数据库在现在的中小型企业中运用是非常多地，但它的损坏也是很常见地，现就SQL数据库损坏的状况、原因及应急方案分析一下。
一． 在还原 数据库和附加数据库时出错 SQL备份有两种方法：一是直接复制MDF和LDF文件，二是利用SQL备份机制创建备份文件，但无论是那种备份都会出现无法附加或无法还原的情况。下面就分析一下出错的原因。
１． 在利用备份出来的数据库文件和日志文件附加时会报“错误：823”和“一致性错误”如图：

这种错误出现的原因有：（１）在数据库读写过程中突然死机或重启，重启后数据库有时会出现“置疑”，这时利用MDF和LDF文件附加时就会出现“一致性错误”，有的会出现“错误： 823”，这种错误出现的原因是在数据库读写过程中，机器突然死机或重启，由于缓冲数据丢失，数据库无法写入正确的数据，那么数据库会写入一些无关的数据，这样就会造成数据库出错。（２）在备份数据库时由于磁盘中有坏道，备份出来的MDF文件不完整时也会出现这种错误，这种情况必须地修复损坏MDF文件中损坏的页，但有时会丢失几条数据！　　　如果出现上面的错误，如果对MDF文件结构不是很清楚的话，请不要对原文件进行胡乱修改，这样会适得其反，会造成更大的损失。
２． 因为SQL备份数据库机制有问题（人个感觉，如果数据非常庞大时，备份出来的文件有时会有问题），当用户利用备份出来的备份文件进行还原数据库，数据库会报“发和内部一致性错误”和无任何提示的错误，其中“发和内部一致性错误”最为常见。如图：


出现这种情况大部分都是备份文件损坏造成地，有部分备份文件备份时一切正常，但还原时就会提示“发和内部一致性错误”，这种错误的修复比较复杂，因为我们不能用任何SQL语句进行修复。如果损坏不是很严重时，我们可以在还原数据时选择“恢复完成状态”中地“使数据库不再运行，但能还原其它事务日志”，这样就可以用命令来修复，常常这种情况用命令修复完后，数据会丢失部分！
二． 附加还原数据库后，检测数据库是出现一致性错误和分配错误,如下面错误：
服务器: 消息 8928，级别 16，状态 6，行 1
对象 ID 0，索引 ID 0: 未能处理页 (1:39)。详细信息请参阅其它错误。
服务器: 消息 2575，级别 16，状态 1，行 1
IAM 页 (0:0)（对象 ID 10，索引 ID 0）的下一页指针指向了 IAM 页 (1:39)，但在扫描过程中未检测到该页。
服务器: 消息 8906，级别 16，状态 1，行 1
扩展盘区 (1:40)（属于数据库 ID 7）在 SGAM (1:3) 和 PFS (1:1) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED   0_PCT_FULL'。
服务器: 消息 8906，级别 16，状态 1，行 1
扩展盘区 (1:38)（属于数据库 ID 7）在 SGAM (1:3) 和 PFS (1:1) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED   0_PCT_FULL'。
服务器: 消息 7965，级别 16，状态 1，行 1
表错误: 由于无效的分配 (IAM) 页，未能检查对象 ID 10，索引 ID 1。
服务器: 消息 8906，级别 16，状态 1，行 1
扩展盘区 (1:39)（属于数据库 ID 7）在 SGAM (1:3) 和 PFS (1:1) 中进行了分配，但未在任何 IAM 中进行过分配。 PFS 标志 'IAM_PG MIXED_EXT ALLOCATED   0_PCT_FULL'。
服务器: 消息 8909，级别 16，状态 1，行 1
表错误: 对象 ID 10，索引 ID 1，页 ID (1:39)。页首结构中的 PageId = (1:0)。
'test' 的 DBCC 结果。
CHECKDB 发现了 1 个分配错误和 0 个一致性错误，这些错误并不与任何单个的对象相关联。
'sysobjects' 的 DBCC 结果。
对象 'sysobjects' 有 55 行，这些行位于 1 页中。
'sysindexes' 的 DBCC 结果。
对象 'sysindexes' 有 34 行，这些行位于 1 页中。
'syscolumns' 的 DBCC 结果。
对象 'syscolumns' 有 359 行，这些行位于 6 页中。
'systypes' 的 DBCC 结果。
对象 'systypes' 有 26 行，这些行位于 1 页中。
'syscomments' 的 DBCC 结果。
对象 'syscomments' 有 127 行，这些行位于 16 页中。
'sysfiles1' 的 DBCC 结果。
对象 'sysfiles1' 有 2 行，这些行位于 1 页中。
'syspermissions' 的 DBCC 结果。
对象 'syspermissions' 有 18 行，这些行位于 1 页中。
'sysusers' 的 DBCC 结果。
对象 'sysusers' 有 0 行，这些行位于 0 页中。
CHECKDB 发现了 4 个分配错误和 2 个一致性错误（在表 'sysusers' 中，该表的对象 ID 为 10）。
'sysproperties' 的 DBCC 结果。
对象 'sysproperties' 有 0 行，这些行位于 0 页中。
'sysdepends' 的 DBCC 结果。
对象 'sysdepends' 有 309 行，这些行位于 1 页中。
'sysreferences' 的 DBCC 结果。
对象 'sysreferences' 有 0 行，这些行位于 0 页中。
'sysfulltextcatalogs' 的 DBCC 结果。
对象 'sysfulltextcatalogs' 有 0 行，这些行位于 0 页中。
'sysfulltextnotify' 的 DBCC 结果。
对象 'sysfulltextnotify' 有 0 行，这些行位于 0 页中。
'sysfilegroups' 的 DBCC 结果。
对象 'sysfilegroups' 有 1 行，这些行位于 1 页中。
'mytest' 的 DBCC 结果。
对象 'mytest' 有 2 行，这些行位于 1 页中。
'dtproperties' 的 DBCC 结果。
对象 'dtproperties' 有 0 行，这些行位于 0 页中。
CHECKDB 发现了 5 个分配错误和 2 个一致性错误（在数据库 'test' 中）。
repair_allow_data_loss 是最低的修复级别（对于由 DBCC CHECKDB (test ) 发现的错误而言）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
引起这种错误一般是因为数据库某个页被改写或清０了，所以会发生一致性错误和分配错误，
三． 最为常见的“未能读取并闩锁页 (1:4234)（用闩锁类型 SH）”
        在检测数据库，会常见到下面的错误： “服务器: 消息 8966，级别 16，状态 1，行 1 未能读取并闩锁页 (1:4234)（用闩锁类型 SH）。sysobjects 失败”。这种“未能读取并闩锁页 (1:4234)（用闩锁类型 SH）”错误常常会出现在系统表中：sysobjects、sysindexes、syscolumns等中，这种错误出现的原因是因为系统表被破坏，这种错误是很麻烦地，因为SQL的效验比较严密，只要稍改一个关键字节，都出报这个错误，但有时可以导出部分数据。
四． 误删除或误格式化后SQL数据库的恢复在很多情况下，用户会误删除或误格式化掉SQL数据库，出现这种情况后用户会用市面上软件FinalData和EasyRecovery来恢复数据库，虽然用这些数据库软件可以恢复出MDF和LDF文件来，但１００％都会无法附加地（除非数据库不使用），即使附加成功，但错误会很多，数据库也无法使用，因为数据库在日常中经常增加和删除记录，这样就会出数据库文件存储不连续的情况，而市面上的软件都是连续取数据，所以会造成数据库无法附加。出现这种错误时，用户应尽量不要使用本计算机，更不要安装软件和写任何数据。由于市面上的软件还没有完全智能地恢复数据库，所以只能 手工恢复这种误删除的数据，这样就必须了解SQL数据库文件的结构。

    [申明]转载 http://blog.bioon.com/user1/6353/archives/2007/148515.shtml