2.2.6 检查点进程

检查点进程

检查点进程定期执行，将内存中所有已经被更新的数据及日志信息写入磁盘，在日志文件中记录检查点信息。

数据库系统并发地为许多用户提供数据访问处理，当前被操作的数据有很大的可能还要继续被处理，因此数据被更新后，仍旧保留在内存中，并不会立即写入磁盘。

如果没有检查点操作，一旦系统由于断电等原因崩溃，数据库系统无法确切地知道那些更新已经写入磁盘，做了永久性确认；那些更新还没有写入磁盘，需要重新执行或者回退。这时数据库系统的恢复需要使用系统运行以来的所有日志文件，整个恢复过程复杂而漫长。

有了检查点进程，在执行检查点操作时，会在日志文件中写入检查点信息，给系统打上一个时间戳，表明在这一时刻，以往所有的更新得到了永久性确认。在数据库系统恢复时，只要从日志文件中最后一个检查点开始就可以了。

检查点操作将内存中所有更新写入磁盘，这些更新所对应事务有的已经提交，有的还没有完成。在数据库系统恢复时，需要根据日志记录，重新执行已经提交的事务，回退尚未完成的事务。有关系统恢复的详细信息，可以参看第8章。

系统在执行检查点操作时，所有的事务处理被暂时中止。直到检查点操作完成后，事务的处理才继续进行。因此需要仔细规划检查点进程的执行间隔，避免给数据库系统带来大的影响。

如果执行间隔设置得太小，数据库系统就可能存在以下问题：

（1）数据库系统频繁地中断用户请求处理。

（2）频繁地引起磁盘读写。由于对磁盘的读写，需要磁头的来回移动，这种机械运动导致磁盘的读写速度比内存的读写速度低几个数量级，必然要影响到系统性能。

如果执行间隔设置得太大，下列问题就需要进行考虑：

（1）检查点操作的执行时间可能很长。在执行检查点操作时，可能有大量更新需要写入磁盘，需要较长的时间。此时，系统中现有的事务可能由于中断时间过长，引起超时而中止，用户的适时响应也会受到严重的影响。

（2）一旦数据库系统崩溃，需要较长的时间进行恢复，进而影响到系统的可用性。

在现有的数据库系统中，通过系统的配置参数，来决定检查点操作的执行间隔。除此之外，数据库系统的一些特定动作，如：日志文件的切换、数据库的备份、数据库系统的正常关闭等等，也会触发检查点操作。

对检查点操作的系统配置，大体上来说，可以归结为以下两种设置方式：

（1）设置固定的时间间隔

数据库系统以固定的时间间隔，执行检查点操作。在设定的时间间隔到来后，不管内存中是否有更新的数据，检查点操作都会被执行。这种设置方式，在数据库系统中存在大量更新时，固定的时间间隔会使检查点操作的时间变长，进而可能影响到系统的正常运行。

（2）以内存中已更新数据量来决定是否激活检查点操作

数据库系统不断地检查内存中已经发生的更新，当已更新的数据量达到预先设置的限制时，就激活检查点进程，执行检查点操作。这种设置方式，在系统有大量更新时，检查点操作会很频繁；在系统处理相对空闲时，检查点操作发生的频度就降低，从而可以有效地避免过长的检查点处理时间。然而系统对内存中已更新数据量的不断监测，需要消耗一定的系统资源。