IDC资讯中心
原文出处:
http://www.eygle.com/statspack/statspack13.htm
enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新 同一数据。enqueue
包括一个排队机制，即fifo（先进先出）排队机制。
enqueue等待常见的有st、hw 、tx 、tm等
st enqueue，用于空间管理和字典管理的表空间(dmt)的区间分配，在dmt中典型的是对于uet$和fet$数据字典表的 争用。对于支持lmt的
版本，应该尽量使用本地管理表空间. 或者考虑手工预分配一定数量的区(extent)，减少动态扩展
时发生的严重队列竞争。
我们通过一个实例来看一下:
db name db id instance inst num release ops host———— ———– ———— ——– ———– — ——————db 40757346 aaa 1 8.1.7.4.0 no server snap id snap time sessions ——- —————— ——– begin snap: 2845 31-10月-03 02:10:16 46 end snap: 2848 31-10月-03 03:40:05 46 elapsed: 89.82 (mins)对于一个statspack的report,采样时间是非常重要的维度，离开时间做参考，任何等待都不足以说明问题。cache sizes~~~~~~~~~~~ db_block_buffers: 51200 log_buffer: 2097152 db_block_size: 16384 shared_pool_size: 209715200………..top 5 wait events~~~~~~~~~~~~~~~~~ wait % totalevent waits time (cs) wt time——————————————– ———— ———— ——-enqueue 53,793 16,192,686 67.86rdbms ipc message 19,999 5,927,350 24.84pmon timer 1,754 538,797 2.26smon timer 17 522,281 2.19sql*net message from client 94,525 520,104 2.18 ————————————————————-在statspack分析中，top 5等待事件是我们最为关注的部分。这个系统中，除了enqueue 等待事件以外，其他4个都属于空闲等待事件，无须关注。我们来关注一下enqueue等待事件，在89.82 (mins)的采样间隔内，累计enqueue等待长达16,192,686cs,即45小时左右。这个等待已经太过显著，实际上这个系统也正因此遭遇了巨大的困难，观察到队列等待以后，我们就应该关注队列等待在等待什么资源。快速跳转的statspack的其他部分，我们看到以下详细内容:enqueue activity for db: db instance: aaa snaps: 2716 -2718-> ordered by waits desc, gets descenqueue gets waits———- ———— ———-st 1,554 1,554 ————————————————————-我们看到主要队列等待在等待st锁定，对于dmt，我们说这个等待跟fet$,uet$的争用紧密相关。我们在回过头来研究捕获的sql语句:-> end buffer gets threshold: 10000-> note that resources reported for pl/sql includes the resources used by all sql statements called within the pl/sql code. as individual sql statements are also reported, it is possible and valid for the summed total % to exceed 100 buffer gets executions gets per exec % total hash value————— ———— ————– ——- ———— 4,800,073 10,268 467.5 51.0 2913840444select length from fet$ where file#=:1 and block#=:2 and ts#=:3 803,187 10,223 78.6 8.5 528349613delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and ext#=:4 454,444 10,300 44.1 4.8 1839874543select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and ext#=:4 23,110 10,230 2.3 0.2 3230982141insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4) 21,201 347 61.1 0.2 1705880752select file# from file$ where ts#=:1…. 9,505 12 792.1 0.1 1714733582select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t where t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0 6,426 235 27.3 0.1 1877781575delete from fet$ where file#=:1 and block#=:2 and ts#=:3我们看到数据库频繁操作uet$,fet$系统表已经成为了系统的主要瓶颈。至此，我们已经可以准确的为该系统定位问题，相应的解决方案也很容易确定，在8.1.7中，使用lmt代替dmt，这是解决问题的根本办法，当然实施起来还要进行综合考虑，实际情况还要复杂得多。
hw enqueue指和段的高水位标记相关等待；手动分配适当区可以避免这一等待。
tx是最常见的enqueue等待。tx enqueue等待通常是以下三个问题之一产生的结果。
第一个问题是唯一索引中的重复索引，你需要执行提交（commit）/回滚（rollback）操作来释放enqueue。
第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址（rowid），所以当多个用户试图更新同一段时，可能一个
用户会锁定其他用户请求的记录，这时等待出现。直到获得锁定的用户提交或回滚， enqueue释放。
第三个问题，也是最可能发生的问题是多个用户同时更新同一个块。如果没有足够的itl槽，就会发生块级锁定。通过增大initrans和/或
maxtrans以允许使用多个itl槽（对于频繁并发进行dml操作的数据表，在建表之初就应该考虑为相应参数设置合理的数值，避免系统运行
以后在线的更改，在8i之前，freelists等参数不能在线更改，设计时的考虑就尤为重要），或者增大表上的pctfree值，就可以很容易的避免
这种情况。
tm enqueue队列锁在进行dml操作前获得，以阻止对正在操作的数据表进行任何ddl操作(在dml操作一个数据表时，其结构不能被更改)。
本文作者:
eygle,oracle技术关注者,来自中国最大的oracle技术论坛itpub.
www.eygle.com是作者的个人站点.你可通过guoqiang.gai@gmail.com来联系作者.欢迎技术探讨交流以及链接交换.
原文出处:
http://www.eygle.com/statspack/statspack13.htm
