Sqlserver的数据恢复案例

wooloov · 发表于 2008-6-4 12:59:39

作为企业级应用，Sqlserver对[wiki]存储[/wiki]硬件的要求极高。一般的ATA[wiki]硬盘[/wiki]没有提供静止系统使用硬盘[wiki]缓存[/wiki]的指令，所以不能在企业级应用中使用。必须采用[wiki]SCSI[/wiki]或FC硬盘，要求更高的系统应该采用智能存储阵列。

当然了，还有很多中小客户根本没有意识到存储对数据库应用的重要性，随便把重要的数据库安装在ATA硬盘上，根本也没有什么断电保护的安全措施。运气好的，数据库能用个三年5载，也没什么故障；运气不好的，简单的一个意外断电，就可能使整个数据库崩溃，数据完整性被破坏，甚至数据文件损坏。。。这时候，就只有祈祷高手的出现了。。。

数据库文件损害问题比较严重。一般的数据库管理人员可能会处理数据库内部逻辑错误造成的数据库打不开，或者一些软件也能修复这些错误；但是如果文件本身损害，系统根本就无法attach上这个数据库，这时候再厉害的数据库高手也英雄无用武之地了。

我们有一个案例，客户的重要数据存放在Sqlserver中，但平时也没有注意备份。一次意外断电，数据文件被损害。重新启动系统时，告知数据库无法打开，请检查是否是有效文件。

面对这样的问题，一般的解决方法是：
1. 新建一个数据库
2. 用需要修复的数据库文件替代新建的数据库文件
3. 重新启动数据库，这时候再对数据库进行处理。。。（略）

以上的解决办法前提是SqlServer还能认出这是个数据库文件，如果由于硬件错误造成数据库文件本身的数据结构变化，SqlServer将拒绝承认这是个合法的数据库文件，因此也无法attach，更谈不上进一步的逻辑修复了。
SqlServer的每一个页面大小为8K，每个页面都顺序编号，这个编号称为page id。如果某个page id错误，SqlServer就会报告823错误，系统无法attach这个数据库。
其实解决办法说难也不难，用一个diskscan的工具，找到文件出错页面的第一个sector，把前两位重置为合法的page id就可以了。
这时候再重新attach数据库，数据库就可以被attach上了。当然这时候会报其它的逻辑错误。但逻辑错误相对就很好处理了，运行dbcc check就能解决掉大部分的问题。
如果损坏的8k页面没有什么重要数据，这时候恢复的数据库就能正常运行了。如果不行，可能还需要手工恢复一些交易信息。

最后强烈建议为了客户的数据安全，一定要做好数据备份。上述错误如果提交给微软，微软会告诉你无法解决，惟一的办法就是利用以前的备份进行恢复。