某网站oracle数据库的HW等待事件

在数据库中，通过下面的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个数也不会很多。