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 % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
enqueue 53,793 16,192,686 67.86
rdbms ipc message 19,999 5,927,350 24.84
pmon timer 1,754 538,797 2.26
smon timer 17 522,281 2.19
SQL*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 desc
Enqueue 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 2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
803,187 10,223 78.6 8.5 528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4
454,444 10,300 44.1 4.8 1839874543
select 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 3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
21,201 347 61.1 0.2 1705880752
select file# from file$ where ts#=:1
….
9,505 12 792.1 0.1 1714733582
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe
re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
6,426 235 27.3 0.1 1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
我们看到数据库频繁操作UET$,FET$系统表已经成为了系统的主要瓶颈。
至此,我们已经可以准确的为该系统定位问题,相应的解决方案也很容易确定,在8.1.7中,使用LMT代替DMT,
这是解决问题的根本办法,当然实施起来还要进行综合考虑,实际情况还要复杂得多。