8.4.1 崩溃恢复

崩溃恢复

数据库系统在正常停止时，会将内存中的所有日志信息、被更新过的数据写入磁盘，然后在日志文件的最后写入检查点记录。这样，所有已提交事务的更新全部落实到磁盘中，数据库中的数据就处于一致状态。如果数据库系统异常中止，那么仍旧在内存中的日志信息、被更新的数据就全部丢失。在这种情况下，一些事务的更新处理可能只是部分落实到磁盘中，从而导致数据库处于不一致状态。重新启动时，在用户能够访问数据库中的数据之前，数据库系统要首先使用日志信息，使数据库处于一致状态。这就是崩溃恢复。

 

1. 崩溃恢复的处理方式

 

崩溃恢复就是数据库系统在异常中止后重新启动，使用数据库日志文件，恢复数据库到一致状态的过程。其关键点就是：决定那些事务需要重做，那些事务需要回滚。通过重做已提交事务，避免事务的丢失；通过回滚未完成事务，删除造成数据不一致的部分事务更新。所有这些操作，是依靠日志文件以及文件中的最后一个检查点记录来实现的。

数据库系统在执行检查点操作时，暂停所有事务的更新处理，将内存中的所有日志信息、被更新过的数据写入磁盘，作永久性的保存。基于日志文件的最后一个检查点记录，系统中的事务有以下三种状态：

（1）在此之前已经提交。这些事务的更新，肯定已经落实到磁盘，不需要考虑。

（2）在此之前已开始执行，但还没有提交。这些事务的更新，在此之前的部分已经落实到磁盘，但无从确定在此之后的部分是否落实到磁盘。

（3）在此之后开始。这些事务的更新，不能确定是否落实到磁盘。

因此，在崩溃恢复时，系统只要基于日志文件中的最后一个检查点记录，找到所有无法确定其更新全部写入磁盘的事务。对这些事务，由最后一个检查点记录开始，正向扫描日志文件，重新执行有提交记录的事务，没有提交记录的事务就进行回滚，这样就可以使数据库处于一致状态。

 

2. 崩溃恢复的处理步骤

 

对崩溃恢复，数据库系统大体上采用以下步骤进行处理：

（1）从日志文件的最后一条记录开始，由后至前扫描日志记录，找到日志文件中的最后一个检查点记录。

（2）找出该检查点操作发生时，正在执行、还没有提交的事务清单。然后由该检查点记录开始，正向扫描日志文件，找到该检查点操作发生后开始的新事务和提交的事务。由此我们可以得到两个事务清单：

① 有提交标识的事务清单。这些事务需要重新执行。

② 没有提交标识的事务清单。这些事务需要回滚。

（3）对需要重新执行的事务，从最后的检查点操作记录开始，正向扫描日志文件，找出这些事务的操作记录重新执行。对需要回滚的事务，从日志文件的最后开始，由后向前扫描，找出这些事务的操作，执行反向处理。

经过以上的崩溃恢复处理，数据库恢复到一致状态，系统就正常运行，允许用户访问数据库中的数据。

 

3. 崩溃恢复的使用说明

 

崩溃恢复由数据库系统自动完成，和数据库使用的日志归档模式无关。只要系统非正常关闭，再次启动时就要执行崩溃恢复。数据库系统在异常中止后重新启动，往往需要更长的时间才能够访问，就是因为系统要执行崩溃恢复的缘故。

崩溃恢复不需要使用数据库备份。从第7章我们知道：日志文件可处于活动和不活动两种状态。崩溃恢复需要使用处于活动状态的日志文件，因而它们不能被归档、删除。一旦这些活动的日志文件不小心被删除或者遭到破坏，无法完成崩溃恢复，无法恢复数据库一致性，那么整个数据库系统就遭到破坏。如果出现这种情况，就只能使用数据库备份，进行数据库的不完整恢复，从而造成数据的丢失。

如果为了提高数据库系统的处理性能，不要求事务提交前将日志信息写入磁盘，那么系统的异常中止可能会造成已提交事务的丢失，崩溃恢复不会重新执行这些事务。在这种应用环境下，在系统异常中止、重新启动后，需要进行人工检查，发现而重新执行那些丢失的事务。