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

　　近日，用户打电话请求技术支持，说素材采集数据库连接不上，笔者在网管控制台启动应用程序，发现确实如此，如图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了。因为文件很大，执行开始以后，笔者就离开机房回到座位上，耐心等待数据库附加完成。不过，最不愿意看到的事情发生了，数据库文件损坏，不是有效的数据库文件头，可以确认这是灾难性的！还好，想到还有完整的数据备份机制，至少可以把损失降低到最低程度吧。

图2 还原数据库

　　拿出以前制定的备份策略看了一下，CMS数据库的备份是这样的：星期日、三凌晨2：00执行数据库完整备份，同时备份事务日志，星期一、二、四、五、六凌晨2：00执行数据库差异备份，同时备份事务日志。MASTER的数据库备份是在每天的1：00执行完全备份，每个星期的每一天都单独保留相应的备份。如果要将CMS数据库还原到星期二下午16：00时的状态，根据备份方案要执行如下操作：还原在星期日凌晨2：00创建的数据库完整备份，还原在星期二凌晨 2:00 创建的差异数据库备份。但是最后一次差异备份后数据库修改的数据怎么办？每天的数据量可是接近万条啊，不会需要手工重新输入吧。

　　现在也不知道MASTER数据库是否完整。根据状况分析，有可能MSATER数据库也有故障。先恢复今天凌晨1：00备份的MASTER数据库。打开企业管理器，选择数据库，右键所有任务，选择还原数据库。

　　选择数据库名为：master，从备份设备上恢复，选择master_back.bak数据库备份，选择数据库完全还原备份集合，然后点击确定。哦，怎么出错了？原来，笔者忙中出错：数据库上要强行恢复正在运行的MASTER数据库，这怎么行呢？正确的步骤应该是首先要进入单用户模式，然后才能恢复MASTER数据库。进入管理工具的服务管理器，找到SQL Server服务，停止该服务。

　　小提示：要以单用户方式启动数据库，必须在启动参数中输入-CM，重新启动数据库就以单用户方式启动了。

　　重新进入还原MASTER数据库窗口，选择备份文件，确定即可。至此，已经成功还原了MASTER数据库，同时又自动关闭了SQL Server服务。为了避免因为操作失误或者其它的原因导致恢复出现错误，决定先在自己的机器上模拟一下恢复过程。

　　于是，在自己的PC上，创建一个数据库test，只建立了一个表qq，输入5条数据，然后完整备份这个test数据库，因为是完整备份而且是第一次，所以选择“追加到媒体”或者“重写现有媒体”均可。这个完全备份相当于星期日凌晨2：00的完全备份。再给test数据库插入5条数据。现在给这个数据库做一次差异备份，这个差异备份的目的相当于星期一凌晨2：00的差异备份。

　　打开test数据库，进入备份数据库窗口，选取刚建立的备份设备，选择差异备份，注意，选择“追加到媒体”。同样的操作再给数据库插入5条纪录，完成星期二凌晨的差异备份。

　　然后是最重要的，现在数据库中有15条纪录，我再加入10纪录，这10条纪录就是我做完差异备份以后没有进行备份的数据，也就是我要恢复的关键数据。我们现在看一下，数据库的记录情况：新加的10条数据就是新增加的，也是要恢复的。到现在为止，已经全部仿真我们的备份状况。按照正常的恢复办法只能恢复15条数据，那最后增加的数据也就是今天的上万条数据就不能恢复了。到底该怎么办呢？

　　无奈之中，只好求助于好友，好友告诉我，这个情况是可以恢复的，不过要两个前提条件：第一个条件是数据库的还原模型是完全模式。笔者这边的数据库还原模式是完全模式，这个没有问题。第二个条件，事务日志是完好的。在查询分析器中打开MASTER，执行“BACKUP LOG test to test_data_backup”，如果执行成功代表log日志正常。马上进行了测试，没有问题，看来问题可以解决。笔者查询了一下日志的资料：

　　执行 BACKUP LOG 语句以备份当前活动的事务日志，同时指定：要备份的事务日志所属的数据库名称。事务日志备份将写入的备份设备。NO_TRUNCATE 子句，通过它备份事务日志而不截断该事务日志的非活动部分。只要事务日志文件是可访问的并且没有损坏，那么即使数据库不可访问，此子句也允许备份事务日志的活动部分。

　　知道了，现在的状况是数据库损坏但是log文件还是好的，而且现在要做的话，肯定要加上NO_TRUNCATE测试一下。停止SQL Server服务，删掉test数据库，重新刷新企业管理器，看到的test数据库的状态也是“置疑”。在查询分析器中，进入到MASTER数据库，敲入脚本命令“BACKUP LOG test to test_data_backup with NO_TRUNCATE”。

　　结果处理成功。也就是说在数据库损坏或者遗失的情况下，日志文件是可以手工恢复的。

　　小提示：为了您的安全请分开指定数据库文件和日志文件的存放位置。

　　进入到数据库还原窗口，可以看到备份设备集合中出现了刚才建立的两个log事务日志。

　　点击确定，数据库开始还原备份以及事务日志，还原完成后。打开数据库，数据已经恢复成功，看来素材数据库恢复也是有希望的。

　　小提示：首先察看故障还原模型一定要是“完全的”，其二，察看LOG日志文件是否受损，其三，恢复日志文件，其四，恢复数据库。

　　按照这个思路，来到服务器上，先把数据库文件和日志文件作了一次备份，然后按照过程进行操作。OK，成功！停掉临时服务器，把临时数据导入到CMS服务器上，重建索引，至此数据恢复成功。

　　小提示：如果没有确认故障的原因，不要在服务器上作任何系统级别的操作。想办法模拟环境，在类似的状态下操作，保证数据的安全性。