全局临时表能能减少TX锁？

显示全部楼层 · 2009-3-17 15:35:53

今天碰到个奇怪的问题：
我有两个系统系统1（schema 1）和系统2( schema 2 )，他们会共同操作一些对象（表）, schema2的应用会update schema1的表。
昨天系统1升级了，但是系统2运行却出现了性能问题（升级前一切正常），我看了下是系统2的一个核心存储过程出了问题，在升级以前运行该存储过程差不多5分钟，而现在升级后需要40分钟-1小时.
我看等待事件中出现了很多的enq: TX - row lock contention等待事件，并且schema2 update schema1的那些对象（表）对频繁的锁，是schema1锁的schema2.
为此，我们另外一个同事改了下这个存储过程，他将里面的update操作改了下：
原来该操作如下：
update t1 set a=

select t.a from (

select ......from

( select ....));
改之后入下：
insert into GT_t2

select t.a from (

select ......from

( select ....));
update t1 set a=select GT.a from GT_T2 GT;
修改之后效率确实提高了不少，现在执行该过程大概需要 15分钟- 20分钟。之后我看了先等待事件，几乎很少enq: TX - row lock contention该事件，并且锁也没了.
全局临时表能能减少TX锁？
据我所知道的，临时表好像没这个作用的.
请大家帮忙分析分析.

千问 · 2009-3-17 15:35:53

晕这样修改能保证一致性么？

千问 · 2009-3-17 15:35:53

GT_T2是个commit级别的全局临时表，他的意思是吧子查询的数据先存入临时表，在用临时表的数据跟新永久表，而不是像以前那样直接用子查询的数据跟新永久表，一致性倒是可以保证的，但是我不明白这么改对性能而言究竟有没好处，看应用的响应时间答案是肯定的，但是没弄明白为什么。

千问 · 2009-3-17 15:35:53

沉得真快啊，高手们，请留言

千问 · 2009-3-17 15:35:53

减少了锁持有的时间

千问 · 2009-3-17 15:35:53

1、将子查询从更新中拿出来，减少了锁持有时间
2、如果整个过程变快了，排除锁等待的因素的话，应该是通过临时表使执行计划也产生了较大变化

千问 · 2009-3-17 15:35:53

关于你的第一点，我也是这么怀疑的，但是没理论依据。
第二点我会测试下，谢谢你的回复
另外你能说下你的第一点的理论依据吗？兄台。