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

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

 

SQL数据库损坏及恢复分析

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

这种错误出现的原因有:(1)在数据库读写过程中突然死机或重启,重启后数据库有时会出现“置疑”,这时利用MDF和LDF文件附加时就会出现“一致性错误”,有的会出现“错误: 823”,这种错误出现的原因是在数据库读写过程中,机器突然死机或重启,由于缓冲数据丢失,数据库无法写入正确的数据,那么数据库会写入一些无关的数据,这样就会造成数据库出错。(2)在备份数据库时由于磁盘中有坏道,备份出来的MDF文件不完整时也会出现这种错误,这种情况必须地修复损坏MDF文件中损坏的页,但有时会丢失几条数据!   如果出现上面的错误,如果对MDF文件结构不是很清楚的话,请不要对原文件进行胡乱修改,这样会适得其反,会造成更大的损失。
2. 因为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 输出了错误信息,请与系统管理员联系。
引起这种错误一般是因为数据库某个页被改写或清0了,所以会发生一致性错误和分配错误,
三. 最为常见的“未能读取并闩锁页 (1:4234)(用闩锁类型 SH)”
        在检测数据库,会常见到下面的错误: “服务器: 消息 8966,级别 16,状态 1,行 1 未能读取并闩锁页 (1:4234)(用闩锁类型 SH)。sysobjects 失败”。这种“未能读取并闩锁页 (1:4234)(用闩锁类型 SH)”错误常常会出现在系统表中:sysobjects、sysindexes、syscolumns等中,这种错误出现的原因是因为系统表被破坏,这种错误是很麻烦地,因为SQL的效验比较严密,只要稍改一个关键字节,都出报这个错误,但有时可以导出部分数据。
四. 误删除或误格式化后SQL数据库的恢复在很多情况下,用户会误删除或误格式化掉SQL数据库,出现这种情况后用户会用市面上软件FinalData和EasyRecovery来恢复数据库,虽然用这些数据库软件可以恢复出MDF和LDF文件来,但100%都会无法附加地(除非数据库不使用),即使附加成功,但错误会很多,数据库也无法使用,因为数据库在日常中经常增加和删除记录,这样就会出数据库文件存储不连续的情况,而市面上的软件都是连续取数据,所以会造成数据库无法附加。出现这种错误时,用户应尽量不要使用本计算机,更不要安装软件和写任何数据。由于市面上的软件还没有完全智能地恢复数据库,所以只能 手工恢复这种误删除的数据,这样就必须了解SQL数据库文件的结构。
    [申明]转载 http://blog.bioon.com/user1/6353/archives/2007/148515.shtml

你可能感兴趣的:(SQL数据库损坏,数据库数据恢复!)