本文章来介绍SQL Server数据库崩溃后的恢复方法，有需要的朋友可参考。
首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如
这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。
如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气馁，还是有别的方案
的。
我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据
库处于此状态。
不过系统表是不能随便改的，设置一下先
| 代码如下 | 复制代码 |
| Use Master Go sp_configure 'allow updates', 1 reconfigure with override Go 然后 update sysdatabases set status = 32768 where name = '' |
|
现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的
日志。如果没有报告什么错误，现在就可以松一口气了。
虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损
坏。
先把SQL Server 重新启动一下，然后检查你的数据库吧。
先设置成单用户模式，然后做
| 代码如下 | 复制代码 |
| dbcc sp_dboption '', 'single user', 'true' DBCC CHECKDB('') |
|
如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。update sysdatabases
| 代码如下 | 复制代码 |
| set status = 28 where name = '' ，当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用 sp_resetstatus go sp_configure 'allow updates', 0 reconfigure with override Go |
|
checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得REPAIR_ALLOW_DATA_LOSS，完成所有修复。
chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解
决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。
