事务内部的故障、系统故障和介质故障是数据库系统中常见的三种故障类型，每种故障都会对数据库的正常运行和数据完整性产生不同程度的影响。

1. 事务内部的故障

定义：

事务内部的故障是指在事务执行过程中，由于某些原因（如非法操作、违反约束条件、逻辑错误等），导致事务无法继续执行下去。这种故障仅影响当前事务，不会直接影响整个系统或其他事务。

常见原因：

• 输入数据不符合约束条件（如外键约束、唯一性约束等）。
• 应用程序代码中的逻辑错误或异常。
• 手动操作（如用户主动终止事务）。

恢复策略：

• 回滚（Rollback）：
  • 数据库管理系统（DBMS）会在事务开始时记录当前数据的状态（通常在日志中），当事务发生故障时，通过回滚操作恢复到事务开始之前的状态。
  • 使用 Undo 日志：在执行事务时，将原始数据保存到 Undo 日志中，回滚时利用日志恢复数据。
• 保证原子性：
  • 确保事务的所有操作要么全部完成（提交），要么全部撤销（回滚）。
• 重启事务：
  • 在某些情况下，可能通过重新执行事务（如修正输入数据或逻辑错误）来完成任务。

2. 系统故障

定义：

系统故障是指由于系统运行环境的异常（如操作系统崩溃、电源故障、服务器重启等）导致数据库运行中断。这种故障通常会影响正在执行的所有事务，但不会损坏数据库的存储介质。

常见原因：

• 服务器宕机（如断电、操作系统崩溃等）。
• 数据库进程崩溃。
• 内存中的缓存数据丢失。

恢复策略：

• 事务日志恢复：
  • 使用 Redo 日志和 Undo 日志：
    • Redo 日志：记录已提交事务的修改，用于重做操作。
    • Undo 日志：记录未完成事务的修改，用于回滚操作。
  • 系统重新启动后，扫描事务日志，进行以下两步：
    1. Undo 未完成事务：撤销未完成的事务操作。
    2. Redo 已提交事务：重做已经提交的事务操作，确保数据一致性。
• 检查点机制（Checkpoint）：
  • 数据库会定期创建检查点，将已提交事务的数据更新到物理存储上，并清理日志。
  • 恢复时，从最近的检查点开始，减少恢复所需的时间。
• 事务原子性和持久性保障：
  • 数据库通过事务管理和日志系统，确保即使发生故障，也能恢复到一致的状态。

3. 介质故障

定义：

介质故障是指存储数据库的物理介质（如硬盘、磁盘阵列等）发生损坏，导致数据部分或全部丢失。这种故障通常是最严重的，因为它可能导致无法通过事务日志直接恢复数据。

常见原因：

• 硬盘损坏或磁盘故障。
• 存储设备的老化或损坏。
• 自然灾害（如火灾、水灾等）造成的物理破坏。

恢复策略：

• 备份恢复：
  • 定期对数据库进行全量备份和增量备份。
  • 如果介质发生故障，通过最新的备份文件恢复数据库。
• 日志恢复：
  • 结合备份和事务日志，执行恢复操作：
    • 先从备份中恢复数据库到某个历史状态。
    • 再通过事务日志（Redo 日志）将数据库恢复到最新状态。
• 容灾技术：
  • 使用 主从复制 或 分布式数据库：
    • 主从复制：将主数据库的事务更新实时同步到备份数据库，一旦主数据库介质发生故障，可以切换到备份数据库。
    • 分布式数据库：将数据分布存储在多个节点上，某一节点发生介质故障时，可从其他节点恢复数据。
  • 远程备份和云备份：
    • 将备份存储到地理位置不同的服务器或云存储上，以防灾难性事件导致数据不可恢复。
• RAID技术：
  • 使用 RAID（磁盘阵列）技术，通过数据冗余（如 RAID 1 的镜像备份）和校验（如 RAID 5、RAID 6）提高磁盘容错能力，减少因单个磁盘损坏造成的数据丢失。

总结对比