Sql server的灾难性恢复

butter7372

　　如果需要你维护或者管理的sql server挂掉了，确实是一场灾难。
　　到目前为止，我是历经数劫，总算都能全身而退----付出的代价是下决心上班前的晚上不要喝酒。
　　如今总结一下，借larry的服务器储存，以备察看。
　　灾难一：
　　如果你嫌硬盘空间不够大(SCIS的一般也不会大到哪里去，也很少客户作RAID或者架DFS)。而你一时心血来潮，发现问题就是Log文件在生事，一气之下，直接将它删掉了---惨了，你制造了一起灾难。
　　这时候你的数据库重新打开时，肯定处于置疑状态，面对只有一个mdf文件，这时候你通过附加等方式是不能成功修复的。那么请尝试如下方法：
　　备份数据文件,然后按下面的步骤处理:
　　1.新建一个同名的数据库(数据文件与原来的要一致)
　　2.再停掉sql server(注意不要分离数据库)
　　3.用原数据库的数据文件覆盖掉这个新建的数据库
　　4.再重启sql server
　　5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
　　6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
　　数据库的脚本创建一个新的数据库,并将数据导进去就行了.
　　USE MASTER
　　GO
　　SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
　　GO
　　UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
　　Go
　　sp_dboption '置疑的数据库名', 'single user', 'true'
　　Go
　　DBCC CHECKDB('置疑的数据库名')
　　Go
　　update sysdatabases set status =28 where name='置疑的数据库名'
　　Go
　　sp_configure 'allow updates', 0 reconfigure with override
　　Go
　　sp_dboption '置疑的数据库名', 'single user', 'false'
　　Go
　　附：正确的删除日志文件的办法是要先分离数据库，然后你就可以直接删除日志文件后，通过附加mdf文件来恢复，从而产生新的日志文件。建议不要在设计数据库的时候限制日志文件的大小，否则很难面对其他灾难性恢复。
　　灾难二：
　　如果你将数据库中的某个很重要的表误删了，并且里面有很多数据。而你在删除之前没有备份----对于不熟悉的人来说，也是一场灾难。
　　别着急。比如，你的数据库建立于2003-10-1，如果一直没有对该数据库用备份文件恢复过，则不需要任何其他条件即可寻找到丢失的数据，如果你在2003-12-1日用备份文件恢复过该数据库，则只要求你具备一个2003-12-1日后任何一个完整备份文件。
　　1.对该数据库作一个专门的日志备份
　　backup log dbName to disk='fileName'
　　2.恢复一个之前的完整备份文件（如果数据库没有动过，则不需要这一步骤）
　　restore database dbName from disk='fileName' with norecovery
　　3.恢复最后一个日志备份即刚做的日志备份，指定恢复时间点到误操作之前的时刻
　　restore log dbName from disk='fileName'
　　with stopat='date_time'
　　灾难三：
　　我们对灾难二多一个架设，架设你对数据库用备份文件恢复过，又不具备一个完整备份文件----可能这个灾难不管怎样都会留下一些遗憾。
　　这时候，我所采用的是只能借助第三方工具（也许sql下一版本会提供，但是一般ms不会把生意作绝的）。利用第三方工具LogExplorer来找到drop那个table的日志纪录，会自动产生create table 和insert values的.sql语句，事实证明，还是会存在一些遗憾，比如对于大的二进制对象，很多会被截断，造成一部分资料不能完整复员。
　　灾难四：
　　如果你的数据库服务器爆炸了---这才是真正的灾难。
　　别着急，赶快寻找爆炸后的硬盘碎片，找一片比较锋利的，朝脖子上一抹就解决问题了。
　　备注：往往删除文件后，可能我们会通过一些辅助工具修复硬盘上丢失的数据，但是对于上G的文件，应该成功恢复的可能性很小吧。