长事务的管理

直观感觉，一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务( Long Transaction )。在OLTP类型的数据库系统中，一个事务的执行时间通常会很短，所以不会感觉其执行时间漫长。

长事务的概念不一而足：在Oracle中，运行时间超过6秒的事务就被视为长事务。Informix把占用整个逻辑日志空间在一定比例以上的事务（事务占用整个逻辑日志空间的百分比超过“长事务深水线比例”这个参数限定的值），叫做“长事务”。

而长事务是数据库用户经常会碰到且是非常令人头疼的问题。长事务处理需要恰当进行，如处理不当可能引起数据库的崩溃，为用户带来不必要的损失。

对于各种并发控制方法而言，长事务会带来较大的危害。比如，对于基于锁的并发控制方法，如果一个事物过长，可能阻塞其它事务执行，则会发生长时间的等待；即使有的数据库系统提供死锁检测机制和封锁超时机制，长事务也会严重阻塞其它事务地并发执行。对于基于时间戳的并发控制方法，一个长事务存在时，尽管并发的事务不需要等待，但一些有冲突发生的事务会被回滚，所以长事务也会严重阻塞其它事务地并发执行。

如果一个数据库系统提供了MVCC机制，如PostgreSQL在MVCC机制下会产生大量的老数据（多版本导致的垃圾数据），而这些数据被VACUUM命令清理的一个条件，是找出当前最老的活跃事务的事务号，在这个事务号之前的多版本的数据才可以被清理。长的一个事物一直执行不完，势必影响着VACUUM命令清理垃圾数据。

在日志方面，“长事务”执行过程中可能会生成很多的RODO日志，大量的日志信息在一个日志文件中保存不下时，意味着会跨越过多的日志文件，导致需要循环使用的日志文件不能被重用（一个日志文件要被重用则不能包含处于活动状态的事务），从而造成数据库系统挂起，无法正常对外提供服务工作。这种情况下，数据库的表现就如同被“hang”住。

另外，如果有的数据库系统提供MVCC机制，又提供基于快照的读，如MySQL的InnoDB基于快照在可重复读隔离级别下的“一致性地非锁定读”，这样的SELECT操作是不加锁的，所以尽管事务很长，也不会产生如上所述的一些负面影响。所以“一致性地非锁定读”非常适合OLAP类型的长时间的复杂查询。

因为危害众多，长事务成为事务管理技术实现时需要考虑的一个较为重要的问题。

对于长事务，不同的数据库有不同的处理方式。Informix数据库在日志文件切换为其它日志文件前先检查本日志文件中是否存在没有完成的事务，如果有则视为长事务，回滚此长事务。Informix还允许设置日志文件大小，并通过参数LTXHWM（长事务深水线比例）和 LTXEHWM（独享的长事务深水线比例）设以判断长事务发生是否发生，如果超过“长事务深水线比例”这个高水位，则回滚此长事务。