在OLTP的环境下使用大事务出现的问题

核心提示： 随着OLTP的进一步发展，并发访问量的进一步提高，在OLTP的环境下使用大事务出现的问题(2)，因事务1本身的事务较大，事务1发生的频率也会越来越高，很容易发生多个session更新同一条记录，容易产生阻塞update test_user set sum_reply = sum_reply

随着OLTP的进一步发展，并发访问量的进一步提高，因事务1本身的事务较大，事务1发生的频率也会越来越高，那时，事务1会与事务1本身产生阻塞，那时我们怎么解决？看来解除事务是唯一的方法，这里有另外一种观点，完全解除事务，即把事务1中的每一个语句都拆开,示例如下：

　　begin transaction
　　　insert into messgae(id,col1,col2...) values(#id,#col1,#col2...);
　　end transaction
　　
　　begin transaction
　　 　　 update thread set post_count=nvl(post_count,0) + 1 where id=#v_id;
　　end transaction
　　
　　begin transaction
　　　　　update test_user set sum_reply = sum_reply + 1 where userid=#v_userid;
　　end transaction

这种方案可以看成事务1的极端，事务1的完全对立面，数据的一致性完全没有保障。如果数据库出现down机，或者应用服务器down掉，那么数据很有可能出现不一致的。为了减少发生数据不一致的概率，可以采用折衷的方案在一定程度上解除事务，事务是一个好东西，就看你怎么用了！对以上事务1的业务进行分析，发现了如下的规律：

insert into messgae(id,col1,col2...) values(#id,#col1,#col2...);这条SQL可以看成"私有"的，不会产生阻塞(这个表上不能有位图索引)

update thread set post_count=nvl(post_count,0) + 1 where id=#v_id;这条SQL是"公共"的，很容易发生多个session更新同一条记录，容易产生阻塞

update test_user set sum_reply = sum_reply + 1 where userid=#v_userid;这条SQL更新自己的东西，也可以看成"私有"的，不会产生阻塞