数据库常见故障类型

数据库系统运行过程中可能发生的故障主要分为以下三类，其破坏性由小到大：

故障类型	别名	根本原因	影响范围	典型例子
​1. 事务故障​	逻辑故障	事务内部的程序逻辑错误或输入异常。	​单个或少量事务。	- 输入数据不合法（如除零错误）。 - 应用程序错误（如转账时余额为负）。 - 死锁（被系统强制终止）。
​2. 系统故障​	软故障（Soft Crash）	硬件（如突然断电）、操作系统或DBMS软件错误，导致系统停止运行。	​所有正在运行的事务，​内存数据丢失，但磁盘数据完好。	- 操作系统崩溃。 - 数据库服务器进程意外被杀。 - 突然断电（需有备用电源支持内存写入磁盘的时间）。
​3. 介质故障​	硬故障（Hard Crash）	存储数据库的物理设备发生损坏。	​破坏磁盘上的数据，影响范围最大。	- 磁盘控制器（Disk Controller）故障。 - 磁头损坏（Head Crash）。 - 磁盘块因老化而永久性损坏。

---

各类故障的恢复策略

各类故障的恢复策略

针对不同的故障类型，数据库系统采用了相应的恢复机制：

1. 事务故障的恢复

•  

  ​恢复方式​： ​撤销（UNDO）​​

•  

  ​实现机制​： 系统反向扫描日志文件，找到该事务的所有更新操作，并对这些操作执行逆操作，将数据库恢复到该事务执行之前的状态，就像这个事务从未发生过一样。

•  

  ​目标​： 消除失败事务对数据库的所有影响。

2. 系统故障的恢复

系统重启后，恢复子系统需要处理两种不确定状态的事务：

•  

  ​未完成的事务​： 事务未提交，但其部分修改可能已写入磁盘。

•  

  ​已提交但未落盘的事务​： 事务已提交，但其数据修改可能还在内存缓冲区，未来得及写入磁盘。

•  

  ​恢复方式​： ​撤销（UNDO） + 重做（REDO）​​

•  

  ​实现机制​：

  1. 1.

     ​撤销（UNDO）​​： 撤销所有未完成事务的操作，确保原子性。

  2. 2.

     ​重做（REDO）​​： 重做所有已提交但未落盘事务的操作，确保持久性。

•  

  ​关键技术​： 通过检查点（Checkpoint）​​ 技术来确定哪些事务需要UNDO，哪些需要REDO，这正是我们上一个对话讨论的核心内容。

3. 介质故障的恢复

•  

  ​恢复方式​： ​重装备份 + 重做日志​

•  

  实现机制​：

  1. 1.

     装入最新的数据库备份​（冷备或热备），将数据库恢复到备份时的状态。

  2. 2.

     装入备份点之后的所有日志文件副本。

  3. 3.

     重做（REDO）备份之后所有已提交事务的操作，将数据库恢复到故障发生前的状态。

•  

  ​特点​： 恢复速度最慢，对可用性影响最大。因此，​制定定期备份策略和日志归档策略至关重要。