在数据库中，通过下面的sql，看到了很多正在执行的sql和等待事件（详细的执行sql
和等待事件见附件）。
col sid format 999999
col serial# format 999999
col spid format 999999
col username format a12
col terminal format a15
col machine format a18
col program format a30
col sql_text format a120
select /*+use_nl(a,b,c)*/distinct a.sid,a.serial#,a.username,a.terminal,a.machine,a.program,b.spid,c.hash_value,c.sql_text
from v$session a,v$process b,v$sql c
where a.paddr = b.addr(+)
and a.sql_hash_value = c.hash_value
and a.sql_address = c.address
and a.status = 'ACTIVE'
and a.type = 'USER'
/
select sid,p1,p1raw,p2,p2raw,p3,p3raw,wait_time,seconds_in_wait,state,event
from v$session_wait
where event not in (select event from perfstat.stats$idle_event)
/
然后又看了下statspack，发现前五的等待事件，有enqueue，
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 7,797,413 33,153 79.47
CPU time 3,884 9.31
direct path read (lob) 907,757 2,044 4.90
log file sync 3,150,943 1,296 3.11
enqueue 28,676 501 1.20
然后又去查了一下enqueue的统计信息
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------
HW 7,943 7,941 0 3,268 308.90 1,009
TX 3,778,248 3,779,996 0 24,421 1.81 44
SQ 3,631 3,631 0 47 .19 0
CF 4,656 4,655 1 1 1.00 0
发现HW的等待比较严重。
根据等待的sql，查看是因为有一个lob表的插入更新导致了这个问题，又查看了下这个表所在的表空间，发现每次extent的分配是1m，因为这个1m，又因为是lob，所以出现了这个问题，经过讨论，认为进行空间预分配可以解决这个问题，如下的sql：
alter table OFFER_DETAIL modify lob(DETAILS) (allocate extent (size 1024m));
这个sql没有导致表的依赖对象失效，但是把内存中关于这个表的sql全都刷出去了，需要重新硬解析，而且这个语句是需要得到一个独享锁，该语句执行的时间和allocate extent (size 1024m)中的size
大小有关，所以这个语句需要在压力低的时候才能搞下。
xxxxxx@webdb>alter table XXXXX_DETAIL modify lob(DETAILS) (allocate extent (size 1024m));
Table altered.
Elapsed: 00:00:11.84
xxxxxx@webdb>
xxxxxx@webdb>alter table XXXXX_DETAIL modify lob(DETAILS) (allocate extent (size 2048m));
Table altered.
Elapsed: 00:00:23.71
xxxxxx@webdb
>exit
预分配之后，就没有再发现HW的enqueue的等待事件，statpack也变好了。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 11,638,913 46,524 82.12
CPU time 3,656 6.45
log file sync 5,610,625 2,560 4.52
direct path read (lob) 1,029,214 2,241 3.96
db file parallel read 49,849 551 .97
Enqueue activity for DB: webdb Instance: webdb Snaps: 17189 -17190
-> Enqueue stats gathered prior to 9i should not be compared with 9i data
-> ordered by Wait Time desc, Waits desc
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------
TX 5,669,770 5,673,328 0 23,813 1.79 43
SQ 5,633 5,633 0 102 .17 0
HW 1,792 1,792 0 19 .84 0
不论是否是使用lob，建议建表空间的时候extent的分配可以大一些，对于一些增长比较快的空间，可以分配8m,16m或者是更多，这样每个表的extent个数也不会很多。
