SQLServer灾难恢复<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

故障情况：

现在时间是星期二下午16：00，用户打电话请求技术支持，说素材采集数据库连接不上，小管在网管控制台启动应用程序，发现确实如此。如图1。

呵呵，这样的以前经常出现阿，很简单，告诉用户等5分钟。然后小管进行了简单的测试：Ping数据库服务器没有问题，证明网络连接没有问题。ODBC连接也可以连接到数据库服务器的MASTER数据库，证明客户端没有问题。问题出在CMS应用数据库上。

现在小管还没有认识到问题的严重性，哼着歌来到数据库服务器上，打开企业管理器，察看CMS数据库的状态，竟然是“置疑”，开什么玩笑，出现“置疑”状态有几种可能：

1、数据库文件或者相关的日志文件丢失；

2、数据库所在的路径发生变化；

3、磁盘可用空间不足；

4、SQLSERVER可能没有足够的时间来恢复数据库；

5、数据库中在数据写入的过程中数据页因为停电或者内存泄漏等操作被损坏。如图2

 

首先，小管重新启动了数据库服务器，察看SQLSERVER服务管理器中的SQLSERVER的运作状况，正常。说明：SQLSERVER服务是正常的。

打开企业管理器，故障情况依旧。

现在时间是16：20。首先向部门领导报告了故障发生的情况，请示以后紧急启用了一台临时服务器。嘿嘿，做方案的时候就考虑到了，万一发生数据库灾难或者服务器损坏的状况，应急使用的一台低端服务器，2年没有使用终于派上用场了。客户端全部使用的是Windows 2000，使用信使服务向所有在线的用户发了一个通知：素材数据库因为故障，数据库的查询功能暂时不可用，其它正常。

现在时间是16：30。根据故障的状况和“置疑”发生的可能性，小管逐一进行了排查。文件路径没有改变，文件也没有丢失，磁盘空间还有<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />30G，没有进行数据库恢复操作，那就只有最后一种可能了。问一下同事：数据中心停电没有，反正自己的办公室没有停电，回答说没有啊。哦，这就很奇怪了！小管的额头开始有汗珠了，事情有点麻烦，现在可是数据处理的高峰时段，而且素材数据库有1000万条的数据啊，每天的数据入库量高达上万条。仔细问了一下，有没有异常发生，这时候有个同事说刚才在调试KVM的时候不小心把电源线给拔下来，由于没有认识到是连接的服务器，连续接插了几次，我晕！！这可是资料存储的SERVER啊！！如图3

 

还好，数据库文件、日志文件还在，可以使用数据库附加到服务器。打开查询分析器输入以下脚本命令：

如果数据库文件没有问题，这样的话就应该OK了。在数据库规划的时候，把数据库文件和日志文件分开存储，防止磁盘发生错误造成2个文件同时损坏。如图4

因为文件很大，执行开始以后，小管就离开机房回到座位上，耐心等待数据库附加完成。

现在时间是16：40。回到机房，上帝啊，最不愿意看到的事情发生了，数据库文件损坏，不是有效的数据库文件头，可以确认这是灾难性的！小管的汗已经流了下来，还好，想到还有完整的数据备份机制，不怎么要紧，至少可以把损失降低到最低程度吧，心中还有一丝庆幸。

现在时间是16：50。向领导报告了处理经过和可能的后果：今天的素材入可能丢失，可以尽最大努力恢复一下是否能够成功恢复今天的数据。怎么大老板也来了，他没有事情从来不到我们这儿！唉，看来事情比预料的要严重得多。

现在时间是17：00。到下班的时间了，今天是别想回家了，弄不好要通宵呢？小管拿出以前制定的备份策略看了一下，CMS数据库的备份是这样的：星期日、三凌晨2：00执行数据库完整备份同时备份事务日志，星期一、二、四、五、六凌晨2：00执行数据库差异备份，同时备份事务日志。MASTER的数据库备份是在每天的1：00执行完全备份，每个星期的每一天都单独保留相应得备份。

如果要将CMS数据库还原到星期二下午16：00时的状态，根据备份方案要这样：还原在星期日凌晨2：00创建的数据库完整备份，还原在星期二凌晨 2:00 创建的差异数据库备份。但是最后一次差异备份后数据库修改的数据怎么办？每天的数据量可是接近万条啊，不会需要手工重新输入吧。

现在也不知道MASTER数据库是否完整。根据状况分析，有可能MSATER数据库也可能有故障。先恢复今天凌晨1：00备份的MASTER数据库。

打开企业管理器，选择数据库右键所有任务选择还原数据库，如图5

。

 

机械操作过程小管很熟悉的，选择数据库名为：master，从备份设备上恢复，选择master_back.bak数据库备份，选择数据库完全还原备份集合，如图6

 

点击确定即可。哦，怎么出错了？原来，小管忙中出错：在正在运行的数据库上要强行恢复正在运行的MASTER数据库，这怎么行呢？如图7

 

首先要进入单用户模式，然后才能恢复MASTER数据库。进入管理工具的服务管理器，找到MSSQLSERVER服务，停止。如图8

小管提示：要以单用户方式启动数据库，必须在启动参数中输入-C–M，重新启动数据库就医单用户方式启动了。如图9

 

重新进入还原MASTER数据库窗口，选择备份文件，确定即可。如图10

 

哦，怎么又弹出一个错误窗口，呵呵，这个错误不要紧，是告诉你，已经成功还原了MASTER数据库，同时又自动关闭了MSSQLSERVER服务，如果要使用SQLSERVER要重新启动该服务。如图11

 

现在是17：20，已经成功恢复了MASTER数据库。下一步，就是要恢复CMS数据库了。领导在那边催大家吃饭了，吃完饭以后再说。吃饭是小问题，关键是大家在一起讨论一下如何能够恢复今天的数据，换换脑子，说不定有别的办法。

17：30-19：00，吃饭，当然主要是讨论的过程，没有什么结果，认为可能性不大，大家以前都没有类似的经历和遇到同样的错误。看来真的很危险了。

现在是19：00，回到数据机房，小管坐下来想了好半天，怎么做才好呢？1、如果现在服务器上直接恢复数据库，在发生问题怎么办？2、如果恢复不成功又引发别的问题怎么办？最好的办法就是在自己的机器上模拟一个环境，通过以后再到SERVER上操作，避免因为操作失误或者其它的原因，增加排故的难度，这是最好的办法。

现在是19：10。在自己的PC上，小管创建了一个数据库，test，只建立了一个表qq，输入5条数据，我们可以看一下是不是只有5条纪录。如图12

 

OK，然后完整备份这个test数据库。展开控制台的层级结构，选中管理下的备份，右键“新建备份设备”：如图13

 

 

 

输入备份设备的名称：如图14

 

 

打开test数据库，进入备份数据库窗口，选取刚建立的备份设备，选择完全备份，因为是完整备份而且是第一次，所以选择“追加到媒体”或者“重写现有媒体”均可。OK备份完成！

这个完全备份的目的相当于星期日凌晨2：00的完全备份。如图15

 

再给test数据库插入5条数据，这样数据库的纪录数量为10条了。再看一下表中是不是有10条纪录了。如图16

 

OK，确实数据已经插入了。现在给这个数据库做一次差异备份，这个差异备份的目的相当于星期一凌晨2：00的差异备份。

打开test数据库，进入备份数据库窗口，选取刚建立的备份设备，选择差异备份，注意：选择“追加到媒体”。OK备份完成！如图17

 

同样的操作在给数据库插入5条纪录，完成星期二凌晨的差异备份。

然后是最重要的，现在数据库中有15条纪录，我在加入10纪录，这10条纪录就是我做完差异备份以后没有进行备份的数据，也就是我要恢复的关键数据。我们现在看一下，数据库的记录情况：框内的数据就是新增加的，也是要恢复的。如图18

 

现在已经是20：30，到现在为止，已经全部仿真我们的备份状况。按照正常的恢复办法只能恢复15条数据，那最后增加的数据也就是今天的上万条数据就可能恢复了。到底该怎么办呢？

打开SQLSERVER联机帮助文件，希望从中得到帮助，但是都没有符合我遇到的这个状况，因为我们的日志备份是晚上进行的，到发生故障时为止，没有经过一次备份。

现在已经是21：30分，找到SQL的QQ群，向兄弟们求助，得到的信息基本上是不可能。大老板的电话到现在已经打了3次了，询问故障的解决状况，没有一丝进展。实在是没有办法了，只好等明天再说。小管离开单位的时候已几经是凌晨2：00了。

现在时间是星期三上午8：00，小管早早来到办公室，打开MSN、QQ看看哥们又没有来的早的，基本上都是9：00上班阿。

现在时间是8：50。有哥们来了，听了我的描述，摇摇头，没有遇到过。这时候一个哥们上来，小管好像看到了一分希望。电话描述以后，告诉我这个情况是可以恢复的，不过要2个前提条件：打开数据库，右键，属性，选择“选项”按钮，看一下你的故障还原模型是什么模式。如果不是完全模式的话，是不可能恢复的。这个设置是默认安装的，如果你没有手工更改的话。这个很简单阿，小管看了一下是“完全”，没有动过。如图19

 

现在时间9：30。第二个条件，事务日志是完好的，如果这个文件发生错误的话，那就没有希望了。在查询分析器中打开MASTER，执行“BACKUP LOG test to test_data_backup”，如果执行成功代表log日志正常。小管马上进行了测试，ok没有问题，看来问题可以解决。如图20

 

这时候小管看了一下时间10：10分，同时又查询了一下日志的资料：

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

知道了，我现在的状况是数据库损坏但是log文件还是好的，而且先在要做的话，肯定要加上NO_TRUNCATE，测试一下。小管停止MSSQLSERVER服务，删掉test数据库，重新刷新企业管理器，看到的test数据库的状态也是“置疑”。如图21

 

在查询分析器中，进入到MASTER数据库，敲入脚本命令“BACKUP LOG test to test_data_backup with NO_TRUNCATE”。如图22

 

处理成功。也就是说在数据库损坏或者遗失的情况下，日志文件是可以手工恢复的。幸亏我的log文件时单独备份的，如果和数据库文件放在一起，说不定也受损了。

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

现在时间10：30。进入到数据库还原窗口，可以看到备份设备集合中出现了刚才建立的2个log事务日志。如图23

 

点击确定，数据库开始还原。如图24

 

开始还原备份以及事务日志，小管这时的心都要跳出来，谢天谢地，没有提示出错信息。如图25

 

看来时没有问题的，小管打开数据库，察看是否数据已经完全恢复。如图26

 

 

现在时间11：00。数据真的已经恢复成功，看来我的素材数据库恢复也是有希望的。

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

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

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