任何数据库系统都无法避免崩溃的状况即使你使用了Clustered双机热备等等仍然无法完全根除系统中的单点故障何况对于大部分用户来说无法承受这样昂贵的硬件投资所以在系统崩溃的时候我们应该如何恢复原有的宝贵数据就成为一个极其重要的问题了
在恢复的时候最理想的情况就是你的数据文件和日志文件都完好无损了这样只需要sp_attach_db把数据文件附加到新的数据库上即可或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行不过一般不推荐这样的做法sp_attach_db比较好虽然麻烦许多
但是呢一般数据库崩溃的时候系统是未必能有时间把未完成的事务和髒页等写入磁盘的这样的情况sp_attach_db就会失败那么寄希望于DBA制定了一个良好的灾难恢复计划吧按照你的恢复计划还原最新的完全备份增量备份或者事务日志备份然后如果你的活动事务日志还能读得出来的话恭喜你!你可以还原到崩溃前的状态
一般的单位都是没有专职的DBA的如果没有可用的备份更可能是最近一次备份的时间过于久远而导致不可接受的数据损失而且你的活动事务日志也处于不可用的状态那就是最麻烦的情况了
不幸的很的是一般数据库崩溃都是由于存储子系统引起的而这样的情况是几乎不可能有可用的日志用于恢复的
那么就只好试一下这些方案了当然是要求至少你的数据文件是存在的要是数据文件日志文件和备份都没有了的话别找我你可以到楼顶上去唱神啊救救我吧
首先你可以试一下sp_attach_single_file_db试着恢复一下你的数据文件虽然能恢复的可能性不大不过假如这个数据库刚好执行了一个checkpoint的话还是有可能成功的
如果你没有好到有摸彩票的手气最重要的数据库没有像你期盼的那样attach上去不要气馁还是有别的方案的
我们可以试着重新建立一个log先把数据库设置为emergency modesysdatabases的status为 就表示数据库处于此状态
不过系统表是不能随便改的设置一下先
Use Master
Go
sp_configure allow updates
reconfigure with override
Go
然后
update sysdatabases set status = where name =
现在祈求满天神佛的保佑吧重新建立一个log文件成功的机会还是相当大的系统一般都会认可你新建立的日志如果没有报告什么错误现在就可以松一口气了
虽然数据是恢复了可是别以为事情就算完成了正在进行的事务肯定是丢失了原来的数据也可能受到一些损坏
先把SQL Server 重新启动一下然后检查你的数据库吧
[] []