三类故障的性质差异及对应恢复策略指向

数据库故障按”破坏范围有多大、影响到哪一层”分三类，破坏范围越大，需要 的恢复手段越重。事务故障范围最小，只影响单个事务本身（逻辑错误、数据 未找到、运算溢出、死锁），发生时数据库系统仍在正常运行，处理方式是 终止该事务并撤销它已做的修改（undo），不需要动用整个系统级别的恢复 机制，甚至可以靠应用程序层面的异常处理提前拦截、降低发生概率。系统 故障范围扩大到整个系统（操作系统崩溃、数据库管理系统出错、断电）， 特点是内存中的数据丢失，但磁盘等非易失性存储没有被破坏——这意味着 “数据其实还在”，只是内存里尚未落盘的部分需要恢复，因此可以靠数据库 自身的恢复技术（重启后基于日志把已提交但未落盘的更新重做、把未提交 的回滚）来解决，不需要外部介入。介质故障范围最大，直接破坏外存本身 （磁盘损坏、磁头碰撞），此时”数据还在”这个前提不成立了，日志和数据 库本体可能一起被毁，恢复必须依赖故障之外的备份（转储的历史副本）加 恢复技术共同完成，事前的预防手段也从”系统内部机制”升级为”物理层面的 冗余”（如镜像服务器）。三类故障的应对思路呈现清晰的递进：影响范围 越小，越能靠系统内部的撤销/重做机制自愈；影响范围越大，越需要依赖 故障之外保留的副本。

结构图：

flowchart TD
    A[事务故障: 影响单个事务<br/>系统仍正常运行] -->|终止事务, 撤销其修改| A1[无需系统级恢复]
    B[系统故障: 影响整个系统<br/>内存丢失,磁盘数据完好] -->|基于日志重做已提交/回滚未提交| B1[依赖数据库自身恢复技术]
    C[介质故障: 破坏外存本身<br/>数据库本体可能被毁] -->|依赖故障之外保留的转储副本| C1[恢复技术+历史备份共同完成]