1、 Oracle AWR 報(bào)告指標(biāo)全解析 2014-10-16 14:48:04分類： Oracle【性能調(diào)優(yōu)】Oracle AWR 報(bào)告指標(biāo)全解析2013/08/31 BY MACLEAN LIU 26 條評(píng)論【性能調(diào)優(yōu)】Oracle AWR 報(bào)告指標(biāo)全解析開(kāi) Oracle 調(diào)優(yōu)鷹眼，深入理解 AWR 性能報(bào)告：http:/ Oracle 調(diào)優(yōu)鷹眼，深入理解 AWR 性能報(bào)告 第二講： http:/ 文章出處：http:/ 有同學(xué)在看過(guò)Oracle 調(diào)優(yōu)鷹眼，深入理解 AWR 性能報(bào)告的教學(xué)視頻后急切期待第三講，但實(shí)際是第三講需要結(jié)合大量的原理知識(shí)才能充分理解 例如 Latch activit

2、y 、Undo、Dynamic Resource Master 均需要理解其原理才能充分理解。 所以這些 AWR 的環(huán)節(jié)將在 Maclean 今后的 系列調(diào)優(yōu)講座中介紹。 對(duì)于Oracle 調(diào)優(yōu)鷹眼系列 則會(huì)增加本附錄，作為對(duì)全部 Oracle AWR 指標(biāo)的介紹， 本附錄對(duì)于原理理解方面的內(nèi)容將不多，而更側(cè)重于指標(biāo)含義的介紹，是對(duì) AWR 鷹眼講座的工具文檔。 如果你覺(jué)得本如果你覺(jué)得本 AWR 解析中的哪些指標(biāo)仍理解不透徹解析中的哪些指標(biāo)仍理解不透徹 或者講的不清楚的，可以在本頁(yè)中留言，謝謝大家的支持?；蛘咧v的不清楚的，可以在本頁(yè)中留言，謝謝大家的支持。 Hawk Eyes 看 AWR 的鷹

3、眼= 基礎(chǔ)理論夯實(shí)+看過(guò) 500 份以上 AWR 啥是 AWR?= AWR (Automatic Workload Repository)一堆歷史性能數(shù)據(jù)，放在 SYSAUX 表空間上， AWR 和 SYSAUX 都是 10g 出現(xiàn)的，是 Oracle 調(diào)優(yōu)的關(guān)鍵特性； 大約 1999 年左右開(kāi)始開(kāi)發(fā)，已經(jīng)有 15 年歷史默認(rèn)快照間隔 1 小時(shí)，10g 保存 7 天、11g 保存 8 天; 可以通過(guò)DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 修改DBA_HIST_WR_CONTROLAWR 程序核心是 dbms_workload_repo

4、sitory 包?/rdbms/admin/awrrpt 本實(shí)例?/rdbms/admin/awrrpti RAC 中選擇實(shí)例號(hào) 誰(shuí)維護(hù) AWR? 主要是 MMON(Manageability Monitor Process)和它的小工進(jìn)程(m00 x)MMON 的功能包括:1.啟動(dòng) slave 進(jìn)程 m00 x 去做 AWR 快照2.當(dāng)某個(gè)度量閥值被超過(guò)時(shí)發(fā)出 alert 告警3.為最近改變過(guò)的 SQL 對(duì)象捕獲指標(biāo)信息 AWR 小技巧 手動(dòng)執(zhí)行一個(gè)快照：Exec dbms_workload_repository.create_snapshot; (這個(gè)要背出來(lái)哦，用的時(shí)候去翻手冊(cè)，丟臉哦

5、J!)創(chuàng)建一個(gè) AWR 基線Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id ,baseline_name);?/rdbms/admin/awrddrpt AWR 比對(duì)報(bào)告?/rdbms/admin/awrgrpt RAC 全局 AWR自動(dòng)生成 AWR HTML 報(bào)告：http:/www.oracle- 1、報(bào)告總結(jié) WORKLOAD REPOSITORY report forDB Name DB Id Instance Inst Num Startup Time Release RAC- - - -

6、 - - -MAC 2629627371 1 22-Jan-13 16:49 .0 YESHost Name Platform CPUs Cores Sockets Memory(GB)- - - - - -MAC10 AIX-Based Systems (64-bit) 128 32 320.00 Snap Id Snap Time Sessions Curs/Sess - - - -Begin Snap: 5853 23-Jan-13 15:00:56 3,520 1.8 End Snap: 5854 23-Jan-13 15:30:41 3,765 1.9 Elapsed

7、: 29.75 (mins) DB Time: 7,633.76 (mins) Elapsed 為該 AWR 性能報(bào)告的時(shí)間跨度(自然時(shí)間的跨度，例如前一個(gè)快照 snapshot 是 4 點(diǎn)生成的，后一個(gè)快照 snapshot 是 6 點(diǎn)生成的，則若使用?/rdbms/admin/awrrpt 腳本中指定這 2 個(gè)快照的話，那么其 elapsed = (6-4)=2 個(gè)小時(shí))，一個(gè) AWR 性能報(bào)告 至少需要 2 個(gè) AWR snapshot 性能快照才能生成 ( 注意這 2 個(gè)快照時(shí)間 實(shí)例不能重啟過(guò)，否則指定這 2 個(gè)快照生成 AWR 性能報(bào)告 會(huì)報(bào)錯(cuò))，AWR 性能報(bào)告中的 指標(biāo)往往是

8、后一個(gè)快照和前一個(gè)快照的 指標(biāo)的 delta，這是因?yàn)?累計(jì)值并不能反映某段時(shí)間內(nèi)的系統(tǒng) workload。 DB TIME= 所有前臺(tái) session 花費(fèi)在 database 調(diào)用上的總和時(shí)間：注意是前臺(tái)進(jìn)程 foreground sessions包括 CPU 時(shí)間、IO Time、和其他一系列非空閑等待時(shí)間，別忘了 cpu on queue timeDB TIME 不等于 響應(yīng)時(shí)間，DB TIME 高了未必響應(yīng)慢，DB TIME 低了未必響應(yīng)快DB Time 描繪了數(shù)據(jù)庫(kù)總體負(fù)載，但要和 elapsed time 逝去時(shí)間結(jié)合其他來(lái)。Average Active Session AAS=

9、 DB time/Elapsed TimeDB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 負(fù)載一般DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 負(fù)載很輕DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系統(tǒng) hang 了吧？ DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue 如果僅有 2 個(gè)邏輯 CPU，而 2 個(gè) session 在 60 分鐘都沒(méi)等待事件，一直跑在 CPU 上，那么： DB

10、 CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120AAS = 120/60=2 正好等于 OS load 2。如果有 3 個(gè) session 都 100%僅消耗 CPU，那么總有一個(gè)要 wait on queueDB CPU = 2* 60 mins ，wait on CPU queue= 60 minsAAS= (120+ 60)/60=3 主機(jī) load 亦為 3，此時(shí) vmstat 看 waiting for run time 真實(shí)世界中？ DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor p

11、in S on X + latch : xxx + db file sequential read + . 阿貓阿狗 1-1 內(nèi)存參數(shù)大小 Cache Sizes Begin End - - Buffer Cache: 49,152M 49,152M Std Block Size: 8K Shared Pool Size: 13,312M 13,312M Log Buffer: 334,848K 內(nèi)存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target) 小內(nèi)存有小內(nèi)存的問(wèn)題， 大內(nèi)存有大內(nèi)存的麻煩！ ORA-04031?! Buffer cache 和 s

12、hared pool size 的 begin/end 值在 ASMM、AMM 和 11gR2 MSMM 下可是會(huì)動(dòng)的哦！ 這里說(shuō) shared pool 一直收縮，則在 shrink 過(guò)程中一些 row cache 對(duì)象被 lock 住可能導(dǎo)致前臺(tái) row cache lock 等解析等待，最好別讓 shared pool shrink。如果這里 shared pool 一直在 grow，那說(shuō)明 shared pool 原有大小不足以滿足需求(可能是大量硬解析)，結(jié)合下文的解析信息和 SGA breakdown 來(lái)一起診斷問(wèn)題。 1-2 Load Profile Load Profile P

13、er Second Per Transaction Per Exec Per Call - - - - DB Time(s): 256.6 0.2 0.07 0.03 DB CPU(s): 3.7 0.0 0.00 0.00 Redo size: 1,020,943.0 826.5 Logical reads: 196,888.0 159.4 Block changes: 6,339.4 5.1 Physical reads: 5,076.7 4.1 Physical writes: 379.2 0.3 User calls: 10,157.4 8.2 Parses: 204.0 0.2 Ha

14、rd parses: 0.9 0.0W/A MB processed: 5.0 0.0 Logons: 1.7 0.0 Executes: 3,936.6 3.2 Rollbacks: 1,126.3 0.9 Transactions: 1,235.3 % Blocks changed per Read: 53.49 Recursive Call %: 98.04 Rollback per transaction %: 36.57 Rows per Sort: 73.70 指標(biāo)指標(biāo)含義redo size單位 bytes，redo size 可以用來(lái)估量 update/insert/delete

15、 的頻率，大的redo size 往往對(duì) lgwr 寫日志，和 arch 歸檔造成 I/O 壓力， Per Transaction 可以用來(lái)分辨是 大量小事務(wù)， 還是少量大事務(wù)。如上例每秒redo 約 1MB ，每個(gè)事務(wù) 800 字節(jié)，符合 OLTP 特征Logical Read單位 次數(shù)*塊數(shù)， 相當(dāng)于 “人*次”， 如上例 196,888 * db_block_size=1538MB/s ， 邏輯讀耗 CPU，主頻和 CPU 核數(shù)都很重要，邏輯讀高則 DB CPU 往往高，也往往可以看到 latch: cache buffer chains 等待。 大量 OLTP 系統(tǒng)(例如 siebel

16、)可以高達(dá)幾十乃至上百 Gbytes。Block changes單位 次數(shù)*塊數(shù) ， 描繪數(shù)據(jù)變化頻率Physical Read單位次數(shù)*塊數(shù)， 如上例 5076 * 8k = 39MB/s， 物理讀消耗 IO 讀，體現(xiàn)在IOPS 和吞吐量等不同緯度上；但減少物理讀可能意味著消耗更多 CPU。好的存儲(chǔ) 每秒物理讀能力達(dá)到幾 GB，例如 Exadata。 這個(gè) physical read 包含了physical reads cache 和 physical reads directPhysical writes單位 次數(shù)*塊數(shù)，主要是 DBWR 寫 datafile，也有 direct path

17、 write。 dbwr 長(zhǎng)期寫出慢會(huì)導(dǎo)致定期 log file switch(checkpoint no complete) 檢查點(diǎn)無(wú)法完成的前臺(tái)等待。 這個(gè) physical write 包含了 physical writes direct +physical writes from cacheUser Calls單位次數(shù)，用戶調(diào)用數(shù)，more details from internalParses解析次數(shù)，包括軟解析+硬解析，軟解析優(yōu)化得不好，則夸張地說(shuō)幾乎等于每秒 SQL 執(zhí)行次數(shù)。 即執(zhí)行解析比 1:1，而我們希望的是 解析一次 到處運(yùn)行哦！Hard Parses萬(wàn)惡之源Cursor

18、 pin s on X， library cache: mutex X ， latch: row cache objects /shared pool.。 硬解析最好少于每秒 20 次W/A MB processed單位 MB W/A workarea workarea 中處理的數(shù)據(jù)數(shù)量結(jié)合 In-memory Sort%， sorts (disk) PGA Aggr 一起看Logons登陸次數(shù)， logon storm 登陸風(fēng)暴，結(jié)合 AUDIT 審計(jì)數(shù)據(jù)一起看。短連接的附帶效應(yīng)是游標(biāo)緩存無(wú)用Executes執(zhí)行次數(shù)，反應(yīng)執(zhí)行頻率Rollback回滾次數(shù)， 反應(yīng)回滾頻率， 但是這個(gè)指標(biāo)不太精

19、確，參考而已，別太當(dāng)真Transactions每秒事務(wù)數(shù)，是數(shù)據(jù)庫(kù)層的 TPS，可以看做壓力測(cè)試或比對(duì)性能時(shí)的一個(gè)指標(biāo)，孤立看無(wú)意義% Blocks changed per Read每次邏輯讀導(dǎo)致數(shù)據(jù)塊變化的比率；如果redo size, block changes pct of blocks changed per read三個(gè)指標(biāo)都很高，則說(shuō)明系統(tǒng)正執(zhí)行大量 insert/update/delete;pct of blocks changed per read = (block changes ) /( logical reads)Recursive Call %遞歸調(diào)用的比率;Recur

20、sive Call % = (recursive calls)/(user calls)Rollback per transaction %事務(wù)回滾比率。 Rollback per transaction %= (rollback)/(transactions)Rows per Sort平均每次排序涉及到的行數(shù) ; Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory) 注意這些 Load Profile 負(fù)載指標(biāo) 在本環(huán)節(jié)提供了 2 個(gè)維度 per second 和 per transaction。per Second:

21、主要是把 快照內(nèi)的 delta 值除以 快站時(shí)間的秒數(shù) ， 例如 在 A 快照中 V$SYSSTAT 視圖反應(yīng) table scans (long tables) 這個(gè)指標(biāo)是 100 ，在 B 快照中 V$SYSSTAT 視圖反應(yīng) table scans (long tables) 這個(gè)指標(biāo)是 3700, 而 A 快照和 B 快照 之間 間隔了一個(gè)小時(shí) 3600 秒， 則 對(duì)于 table scans (long tables) per second 就是 ( 3700- 100) /3600=1。pert Second 是我們審視數(shù)據(jù)的主要維度 ，任何性能數(shù)據(jù)脫離了 時(shí)間模型則毫無(wú)意義。在

22、statspack/AWR 出現(xiàn)之前 的調(diào)優(yōu) 洪荒時(shí)代， 有很多 DBA 依賴 V$SYSSTAT 等視圖中的累計(jì) 統(tǒng)計(jì)信息來(lái)調(diào)優(yōu)，以當(dāng)前的調(diào)優(yōu)眼光來(lái)看，那無(wú)異于刀耕火種。 per transaction : 基于事務(wù)的維度， 與 per second 相比 是把除數(shù)從時(shí)間的秒數(shù)改為了該段時(shí)間內(nèi)的事務(wù)數(shù)。 這個(gè)維度的很大用戶是用來(lái) 識(shí)別應(yīng)用特性的變化 ，若 2 個(gè) AWR 性能報(bào)告中該維度指標(biāo) 出現(xiàn)了大幅變化，例如 redo size 從本來(lái) per transaction 1k 變化為 10k per transaction，則說(shuō)明 SQL 業(yè)務(wù)邏輯肯定發(fā)生了某些變化。 注意 AWR 中的這

23、些指標(biāo) 并不僅僅用來(lái)孤立地了解 Oracle 數(shù)據(jù)庫(kù)負(fù)載情況， 實(shí)施調(diào)優(yōu)工作。 對(duì)于 故障診斷 例如HANG、Crash 等， 完全可以通過(guò)對(duì)比問(wèn)題時(shí)段的性能報(bào)告和常規(guī)時(shí)間來(lái)對(duì)比，通過(guò)各項(xiàng)指標(biāo)的對(duì)比往往可以找出 病灶所在。 SELECT VALUE FROM DBA_HIST_SYSSTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in ( db block changes,user calls,user rollbacks,user commits,redo size,physica

24、l reads direct,physical writes,parse count (hard),parse count (total),session logical reads,recursive calls,redo log space requests,redo entries,sorts (memory),sorts (disk),sorts (rows),logons cumulative,parse time cpu,parse time elapsed,execute count,logons current,opened cursors current,DBWR fusio

25、n writes,gcs messages sent,ges messages sent,global enqueue gets sync,global enqueue get time,gc cr blocks received,gc cr block receive time,gc current blocks received,gc current block receive time,gc cr blocks served,gc cr block build time,gc cr block flush time,gc cr block send time,gc current blo

26、cks served,gc current block pin time,gc current block flush time,gc current block send time,physical reads,physical reads direct (lob),SELECT TOTAL_WAITS FROM DBA_HIST_SYSTEM_EVENT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND EVENT_NAME in (gc buffer busy,buffer busy waitsSELECT

27、VALUE FROM DBA_HIST_SYS_TIME_MODEL WHERE DBID = :B4 AND SNAP_ID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in (DB CPU,sql execute elapsed time,DB timeSELECT VALUE FROM DBA_HIST_PARAMETER WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND PARAMETER_NAME in (_db_cache_size,_shared_poo

28、l_size,sga_target,pga_aggregate_target,undo_management,db_block_size,log_buffer,timed_statistics,statistics_levelSELECT BYTES FROM DBA_HIST_SGASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND POOL IN (shared pool, all pools) AND NAME in (free memory,SELECT BYTES FROM DBA_HIST_SG

29、ASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND NAME = :B1 AND POOL IS NULLSELECT (E.BYTES_PROCESSED - B.BYTES_PROCESSED) FROM DBA_HIST_PGA_TARGET_ADVICE B, DBA_HIST_PGA_TARGET_ADVICE E WHERE B.DBID = :B4 AND B.SNAP_ID = :B3 AND B.INSTANCE_NUMBER = :B2 AND B.ADVICE_STATUS = ON

30、 AND E.DBID = B.DBID AND E.SNAP_ID = :B1 AND E.INSTANCE_NUMBER = B.INSTANCE_NUMBER AND E.PGA_TARGET_FACTOR = 1 AND B.PGA_TARGET_FACTOR = 1 AND E.ADVICE_STATUS = ONSELECT SUM(E.TOTAL_WAITS - NVL(B.TOTAL_WAITS, 0) FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B4 AND E.SNA

31、P_ID = :B3 AND B.DBID(+) = :B2AND E.DBID = :B2 AND B.INSTANCE_NUMBER(+) = :B1 AND E.INSTANCE_NUMBER = :B1 AND B.EVENT_ID(+) = E.EVENT_ID AND (E.EVENT_NAME = latch free OR E.EVENT_NAME LIKE latch:%)SELECT DECODE(B.TOTAL_SQL, 0, 0, 100*(1-B.SINGLE_USE_SQL/B.TOTAL_SQL), DECODE(E.TOTAL_SQL, 0, 0, 100*(1

32、-E.SINGLE_USE_SQL/E.TOTAL_SQL), DECODE(B.TOTAL_SQL_MEM, 0, 0, 100*(1-B.SINGLE_USE_SQL_MEM/B.TOTAL_SQL_MEM), DECODE(E.TOTAL_SQL_MEM, 0, 0, 100*(1-E.SINGLE_USE_SQL_MEM/E.TOTAL_SQL_MEM) FROM DBA_HIST_SQL_SUMMARY B, DBA_HIST_SQL_SUMMARY E WHERE B.SNAP_ID = :B4 AND E.SNAP_ID = :B3 AND B.INSTANCE_NUMBER =

33、 :B2 AND E.INSTANCE_NUMBER = :B2 AND B.DBID = :B1 AND E.DBID = :B1SELECT EVENT, WAITS, TIME, DECODE(WAITS, NULL, TO_NUMBER(NULL), 0, TO_NUMBER(NULL), TIME/WAITS*1000) AVGWT, PCTWTT, WAIT_CLASS FROM (SELECT EVENT, WAITS, TIME, PCTWTT,WAIT_CLASS FROM (SELECT E.EVENT_NAME EVENT, E.TOTAL_WAITS - NVL(B.T

34、OTAL_WAITS,0) WAITS, (E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0) / 1000000 TIME, 100 * (E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0) / :B1 PCTWTT, E.WAIT_CLASS WAIT_CLASS FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B5 AND E.SNAP_ID = :B4 AND B.DBID(+) = :B3

35、AND E.DBID = :B3 AND B.INSTANCE_NUMBER(+) = :B2 AND E.INSTANCE_NUMBER = :B2 AND B.EVENT_ID(+) = E.EVENT_ID AND E.TOTAL_WAITS NVL(B.TOTAL_WAITS,0) AND E.WAIT_CLASS != Idle UNION ALL SELECT CPU time EVENT, TO_NUMBER(NULL) WAITS, :B6 /1000000 TIME, 100 * :B6 / :B1 PCTWTT, NULL WAIT_CLASS FROM DUAL WHER

36、E :B6 0) ORDER BY TIME DESC, WAITS DESC) WHERE ROWNUM select sum(TOTAL_WAITS) from v$system_event where event=buffer busy waits;SUM(TOTAL_WAITS)-33070394SQL select sum(count) from v$waitstat;SUM(COUNT)-3306933510g waitstat 的總次數(shù)基本等于 buffer busy waits 和 read by other session 等待的次數(shù)總和SQL select sum(TOTA

37、L_WAITS) from v$system_event where event=buffer busy waits or event=read by other session;SUM(TOTAL_WAITS)-60675815SQL select sum(count) from v$waitstat;SUM(COUNT)-60423739 Buffer Nowait %的計(jì)算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)，例如在 AWR 中： ClassClassWaitsWaits

38、TotalTotal WaitWait TimeTime (s)(s) AvgAvg TimeTime (ms)(ms)data block24,5432,26792undo header74323undo block1,116001st level bmb3500 session logical reads 40,769,800 22,544.84 204.71 Buffer Nowait %:99.94 Buffer Nowait= ( 40,769,800 (24543+743+1116+35)/ ( 40,769,800) = 0.99935= 99.94% SELECT SUM(WA

39、IT_COUNT) FROM DBA_HIST_WAITSTAT WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1 2、buffer HIT%: 經(jīng)典的經(jīng)典，高速緩存命中率，反應(yīng)物理讀和緩存命中間的糾結(jié)，但這個(gè)指標(biāo)即便 99% 也不能說(shuō)明物理讀等待少了不合理的 db_cache_size，或者是 SGA 自動(dòng)管理 ASMM /Memory 自動(dòng)管理 AMM 下都可能因?yàn)?db_cache_size 過(guò)小引起大量的db file sequential /scattered read 等待事件； maclean 曾經(jīng)遇到過(guò)因?yàn)?/p>

40、大量硬解析導(dǎo)致 ASMM 下 shared pool 共享池大幅度膨脹，而 db cache 相應(yīng)縮小 shrink 的例子，最終 db cache 收縮到只有幾百兆，本來(lái)沒(méi)有的物理讀等待事件都大幅涌現(xiàn)出來(lái) 。此外與 buffer HIT%相關(guān)的指標(biāo)值得關(guān)注的還有 table scans(long tables) 大表掃描這個(gè)統(tǒng)計(jì)項(xiàng)目、此外相關(guān)的欄目還有 Buffer Pool Statistics 、Buffer Pool Advisory 等（如果不知道在哪里，直接找一個(gè) AWR 去搜索這些關(guān)鍵詞即可)。 buffer HIT%在 不同版本有多個(gè)計(jì)算公式：在 9i 中Buffer Hit

41、Ratio = 1 (physical reads physical reads direct physical reads direct (lob) / (db block gets + consistent gets physical reads direct physical reads direct (lob)在 10g 以后：Buffer Hit Ratio= 1 (physical reads cache) / (consistent gets from cache + db block gets from cache)注意：但是實(shí)際注意：但是實(shí)際 AWR 中中 似乎還是按照似乎還

42、是按照 9i 中的算法，雖然算法的區(qū)別對(duì)最后算得的比率影響不大。中的算法，雖然算法的區(qū)別對(duì)最后算得的比率影響不大。對(duì)于對(duì)于 buffer hit % 看它的命中率有多高沒(méi)有意義，主要是關(guān)注看它的命中率有多高沒(méi)有意義，主要是關(guān)注 未命中的次數(shù)有多少。通過(guò)上述公式很容易反推出未命中的物理讀未命中的次數(shù)有多少。通過(guò)上述公式很容易反推出未命中的物理讀的次數(shù)。的次數(shù)。db block gets 、consistent gets 以及 session logical reads 的關(guān)系如下：db block getsdb block gets directdb block gets from cachec

43、onsistent getsconsistent gets from cacheconsistent gets directconsistent gets from cacheconsistent gets examination + elseconsistent gets examination=指的是不需要 pin buffer 直接可以執(zhí)行 consistent get 的次數(shù)，常用于索引，只需要一次 latch get session logical reads = db block gets +consistent gets 其中 physical reads 、physical r

44、eads cache、physical reads direct、physical reads direct (lob)幾者的關(guān)系為：physical reads = physical reads cache +physical reads direct這個(gè)公式其實(shí)說(shuō)明了 物理讀有 2 種 ：物理讀進(jìn)入 buffer cache 中 ，是常見(jiàn)的模式 physical reads cache物理讀直接進(jìn)入 PGA 直接路徑讀， 即 physical reads direct physical reads8Total number of data blocks read from disk. Th

45、is value can be greater than the value of “physical reads direct” plus “physical reads cache” as reads into process private buffers also included in this statistic.physical reads cache8Total number of data blocks read from disk into the buffer cache. This is a subset of “physical reads” statistic.ph

46、ysical reads direct8Number of reads directly from disk, bypassing the buffer cache. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resid

47、ent in the buffer cache. physical reads direct = physical reads direct (lob) + physical reads direct temporary tablespace + physical reads direct(普通)這個(gè)公式也說(shuō)明了 直接路徑讀 分成三個(gè)部分：physical reads direct (lob) 直接路徑讀 LOB 對(duì)象physical reads direct temporary tablespace 直接路徑讀臨時(shí)表空間physical read direct(普通) 普通的直接路徑讀， 一

48、般是 11g 開(kāi)始的自動(dòng)的大表 direct path read 和并行引起的 direct path read physical writes direct= physical writes direct (lob)+ physical writes direct temporary tablespaceDBWR checkpoint buffers written = DBWR thread checkpoint buffers written+ DBWR tablespace checkpoint buffers written+ DBWR PQ tablespace checkpoin

49、t buffers written+. 3、Redo nowait%: session 在生成 redo entry 時(shí)不用等待的比例，redo 相關(guān)的資源爭(zhēng)用例如 redo space request 爭(zhēng)用可能造成生成redo 時(shí)需求等待。此項(xiàng)數(shù)據(jù)來(lái)源于 v$sysstat 中的(redo log space requests/redo entries)。 一般來(lái)說(shuō) 10g 以后不太用關(guān)注log_buffer 參數(shù)的大小，需要關(guān)注是否有十分頻繁的 log switch ； 過(guò)小的 redo logfile size 如果配合較大的 SGA 和頻繁的 commit提交都可能造成該問(wèn)題。 考慮增

50、到 redo logfile 的尺寸 : 14G 每個(gè)，710 組都是合適的。同時(shí)考慮優(yōu)化 redo logfile 和 datafile 的 I/O。 4、In-memory Sort%:這個(gè)指標(biāo)因?yàn)樗挥?jì)算 workarea 中所有的操作類型，所以現(xiàn)在越來(lái)越雞肋了。 純粹在內(nèi)存中完成的排序比例。數(shù)據(jù)來(lái)源于 v$sysstat statistics sorts (disk) 和 sorts (memory)， In-memory Sort% = sort(memory) / ( sort(disk)+ sort(memory) ) 5、Library Hit%: library cache

51、命中率，申請(qǐng)一個(gè) library cache object 例如一個(gè) SQL cursor 時(shí)，其已經(jīng)在 library cache 中的比例。 數(shù)據(jù)來(lái)源 V$librarycache 的 pins 和 pinhits。 合理值：95% ，該比例來(lái)源于 1- ( (pin Requests * Pct Miss) / Sum(Pin Requests) ) 維護(hù)這個(gè)指標(biāo)的重點(diǎn)是 保持 shared pool 共享池有足夠的 Free Memory，且沒(méi)有過(guò)多的內(nèi)存碎片，具體可以參考這里。 顯然過(guò)小的 shared pool 可用空間會(huì)導(dǎo)致 library cache object 被 aged

52、 out 換出共享池。 此外保證 SQL 語(yǔ)句綁定變量和游標(biāo)可以共享也是很重要的因素。 Library Cache Activity DB/Inst: G10R25/G10R25 Snaps: 2964-2965- Pct Misses should be very low http:/ Get Pct Pin Pct Invali-Namespace Requests Miss Requests Miss Reloads dations- - - - - - -BODY 5 0.0 6 16.7 1 0CLUSTER 10 0.0 26 0.0 0 0SQL AREA 601,357 99.

53、8 902,828 99.7 47 2TABLE/PROCEDURE 83 9.6 601,443 0.0 48 0 GETSNUMBERNumber of times a lock was requested for objects of this namespaceGETHITSNUMBERNumber of times an objects handle was found in memoryGETHITRATIONUMBERRatio of GETHITS to GETSPINSNUMBERNumber of times a PIN was requested for objects

54、of this namespacePINHITSNUMBERNumber of times all of the metadata pieces of the library object were found in memoryPINHITRATIONUMBERRatio of PINHITS to PINSRELOADSNUMBERAny PIN of an object that is not the first PIN performed since the object handle was created, and which requires loading the object

55、 from diskINVALIDATIONSNUMBERTotal number of times objects in this namespace were marked invalid because a dependent object was modified SELECT SUM(PINS), SUM(PINHITS) FROM DBA_HIST_LIBRARYCACHE WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1 6、Soft Parse: 軟解析比例，無(wú)需多說(shuō)的經(jīng)典指標(biāo)，數(shù)據(jù)來(lái)源 v$sysstat

56、 statistics 的 parse count(total)和 parse count(hard)。 合理值95%Soft Parse %是 AWR 中另一個(gè)重要的解析指標(biāo)，該指標(biāo)反應(yīng)了快照時(shí)間內(nèi) 軟解析次數(shù) 和 總解析次數(shù) (soft+hard 軟解析次數(shù)+硬解析次數(shù))的比值，若該指標(biāo)很低，那么說(shuō)明了可能存在劇烈的 hard parse 硬解析，大量的硬解析會(huì)消耗更多的 CPU 時(shí)間片并產(chǎn)生解析爭(zhēng)用(此時(shí)可以考慮使用 cursor_sharing=FORCE)； 理論上我們總是希望 Soft Parse % 接近于 100%， 但并不是說(shuō) 100%的軟解析就是最理想的解析狀態(tài)，通過(guò)設(shè)置

57、session_cached_cursors 參數(shù)和反復(fù)重用游標(biāo)我們可以讓解析來(lái)的更輕量級(jí)，即通俗所說(shuō)的利用會(huì)話緩存游標(biāo)實(shí)現(xiàn)的軟軟解析(soft soft parse)。 7、Execute to Parse% 指標(biāo)反映了執(zhí)行解析比 其公式為 1-(parse/execute) , 目標(biāo)為 100% 及接近于只 執(zhí)行而不解析。 數(shù)據(jù)來(lái)源v$sysstat statistics parse count (total) 和 execute count在 oracle 中解析往往是執(zhí)行的先提工作，但是通過(guò)游標(biāo)共享 可以解析一次 執(zhí)行多次， 執(zhí)行解析可能分成多種場(chǎng)景：1.hard coding = 硬

58、編碼代碼 硬解析一次 ，執(zhí)行一次， 則理論上其執(zhí)行解析比 為 1:1 ，則理論上 Execute to Parse =0 極差，且 soft parse 比例也為 0%2.綁定變量但是仍軟解析= 軟解析一次，執(zhí)行一次 ， 這種情況雖然比前一種好 但是執(zhí)行解析比(這里的 parse，包含了軟解析和硬解析)仍是 1:1， 理論上 Execute to Parse =0 極差， 但是 soft parse 比例可能很高3.使用 靜態(tài) SQL、動(dòng)態(tài)綁定、session_cached_cursor、open cursors 等技術(shù)實(shí)現(xiàn)的 解析一次，執(zhí)行多次， 執(zhí)行解析比為 N:1， 則 Execute

59、to Parse= 1- (1/N) 執(zhí)行次數(shù)越多 Execute to Parse 越接近 100% ，這種是我們?cè)?OLTP 環(huán)境中喜聞樂(lè)見(jiàn)的！通俗地說(shuō) soft parse% 反映了軟解析率， 而軟解析在 oracle 中仍是較昂貴的操作， 我們希望的是解析 1 次執(zhí)行 N 次，如果每次執(zhí)行均需要軟解析，那么雖然 soft parse%=100% 但是 parse time 仍可能是消耗 DB TIME 的大頭。Execute to Parse 反映了 執(zhí)行解析比，Execute to Parse 和 soft parse% 都很低 那么說(shuō)明確實(shí)沒(méi)有綁定變量 ， 而如果 soft par

60、se% 接近 99% 而 Execute to Parse 不足 90% 則說(shuō)明沒(méi)有執(zhí)行解析比低， 需要通過(guò) 靜態(tài) SQL、動(dòng)態(tài)綁定、session_cached_cursor、open cursors 等技術(shù)減少軟解析。 8、Latch Hit%: willing-to-wait latch 閂申請(qǐng)不要等待的比例。 數(shù)據(jù)來(lái)源 V$latch gets 和 misses Latch Name- Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3- - - - - - -shared pool 9,988,637 364 23 34