• 闪回查询/闪回表

        数据量较小，故障发生时间较近时，Oracle/MySQL可以通过闪回查询的方式获得指定数据的过去版本，直接进行热恢复。耗时较低，操作复杂度不高——可精确查询到某时间点或scn号下该数据的状态，通过sql语句进行update操作，或直接flashback table即可。

• 闪回数据库（Oracle）

        由于闪回查询原理为借助undo表空间查询数据的历史版本，但undo表空间为循环使用的区域，仅根据参数UNDO_RETENTION保障短暂的可靠保存时间（默认900秒）。因此当逻辑故障涉及数据较多（一次删除修改直接导致undo表空间多次覆盖），或发现时间不够及时时， Oracle可通过闪回数据库的方式进行恢复。闪回数据库需要停止数据库实例，并且一旦决定闪回时间点，该时间点之后所有修改均被永久放弃。

     
      【恢复用时：数小时级别】

• MySQL Binlog Flashback（MySQL）

        MySQL Binlog Flashback是MySQL特有工具，由阿里云高级数据库专家彭立勋实现并提交给MariaDB基金会。原理为获取binlog日志并反向生成操作日志进行恢复，如delete生成insert，update生成反向update等。该操作为热恢复，需要DBA严格查出每个误操作的日志号。同时，由于恢复原理为binlog反向操作，因此同样无法恢复DDL操作（如TRUNCATE TABLE）。

     
      【处理用时：数小时级别】

• Log Explorer for SQLServer（SQLServer）

        Log Explorer for SQLServer是针对SQLServer的日志查询和恢复工具，原理与MySQL binlog flashback类似，即通过生成事务的逆向操作脚本进行数据恢复。同样无法恢复DDL操作。

     
      【处理用时：数小时级别】

• 备份恢复

        备份恢复是最传统也是最后的恢复手段。需要调用备份，应用备份，往往耗时最长。此恢复为不完全恢复，即恢复到故障出现前的某时间点。

        备份恢复作为最后的恢复手段，却常常是中小规模企业DBA倾向使用的方法。相比各种日志反向操作工具，备份恢复显得更为可靠，操作复杂度也更低，DBA可以很方便地在非生产环境将数据库恢复出来，再获取想要的数据进行生产环境恢复。

        但对于银行、保险等金融机构，DBA水平更高，对RTO要求更严苛，使用备份恢复往往作为最后的选择。

     
      【处理用时：数小时-数日级别】

• 非宕机临时故障

        网络故障、文件系统空间不足、计算资源不足等。

       
        临时故障往往会导致数据库性能下降甚至实例挂起，直到处理完成或获得足够资源后自动修复。此类故障一般会有明确告警信息，不需要太多DBA经验就足以判断故障原因，解决方案也较明确。但此类故障频繁发生时，往往需要进行资源整改。

     
      【处理用时：数分钟级别】

• 非宕机持续故障

       非系统表空间软坏块、非系统表空间数据文件丢失、归档损坏、其他数据库待优化项等。

       非宕机持续故障往往会造成持续性能降低，或数据完整性缺失，导致前端业务受到影响。此类与临时故障的区别主要在于故障原因。临时故障症结主要来自资源不足，持续故障原因则比较复杂，可能来自文件丢失，文件损坏，不合理的归档日志清理流程，或错误的性能调优行为。

        此类故障需要DBA拥有一定经验进行判断排除，且修复过程各异。一般来说，涉及文件丢失的情况，常常需要调用备份进行恢复，有时需要停止业务进行部分表空间offline的数据库热修复。而涉及调优时，可能需要涉及实例重启。

      【处理用时：数小时-数日级别】

• 宕机故障

        系统表空间软坏块、系统表空间数据文件丢失、在线日志文件丢失，控制文件丢失等。

        宕机故障与非宕机持续故障的成因大部分重合，排查难度和修复方式也类似。如果数据库处于高可用架构中，则单一节点发生宕机故障并不会引起长时间业务问题，前端连接failover到健康节点后，宕机故障可以通过调用备份恢复的方式进行修复。

        但需要注意的是，宕机修复后重新启动的数据库实例，将经历一段性能受限时期，如Oracle重新将热数据块和sql写入缓冲的过程等。

      【处理用时：数小时-数日级别】

• 通信设备故障

        通信设备或通信线路发生故障，表现为网络/存储通信变慢或中断。由于故障现象的可能原因很多，因此排查难度较高。通信故障虽然不会造成数据丢失，但对业务影响往往不小。所有硬件故障都无法由DBA角色单独确认，因此硬件故障往往需要数小时甚至数天时间才能排查清楚。

      【排查用时：数小时级别】

      【修复用时：数小时-数日级别】

• 服务器故障

        计算节点出现硬件故障，一般会伴随服务器宕机。该故障可通过高可用架构规避，一般不会造成服务长时间中断。但非常考验监控系统的完备性。最后一个健康节点宕机后，才发现数据库之前长期处于单点运行，是中小型公司中经常出现的状况。

• 储存故障

        与数据丢失紧密挂钩，是Oracle RAC等非分布式架构的致命故障。存储故障一般分为磁盘故障与控制器故障，后者不太常见。磁盘故障发生时，数据库一般会出现坏块告警，但由于读取该坏块的请求被执行时（比如每日备份），数据库才能发现坏块并告警，该故障往往存在一定延时性。

        该故障发生后，备用的计算节点和备用存储，完备的备份集都是故障修复的必备条件。

• 排查耗时

        排查难度高，如著名的ORA-600 internal error。经常出现在操作系统或数据库软件进行补丁升级、调优变更后。排查用时无法预估，往往需要通过查询官方文档进行调查。

• 影响程度

        影响性能、数据库工具的使用、严重时也会造成数据库宕机或无法对外通讯的情况。

• 修复难度

        修复该故障往往没有明确的解决方法，如果由补丁引起，则回滚补丁。其他BUG则需等待官方修复补丁放出。所以DBA对于数据库版本升级和打补丁都采取较为保守的态度，一般会等待某个版本或PSU经过足够时间考验，确认稳定后才愿意使用。