5.首要等待事件
常見等待事件說明：
oracle等待事件是衡量oracle執行狀況的重要依據及指示，主要有空閒等待事件和非空閒等待事件。
TIMED_STATISTICS：=TRUE，等待事件按等待的時間排序，= FALSE，等待事件按等待的數量排序。
執行statspack期間必須session上設定TIMED_STATISTICS = TRUE。
空閒等待事件是oracle正等待某種工作，在診斷和最佳化資料庫時候，不用過多注意這部分事件，非空閒等待事件專門針對oracle的活動，指資料庫任務或應用程式執行過程中發生的等待，這些等待事件是我們在調整資料庫應該關注的。

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 22,154 259 62.14
CPU time 49 11.67
log file parallel write 2,439 26 6.30
db file parallel write 400 22 5.32
SQL*Net message from dblink 4,575 15 3.71
-------------------------------------------------------------

這裡是比其他任何事件都能使速度減慢的事件。比較影響效能的常見等待事件：
db file scattered read：該事件通常與全表掃描有關。因為全表掃描是被放入記憶體中進行的進行的，通常情況下它不可能被放入連續的緩衝區中，所以就散佈在緩衝區的快取中。該指數的數量過大說明缺少索引或者限制了索引的使用(也可以調整optimizer_index_cost_adj)。這種情況也可能是正常的，因為執行全表掃描可能比索引掃描效率更高。當系統存在這些等待時，需要透過檢查來確定全表掃描是否必需的來調整。如果經常必須進行全表掃描，而且表比較小，把該表存人keep池。如果是大表經常進行全表掃描，那麼應該是OLAP系統，而不是OLTP的。
db file sequential read：該事件說明在單個資料塊上大量等待，該值過高通常是由於表間連線順序很糟糕，或者使用了非選擇性索引。透過將這種等待與statspack報表中已知其它問題聯絡起來(如效率不高的sql),透過檢查確保索引掃描是必須的，並確保多表連線的連線順序來調整, DB_CACHE_SIZE可以決定該事件出現的頻率。
db file sequential read：該事件說明在單個資料塊上大量等待，該值過高通常是由於表間連線順序很糟糕，或者使用了非選擇性索引。透過將這種等待與statspack報表中已知其它問題聯絡起來（如效率不高的sql），透過檢查確保索引掃描是必須的，並確保多表連線的連線順序來調整，DB_CACHE_SIZE可以決定該事件出現的頻率。
buffer busy wait：當緩衝區以一種非共享方式或者如正在被讀入到緩衝時，就會出現該等待。該值不應該大於1%，確認是不是由於熱點塊造成（如果是可以用反轉索引，或者用更小塊大小）。
latch free：常跟應用沒有很好的應用繫結有關。閂鎖是底層的佇列機制（更加準確的名稱應該是互斥機制），用於保護系統全域性區（SGA）共享記憶體結構閂鎖用於防止對記憶體結構的並行訪問。如果閂鎖不可用，就會記錄一次閂鎖丟失。絕大多數得閂鎖問題都與使用繫結變數失敗（庫快取閂鎖）、生成重作問題（重執行分配閂鎖）、快取的爭用問題(快取LRU鏈) 以及快取的熱資料寬塊(快取鏈)有關。當閂鎖丟失率高於0.5%時，需要調整這個問題。
log buffer space：日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度，可以增大日誌檔案大小，增加日誌緩衝區的大小，或者使用更快的磁碟來寫資料。
logfile switch：通常是因為歸檔速度不夠快，需要增大重做日誌。
log file sync：當一個使用者提交或回滾資料時，LGWR將會話得重做操作從日誌緩衝區填充到日誌檔案中，使用者的程式必須等待這個填充工作完成。在每次提交時都出現，如果這個等待事件影響到資料庫效能，那麼就需要修改應用程式的提交頻率, 為減少這個等待事件，須一次提交更多記錄，或者將重做日誌REDO LOG檔案訪在不同的物理磁碟上。
Wait time: 等待時間包括日誌緩衝的寫入和傳送操作。

6.資料庫使用者程式發生的所有等待事件

Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 22,154 0 259 12 886.2
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
SQL*Net message from dblink 4,575 0 15 3 183.0
SQL*Net more data from dblin 64,490 0 13 0 2,579.6
control file parallel write 416 0 5 13 16.6
db file scattered read 456 0 5 11 18.2
write complete waits 9 0 5 568 0.4
control file sequential read 370 0 5 13 14.8
log buffer space 126 0 4 34 5.0
free buffer waits 11 1 3 313 0.4
log file switch completion 13 0 2 188 0.5
log file sync 90 0 1 8 3.6
log file sequential read 10 0 0 16 0.4
latch free 17 6 0 8 0.7
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
SQL*Net more data to client 173 0 0 0 6.9
SQL*Net message to dblink 4,575 0 0 0 183.0
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
db file single write 5 0 0 0 0.2
SQL*Net break/reset to clien 5 0 0 0 0.2
async disk IO 15 0 0 0 0.6
SQL*Net message from client 789 0 3,290 4170 31.6
virtual circuit status 36 36 1,082 30069 1.4
wakeup time manager 34 34 1,034 30403 1.4
SQL*Net message to client 791 0 0 0 31.6
SQL*Net more data from clien 30 0 0 0 1.2
-------------------------------------------------------------

7.資料庫後臺程式發生的等待事件

Background Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
control file parallel write 406 0 5 13 16.2
control file sequential read 258 0 4 16 10.3
db file sequential read 19 0 1 51 0.8
log buffer space 24 0 0 9 1.0
log file sequential read 10 0 0 16 0.4
latch free 14 6 0 9 0.6
db file scattered read 6 0 0 14 0.2
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
rdbms ipc message 7,339 3,337 3,172 432 293.6
pmon timer 373 373 1,083 2903 14.9
smon timer 3 3 924 ###### 0.1
-------------------------------------------------------------

8.TOP SQL

調整首要的25個緩衝區讀操作和首要的25個磁碟讀操作做的查詢，將可對系統效能產生5%到5000%的增益。

SQL ordered by Gets for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> 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

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
1,230,745 1 1,230,745.0 27.5 16.39 60.69 1574310682
Module: PL/SQL Developer
insert into city_day_cal select * from 1

143,702 1 143,702.0 3.2 1.75 18.66 3978122706
Module: PL/SQL Developer
insert into city_day_cal select * from 1 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1

在報表的這一部分，透過Buffer Gets對SQL語句進行排序，即透過它執行了多少個邏輯I/O來排序。頂端的註釋表明一個PL/SQL單元的快取獲得(Buffer Gets)包括被這個程式碼塊執行的所有SQL語句的Buffer Gets。因此將經常在這個列表的頂端看到PL/SQL過程，因為儲存過程執行的單獨的語句的數目被總計出來。

SQL ordered by Reads for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> End Disk Reads Threshold: 1000

CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
3,587 1 3,587.0 13.9 0.17 5.13 3342983569
Module: PL/SQL Developer
select min(curtime),max(curtime) from city_day_cal

1,575 1 1,575.0 6.1 1.75 18.66 3978122706
Module: PL/SQL Developer
insert into city_day_cal select * from 1 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1

這部分透過物理讀對SQL語句進行排序。這顯示引起大部分對這個系統進行讀取活動的SQL，即物理I/O。

SQL ordered by Executions for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> End Executions Threshold: 100

CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
748 748 1.0 0.00 0.00 3371479671
select t.name, (select owner_instance from sys.aq$_queue_table_
affinities where table_objno = t.objno) from system.aq$_queue
_tables t where t.name = :1 and t.schema = :2 for update skip lo
cked

442 1,142 2.6 0.00 0.00 1749333492
select position#,sequence#,level#,argument,type#,charsetid,chars
etform,properties,nvl(length, 0), nvl(precision#, 0),nvl(scale,
0),nvl(radix, 0), type_owner,type_name,type_subname,type_linknam
e,pls_type from argument$ where obj#=:1 and procedure#=:2 order
by sequence# desc

這部分告訴我們在這段時間中執行最多的SQL語句。為了隔離某些頻繁執行的查詢，以觀察是否有某些更改邏輯的方法以避免必須如此頻繁的執行這些查詢，這可能是很有用的。或許一個查詢正在一個迴圈的內部執行，而且它可能在迴圈的外部執行一次，可以設計簡單的演算法更改以減少必須執行這個查詢的次數。即使它執行的飛快，任何被執行幾百萬次的操作都將開始耗盡大量的時間。

[@more@]

Statspack分析報告詳解(3)

相關文章