修复受损的数据库备份文件
2018-03-04
故障现象
笔者单位的一台Web服务器近来数据存储出现异常，因为后台采用的是SQL Server数据库，之前对其进行过备份，因此决定对数据库进行恢复。
本来数据恢复是简单的事情，运行“RESTORE DATABASE DBNAME FROM='f:databakXXX.bak '”命令，就可以使用备份文件恢复数据库（“DBNAME”表示目标数据库名称，“xxx.bak”表示备份文件的名称），但是，在恢复时系统提 示“RESTORE cound not start database 'DBNAME' ,file ' DBNAME_log'on file 1”，“RESTORE DATABASE is terminating abnormally”，“SQL SERVER detected a logical consistency-Based I/Oerror:incorrect checksum”等警告信息，说明备份文件出现损坏，无法顺利恢复数据。
故障排查
该SQL Server数据库最近只进行了一次备份，如果不能从该受损的备份文件中恢复数据，无疑会对Web服务器的运行造成不利影响。我们知道，当SQL Server在进行数据备份时，只是简单地将数据页面复制下来，一般不会做数据一致性检查，当进行数据恢复时，则需要将数据库恢复到事务一致的某个时间点，如果备份文件中的损坏部分对Redo前滚和Undo后滚造成影响，那么数据恢复就会出现问题。
既然在恢复备份文件时出现故障，那么忽略该错误，让恢复操作继续进行，或许可以完成恢复操作，至少可以得到尽可能多的有效数据。这里使用的是SQL Server 2012，针对这一故障，可以使用其提供的忽略错误功能，来尝试解决上述故障。
在“RESTORE”命令中提供了名为“CONTINUE_AFTER_ERROR”的参数，可以让恢复操作避开错误提示，尝试修复报告中的所有错误，尽可能地还原备份文件中所有内容。当数据还原完成后，可以使用后续的事务日志备份，来恢复数据库。当在恢复日志时出现错误，SQL Server可以在日志中进行记录，禁止用户访问这些和事务相关的页面，让数据库可以尽可能地联机运行。当然，这些修复行为不是万能的，在某些情况下可能丢失部分数据。对于一般的数据来说，当出现错误时，会进入可疑状态，但不会影响到恢复的进程。
对于存在问题的页面，会被记录到相关的表和日志中。如果数据错误出现在备份文件的关键位置（例如文件头等），那么恢复操作将彻底失败，因此该方法无法保证解决所有的恢复失败故障。当数据库还原之后，还需要使用SQL Server提供的DBCC CHECKDB命令，来修复数据库，让其可以真正处于可用状态。使用该命令，可以有效地检测数据库中是否存在损坏情况，当发现有损坏的迹象时，可以尽可能地修复数据库，使用户可以正常访问其中的数据。
在执行该命令时，会检测一些关键的系统表，在每张数据表中都存在聚集索引，通过检测，保证这些表中的所有页面以及其中的数据可以正常读出。该命令会检查目标数据库中所有页面的分配情况，通过检验内部结构，来跟踪这些页面以及之间的关系。同时，检测数据库中的所有表是否正确链接索引，索引是否正常排序，所有指针是否一致，页面上的数据是否合理，页面偏移量是否正确，分区表或索引的每行是否处于正确的分区中。可以检测数据据库中的系统表中记录的元数据的逻辑一致性，验证数据库中所有索引试图的内容，检测数据库中的Service Broker数据等。
排除故障
找到了修复的方法后，执 行“RESTORE DATABASE DBNAMEFROM= 'f:databakXXX.bak ' WITH CONTINUE_AFTER_ERROR”命令，执行恢复操作，系统提示“Restore was successful but defered transactions remain. These transactions cannot be resolved because there are data that is unavailable”，“RESTORE WITH CONTINUE_AFTER_ERROR was successful but some damage was encountered,Inconsi stencies in the database are possible”，“RESTORE DATABASE successfully processes x pages in x seconds”等提示，说明数据库恢复顺利完成。
之后该数据库处于Suspect可疑状态无法直接使用，执行“ALTER CHECKDB DNNAME SET EMERGENCY”命令，将其设置为紧急状态。执行“DBCC CHECKDB(DBNAME)”，“DBCC CHECKED(DBNAME, REPAIR_ALLOW_DATA_LOSS)”命令进行修复处理。
修复完成后，执行“use dbname”，“select * from salestb”等命令，可以正常打开并访问其中的数据表。经过检测，虽然丢失了少量数据，但是绝大部分数据都还在，这对数据库影响不大，至此数据恢复成功完成。
当然，这里的紧急修复操作，只是无奈之举，存在丢失数据甚至失败的风险，因此在日常维护数据库时，需要定期对数据库进行备份和检测，将风险降到最低。因为单位的SQL Server数据库体积不大，所以执行“DBCC CHECKDB”命令消耗的时间不长，但是对于体积庞大的数据库来说，如果存在的问题较多的话，修复起来就会极为耗时，同时，还会引起数据库阻塞。
