分布式 DBMS - 失败和提交

---

数据库管理系统容易出现多种故障。在本章中，我们将研究失败类型和提交协议。在分布式数据库系统中，故障大致可以分为软故障、硬故障和网络故障。

软故障

软故障是导致计算机易失性内存丢失而不是持久存储丢失的故障类型。这里，存储在非持久存储（如主存储器、缓冲区、高速缓存或寄存器）中的信息会丢失。它们也称为系统崩溃。各种类型的软故障如下 -

• 操作系统故障。
• 主内存崩溃。
• 交易失败或中止。
• 系统生成的错误，例如整数溢出或被零除错误。
• 支持软件故障。
• 电源（检测）失败。

硬故障

硬故障是导致持久性或非易失性存储（如磁盘）中数据丢失的故障类型。磁盘故障可能会导致某些磁盘块中的数据损坏或整个磁盘发生故障。硬故障的原因是 -

• 电源（检测）失败。
• 介质故障。
• 读写故障。
• 磁盘上的信息损坏。
• 磁盘读写头崩溃。

如果有备用的新的、格式化的且随时可用的磁盘，则从磁盘故障中恢复的时间可能会很短。否则，持续时间包括获取采购订单、购买磁盘和准备磁盘所需的时间。

网络故障

网络故障在分布式或网络数据库中普遍存在。这些错误包括由于数据的分布式特性和通过网络传输数据而在数据库系统中引起的错误。网络故障的原因如下：

• 通讯链路故障。
• 网络拥塞。
• 传输过程中的信息损坏。
• 站点故障。
• 网络分区。

提交协议

任何数据库系统都应该保证即使在发生故障后也能维持事务的所需属性。如果事务执行过程中发生故障，可能会出现该事务带来的所有更改都没有提交的情况。这使得数据库不一致。提交协议使用事务撤消（回滚）或事务重做（前滚）来防止这种情况。

提交点

决定提交还是中止事务的时间点称为提交点。以下是提交点的属性。

• 这是数据库一致的时间点。

• 此时，数据库带来的修改可以被其他事务看到。所有事务都可以拥有一致的数据库视图。

• 至此，事务的所有操作均已成功执行，并且其效果已记录在事务日志中。

• 此时，如果需要，可以安全地撤消交易。

• 此时，一个事务释放了它持有的所有锁。

交易撤销

撤消事务对数据库所做的所有更改的过程称为事务撤消或事务回滚。这主要适用于软故障的情况。

事务重做

重新应用事务对数据库所做的更改的过程称为事务重做或事务前滚。这主要用于从硬故障中恢复。

交易日志

事务日志是一个连续文件，用于跟踪数据库项上的事务操作。由于日志本质上是顺序的，因此它要么从头开始，要么从末尾开始顺序处理。

事务日志的目的 -

• 支持提交协议以提交或支持事务。
• 帮助数据库在发生故障后恢复。

事务日志通常保存在磁盘上，这样就不会受到软故障的影响。此外，日志还会定期备份到磁带等档案存储中，以保护其免受磁盘故障的影响。

事务日志中的列表

事务日志根据事务的状态维护五种类型的列表。该列表有助于恢复管理器确定事务的状态。状态和相应列表如下 -

• 具有事务开始记录和事务提交记录的事务是已提交事务——维护在提交列表中。

• 具有事务开始记录和事务失败记录但没有事务中止记录的事务是失败事务 - 维护在失败列表中。

• 具有事务开始记录和事务中止记录的事务是中止事务——在中止列表中维护。

• 具有事务开始记录和事务提交前记录的事务是提交前事务，即所有操作都已执行但未提交的事务——维护在提交前列表中。

• 具有事务开始记录但没有提交前、提交、中止或失败记录的事务是活动事务 – 维护在活动列表中。

立即更新和延迟更新

立即更新和延迟更新是维护事务日志的两种方法。

在立即更新模式下，当事务执行时，事务所做的更新将直接写入磁盘。旧值和更新值会先写入日志，然后再写入磁盘中的数据库。提交后，对磁盘所做的更改将永久生效。回滚时，数据库中事务所做的更改将被丢弃，旧值将从日志中存储的旧值恢复到数据库中。

在延迟更新模式下，当事务执行时，事务对数据库所做的更新会记录在日志文件中。提交时，日志中的更改将写入磁盘。回滚时，日志中的更改将被丢弃，并且不会将任何更改应用于数据库。