长事务相关

长事务是一个非常重要的机制，该机制如果处理不好必将非常严重的影响数据库的性能和使用。其他数据库貌似没有类似的问题。

      长事务出现的根源是一个事务跨越的逻辑日志文件的数量和全部逻辑日志文件的数量比例控制的不好。

       先说一个事务跨越的逻辑日志文件的数量，该数量的大小依赖于两个方面：

      1、事务不大，但是一直没有commit，其他事务在大量的使用逻辑日志，当前事务跨越的逻辑日志文件数量就显得很大；

      2、事务确实很多，一直做不完，使用了大量的逻辑日志，在此期间其他事务也在频繁的使用逻辑日志，最后该事务被判定为长事务；

       为了避免长事务的出现， 所以逻辑日志文件的个数和大小都尽量加大。

       长事务带来的影响：

        当一个事务使用的逻辑日志个数>=全部逻辑日志个数*LTXHWM/100的时候，该事务就被判定为长事务，该事务开始回滚，其他事务照旧执行，没有影响。当该事务的逻辑日志使用个数>=全部逻辑日志个数*LTXEHWM/100的时候，数据库就会阻塞全部的在运行的事务(除去被判定为长事务的事务照常回滚之外)。我理解数据库之所以要阻塞其他事务的运行，是为了保障当前正在回滚的长事务必须能够回滚完成。

       一旦在其他事务被阻塞，当前长事务回滚的时候逻辑日志被耗尽，数据库将变的不可用。为了避免该问题的出现，需要及早给数据库服务器增加逻辑日志(onparams -a -d -s -i) 。

      所以控制事务的大小和增加逻辑日志文件的个数是解决长事务问题的王道和根本。

长事务的分类大致如下：

1、online.log中看到长事务的信息如下：

Continuing Long Transaction (for COMMIT): tx 0xc0000000b28f5338 username: fisp uid: 107

事务使用逻辑日志的数量超过了LTXHWM，该事务被server判定为长事务。但是事务已经进入了commit或rollback阶段，此时数据库服务器允许该事务仍然使用逻辑日志以便完成提交或回滚，而不进行强制回滚。

2、online.log中看到长事务的信息如下：

Aborting Long Transaction: tx 0xc0000000b8d20c18 username: fisp uid: 107

事务使用逻辑日志的数量超过了LTXHWM，该事务被server判定为长事务。但是事务没有进入了commit或rollback阶段，此时数据库会自动回滚该事务。