数据库管理员最大的梦魇，莫过于已经做了备份，但是在想恢复的时候，发现备份文件也是坏的。这将意味着数据库的丢失，后果非常可怕。发生这种情况的原因一般有3个： · 备份文件和数据库放在同一个(或一组)物理硬盘上。硬盘出故障，备份也保不
数据库管理员最大的梦魇，莫过于已经做了备份，但是在想恢复的时候，发现备份文件也是坏的。这将意味着数据库的丢失，后果非常可怕。发生这种情况的原因一般有3个：
· 备份文件和数据库放在同一个(或一组)物理硬盘上。硬盘出故障，备份也保不住。
· 备份介质损坏；或者做的是网络备份，数据在网络传输中发生了损坏。
· 数据库在做完整备份、文件备份或者文件组备份的时候，里面的内容就已经有了损坏。
SQL Server在做数据备份的时候为了节省时间，基本只是很简单地把数据页面拷贝下来，不会做一致性检查的。但是在恢复的时候，需要将数据库恢复(Recover)到事务一致的一个时间点。如果备份中的损坏妨碍了SQL Server的前滚后滚(Redo和Undo)，恢复动作就会遇到错误。
无论何种情况，您都可以：
· 修复硬件错误并重新尝试还原操作。
· 忽略错误，继续还原操作，并在还原完成后修复数据库。
· 放弃还原操作，改用备用还原计划。
在现实环境里，能够通过重试解决的问题还是比较少的。硬件错误往往会永久地损坏备份文件里的内容。在先前的SQLServer版本里，管理员可能不得不尝试去寻找更早的备份。这往往意味着有很多天的数据丢失，损失是比较大的。
SQL Server 数据库恢复有一个“忽略错误”的功能，在这种为难的时刻可以发挥很大的作用。
忽略错误继续执行操作
CONTINUE_AFTER_ERROR是恢复命令(RESTORE)里面的一个选项。它将使还原操作跳过错误继续进行，并还原SQL Server现在所能还原的所有内容。数据还原结束后，可以应用后续事务日志备份，将数据库恢复。如果日志恢复时遇到错误，SQLServer会在日志中报告，并且不让用户访问和这些事务有关的页面。数据库将在尽可能的情况下联机。所以大部分情况下，数据库整体还是能恢复出来，只是部分数据有可能会丢失。
数据丢失量取决于遇到的错误。例如，一般数据页中的错误只会引起该页进入可疑状态，但数据库恢复还会继续。有问题的页面编号将被写入磁盘并记录到suspect_pages表和错误日志中，提醒管理员在恢复结束后继续处理它们。如果不设置CONTINUE_AFTER_ERROR，SQL Server只要遇到一个页面有问题，整个恢复动作都会停止。
如果错误发生在一些比较关键的地方，比如某个数据文件的文件头信息，那么恢复还是有可能完全失败，数据库无法恢复。所以这个方法只供救急之用。不能保证每次使用的效果。使用WITHCONTINUE_AFTER_ERROR还原数据后，要检查错误日志以了解有关错误的详细信息。
基本的RESTORE语法为：
RESTORE DATABASE database_name
FROM backup_deviceWITH CONTINUE_AFTER_ERROR,
[NORECOVERY ]
管理员可以在忽略错误继续执行的还原顺序结束时，使用DBCCCHECKDB修复数据库。要使CHECKDB在使用RESTORECONTINUE_AFTER_ERROR后以最大的一致性运行，建议在DBCC CHECKDB命令中使用WITH TABLOCK选项。在极个别情况下，可能没有足够的信息来修复数据库，CHECKDB也没办法修好数据库，数据丢失将不可避免。不是说，有了RESTORE CONTINUE_AFTER_ERROR，备份坏掉也没关系的。
建立备用(Standby)服务器
CONTINUE_AFTER_ERROR只不过是命令SQLServer跳过一切它能够跳过的错误，将所有还能读出来的数据恢复出来，从而最大程度地挽回数据。但是有些对数据一致性要求比较高的系统，比如银行账户系统，用户可不接受“部分”数据恢复。对他们来讲，数据不一致可能就意味着钱已经从一个账户转走，但是没有进入另一个账户，这是不可接受的。所以他们宁可将数据库恢复到昨天的状态，把今天所有的操作重做一遍。
对于这样的系统，在建立备份和选择恢复策略的时候，就要考虑到最坏的情况，预先想好方案，将损失降到最低。
事先预备一台备用机，将做好的备份使用LogShipping或者其他类似的机制在备用服务器上预先恢复好，是一个值得推荐的方法。这样做的好处有：
(1)比起物理镜像之类的技术，这种方案比较经济。备用服务器的硬件要求不高，只要硬盘足够大。
(2)虽然SQL Server提供了若干备份校验机制，但是确保备份完整可靠的唯一办法是真正地去恢复它。
(3)提前恢复备份，使得在真正灾难发生时，只需要恢复最后一个日志备份即可，而不需要在火烧眉毛的时候，去等那个漫长的完整备份恢复，可以大大节约灾难恢复时间。
(4)备用机上的数据库虽然不能修改，但是可以使用STANDBY参数将数据库恢复到只读模式。可以将一些报表查询工作转移到备用机上，减轻生产服务器的负担。
总之，数据安全非常重要，灾难恢复时间要求很短的数据库，如果没有镜像技术的保障，备用服务器是非常必要的。
本条技术文章来源于互联网，如果无意侵犯您的权益请点击此处反馈版权投诉
本文系统来源：php中文网