|
這種情況通常顯示與全表掃描相關(guān)的等待。
當(dāng)數(shù)據(jù)庫進(jìn)行全表掃時，基于性能的考慮，數(shù)據(jù)會分散(scattered)讀入Buffer
Cache。如果這個等待事件比較顯著，
可能說明對于某些全表掃描的表，沒有創(chuàng)建索引或者沒有創(chuàng)建合適的索引，我們可能需要檢查這些數(shù)據(jù)表已確定是否進(jìn)
行了正確的設(shè)置。
然而這個等待事件不一定意味著性能低下，在某些條件下Oracle會主動使用全表掃描來替換索引掃描以提高性能，這
和訪問的數(shù)據(jù)量有關(guān)，在CBO下Oracle會進(jìn)行更為智能的選擇，在RBO下Oracle更傾向于使用索引。
因?yàn)槿頀呙璞恢糜贚RU（Least Recently Used，最近最少適用）列表的冷端（cold
end），對于頻繁訪問的較
小的數(shù)據(jù)表，可以選擇把他們Cache到內(nèi)存中，以避免反復(fù)讀取。
當(dāng)這個等待事件比較顯著時，可以結(jié)合v$session_longops動態(tài)性能視圖來進(jìn)行診斷，該視圖中記錄了長時間（運(yùn)
行時間超過6秒的）運(yùn)行的事物，可能很多是全表掃描操作（不管怎樣，這部分信息都是值得我們注意的）。
我們通過通過一個案例分析來熟悉一下這個等待事件:
DB Name DB Id Instance Inst Num Release OPS Host
---------- ----------- ---------- -------- ---------- ---- ----------
K2 1999167370 k2 1 8.1.5.0.0 NO k2
這是一個8.1.5的數(shù)據(jù)庫系統(tǒng)，通過腳本增強(qiáng)，我們可以在8.1.5的數(shù)據(jù)庫上使用statspack來進(jìn)行數(shù)據(jù)庫診斷。
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
-------------------------------------------------------------
這是一個典型的性能低下的系統(tǒng)，幾個重要的等待事件都在Top 5中出現(xiàn)，其中，前3個等待極為顯著，需要進(jìn)行
相應(yīng)的調(diào)整。
在5小時的采樣間隔內(nèi)，其中db file scattered read累計等待時間約10小時，已經(jīng)成為影響系統(tǒng)性能的主要原因。
了解了這些以后我們就可以進(jìn)一步察看相關(guān)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",
………..
注意到以上很多查詢導(dǎo)致的Buffer Gets都非常龐大，我們非常有理由懷疑索引存在問題，甚至缺少必要的索引。
以上記錄的是SQL的片段，通過Hash Value值結(jié)合v$sql_text我們可以獲得完整的SQL語句。
在這次診斷中，我緊接著去查詢的是v$session_longops數(shù)據(jù)表，一個分組查詢的結(jié)果如下:
TARGET COUNT(*)
---------------------------------------------------------------- ----------
SA.PPBT_GRAPHOBJTABLE 418
SA.PPBT_PPBTOBJRELATTABLE 53
我們發(fā)現(xiàn)這些問題SQL的全表掃描(結(jié)合v$session_longops視圖中的OPNAME)主要集中在PPBT_GRAPHOBJTABLE和
PPBT_PPBTOBJRELATTABLE兩張數(shù)據(jù)表上。
進(jìn)一步研究發(fā)現(xiàn)這兩個數(shù)據(jù)表上沒有任何索引，并且有相當(dāng)?shù)臄?shù)據(jù)量:
SQL> select count(*) from SA.PPBT_PPBTOBJRELATTABLE;
COUNT(*)
----------
1209017
SQL> select count(*) from SA.PPBT_GRAPHOBJTABLE;
COUNT(*)
----------
2445
在創(chuàng)建了合適的索引后，系統(tǒng)性能得到了大幅提高!
|
|
