第二章 informix 长事务详解.doc

长事务 ( Long Transaction ) 是数据库用户经常会碰到和非常头疼的问题。长事务处理不当常常会引起数据库的崩溃，给企业运营带来不必要的损失。本文旨在帮助用户理解什么是长事务，为什么会出现长事务，怎样避免长事务以及如何解决长事务可能带来的系统挂起甚至崩溃问题。 什么是“长事务”? 要理解什么是“长事务”，还要从“事务”本身及数据库的逻辑日志工作原理谈起。所谓“事务”(transaction)，是一个完整的不可分割的数据处理单元。该单元中所有的数据处理操作要么全部处理成功，要么因其中任意一个操作的失败而完全回滚至整个事务处理前状态。为了保证事务的完整性，Informix 数据库通过逻辑日志 (logical log) 来记录所有的事务操作及其处理的数据。逻辑日志的作用之一在于对数据所发生的变化进行记录以满足可能的回滚需要。 Informix 数据库服务器把逻辑日志分成多个相互分离的磁盘空间，每个磁盘空间称为一个逻辑日志文件。由于逻辑日志文件的大小和个数由参数指定，整个逻辑日志的空间是相对固定的，并不能无限制的增长。所以对于逻辑日志文件的使用是循环进行的。Informix 数据库服务器按数字顺序依次填充空闲的（即状态为 free 或 available）的逻辑日志文件。当第一个逻辑日志文件变满时，接着开始填充下一个逻辑日志文件，直到填充完最后一个逻辑日志文件。这时，数据库服务器回到第一个逻辑日志文件，试图将其内容释放，以循环使用 ( 如图 1)。 图 1. 循环使用的逻辑日志 释放已经使用过的逻辑日志，需要具备很多条件。其中之一就是该日志不能包含仍然活动的 ( 即还没有提交 ) 的事务。 因为活动的事务随时存在需要回滚的可能性，如果在事务还没有提交时，包含该事务记录的日志由于被释放重用，原来的事务操作记录被覆盖，当事务由于各种原因需要回滚时，回滚所需的记录就会缺失，从而导致无法保证事务的原子性和完整性。 那么，当数据库服务器需要循环使用某个逻辑日志文件，而该文件又包含有还没有提交的事务时，数据库系统就将被挂起 (hang), 处于一种停滞状态，任何对数据库的更新操作都无法继续，从而影响系统的正常处理工作 ( 如图 2)。 图 2. 长事务导致系统挂起 为了防止这种现象的发生，我们把占用整个逻辑日志空间在一定比例以上的事务，就叫做“长事务”。“长事务”意味着可能由于跨越过多的日志文件，导致需要循环使用的日志文件不能及时释放。从而造成数据库系统挂起无法正常工作的可能性。  回页首 与长事务相关的数据库参数 那么究竟多长的事务就是“长事务”呢？事实上，“长事务”由一系列数据库参数决定。 LOGFILES 该参数指定系统初始化或重启动时创建的逻辑日志文件的个数。之后系统管理员还可以继续追加逻辑日志文件数。Informix 数据库要求逻辑日志文件最少有 3 个，最多可以追加到 32,767 个或直至逻辑日志所在空间 (dbspace) 被占满。 LOGSIZE 该参数指定创建的逻辑日志文件的缺省大小。当系统管理员手工追加日志文件时，可以重新指定日志文件大小。 所以逻辑日志文件的个数和其大小决定了系统可用逻辑日志空间的总和。 Long-Transaction High-Watermark (LTXHWM) 长事务深水线比例是指整个逻辑日志空间的一个百分比值。当一个事务占用整个逻辑日志空间的百分比超过这个值时，该事务就成为长事务。数据库系统系统就会强制对该事务进行回滚（rollback ）， 以防止该事务继续填充日志，最终导致日志需要循环重用时无法释放而造成系统挂起。 例如，数据库服务器有 10 个逻辑日志文件，如果 LTXHWM 设置为 80 。一个事务（transaction ）从日志文件 1 （log1 ）开始填充，随着该事务的更新 (update) ，当其操作填充到第 8 个日志文件满时，该事务就到达了长事务深水线比例（LTXHWM ），为了防止系统挂起，数据库服务器将回滚该事务。 Exclusive Access, Long-Transaction High-Watermark (LTXEHWM) 当一个事务到达长事务深水线比例（LTXHWM ）后，数据库服务器会回滚该事务。事务回滚本身也会产生日志，仍然要继续填充日志空间。同时，由于并发事务的存在，其他事务也在不断填充日志空间。所以如果在该事务完全回滚之前，日志空间被填满，仍然会造成系统的挂起。为了尽量避免这种情况的发生，我们用独享的长事务深水线来限制长事物回滚时其他事务对日志空间的使用。 独享的长事务深水线也是整个逻辑日志空间的一个百分比值。当正在回滚的长事务占用日志空间的百分比到达这个值时，系统会急剧降低对日志文件的填充速度。此时，数据库系统几