informix 长事务详解

长事务( 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 ）后，数据库服务器会回滚该事务。

事务回滚本身也会产生日志，仍然要继续填充日志空间。

同时，由于并发事务的存在，其他事务也在不断填充日志空间。

所以如果在该事务完全回滚之前，日志空间被填满，仍然会造成系统的挂起。

为了尽量避免这种情况的发生，我们用独享的长事务深水线来限制长事物回滚时其他事务对日志空间的使用。

独享的长事务深水线也是整个逻辑日志空间的一个百分比值。

当正在回滚的长事务占用日志空间的百分比到达这个值时，系统会急剧降低对日志文件的填充速度。

此时，数据库系统几乎给予正在回滚的长事务以独占使用剩余日志空间的权利，以最大限度地保障长事务回滚能够在日志空间添满前能够顺利完成，从而使日志释放重用得以实现。

例如，数据库服务器有10 个逻辑日志文件，如果LTXHWM 设置为80, LTXEHWM 设置为90 。

一个事务（transaction ）从日志文件1 （log1 ）开始填充，随着该事务的更新(update) ，当其操作填充到第8 个日志文件满时，该事务就到达了长事务深水线比例（LTXHWM ），为了防止系统挂起，数据库服务器开始回滚该事务，此时日志内容由于该事务回滚和其他事务继续增长，当其操作填充到第9 个日志文件满时，如果该事务还未回滚完成，则到达独享的长事务深水线比例（LTXEHWM ），这时候数据库系统会暂停其他事务的操作（除commit 操作外），留下剩余的日志空间，让该事务回滚，以防止日志空间在回滚结束前被占满。

( 如图3)图 3. 长事务深水线比例（LTXHWM）与独享的长事务深水线比例（LTXEHWM）示意DYNAMIC_LOGS从Informix Dynamic Server （IDS）版本9.30 开始，用户可以通过对数据库参数中的DYNAMIC_LOGS 参数进行设置以实现系统逻辑日志的自动分配。

该参数允许用户在服务器工作状态动态添加新的日志并且立即生效，从而动态增加整个逻辑日志空间的大小，消除或减小长事务处理引起挂机的可能性。

DYNAMIC_LOGS 参数有三个值分别为0,1,2：缺省为2( 系统自动分配日志)。

假如当前使用的日志为n，系统自动为Transation 检查log n+1 的状态，如果返回的结果为真( 即Log n+1无法被释放而重用)，系统将在n 和n+1 之间加入新的日志并一直增加到满足当前Transation 完成且立即生效。

新增加的日志缺省建立到逻辑日志最后被添加的dbspace 中，或根据系统规则建立到指定的dbspace 中。

新增日志的大小将取已有最大日志和最小日志的均值。

或根据请求空间的大小进行相应的调整，日志最小为200K。

图 4. 逻辑日志的动态分配示意∙当DYNAMIC_LOGS 参数设置为1 时，系统也自动为Transation 检查logn+1 的状态，如果返回的结果为真( 即Log n+1 无法被释放而重用)，系统将等待系统管理员手工在当前日志后添加日志，系统管理员可以在任何时间使用ISA 或onparams 多种方式为系统添加日志。

∙如果DYNAMIC_LOGS 参数为0，系统将不会自动添加日志也不会出现等待状况。

回页首什么情况下会出现长事务从以上数据库参数可以看出，长事务与整个日志空间大小有关，与长事务深水线比例有关。

直接来看，在整个逻辑日志空间相对固定的前提下，当一个事务越大（包含的操作越多），其需要填充的逻辑日志空间就会越大。

如果该事务需要记录的日志占用整个逻辑日志的百分比超过长事务深水线比例（LTHWM），该事务就成为长事务。

那么，如果我们能够预计最复杂的事务需要填充日志空间的大小，如果我们分配给系统足够大的日志空间（系统整个日志空间*LTHWM/100 > 最复杂的事务需要填充的日志空间），是不是就完全能够杜绝长事务的发生呢？另外，一个非常小的事务（其实际填充的日志空间远远小于系统整个日志空间）是不是就一定不会成为长事务呢？答案并非如此。

事实上，事务之所以成为长事务，其所占日志空间定义为该事务从第一条日志记录到最终commit 或者rollback 记录之间的所有日志空间。

当这个空间占用整个逻辑日志空间的百分比超过长事务深水线比例时，该事务就成为长事务了。

首先，事务包含的操作的多少只是决定该事务是否将成为长事务的因素之一。

还有其它一些因素会影响事务占用逻辑日志空间的大小。

例如，一条Alter table 虽然仅仅是一个操作，但语句将会为每一次往新修改了的表中的插入操作生成一条逻辑日志记录。

数据行的数量与表的大小都将会影响生成的逻辑日志记录的数目与大小。

操作的数据行数越多，生成的逻辑日志记录越多，所占用的逻辑日志空间既然越大。

其次，在另外一些情况下，虽然事物的操作和数据行大小并不大，但由于系统并发的存在，事务的持续时间也是一个不能为用户所控制的主要的变化量。

在事务持续时间中，该事务所占日志空间中可能包含了许多其他并发事务的日志记录。

因此，系统的并发性越大，事务的操作时间越长，事务占用( 跨越) 的逻辑日志空间就越大。

一个应用，也许并不需要过多的逻辑日志记录空间，但如果用户允许事务在很长时间内保持打开，这时就可能造成长事务事件。

回页首发生长事务事件的结果及影响当一个事务所跨逻辑日志空间的百分比超过长事务深水线比例(LTXHWM) 时，系统会将该事务标记为长事务，并开始回滚(rollback) 该事务。

如果此时还没有达到独享的长事务深水线比例(LTXEHWM) ，则系统在回滚该事务的同时允许其他并发事务的继续操作。

当该事务日志占用超过独享的长事务深水线比例(LTXEHWM) 时，系统会暂停其他并发事务的进行，优先进行该事务的回滚操作，直到事务回滚完成。

如果在该事务回滚完成之前，系统逻辑日志空间已被全部占满，则数据库系统会挂起，无法为客户端继续提供正常服务。

所以，只要配置足够的逻辑日志空间和较低的长事务深水线比例(LTXHWM)、独享的长事务深水线比例(LTXEHWM)，就有可能保证长事务的顺利回滚。

但是，长事务的出现，会影响业务的正常操作，导致该事务无法执行成功。

而且，长事务独享日志回滚期间，也会影响整个系统的并发效率。

然而，最糟糕的情况莫过于出现长事务回滚完成之前，系统逻辑日志空间已被全部占满，从而带来致命的系统挂起，给系统运营带来损失。

回页首如何监控长事务当数据库系统发生长事务事件时，可以在所有onstat 命令的输出头上看到。

“onstat –”命令（不带有任何选项）只输出头部信息，对于观察系统的状态非常onstat 输出下方还会有如下显当数据库系统由于各种原因被阻止时，在以上其中，“reason”可能的跟长事务相关的值见表1：)另外，“onstat -x”命令还可以看到回滚的事务( 如图 5 所示)。