教學鏈接：http://www.tudou.com/programs/view/Dp_YYjvX-KM/ --感謝maclean大師
WORKLOAD REPOSITORY report for
|
DB Name |
DB Id |
Instance |
Inst num |
Release |
RAC |
Host |
|
ICCI |
1314098396 |
ICCI1 |
1 |
10.2.0.3.0 |
YES |
HPGICCI1 |
|
|
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
|
Begin Snap: |
2678 |
25-Dec-08 14:04:50 |
24 |
1.5 |
|
End Snap: |
2680 |
25-Dec-08 15:23:37 |
26 |
1.5 |
|
Elapsed: |
|
78.79 (mins) |
|
|
|
DB Time: |
|
11.05 (mins) |
|
|
這裏是一些基本信息。跨度爲3個快照。一共經過了79分鐘左右，在79分鐘裏（其間收集了3次快照數據），數據庫耗時11分鐘，RDA數據中顯示系統有8個邏輯CPU（4個物理CPU），平均每個CPU耗時11/8=1.4分鐘，CPU利用率只有大約2%（1.4/79）。說明系統壓力非常小。
BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
比如：服務器是AIX的系統，4個雙核cpu,共8個核:
/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7
CPU就總共花費了80*1=80分鐘，11/80=13%,負載很低了
DB TIME= 所有前臺session花費在database調用上的總和時間。不包括Oracle後臺進程消耗的時間。如果DB Time遠遠小於Elapsed時間，說明數據庫比較空閒。但還要注意的是不同的系統，不同的時間段系統繁忙的程度不同，不然AWR報告分析結果沒有意義。
補充：AVERAGE ACTIVE SESSION 平均活躍會話
AVERAGE ACTIVE SESSION=db time/elapsed time ，AAS 接近1 說明此採樣時間段數據庫負載一般，ASS 小於1說明此採樣時間段數據負載小，AAS 遠遠大於1 說明此採樣時間段數據庫負載高，最上面的awr報告中，11/78<1，代表負載很小
elapsed time：自然流失時間，等於兩個快照之間的時間
DB time = DB CPU time + all of nonidle wait event time+WAIT ON CPU QUEUE TIME（不包含空閒等待）
說白了就是db time就是記錄的服務器花在數據庫運算(非後臺進程)和等待(非空閒等待)上的時間
舉例：
如果僅有2個邏輯CPU，而2個session在60分鐘都沒等待事件，一直跑在CPU上，那麼：
DB CPU= 2 * 60 mins， DB Time = 2* 60 + 0 + 0 =120， AAS = 120/60=2 正好等於OS load 2。
如果有3個session都100%僅消耗CPU，那麼總有一個要wait on queue
DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins
AAS= (120+ 60)/60=3 è 主機load 亦爲3，此時vmstat 看waiting for run time
真實世界中？
DB Cpu = xx mins，Non-Idle Wait= enq:TX + cursor pin S on X + latch : xxx + db file sequential read + ……
注意：DB TIME不等於響應時間，DB TIME高了未必響應慢，DB TIME低了未必響應快,DB Time描繪了數據庫總體負載，但要和elapsed time逝去時間結合其他來。
結合：Time Model Statistics 來理解
Total time in database user-calls (DB Time): 663s
Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
Ordered by % or DB time desc, Statistic name x
|
Statistic Name |
Time (s) |
% of DB Time |
|
DB CPU |
514.50 |
77.61 |
|
sql execute elapsed time |
482.27 |
72.74 |
|
parse time elapsed |
3.76 |
0.57 |
|
PL/SQL execution elapsed time |
0.50 |
0.08 |
|
hard parse elapsed time |
0.34 |
0.05 |
|
connection management call elapsed time |
0.08 |
0.01 |
|
hard parse (sharing criteria) elapsed time |
0.00 |
0.00 |
|
repeated bind elapsed time |
0.00 |
0.00 |
|
PL/SQL compilation elapsed time |
0.00 |
0.00 |
|
failed parse elapsed time |
0.00 |
0.00 |
|
DB time |
662.97 |
|
|
background elapsed time |
185.19 |
|
|
background cpu time |
67.48 |
|
此節顯示了各種類型的數據庫處理任務所佔用的CPU時間。
補充：時間模型
至於DB對CPU的利用情況，這就涉及到10g新引入的一個關於時間統計的視圖V$SYS_TIME_MODEL，
簡單而言，Oracle採用了一個統一的時間模型對一些重要的時間指標進行了記錄，具體而言，這些指標包括：
1) Background elapsed time
2) Background CPU time
3) RMAN CPU time (backup/restore)
1) DB time
2) DB CPU
2) Connection management call elapsed time
2) Sequence load elapsed time
2) SQL execute elapsed time
2) Parse time elapsed
3) Hard parse elapsed time
4) Hard parse (sharing criteria) elapsed time
5) Hard parse (bind mismatch) elapsed time
3) Failed parse elapsed time
4) Failed parse (out of shared memory) elapsed time
2) PL/SQL execution elapsed time
2) Inbound PL/SQL RPC elapsed time
2) PL/SQL compilation elapsed time
2) Java execution elapsed time
2) Repeated bind elapsed time
這裏我們關注的只有和CPU相關的兩個： Background CPU time 和 DB CPU。
Report Summary
Cache Sizes
|
|
Begin |
End |
|
|
|
Buffer Cache: |
3,344M |
3,344M |
Std Block Size: |
8K |
|
Shared Pool Size: |
704M |
704M |
Log Buffer: |
14,352K |
顯示SGA中每個區域的大小（在AMM改變它們之後），可用來與初始參數值比較。內存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target) ,小內存有小內存的問題， 大內存有大內存的麻煩！小內存有時候報ORA-04031 4030。大內存會存在頁管理、page table..等問題.
shared pool主要包括library cache和dictionary cache。library cache用來存儲最近解析（或編譯）後SQL、PL/SQL和Java classes等。library cache用來存儲最近引用的數據字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多。因此shared pool的設置要確保最近使用的數據都能被cache。
Buffer cache和shared pool size的 begin/end值在ASMM、AMM和11gR2 MSMM下可是會動的哦！
這裏說 shared pool一直收縮，則在shrink過程中一些row cache 對象被lock住可能導致前臺row cache lock等解析等待，最好別讓shared pool shrink。如果這裏shared pool一直在grow，那說明shared pool原有大小不足以滿足需求(可能是大量硬解析)，結合下文的解析信息和SGA breakdown來一起診斷問題。
這裏硬解析超級大，Hard parses大於每秒100、全部parses超過每秒300表明可能有爭用問題
Load Profile
|
|
Per Second |
Per Transaction |
|
Redo size: |
918,805.72 |
775,912.72 |
|
Logical reads: |
3,521.77 |
2,974.06 |
|
Block changes: |
1,817.95 |
1,535.22 |
|
Physical reads: |
68.26 |
57.64 |
|
Physical writes: |
362.59 |
306.20 |
|
User calls: |
326.69 |
275.88 |
|
Parses: |
38.66 |
32.65 |
|
Hard parses: |
0.03 |
0.03 |
|
Sorts: |
0.61 |
0.51 |
|
Logons: |
0.01 |
0.01 |
|
Executes: |
354.34 |
299.23 |
|
Transactions: |
1.18 |
|
顯示數據庫負載概況，將之與基線數據比較才具有更多的意義，如果每秒或每事務的負載變化不大，說明應用運行比較穩定。單個的報告數據只說明應用的負載情況，絕大多數據並沒有一個所謂“正確”的值，然而Logons大於每秒1~2個、Hard parses大於每秒100、全部parses超過每秒300表明可能有爭用問題。
其中Hard parses：其中硬解析的次數，硬解析太多，說明SQL重用率不高。
Redo size：每秒產生的日誌大小(單位字節)，可標誌數據變更頻率, 大的redo size往往對lgwr寫日誌，和arch歸檔造成I/O壓力， 也有可能造成log buffer 堵塞（注意，這裏不是進程慢，而是由於i/o導致）從而產生相關的等待事件。很繁忙的系統中日誌生成量可能達到幾百k，甚至幾M。如果等待事件中有LOG方面的等待事件，說明REDO生成的頻率太高。等待就要考慮增加log buffer。如果真的出現LOG BUFFER小了，大家記住算法，redo size * 600 > LOG BUFFER，10分鐘內生成的REDO大於LOG BUFFER。這裏的 918,805.72*600/1024/1024=525M>23M,已經很大了，所以需要提高LGWR的效率了，那麼這裏還需要結合TOP 5 TIMED EVENTS處理。但後面的TOP 5沒有IO等待，那麼這裏沒有問題。
Per Transaction可以用來分辨是 大量小事務， 還是少量大事務。如上例每秒redo 約900多K，每個事務7k，符合OLTP特徵（很多小事務）.
補充：logbuffer 理論上不超過32m，增大不益，等於浪費。
Logical reads：每秒/每事務邏輯讀的塊數.平決每秒產生的邏輯讀的block數。Logical Reads= Consistent Gets + DB Block Gets 當前讀+一致性讀 這裏的邏輯讀爲3521*8K=28000K, 大量OLTP系統(例如siebel)可以高達幾十乃至上百Gbytes。邏輯讀耗CPU，主頻和CPU核數都很重要，邏輯讀高則DB CPU往往高，也往往可以看到latch: cache buffer chains
Block changes：每秒/每事務修改的塊數
Physical reads：每秒/每事務物理讀的塊數，物理讀消耗IO讀，體現在IOPS和吞吐量等不同緯度上；但減少物理讀可能意味着消耗更多CPU。好的存儲 每秒物理讀能力達到幾GB，例如Exadata
Physical writes：每秒/每事務物理寫的塊數。主要是DBWR寫datafile，也有direct path write。 dbwr長期寫出慢會導致定期log file switch(checkpoint no complete) 檢查點無法完成的前臺等待。
User calls：每秒/每事務用戶call次數，通常執行一次需要多次用戶調用，最優的情況是用戶調用跟執行數接近，但只是指導，沒有特別的意義。比如：一個存儲過程中出現調用一次，執行兩次的情況。差太多，有可能是存儲過程多。
Parses:包括軟解析+硬解析，不包括軟軟解析（fast parse），軟解析優化得不好，則誇張地說幾乎等於每秒SQL執行次數。 即執行解析比1:1，而我們希望的是解析一次 到處運行哦！
SQL解析的次數.每秒解析次數，軟解析每秒超過300次意味着你的"應用程序"效率不高,因爲要重複的打開私有CURSOR。要實現軟軟解析，優化程序設計需要調整session_cursor_cache。在這裏，fast parse指的是直接在PGA中命中的情況（設置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse則是指都不命中的情況。
Hard parses:Cursor pin s on X， library cache: mutex X ， latch: row cache objects /shared pool……………..。 硬解析最好少於每秒20次
每秒產生的硬解析次數, 每秒超過100次，就可能說明你綁定使用的不好，也可能是共享池設置不合理。這時候可以啓用參數cursor_sharing=similar|force，該參數默認值爲exact。但該參數設置爲similar時，存在bug，可能導致執行計劃的不優
Sorts：每秒/每事務的排序次數
Logons：每秒/每事務登錄的次數，如果系統應用採用長連接，這裏基本沒有問題。如果採用大量短連接，這裏的登錄次數非常高，會產生登錄風暴（短時間內大量用戶嘗試登錄）。 weblogic等中間件分配的連接就是長連接
Executes：每秒/每事務SQL執行次數
Transactions：每秒事務數，簡稱TPS，可以看做壓力測試或比對性能是的一個指標，孤立看無意義。 還有一個QPS(query per sec)
每秒的事務數，這是一個OLTP數據庫事務規模的重要指標。通常爲個位，十位的單位,大的事務數據庫，可能有TPS到百，千
|
% Blocks changed per Read: |
51.62 |
Recursive Call %: |
51.72 |
|
Rollback per transaction %: |
85.49 |
Rows per Sort: |
######## |
Blocks changed per Read：表示邏輯讀用於修改數據塊的比例.在每一次邏輯讀中更改的塊的百分比。
Recursive Call：遞歸調用佔所有操作的比率，如果有很多PL/SQL，那麼這個值就會比較高。
Rollback per transaction：每事務的回滾率
每事務的回滾率.看回滾率是不是很高，因爲回滾很耗資源 ,如果回滾率過高,可能說明你的數據庫經歷了太多的無效操作 ,過多的回滾可能還會帶來Undo Block的競爭 該參數計算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。但是這個指標不太精確，參考而已，
Rows per Sort：每次排序的行數
Oracle的硬解析和軟解析
提到軟解析(soft parse)和硬解析(hard parse)，就不能不說一下Oracle對sql的處理過程。當你發出一條sql語句交付Oracle，在執行和獲取結果前，Oracle對此sql將進行幾個步驟的處理過程：
1、語法檢查(syntax check)
檢查此sql的拼寫是否語法。
2、語義檢查(semantic check)
諸如檢查sql語句中的訪問對象是否存在及該用戶是否具備相應的權限。
3、對sql語句進行解析(parse)
利用內部算法對sql進行解析，生成解析樹(parse tree)及執行計劃(execution plan)。
4、執行sql，返回結果(execute and return)
其中，軟、硬解析就發生在第三個過程裏。
Oracle利用內部的hash算法來取得該sql的hash值，然後在library cache裏查找是否存在該hash值；
假設存在，則將此sql與cache中的進行比較；
假設“相同”，就將利用已有的解析樹與執行計劃，而省略了優化器的相關工作。這也就是軟解析的過程。
誠然，如果上面的2個假設中任有一個不成立，那麼優化器都將進行創建解析樹、生成執行計劃的動作。這個過程就叫硬解析。
創建解析樹、生成執行計劃對於sql的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，儘量使用軟解析。
硬解析案例：
硬解析數和 hard parse elapsed time對應， 看一眼Time Model Statistics，即可知該系統是否 是 解析敏感的，然後根據TOP5 進一步觀察。
Instance Efficiency（效率） Percentages (Target 100%)
基於命中率的調優方法已經過時，但仍然具有參考價值
|
Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
|
Buffer Hit %: |
98.72 |
In-memory Sort %: |
99.86 |
|
Library Hit %: |
99.97 |
Soft Parse %: |
99.92 |
|
Execute to Parse %: |
89.09 |
Latch Hit %: |
99.99 |
|
Parse CPU to Parse Elapsd %: |
7.99 |
% Non-Parse CPU: |
99.95 |
本節包含了Oracle關鍵指標的內存命中率及其它數據庫實例操作的效率。
其中Buffer Hit Ratio 也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節相同，這一節也沒有所謂“正確”的值，而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型並行查詢的DSS環境，20%的Buffer Hit Ratio是可以接受的，而這個值對於一個OLTP系統是完全不能接受的。根據Oracle的經驗，對於OLTPT系統，Buffer Hit Ratio理想應該在90%以上。
Buffer Nowait :表示在內存獲得數據的未等待比例。在緩衝區中獲取Buffer的未等待比率。Buffer Nowait的這個值一般需要大於99%。否則可能存在爭用，可以在後面的等待事件中進一步確認。
buffer hit:表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，如果此值低於80%，應該給數據庫分配更多的內存。數據塊在數據緩衝區中的命中率，通常應在95%以上。否則，小於95%，需要調整重要的參數，小於90%可能是要加db_cache_size。一個高的命中率，不一定代表這個系統的性能是最優的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的db file sequential read），但是一個比較低的命中率，一般就會對這個系統的性能產生影響，需要調整。命中率的突變，往往是一個不好的信息。如果命中率突然增大，可以檢查top buffer get SQL，查看導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。
在OLAP主要是IO操作，低的命中率影響不大，因爲大的數據訪問需要BUFFER塊的回收。
注意有時不合理的使用大的索引，會頻繁命中索引塊，造成很高的緩衝區命中率。
有時候指標會出現負數，BUFFER 命中率變負數是由於buffer cache太小經常被換出，而又經常被重新讀入。沒有命中，而且沒命中的BUFFER還經常的被擠掉，就會產生負數
例子：100個 A 一致性讀塊，沒一個人去要 A塊，沒有1個命中，而且還有55個 A 塊還被擠掉了，那命中率是多少？-45%
Redo NoWait:表示在LOG緩衝區獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。當redo buffer達到1M時，就需要寫到redo log文件，所以一般當redo buffer設置超過1M，不太可能存在等待buffer空間分配的情況。當前，一般設置爲2M的redo buffer，對於內存總量來說，應該不是一個太大的值。
library hit:表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，並在Library Cache中爲它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低性能。如果library hit ratio低於90%，可能需要調大shared pool區。STATEMENT在共享區的命中率，通常應該保持在95%以上，否則需要要考慮：加大共享池；使用綁定變量；修改cursor_sharing等參數。
Latch Hit：Latch是一種保護內存結構的鎖，可以認爲是SERVER進程獲取訪問內存數據結構的許可。要確保Latch Hit>99%，否則意味着Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用綁定變更或調大Shared Pool解決。要確保>99%，否則存在嚴重的性能問題。當該值出現問題的時候，我們可以藉助後面的等待時間和latch分析來查找解決問題。
Parse CPU to Parse Elapsd：（CPU解析時間和CPU等待時間比）解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。如果該比率爲100%，意味着CPU等待時間爲0，沒有任何等待。
Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。計算公式爲：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個值比較小，表示解析消耗的CPU時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。計算公式爲：Execute to Parse =100 * (1 - Parses/Executions)。本例中，差不多每execution 5次需要一次parse。所以如果系統Parses > Executions，就可能出現該比率小於0的情況，語句只分析不執行。該值<0通常說明shared pool設置或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,或者是可能同snapshot有關，通常說明數據庫性能存在問題。
In-memory Sort：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA。如果低於95%，可以通過適當調大初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個參數設置作用的範圍時不同的，SORT_AREA_SIZE是針對每個session設置的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。
Soft Parse：軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用綁定變量。sql在共享區的命中率，小於<95%,需要考慮綁定，如果低於80%，那麼就可以認爲sql基本沒有被重用
雖然軟解析比硬解析效率高，但是過度的軟解析，會對LATCH有些影響，因爲畢竟不是軟軟解析，如果你發現LATCH，特別是LIBRARY CACHE LATCH很高，而軟解析率雖然很高，比如60%以上，說明你軟解析率可能還是過度了
補充：軟解析，需要通過HASH定位到LIBRARY CACHE鏈，需要LIBRARY CACHE PIN，以及要獲取LIBRARY CACHE 鏈的LATCH，如果多個會話同時軟解析同一條SQL，要獲取同一個LIBRARY CACHE 鏈的LATCH，就有衝突了。
Shared Pool Statistics （這個不是整個共享池而言，而是針對SQL佔用共享池而言）
|
|
Begin |
End |
|
Memory Usage %: |
47.19 |
47.50 |
|
% SQL with executions>1: |
88.48 |
79.81 |
|
% Memory for SQL w/exec>1: |
79.99 |
73.52 |
Memory Usage %：對於一個已經運行一段時間的數據庫來說，共享池內存使用率，應該穩定在75%-90%間，如果太小，說明Shared Pool有浪費，而如果高於90，說明共享池中有爭用，內存不足。
如果這個百分比太低，表明共享池設置過大，帶來額外的管理上的負擔，從而在某些條件下會導致性能的下降。如果這個百分率太高，會使共享池外部的組件老化，如果SQL語句被再次執行，這將使得SQL語句被硬解析。在一個大小合適的系統中，共享池的使用率將處於75%到略低於90%的範圍內.
SQL with executions>1：執行次數大於1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析，或者是因爲SHARED POOL太小，被擠出去了，所以可以用這個參數值來判斷執行計劃是不是經常被擠出。
在一個趨向於循環運行的系統中，必須認真考慮這個數字。在這個循環系統中，在一天中相對於另一部分時間的部分時間裏執行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執行過的SQL語句，這僅僅是因爲要執行它們的語句在觀察期間沒有運行。只有系統連續運行相同的SQL語句組，這個數字纔會接近100%。
如果該環節中% SQL with executions>1的 比例 小於%90 ， 考慮用下面鏈接的SQL去抓 硬編碼的非綁定變量SQL語句。
http://www.askmaclean.com/archives/%E5%88%A9%E7%94%A8force_matching_signature%E6%8D%95%E8%8E%B7%E9%9D%9E%E7%BB%91%E5%AE%9A%E5%8F%98%E9%87%8Fsql.html
Memory for SQL w/exec>1：執行次數大於1的SQL消耗內存的佔比。這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內存多少的一個度量。這個數字將在總體上與% SQL with executions>1非常接近，除非有某些查詢任務消耗的內存沒有規律。在穩定狀態下，總體上會看見隨着時間的推移大約有75%～85%的共享池被使用。如果Statspack報表的時間窗口足夠大到覆蓋所有的週期，執行次數大於一次的SQL語句的百分率應該接近於100%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。
ASMM中shared pool的大小會產生變化，穩定的系統此項指標應該維持在75-90%左右
小結：通過ORACLE的實例有效性統計數據，我們可以獲得大概的一個整體印象，然而我們並不能由此來確定數據運行的性能。當前性能問題的確定，我們主要還是依靠下面的等待事件來確認。我們可以這樣理解兩部分的內容，hit統計幫助我們發現和預測一些系統將要產生的性能問題，由此我們可以做到未雨綢繆。而wait事件，就是表明當前數據庫已經出現了性能問題需要解決，所以是亡羊補牢的性質。
Top 5 Timed Events （調優的主流，每個指標都重要）
|
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
|
CPU time |
|
515 |
|
77.6 |
|
|
SQL*Net more data from client |
27,319 |
64 |
2 |
9.7 |
Network |
|
log file parallel write |
5,497 |
47 |
9 |
7.1 |
System I/O |
|
db file sequential read |
7,900 |
35 |
4 |
5.3 |
User I/O |
|
db file parallel write |
4,806 |
34 |
7 |
5.1 |
System I/O |
基於Wait Interface的調優是目前的主流！每個指標都重要！ 基於命中比例的調優，好比是統計局的報告，張財主家財產100萬，李木匠家財
產1萬， 平均財產50.5萬。
基於等待事件的調優，好比馬路上100輛汽車的行駛記錄表，上車用了幾分鐘， 紅燈等了幾分鐘，擁堵塞了幾分鐘。。。
通常，在沒有問題的數據庫中，CPU time總是列在第一個。
但DB CPU/CPU time是Top 1 是好事情嗎？ 未必！ 注意DB CPU不包含 wait on cpu queue！
這是報告概要的最後一節，顯示了系統中最嚴重的5個等待，按所佔等待時間的比例倒序列示。當我們調優時，總希望觀察到最顯著的效果，因此應當從這裏入手確定我們下一步做什麼。例如如果‘buffer busy wait’是較嚴重的等待事件，我們應當繼續研究報告中Buffer Wait和File/Tablespace IO區的內容，識別哪些文件導致了問題。如果最嚴重的等待事件是I/O事件，我們應當研究按物理讀排序的SQL語句區以識別哪些語句在執行大量I/O，並研究Tablespace和I/O區觀察較慢響應時間的文件。如果有較高的LATCH等待，就需要察看詳細的LATCH統計識別哪些LATCH產生的問題。
在這裏，log file parallel write是相對比較多的等待，佔用了7%的CPU時間。
更多的等待事件，參見本報告 的Wait Events一節。
評估io的經驗
計算下平均等待時間：總等待時間/等待次數 IO相關的事件的平均等待時間如果大於20msec毫秒，那IO可能需要優化
1 秒=1000 毫秒(ms) 1 秒=1,000,000 微秒(μs) 47/27319=0.0085 8.5毫秒 後面平均爲9毫秒，IO沒有問題。
補充：LGWR太慢，我們就需要看是不是LOG FILE 寫的操作平均寫超過20毫秒（這裏沒有），如果超過了，那麼就需要優化磁盤介質
Cause Identified: Logwriter is writing too slow
If the size of the log buffer is already large (more than 3 MB), speed up the LGWR background process write operations by ensuring that the I/O devices where the redolog files are stored are not suffering from I/O contention.
Cause Justification
AWR / Statspack:
l log buffer space waits
l The average time for log file parallel write is MORE than 20mSec
TOP 5 timed events 要結合Host CPU、Instance CPU、 SQL ordered by CPU Time一起看哦！
Wait Class 等待事件的類型
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
查詢Oracle 10gR1提供的12個等待事件類：
select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;
|
Wait Class |
Waits |
%Time -outs |
Total Wait Time (s) |
Avg wait (ms) |
Waits /txn |
|
User I/O |
66,837 |
0.00 |
120 |
2 |
11.94 |
|
System I/O |
28,295 |
0.00 |
93 |
3 |
5.05 |
|
Network |
1,571,450 |
0.00 |
66 |
0 |
280.72 |
|
Cluster |
210,548 |
0.00 |
29 |
0 |
37.61 |
|
Other |
81,783 |
71.82 |
28 |
0 |
14.61 |
|
Application |
333,155 |
0.00 |
16 |
0 |
59.51 |
|
Concurrency |
5,182 |
0.04 |
5 |
1 |
0.93 |
|
Commit |
919 |
0.00 |
4 |
4 |
0.16 |
|
Configuration |
25,427 |
99.46 |
1 |
0 |
4.54 |
Wait Events 現實非空閒等待事件後面是空閒等待事件
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)
（1）查詢所有等待事件及其屬性：
select event#, name, parameter1, parameter2, parameter3 from v$event_name order by name;
（2）查詢Oracle 10gR1提供的12個等待事件類：
select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;
wait_event.doc
下面顯示的內容可能來自下面幾個視圖）
V$EVENT_NAME視圖包含所有爲數據庫實例定義的等待事件。
V$SYSTEM_EVENT視圖顯示自從實例啓動後，所有Oracle會話遇到的所有等待事件的總計統計。
V$SESSION_EVENT視圖包含當前連接到實例的所有會話的總計等待事件統計。該視圖包含了V$SYSTEM_EVENT視圖中出現的所有列。它記錄會話中每一個等待事件的總等待次數、已等待時間和最大等待時間。SID列標識出獨立的會話。每個會話中每個事件的最大等待時間在MAX_WAIT列中追蹤。通過用SID列將V$SESSION_EVENT視圖和V$SESSION視圖結合起來，可得到有關會話和用戶的更多信息。
V$SESSION_WAIT視圖提供關於每個會話正在等待的事件或資源的詳細信息。該視圖在任何給定時間，只包含每個會話的一行活動的或不活動的信息。
自從OWI在Oracle 7.0.12中引入後，就具有下來4個V$視圖：
V$EVENT_NAME
V$SESSION_WAIT
V$SESSION_EVENT
V$SYSTEM_EVENT
除了這些等待事件視圖之外，Oracle 10gR1中引入了下列新視圖以從多個角度顯示等待信息：
V$SYSTEM_WAIT_CLASS
V$SESSION_WAIT_CLASS
V$SESSION_WAIT_HISTORY
V$EVENT_HISTOGRAM
V$ACTIVE_SESSION_HISTORY
然而，V$SESSION_WAIT、V$SESSION_WAIT和V$SESSION_WAIT仍然是3個重要的視圖，它們提供了不同粒度級的等待事件統計和計時信息。三者的關係如下：
V$SESSION_WAIT Ì V$SESSION_EVENT ÌV$SYSTEM_EVENT
|
Event |
Waits |
%Time -outs |
Total Wait Time (s) |
Avg wait (ms) |
Waits /txn |
|
SQL*Net more data from client |
27,319 |
0.00 |
64 |
2 |
4.88 |
|
log file parallel write |
5,497 |
0.00 |
47 |
9 |
0.98 |
|
db file sequential read |
7,900 |
0.00 |
35 |
4 |
1.41 |
|
db file parallel write |
4,806 |
0.00 |
34 |
7 |
0.86 |
|
db file scattered read |
10,310 |
0.00 |
31 |
3 |
1.84 |
|
direct path write |
42,724 |
0.00 |
30 |
1 |
7.63 |
|
....... |
........ |
........... |
......... |
....... |
...... |
SQL Statistics
SQL ordered by Sharable Memory
SQL ordered by Cluster Wait Time
本節按各種資源分別列出對資源消耗最嚴重的SQL語句，並顯示它們所佔統計期內全部資源的比例，這給出我們調優指南。例如在一個系統中，CPU資源是系統性能瓶頸所在，那麼優化buffer gets最多的SQL語句將獲得最大效果。在一個I/O等待是最嚴重事件的系統中，調優的目標應該是physical IOs最多的SQL語句。
在STATSPACK報告中，沒有完整的SQL語句，可使用報告中的Hash Value通過下面語句從數據庫中查到：
select sql_text
from stats$sqltext
where hash_value = &hash_value
order by piece;
Segments by Row Lock Waits
當一個進程予在正被其它進程鎖住的數據行上獲得排它鎖時發生這種等待。這種等待經常是由於在一個有主鍵索引的表上做大量INSERT操作。
Operating System Statistics
|
Statistic |
Total |
|
NUM_LCPUS |
0 |
|
NUM_VCPUS |
0 |
|
AVG_BUSY_TIME |
101,442 |
|
AVG_IDLE_TIME |
371,241 |
|
AVG_IOWAIT_TIME |
5,460 |
|
AVG_SYS_TIME |
25,795 |
|
AVG_USER_TIME |
75,510 |
|
BUSY_TIME |
812,644 |
|
IDLE_TIME |
2,971,077 |
|
IOWAIT_TIME |
44,794 |
|
SYS_TIME |
207,429 |
|
USER_TIME |
605,215 |
|
LOAD |
0 |
|
OS_CPU_WAIT_TIME |
854,100 |
|
RSRC_MGR_CPU_WAIT_TIME |
0 |
|
PHYSICAL_MEMORY_BYTES |
8,589,934,592 |
|
NUM_CPUS |
8 |
|
NUM_CPU_CORES |
4 |
NUM_LCPUS： 如果顯示0，是因爲沒有設置LPARS
NUM_VCPUS： 同上。
AVG_BUSY_TIME： BUSY_TIME / NUM_CPUS
AVG_IDLE_TIME： IDLE_TIME / NUM_CPUS
AVG_IOWAIT_TIME： IOWAIT_TIME / NUM_CPUS
AVG_SYS_TIME： SYS_TIME / NUM_CPUS
AVG_USER_TIME： USER_TIME / NUM_CPUSar o
BUSY_TIME： time equiv of %usr+%sys in sar output
IDLE_TIME： time equiv of %idle in sar
IOWAIT_TIME： time equiv of %wio in sar
SYS_TIME： time equiv of %sys in sar
USER_TIME： time equiv of %usr in sar
LOAD： 未知
OS_CPU_WAIT_TIME： supposedly time waiting on run queues
RSRC_MGR_CPU_WAIT_TIME： time waited coz of resource manager
PHYSICAL_MEMORY_BYTES： total memory in use supposedly
NUM_CPUS： number of CPUs reported by OS 操作系統CPU數
NUM_CPU_CORES： number of CPU sockets on motherboard 主板上CPU插槽數
總的elapsed time也可以用以公式計算：
BUSY_TIME + IDLE_TIME + IOWAIT TIME
或：SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME
（因爲BUSY_TIME = SYS_TIME+USER_TIME）
W/A MB processed
W/A MB processed :單位MB W/A workarea workarea中處理的數據數量 結合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Instance Efficiency Percentages (Target 100%)
|
Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
|
Buffer Hit %: |
98.72 |
In-memory Sort %: |
99.86 |
|
Library Hit %: |
99.97 |
Soft Parse %: |
99.92 |
|
Execute to Parse %: |
89.09 |
Latch Hit %: |
99.99 |
|
Parse CPU to Parse Elapsd %: |
7.99 |
% Non-Parse CPU: |
99.95 |
總結：性能優化的多維度理論
• 增加了cpuè更大的併發量，更多的併發爭用
• 調整了Io存儲è 更少的IO，更多的CPU計算，更高的cpu使用率
• Redo寫得慢è影響commit，造成enq:tx和gc buffer busy等待等
• Datafile寫得慢è檢查點完不成，日誌無法切換，前臺DML hang
• Sequence nocacheè INSERT index很容易造成enq:index contention，和row cache lock和 enq:SQ
• 通過數據庫手段優化了性能è 應用本身設計的瓶頸越來越凸顯