读书笔记-高级owi与oracle性能调整-transaction

enq:tm-contention
执行dml期间,为防止对与dml相关的对象进行修改,执行dml的进程必须对该表获得tm锁.若在获取tm锁的过程中发生争用,则等待
enq:tm-contenttion事件.
一般发生tm锁争用的情况如下:
(1)修改无索引外键的父键时
(2)dml和ddl之间的tm锁争用
(3)lock table...引起的tm锁争用
(4)direct load工作引起的tm锁争用
解决办法:
(1)从oracle 9i开始,没有索引的外键列,算法大幅得到改善,不再发生类似的争用现象.
(2)若对于数据多的表执行不当的ddl,则访问此表的所有dml会话都会陷入等待状态,可能发展至故障状态.通过合理的管理从根本上防止才是最好的方 法.执行ddl时,最好使用online选项.随着oracle版本的升级,online状态下可执行的ddl逐步增加.使用parallel ddl将ddl的执行速度最大化.对拥有大量数据的表执行ddl时,若恰当使用parallel选项,可将ddl本身性能最大化,而且同时使用 nologging选项也比较好.如果提升ddl执行速度,tx锁争用引起的等待时间相应地也会下降.
(3)发生tm锁引起的争用时,收集锁拥有者在会话上执行的sql语句尤为重要.与其为了同步对整个表上锁,不如考虑使用dmbs_lock程序包或使用select...for update等,减少锁范围的方法.
(4)direct load工作不经过sga,而是直接写入到数据文件里,所以在执行工作期间不允许对表进行任何修改.以exclusive模式获得tm锁,对于表不允许发生任何修改.

enq:tx-row lock contention
(1)多个会话修改相同行时,mode=6
修改相同行伴随着的tx锁争用,完全是应用程序问题.长时间执行的update或delete命令最好是在事务较少的时段执行.还有,优化update或 delete命令本身也是改善性能的另一种方法.特别是对大量数据执行update,不公引起tx锁争用问题,而且会引起许多性能
问题.
(2)多个会话引起唯一健冲突时,mode=4
唯一键冲突引起的tx锁争用完全是应用程序的问题.为创建唯一键,使用特别算法或从已存表里筛选最大值等方法时,唯一键冲突引起的tx锁争用随时可能发生.最好的解决方法就是使用sequence创建唯一键.
(3)多个会话引起位图索引冲突时,mode=4
一个叶节点管理大范围的rowid.每当表的行被修改时,对位图索引相应的值,每次都要重新计算行所属叶节点的位图.因此,两个会话同时对相同的叶节点执 行位图运算时,为保障顺序,应该获取tx锁.对dml频繁的表取消其位图索引,改用基于decode的索引或普通索引,也可以使用 materializedview之类的功能.

enq:tx-allocate itl entry
itl条目不足,mode=4
所有事务在修改块之前,必须在块头的itl上登记条目.若itl超过maxtrans指定的最大值或块内的剩余空间不足,而不能登记条目时,为了以 shared模式获得,早已在itl上登记条目的其它进程以exclusive模式获得的tx锁而等待.这时的等待现象可能过enq:tx- allocate itl entry事件观察.
影响itl的三个属性:initrans,maxtrans,pctfree.
一般情况下,itl条目不足伴随着的tx锁争用现象不会发生,这是因为数十或数百个会话不大可能同时对一个块的不同行进行修改.但若是发生了行链接或行迁移的行,则更新一个行时,对多个块都要分配itl条目,因此发生itl条目不足引起的tx锁争用的概率会升高.
创建表时设定较高的initrans值,是解决itl空间不足伴随着的tx锁争用现象的一般方法.更为重要的是,判断是否是错误的应用程序设计引发的争 用,若的确是错误的设计引发的,则修改应用程序是唯一的解决方法.利用v$segment_statistics视图,可以得知对哪些段较多发生itl不 是引起的争用.利用statistic_name='ITL waits'这个条件,可以了解对哪些段较多发生itl不足引起的争用.

enq:tx-index contention
索引叶节点上发生分割时,mode=4
b*tree索引在添加数据的过程中,如果叶节点已满就会进行分割,以此达到平衡.会话A在exclusive模式已获tx锁的情况下,执行分割的过程 中,会话B正要修改叶节点时,会话B为了以shared模式获得会话A拥有的tx锁只好等待,在此期间会发生enq:tx- indexcontention等待事件.
一般情况下enq:tx-index contention等待不会发生,它主要是在多个会话对已有索引的表执行较多量的dml时发生.这个等待现象
虽然不经常发生,但创建的数量多,组成索引的列值大而指针叶节点的块频繁被分割时,成为性能下降的原因.特别是使用sequence等方式生成值的列在创 建索引时,一直出现只在最后的叶节点添加值的现象,所以可能经常发生索引分割.这是以排序形式保持叶节点的b*tree索引引起的,因此多个会话将大量数 据执行insert时,与buffer busy waits等待一起发生enq:tx-index contention等待.
减少索引分割引发的争用的基本方法,就是阻止在相同的叶节点块里集中添加数据的现象.另一种解决方法是将索引的块设定得较大.
使用较大的块时,一个块上的条目数量多,因此较少发生分割,但是若块大小增加,就可能引发buffer lock争用引起的buffer busy waits等待现象,所以要谨慎使用.
修改没有创建索引的表过程中,有时也能发生enq:tx-index contention等待,表里有lob列时,就会从内部创建对于lob数据的索引(称为lob索引),因此多个会话同时修改lob数据时会发生索引争用.

enq:tx-contention
分布式事务环境下,通过prepared transaction读取已获得锁的行时,直到事务结束为止,为了以shared模式获取tx锁而需要等待.
将flm以段空间管理方法使用时,想要分配tfl(transaction free list)的进程无法分配到tfl时,为了以shared模式获得已经占有tfl的事务的tx锁,而需要等待.
回滚段头的事务表上想要分配到新的slot时,应该以exclusive模式获得tx锁.

enq:ul-contention
使用dbms_lock程序包,可以对任意假想的资源挂起锁.如果是因为dml发生的锁时,虽然必须需要物理资源,但使用dbms_lock程序包
时没有这种限制.利用dbms_lock程序包获取的锁称为ul(userdefined lock)锁.为获得ul锁而等待的会话,将发生enq:ul-contention等待事件.
利用dbms_lock.request函数,可以将ul锁以exclusive模式获得,利用dbms_lock.release函数,可以释放锁.
ul锁引起的争用是在没能有效使用dbms_lock程序包时发生的.ul锁的释放只能在拥有锁的会话上实现.若特定会话因长时间拥有ul锁,而引起并发 性问题,则除了强制结束会话之外没有其它方法.使用dbms_lock.request函数时,尽量使用release_on_commit选项,以避免 多余地拥有锁.使用这个选项若发生提交或回滚,则自动释放该事务所拥有的ul锁

pl/sql lock timer
利用dbms_lock.sleep暂时中断事务时,该进程则等待pl/sql lock timer事件.
此等待不会引起性能问题,如果等待时间比预期的长,就应该重新检查应用程序的实现逻辑是否存有问题.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28539951/viewspace-1264950/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28539951/viewspace-1264950/