此文章主要介绍的是SQL Server 数据库出现崩溃的情况的恢复方案，在实际操作中可以说任何的数据库系统出现崩溃状况都是正常的，即便你使用了Clustered，双机热备……仍然无法完全根除系统中的单点故障，何况对于大部分用户来说，无法承受这样昂贵的硬件投资。
所以，在系统崩溃的时候，如何恢复原有的宝贵数据就成为一个极其重要的问题了。
在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。
不幸的是，一般SQL Server 数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。
首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。
我们可以试着重新建立一个Log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示SQL Server 数据库处于此状态。
不过系统表是不能随便改的，设置一下先Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo然后 update sysdatabases set status = 32768 where name = '' 现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。假如没有报告什么错误，现在就可以松一口气了。
虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏：
先把SQL Server 重新启动一下，然后检查你的数据库吧；
先设置成单用户模式，然后做dbcc sp_dboption '', 'single user', 'true'DBCC CHECKDB('')；
假如没有什么大问题就可以把SQL Server 数据库状态改回去了，记得别忘了把系统表的修改选项关掉。update sysdatabases set status = 28 where name = '' ，当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用：
sp_resetstatusgosp_configure 'allow updates', 0reconfigure with overrideGo
checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了；checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得REPAIR_ALLOW_DATA_LOSS，完成所有修复；chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解决问题了，假如还报告错误，试着把数据select into到另一张表检查一下。
这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。可以从DBCC DBREINDEX得到帮助。
以上的相关内容就是对SQL Server 数据库崩溃后的恢复之法的介绍，望你能有所收获。
上述的相关内容就是对SQL Server 数据库崩溃后的恢复之法的描述，希望会给你带来一些帮助在此方面。