tatspack之十二-db file scattered read-DB檔案分散讀取

liuya1985liuya發表於2007-12-27

這種情況通常顯示與全表掃描相關的等待。
當資料庫進行全表掃時,基於效能的考慮,資料會分散(scattered)讀入Buffer Cache。如果這個等待事件比較顯著,
可能說明對於某些全表掃描的表,沒有建立索引或者沒有建立合適的索引,我們可能需要檢查這些資料表已確定是否進
行了正確的設定。

然而這個等待事件不一定意味著效能低下,在某些條件下Oracle會主動使用全表掃描來替換索引掃描以提高效能,這
和訪問的資料量有關,在CBO下Oracle會進行更為智慧的選擇,在RBO下Oracle更傾向於使用索引。

因為全表掃描被置於LRU(Least Recently Used,最近最少適用)列表的冷端(cold end),對於頻繁訪問的較
小的資料表,可以選擇把他們Cache到記憶體中,以避免反覆讀取。

當這個等待事件比較顯著時,可以結合v$session_longops動態效能檢視來進行診斷,該檢視中記錄了長時間(運
行時間超過6秒的)執行的事物,可能很多是全表掃描操作(不管怎樣,這部分資訊都是值得我們注意的)。

我們通過通過一個案例分析來熟悉一下這個等待事件:

 

DB Name        DB Id     Instance    Inst Num  Release     OPS   Host         
----------  -----------  ----------  --------  ----------  ----  ----------   
K2        1999167370      k2              1  8.1.5.0.0   NO      k2       


這是一個8.1.5的資料庫系統,通過指令碼增強,我們可以在8.1.5的資料庫上使用statspack來進行資料庫診斷。

                                                             Snap Length   
Start Id    End Id       Start Time             End Time         (Minutes)    
--------  --------  --------------------  --------------------  -----------   
     170       176  25-Feb-03 10:00:11    25-Feb-03 15:00:05         299.90   

Cache Sizes                                                                   
~~~~~~~~~~~                                                                   
           db_block_buffers:       64000                                      
              db_block_size:        8192                                      
                 log_buffer:     8388608                                      
           shared_pool_size:   157286400                                      
                                                                              
………………                    
                                                                              
Top 5 Wait Events                                                             
~~~~~~~~~~~~~~~~~                                                     Wait  % Total
Event                                          Waits     Time (cs)  Wt Time
-------------------------------------------- ------------ ----------------------- -------
db file scattered read                         16,842,920             3,490,719   43.32
latch free                                     844,272      3,270,073   40.58
buffer busy waits                               114,421          933,136   11.58
db file sequential read                          2,067,910         117,750    1.46
enqueue                                          464          110,840    1.38
         -------------------------------------------------------------        

這是一個典型的效能低下的系統,幾個重要的等待事件都在Top 5中出現,其中,前3個等待極為顯著,需要進行
相應的調整。
在5小時的取樣間隔內,其中db file scattered read累計等待時間約10小時,已經成為影響系統效能的主要原因。
瞭解了這些以後我們就可以進一步察看相關SQL看是否存在可以的SQL語句。

SQL ordered by Gets for DB: K2  Instance: k2  Snaps:     170 -    176   
                                                                              
                                Gets       % of                               
   Buffer Gets     Executes   per Exec    Total   Hash Value                  
-------------- ------------ ------------ ------ ------------                  
SQL statement                                                                 
------------------------------------------------------------------------------
     6,480,163           12    540,013.6    2.4   3791855498                  
  SELECT "PROCESS_REQ"."WORK_ID", "PROCESS_REQ"."STOCK_NO",    "PROCESS_R
                                                                              
     3,784,566           16    236,535.4    1.4   2932917818                  
SELECT * FROM FIND_LATER_WO ORDER BY NOTE,ORDER_NO                            
                                                                                
     1,200,976            3    400,325.3     .4   4122791109                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                               
       923,944            9    102,660.4     .3   2200071737                  
  SELECT  "ITEM_STOCK"."ITEM_NO" ,           "ITEM_STOCK"."STOCK_NO" ,        
                                                                              
       921,301            3    307,100.3     .3   2218843294                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                              
       911,285            3    303,761.7     .3   1769130587                  
  SELECT  "LISTS"."ITEM_NO" ,           "LISTS"."SUB_ITEM" ,           "LISTS"
                                                                              
       831,439            2    415,719.5     .3   1349577999                  
  SELECT  "GROUP_OPER"."ITEM_NO" ,           "GROUP_OPER"."PROCESS_ID" ,      
                                                                              
       802,918            1    802,918.0     .3   3613809507                  
  SELECT  "LISTS"."ITEM_NO" ,           "LISTS"."SUB_ITEM" ,           "ITEM".
                                                                              
       800,548            2    400,274.0     .3   2643788247                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                              
       666,085            2    333,042.5     .2   3391363608                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM_STOCK"."STOCK_NO",        
          ………..                                                               

注意到以上很多查詢導致的Buffer Gets都非常龐大,我們非常有理由懷疑索引存在問題,甚至缺少必要的索引。
以上記錄的是SQL的片段,通過Hash Value值結合v$sql_text我們可以獲得完整的SQL語句。

在這次診斷中,我緊接著去查詢的是v$session_longops資料表,一個分組查詢的結果如下:

TARGET                                  COUNT(*)
---------------------------------------------------------------- ----------
SA.PPBT_GRAPHOBJTABLE                  418
SA.PPBT_PPBTOBJRELATTABLE              53

我們發現這些問題SQL的全表掃描(結合v$session_longops檢視中的OPNAME)主要集中在PPBT_GRAPHOBJTABLE和
PPBT_PPBTOBJRELATTABLE兩張資料表上。
進一步研究發現這兩個資料表上沒有任何索引,並且有相當的資料量:

SQL> select count(*) from SA.PPBT_PPBTOBJRELATTABLE;

  COUNT(*)
----------
   1209017
 SQL> select count(*) from SA.PPBT_GRAPHOBJTABLE;

   COUNT(*)
----------
      2445

在建立了合適的索引後,系統效能得到了大幅提高!
原文地址:http://www.eygle.com/statspack/statspack12.htm

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8750110/viewspace-6857/,如需轉載,請註明出處,否則將追究法律責任。

相關文章