Statspack之十三-Enqueue

 
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，
這是解決問題的根本辦法，當然實施起來還要進行綜合考慮，實際情況還要複雜得多。