7.3 长事务的处理

长事务的处理

一个管理员在日常的数据库系统维护过程中，不可避免会遇到大批量的数据更新处理。有时候，这种事务处理涉及的记录数可能高达上百万、甚至上千万条记录。我们把这样的事务称为长事务。

长事务只是一个相对的概念，大多情况下用来维护数据库中的历史数据，一般不会出现在日常的业务处理过程中。和一般的事务相比，它具有以下特点：

（1）需要更新的记录数很多

（2）整个处理需要较长的一段时间

虽然长事务被运行的几率较低，但它的执行会对整个数据库系统产生比较大的影响，而且不正确的使用可能造成整个数据库系统的破坏。因此用户在处理长事务时，需要仔细地规划和考虑。如果很随意地开始长事务的处理，往往会带来以下的结果：

（1）事务运行时间远远超过预期。事务已经运行了好几个小时，还远没有结束。由于影响到正常的业务处理，管理员被迫中止事务的运行。事务的异常中止又引起事务回滚，系统需要反向执行所有已经执行的操作，这又需要很长的一段时间。

（2）数据库系统被挂起。事务在执行时要产生日志信息，长事务所需要的日志空间是非常可观的。在所有的日志文件被写满之后，由于事务没有提交，系统不能够覆盖最早的日志文件，新的日志信息无处存放，于是系统就被挂起。

事务的异常中止、系统的挂起，都会造成数据库中数据的不一致。如果处理不当，就可能破坏数据库，进而需要对整个数据库系统进行恢复，日常的业务处理被迫中断。

为了降低长事务执行对系统产生的影响，我们可以考虑采取以下措施：

（1）保证系统日志文件有足够空间。在系统中创建更多的日志文件，或者使系统在需要时能够自动创建新的日志文件，从而保证长事务的运行有足够的可用日志空间，进而避免事务的挂起。

（2）将长事务分成多个小事务。使用条件限制或者其他手段，将一个长事务划分成很多个小事务，这样对数据的处理就可以分批、多次进行。由于每次执行所需时间、日志空间都较小，从而减少了对系统的影响。

（3）不生成数据库日志。就是通过设置，使长事务的处理不产生日志信息，避免对日志文件的写入。在加快事务处理的同时，又可以避免系统被挂起。然而其具体实现存在一些限制和注意事项，详细可见第7.1.5一节。

（4）使用表的分区。将数据量大的表分区，例如：根据日期、年份，将数据存放在表的不同分区中。在维护数据库时，如果需要移走历史数据，就可以直接将单个的分区移走。倘若需要查询历史数据，又可以方便地将被保存的分区直接加入表中。这种数据维护方法，需要在应用系统设计时就进行考虑。

尽可能缩短长事务的处理时间，是用户比较关心的问题。除了对表分区、不生成日志信息之外，用户还可以考虑采取以下措施：

（1）利用系统空闲时间，执行长事务的处理。例如：夜晚、非工作时间等。

（2）删除表上索引。在长事务处理完成后，重新创建。这样可以避免对表的每一个更新处理，都连带要引起索引的更新处理。

（3）使用表锁或者数据库锁。这样可以减少锁的使用，防止锁资源不足，同时也避免每次处理都要申请锁，减缓事务处理速度。

做好数据库备份是长事务处理前必须要完成的工作。在长事务处理完成后，用户有必要重新收集表、索引的统计信息，以保证优化器能够生成合理、正确的执行计划。如果需要，用户还可以重新组织表、索引的存储结构，以加快系统的I/O处理。