恢复SQL数据库详细攻略实例(1)

近日，用户打电话请求技术支持，说素材采集数据库连接不上，笔者在网管控制台启动应用程序，发现确实如此，如图1。
笔者进行了简单的测试：ping数据库服务器没有问题，证明网络连接没有问题。ODBC连接也可以连接到数据库服务器的MASTER数据库，证明客户端没有问题。问题应该出在CMS应用数据库上。
直到现在笔者还没有认识到问题的严重性，打开企业管理器，察看CMS数据库的状态，竟然是“置疑”！

 
图1 错误信息

出现“置疑”状态有几种可能：
1、数据库文件或者相关的日志文件丢失；
2、数据库所在的路径发生变化；
3、磁盘可用空间不足；
4、SQL Server可能没有足够的时间来恢复数据库；
5、数据库在数据写入的过程中数据页因为停电或者内存泄漏等操作被损坏。
为了查看故障情况，首先，重新启动了数据库服务器，察看SQL Server服务管理器中的SQL Server的运作状况，发现其运行正常，说明SQL Server服务是正常的。打开企业管理器，故障情况依旧。
首先向部门领导报告了故障发生的情况，请示以后紧急启用了一台临时服务器。
根据故障的状况和“置疑”发生的可能性，笔者逐一进行了排查。文件路径没有改变，文件也没有丢失，磁盘空间还有30GB，没有进行数据库恢复操作，那就只有最后一种可能了。问一下同事数据中心是否停过电，回答是没有。仔细问了一下，有没有异常发生，这时候有个同事说刚才在调试KVM的时候不小心把电源线给拔下来，由于没有认识到是连接的服务器，连续接插了几次，啊！这可是资料存储的Server啊！不过还好，数据库文件、日志文件还在，可以使用数据库附加到服务器。打开查询分析器输入以下脚本命令：
EXEC sp_attach_db @dbname = N'cms',
@filename1 = N'd:\Data\cms.mdf',
@filename2 = N'e:\Data\cms_log.ldf'
如果数据库文件没有问题，这样的话就应该OK了。因为文件很大，执行开始以后，笔者就离开机房回到座位上，耐心等待数据库附加完成。不过，最不愿意看到的事情发生了，数据库文件损坏，不是有效的数据库文件头，可以确认这是灾难性的！还好，想到还有完整的数据备份机制，至少可以把损失降低到最低程度吧。