溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關如何進行Oracle AWR報告指標的解析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
2013/08/31 BY 26條評論
physical read bytes
| physical read total bytes | 物理讀的吞吐量/秒 | |
| physical read IO requests | physical read total IO requests | 物理讀的IOPS |
| physical write bytes | physical write total bytes | 物理寫的吞吐量/秒 |
| physical write IO requests | physical write total IO requests | 物理寫的IOPS |
總的物理吞吐量/秒=physical read total bytes+physical write total bytes
總的物理IOPS= physical read total IO requests+ physical write total IO requests
IO的主要指標 吞吐量、IOPS和延遲 均可以從AWR中獲得了， IO延遲的信息可以從 User I/O的Wait Class Avg Wait time獲得，也可以參考11g出現的IOStat by Function summary
Instance Activity Stats有大量的指標，但是對于這些指標的介紹 沒有那一份文檔有完整詳盡的描述，即便在Oracle原廠內部要沒有(或者是Maclean沒找到)，實際是開發人員要引入某一個Activity Stats是比較容易的，并不像申請引入一個新后臺進程那樣麻煩，Oracle對于新版本中新后臺進程的引入有嚴格的要求，但Activity Stats卻很容易，往往一個one-off patch中就可以引入了，實際上Activity Stats在源代碼層僅僅是一些計數器。’
較為基礎的statistics，大家可以參考官方文檔的Statistics Descriptions描述，地址在這里。
對于深入的指標 例如 “Batched IO (space) vector count”這種由于某些新特性被引入的，一般沒有很詳細的材料，需要到源代碼中去閱讀相關模塊才能總結其用途，對于這個工作一般原廠是很延遲去完成的，所以沒有一個完整的列表。 如果大家有對此的疑問，請去t.askmaclean.com 發一個帖子提問。
Instance Activity Stats - Absolute Values Snaps: 7071 -> Statistics with absolute values (should not be diffed) Statistic Begin Value End Value -------------------------------- --------------- --------------- session pga memory max 1.157882826E+12 1.154290304E+12 session cursor cache count 157,042,373 157,083,136 session uga memory 5.496429019E+14 5.496775467E+14 opened cursors current 268,916 265,694 workarea memory allocated 827,704 837,487 logons current 2,609 2,613 session uga memory max 1.749481584E+13 1.749737418E+13 session pga memory 4.150306913E+11 4.150008177E+11
Instance Activity Stats – Absolute Values是顯示快照 起點 和終點的一些指標的絕對值
logon current 當前時間點的登錄數
opened cursors current 當前打開的游標數
session cursor cache count 當前存在的session緩存游標數
Instance Activity Stats - Thread ActivityDB/Inst: G10R25/G10R25 Snaps: 3663-3 -> Statistics identified by '(derived)' come from sources other than SYSSTAT Statistic Total per Hour -------------------------------- ------------------ --------- log switches (derived) 17 2,326.47
log switches (derived) 日志切換次數 ， 見 《理想的在線重做日志切換時間是多長？》
5 IO 統計
5-1 Tablespace IO Stats 基于表空間分組的IO信息
Tablespace IO Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723 -> ordered by IOs (Reads + Writes) desc Tablespace ------------------------------ Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------- ------- ------------ -------- ---------- ------- DATA_TS 17,349,398 4,801 2.3 1.5 141,077 39 4,083,704 5.8 INDEX_TS 9,193,122 2,544 2.0 1.0 238,563 66 3,158,187 46.1 UNDOTBS1 1,582,659 438 0.7 1.0 2 0 12,431 69.0
reads : 指 該表空間上發生的物理讀的次數(單位不是塊，而是次數)
Av Reads/s : 指該表空間上平均每秒的物理讀次數 (單位不是塊，而是次數)
Av Rd(ms): 指該表空間上每次讀的平均讀取延遲
Av Blks/Rd: 指該表空間上平均每次讀取的塊數目，因為一次物理讀可以讀多個數據塊；如果Av Blks/Rd>>1 則可能系統有較多db file scattered read 可能是診斷FULL TABLE SCAN或FAST FULL INDEX SCAN，需要關注table scans (long tables) 和index fast full scans (full) 2個指標
Writes : 該表空間上發生的物理寫的次數 ; 對于那些Writes總是等于0的表空間 不妨了解下是否數據為只讀，如果是可以通過read only tablespace來解決 RAC中的一些性能問題。
Av Writes/s : 指該表空間上平均每秒的物理寫次數
buffer Waits: 該表空間上發生buffer busy waits和read by other session的次數( 9i中buffer busy waits包含了read by other session)。
Av Buf Wt(ms): 該表空間上發生buffer Waits的平均等待時間，單位為ms
5-2 File I/O
File IO Stats Snaps: 70719-70723 -> ordered by Tablespace, File Tablespace Filename ------------------------ ---------------------------------------------------- Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------- ------- ------------ -------- ---------- ------- AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data2/amg_album_idx_ts01.dbf 23,298 6 0.6 1.0 2 0 0 0.0 AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data3/amg_album_idx_ts02.dbf 3,003 1 0.6 1.0 2 0 0 0.0
Tablespace 表空間名
FileName 數據文件的路徑
Reads: 該數據文件上累計發生過的物理讀次數，不是塊數
Av Reads/s: 該數據文件上平均每秒發生過的物理讀次數，不是塊數
Av Rd(ms): 該數據文件上平均每次物理讀取的延遲，單位為ms
Av Blks/Rd: 該數據文件上平均每次讀取涉及到的塊數，OLTP環境該值接近 1
Writes : 該數據文件上累計發生過的物理寫次數，不是塊數
Av Writes/s: 該數據文件上平均每秒發生過的物理寫次數，不是塊數
buffer Waits: 該數據文件上發生buffer busy waits和read by other session的次數( 9i中buffer busy waits包含了read by other session)。
Av Buf Wt(ms): 該數據文件上發生buffer Waits的平均等待時間，單位為ms
若某個表空間上有較高的IO負載，則有必要分析一下 是否其所屬的數據文件上的IO 較為均勻 還是存在傾斜， 是否需要結合存儲特征來 將數據均衡分布到不同磁盤上的數據文件上，以優化 I/O
6 緩沖池統計 Buffer Pool Statistics
Buffer Pool Statistics Snaps: 70719-70723 -> Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k Free Writ Buffer Number of Pool Buffer Physical Physical Buff Comp Busy P Buffers Hit% Gets Reads Writes Wait Wait Waits --- ---------- ---- ------------ ------------ ----------- ------ ------ -------- 16k 15,720 N/A 0 0 0 0 0 0 D 2,259,159 98 2.005084E+09 42,753,650 560,460 0 1 8.51E+06
該環節的數據主要來源于WRH$_BUFFER_POOL_STATISTICS， 而WRH$_BUFFER_POOL_STATISTICS是定期匯總v$SYSSTAT中的數據
P pool池的名字 D: 默認的緩沖池 default buffer pool , K : Keep Pool , R: Recycle Pool ; 2k 4k 8k 16k 32k: 代表各種非標準塊大小的緩沖池
Number of buffers: 實際的 緩沖塊數目， 約等于 池的大小 / 池的塊大小
Pool Hit % : 該緩沖池的命中率
Buffer Gets: 對該緩沖池的中塊的訪問次數 包括 consistent gets 和 db block gets
Physical Reads: 該緩沖池Buffer Cache引起了多少物理讀， 其實是physical reads cache ，單位為 塊數*次數
Physical Writes ：該緩沖池中Buffer cache被寫的物理寫， 其實是physical writes from cache， 單位為 塊數*次數
Free Buffer Waits: 等待空閑緩沖的次數， 可以看做該buffer pool 發生free buffer waits 等待的次數
Write Comp Wait: 等待DBWR寫入臟buffer到磁盤的次數， 可以看做該buffer pool發生write complete waits等待的次數
Buffer Busy Waits: 該緩沖池發生buffer busy wait 等待的次數
7-1 Checkpoint Activity 檢查點與 Instance Recovery Stats 實例恢復
Checkpoint Activity Snaps: 70719-70723 -> Total Physical Writes: 590,563 Other Autotune Thread MTTR Log Size Log Ckpt Settings Ckpt Ckpt Writes Writes Writes Writes Writes Writes ----------- ----------- ----------- ----------- ----------- ----------- 0 0 0 0 12,899 0 ------------------------------------------------------------- Instance Recovery Stats Snaps: 70719-70723 -> B: Begin Snapshot, E: End Snapshot Estd Targt Estd Log Ckpt Log Ckpt Opt RAC MTTR MTTR Recovery Actual Target Log Sz Timeout Interval Log Avail (s) (s) Estd IOs RedoBlks RedoBlks RedoBlks RedoBlks RedoBlks Sz(M) Time - ----- ----- -------- -------- -------- -------- -------- -------- ------ ----- B 0 6 12828 477505 1786971 5096034 1786971 N/A N/A 3 E 0 7 16990 586071 2314207 5096034 2314207 N/A N/A 3 -------------------------------------------------------------
該環節的數據來源于WRH$_INSTANCE_RECOVERY
MTTR Writes : 為了滿足FAST_START_MTTR_TARGET 指定的MTTR值 而做出的物理寫 WRITES_MTTR
Log Size Writes ：由于最小的redo log file而做出的物理寫 WRITES_LOGFILE_SIZE
Log Ckpt writes: 由于 LOG_CHECKPOINT_INTERVAL 和 LOG_CHECKPOINT_TIMEOUT 驅動的增量檢查點而做出的物理寫 WRITES_LOG_CHECKPOINT_SETTINGS
Other Settings Writes ：由于其他設置(例如FAST_START_IO_TARGET）而引起的物理寫， WRITES_OTHER_SETTINGS
Autotune Ckpt Writes : 由于自動調優檢查點而引起的物理寫， WRITES_AUTOTUNE
Thread Ckpt Writes ：由于thread checkpoint而引起的物理寫，WRITES_FULL_THREAD_CKPT
B 代表 開始點， E 代表結尾
Targt MTTR (s) : 目標MTTR (mean time to recover)意為有效恢復時間，單位為秒。 TARGET_MTTR 的計算基于 給定的參數FAST_START_MTTR_TARGET，而TARGET_MTTR作為內部使用。 實際在使用中 Target MTTR未必能和FAST_START_MTTR_TARGET一樣。 如果FAST_START_MTTR_TARGET過小，那么TARGET_MTTR 將是系統條件所允許的最小估算值； 如果FAST_START_MTTR_TARGET過大，則TARGET_MTTR以保守算法計算以獲得完成恢復的最長估算時間。
estimated_mttr (s): 當前基于 臟buffer和重做日志塊的數量，而評估出的有效恢復時間 。 它的估算告訴用戶 以當下系統的負載若發生實例crash，則需要多久時間來做crash recovery的前滾操作，之后才能打開數據庫。
Recovery Estd IOs ：實際是當前buffer cache中的臟塊數量，一旦實例崩潰 這些臟塊要被前滾
Actual RedoBlks ： 當前實際需要恢復的redo重做塊數量
Target RedoBlks ：是 Log Sz RedoBlks 、Log Ckpt Timeout RedoBlks、 Log Ckpt Interval RedoBlks 三者的最小值
Log Sz RedoBlks : 代表 必須在log file switch日志切換之前完成的 checkpoint 中涉及到的redo block，也叫max log lag； 數據來源select LOGFILESZ from X$targetrba; select LOG_FILE_SIZE_REDO_BLKS from v$instance_recovery;
Log Ckpt Timeout RedoBlks ： 為了滿足LOG_CHECKPOINT_TIMEOUT 所需要處理的redo block數，lag for checkpoint timeout ； 數據來源select CT_LAG from x$targetrba;
Log Ckpt Interval RedoBlks ：為了滿足LOG_CHECKPOINT_INTERVAL 所需要處理的redo block數， lag for checkpoint interval； 數據來源select CI_LAG from x$targetrba;
Opt Log Sz(M) : 基于FAST_START_MTTR_TARGET 而估算出來的redo logfile 的大小，單位為MB 。 Oracle官方推薦創建的重做日志大小至少大于這個估算值
Estd RAC Avail Time ：指評估的 RAC中節點失敗后 集群從凍結到部分可用的時間， 這個指標僅在RAC中可用，單位為秒。 ESTD_CLUSTER_AVAILABLE_TIME
7-2 Buffer Pool Advisory 緩沖池建議
Buffer Pool Advisory DB/Inst: ITSCMP/itscmp2 Snap: 70723 -> Only rows with estimated physical reads >0 are displayed -> ordered by Block Size, Buffers For Estimate Est Phys Estimated Est Size for Size Buffers Read Phys Reads Est Phys %DBtime P Est (M) Factor (thousands) Factor (thousands) Read Time for Rds --- -------- ------ ------------ ------ -------------- ------------ ------- D 1,920 .1 227 4.9 1,110,565,597 1 1.0E+09 D 3,840 .2 454 3.6 832,483,886 1 7.4E+08 D 5,760 .3 680 2.8 634,092,578 1 5.6E+08 D 7,680 .4 907 2.2 500,313,589 1 4.3E+08 D 9,600 .5 1,134 1.8 410,179,557 1 3.5E+08 D 11,520 .6 1,361 1.5 348,214,283 1 2.9E+08 D 13,440 .7 1,588 1.3 304,658,441 1 2.5E+08 D 15,360 .8 1,814 1.2 273,119,808 1 2.2E+08 D 17,280 .9 2,041 1.1 249,352,943 1 2.0E+08 D 19,200 1.0 2,268 1.0 230,687,206 1 1.8E+08 D 19,456 1.0 2,298 1.0 228,664,269 1 1.8E+08 D 21,120 1.1 2,495 0.9 215,507,858 1 1.7E+08 D 23,040 1.2 2,722 0.9 202,816,787 1 1.6E+08 D 24,960 1.3 2,948 0.8 191,974,196 1 1.5E+08 D 26,880 1.4 3,175 0.8 182,542,765 1 1.4E+08 D 28,800 1.5 3,402 0.8 174,209,199 1 1.3E+08 D 30,720 1.6 3,629 0.7 166,751,631 1 1.2E+08 D 32,640 1.7 3,856 0.7 160,002,420 1 1.2E+08 D 34,560 1.8 4,082 0.7 153,827,351 1 1.1E+08 D 36,480 1.9 4,309 0.6 148,103,338 1 1.1E+08 D 38,400 2.0 4,536 0.6 142,699,866 1 1.0E+08
緩沖池的顆粒大小 可以參考 SELECT * FROM V$SGAINFO where name like(‘Granule%’);
P 指 緩沖池的名字 可能包括 有 D default buffer pool , K Keep Pool , R recycle Pool
Size For Est(M): 指以該尺寸的buffer pool作為評估的對象，一般是 目前current size的 10% ~ 200%，以便了解 buffer pool 增大 ~減小 對物理讀的影響
Size Factor : 尺寸因子， 只 對應buffer pool 大小 對 當前設置的比例因子， 例如current_size是 100M ， 則如果評估值是110M 那么 size Factor 就是 1.1
Buffers (thousands) ：指這個buffer pool 尺寸下的buffer 數量， 要乘以1000才是實際值
Est Phys Read Factor ：評估的物理讀因子， 例如當前尺寸的buffer pool 會引起100個物理讀， 則別的尺寸的buffer pool如果引起 120個物理讀， 那么 對應尺寸的Est Phys Read Factor就是1.2
Estimated Phys Reads (thousands)：評估的物理讀數目， 要乘以 1000才是實際值， 顯然不同尺寸的buffer pool對應不同的評估的物理讀數目
Est Phys Read Time ： 評估的物理讀時間
Est %DBtime for Rds：評估的物理讀占DB TIME的比率
我們 看buffer pool advisory 一般有2個目的：
在物理讀較多的情況下，希望通過增加buffer pool 大小來緩解物理讀等待，這是我們關注Size Factor > 1的buffer pool尺寸是否能共有效減少Est Phys Read Factor， 如果Est Phys Read Factor隨著Size Factor 增大 而顯著減少，那么說明增大buffer cache 是可以有效減少物理讀的。
在內存緊張的情況下 ，希望從buffer pool中勻出部分內存來移作他用， 但是又不希望 buffer cache變小導致 物理讀增多 性能下降， 則此時 觀察Est Phys Read Factor 是否隨著Size Factor 減小而 顯著增大， 如果不是 則說明減少部分buffer cache 不會導致 物理讀大幅增加，也就可以安心 減少 buffer cache
注意 Size Factor 和 Est Phys Read Factor之間不是簡單的 線性關系，所以需要人為介入評估得失
7-3 PGA Aggr Summary
PGA Aggr Summary Snaps: 70719-70723 -> PGA cache hit % - percentage of W/A (WorkArea) data processed only in-memory PGA Cache Hit % W/A MB Processed Extra W/A MB Read/Written --------------- ------------------ -------------------------- 99.9 412,527 375
PGA Cache Hit % : 指 W/A WorkArea工作區的數據僅在內存中處理的比率， PGA緩存命中率
workarea是PGA中負責處理 排序、哈希連接和位圖合并操作的區域; workarea 也叫做 SQL 作業區域
W/A MB processes: 指 在Workarea中處理過的數據的量，單位為MB
Extra W/A MB Read/Written : 指額外從磁盤上 讀寫的 工作區數據， 單位為 MB
7-4 PGA Aggr Target Stats
Warning: pga_aggregate_target was set too low for current workload, as this value was exceeded during this interval. Use the PGA Advisory view to help identify a different value for pga_aggregate_target. PGA Aggr Target Stats Snaps: 70719-70723 -> B: Begin Snap E: End Snap (rows dentified with B or E contain data which is absolute i.e. not diffed over the interval) -> Auto PGA Target - actual workarea memory target -> W/A PGA Used - amount of memory used for all Workareas (manual + auto) -> %PGA W/A Mem - percentage of PGA memory allocated to workareas -> %Auto W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt -> %Man W/A Mem - percentage of workarea memory under manual control %PGA %Auto %Man PGA Aggr Auto PGA PGA Mem W/A PGA W/A W/A W/A Global Mem Target(M) Target(M) Alloc(M) Used(M) Mem Mem Mem Bound(K) - ---------- ---------- ---------- ---------- ------ ------ ------ ---------- B 8,192 512 23,690.5 150.1 .6 100.0 .0 838,860 E 8,192 512 23,623.6 156.9 .7 100.0 .0 838,860 -------------------------------------------------------------
此環節的數據來源主要是 WRH$_PGASTAT
PGA Aggr Target(M) ：本質上就是pga_aggregate_target ， 當然在AMM(memory_target)環境下 這個值可能會自動變化
Auto PGA Target(M) : 在自動PGA 管理模式下 實際可用的工作區內存 “aggregate PGA auto target “， 因為PGA還有其他用途 ，不能全部作為workarea memory
PGA Mem Alloc(M) ：目前已分配的PGA內存， alloc 不等于 inuse 即分配的內存不等于在使用的內存，理論上PGA會將確實不使用的內存返回給OS(PGA memory freed back to OS) ，但是存在PGA占用大量內存而不釋放的場景
在上例中 pga_aggregate_target 僅為8192M ，而實際processes 在 2,615~ 8000之間，如果一個進程耗費5MB的PGA 也需要 10000M的PGA ，而實際這里 PGA Mem Alloc(M)是23,690 M ，這說明 存在PGA 的過載， 需要調整pga_aggregate_target
W/A PGA Used(M) ：所有的工作區workarea(包括manual和 auto)使用的內存總和量， 單位為MB
%PGA W/A Mem: 分配給workarea的內存量占總的PGA的比例， (W/A PGA Used)/PGA Mem Alloc
%Auto W/A Mem : AUTO 自動工作區管理所控制的內存(workarea_size_policy=AUTO) 占總的workarea內存的比例
%Man W/A Mem : MANUAL 手動工作區管理所控制的內存(workarea_size_policy=MANUAL)占總的workarea內存的比例
Global Mem Bound(K) : 指 在自動PGA管理模式下一個工作區所能分配的最大內存(注意 一個SQL執行過程中可能有多個工作區workarea)。 Global Mem Bound(K)這個指標在實例運行過程中將被持續性的修正，以反應數據庫當時工作區的負載情況。顯然在有眾多活躍工作區的系統負載下相應地Global Mem Bound將會下降。 但應當保持global bound值不要小于1 MB ， 否則建議 調高pga_aggregate_target
7-5 PGA Aggr Target Histogram
PGA Aggr Target Histogram Snaps: 70719-70723 -> Optimal Executions are purely in-memory operations Low High Optimal Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs ------- ------- -------------- -------------- ------------ ------------ 2K 4K 262,086 262,086 0 0 64K 128K 497 497 0 0 128K 256K 862 862 0 0 256K 512K 368 368 0 0 512K 1024K 440,585 440,585 0 0 1M 2M 68,313 68,313 0 0 2M 4M 169 161 8 0 4M 8M 50 42 8 0 8M 16M 82 82 0 0 16M 32M 1 1 0 0 32M 64M 12 12 0 0 128M 256M 2 0 2 0 -------------------------------------------------------------
數據來源：WRH$_SQL_WORKAREA_HISTOGRAM
Low Optimal： 此行所包含工作區workarea最適合內存要求的下限
High Optimal： 此行所包含工作區workarea最適合內存要求的上限
Total Execs: 在 Low Optimal~High Optimal 范圍工作區內完成的總執行數
Optimal execs: optimal 執行是指完全在PGA內存中完成的執行次數
1-pass Execs : 指操作過程中僅發生1次磁盤讀取的執行次數
M-pass Execs: 指操作過程中發生了1次以上的磁盤讀取， 頻發磁盤讀取的執行次數
7-6 PGA Memory Advisory
PGA Memory Advisory Snap: 70723 -> When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0 Estd Extra Estd P Estd PGA PGA Target Size W/A MB W/A MB Read/ Cache Overallo Estd Est (MB) Factr Processed Written to Disk Hit % Count Time ---------- ------- ---------------- ---------------- ------ -------- ------- 1,024 0.1 2,671,356,938.7 387,531,258.9 87.0 1.07E+07 7.9E+11 2,048 0.3 2,671,356,938.7 387,529,979.1 87.0 1.07E+07 7.9E+11 4,096 0.5 2,671,356,938.7 387,518,881.8 87.0 1.07E+07 7.9E+11 6,144 0.8 2,671,356,938.7 387,420,749.5 87.0 1.07E+07 7.9E+11 8,192 1.0 2,671,356,938.7 23,056,196.5 99.0 1.07E+07 6.9E+11 9,830 1.2 2,671,356,938.7 22,755,192.6 99.0 6.81E+06 6.9E+11 11,469 1.4 2,671,356,938.7 20,609,438.5 99.0 4.15E+06 6.9E+11 13,107 1.6 2,671,356,938.7 19,021,139.1 99.0 581,362 6.9E+11 14,746 1.8 2,671,356,938.7 18,601,191.0 99.0 543,531 6.9E+11 16,384 2.0 2,671,356,938.7 18,561,361.1 99.0 509,687 6.9E+11 24,576 3.0 2,671,356,938.7 18,527,422.3 99.0 232,817 6.9E+11 32,768 4.0 2,671,356,938.7 18,511,872.6 99.0 120,180 6.9E+11 49,152 6.0 2,671,356,938.7 18,500,815.3 99.0 8,021 6.9E+11 65,536 8.0 2,671,356,938.7 18,498,733.0 99.0 0 6.9E+11
PGA Target Est (MB) 用以評估的 PGA_AGGREGATE _TARGET值
Size Factr ， 當前用以評估的PGA_AGGREGATE _TARGET 和 當前實際設置的PGA_AGGREGATE _TARGET 之間的 比例因子 PGA Target Est / PGA_AGGREGATE_TARGE
W/A MB Processed ：workarea中要處理的數據量， 單位為MB
Estd Extra W/A MB Read/ Written to Disk : 以 one-pass 、M-Pass方式處理的數據量預估值， 單位為MB
Estd P Cache Hit % : 預估的PGA緩存命中率
Estd PGA Overalloc Count: 預估的PGA過載量， 如上文所述PGA_AGGREGATE _TARGET僅是一個目標值，無法真正限制PGA內存的使用，當出現 PGA內存硬性需求時會產生PGA overallocate 過載(When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0)
7-7 Shared Pool Advisory
Shared Pool Advisory Snap: 70723 -> SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor -> Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid. Est LC Est LC Est LC Est LC Shared SP Est LC Time Time Load Load Est LC Pool Size Size Est LC Saved Saved Time Time Mem Obj Size(M) Factr (M) Mem Obj (s) Factr (s) Factr Hits (K) -------- ----- -------- ------------ -------- ------ ------- ------ ------------ 304 .8 56 3,987 7,728 1.0 61 1.4 332 352 .9 101 6,243 7,745 1.0 44 1.0 334 400 1.0 114 7,777 7,745 1.0 44 1.0 334 448 1.1 114 7,777 7,745 1.0 44 1.0 334 496 1.2 114 7,777 7,745 1.0 44 1.0 334 544 1.4 114 7,777 7,745 1.0 44 1.0 334 592 1.5 114 7,777 7,745 1.0 44 1.0 334 640 1.6 114 7,777 7,745 1.0 44 1.0 334 688 1.7 114 7,777 7,745 1.0 44 1.0 334 736 1.8 114 7,777 7,745 1.0 44 1.0 334 784 2.0 114 7,777 7,745 1.0 44 1.0 334 832 2.1 114 7,777 7,745 1.0 44 1.0 334 -------------------------------------------------------------
Shared Pool Size(M) : 用以評估的shared pool共享池大小，在AMM /ASMM環境下 shared_pool 大小都可能浮動
SP Size Factr ：共享池大小的比例因子， （Shared Pool Size for Estim / SHARED_POOL_SIZE）
Estd LC Size(M) : 評估的 library cache 大小 ，單位為MB ， 因為是shared pool中包含 library cache 當然還有其他例如row cache
Est LC Mem Obj 指評估的指定大小的共享池內的library cache memory object的數量 ESTD_LC_MEMORY_OBJECTS
Est LC Time Saved(s): 指在 指定的共享池大小情況下可找到需要的library cache memory objects，從而節約的解析時間 。 這些節約的解析時間也是 花費在共享池內重復加載需要的對象(reload)，這些對象可能因為共享池沒有足夠的free memory而被aged out. ESTD_LC_TIME_SAVED
Est LC Time Saved Factr : Est LC Time Saved(s)的比例因子，( Est LC Time Saved(s)/ Current LC Time Saved(s) ) ESTD_LC_TIME_SAVED_FACTOR
Est LC Load Time (s): 在指定的共享池大小情況下解析的耗時
Est LC Load Time Factr：Est LC Load Time (s)的比例因子， (Est LC Load Time (s)/ Current LC Load Time (s)) ESTD_LC_LOAD_TIME_FACTOR
Est LC Mem Obj Hits (K) : 在指定的共享池大小情況下需要的library cache memory object正好在共享池中被找到的次數 ESTD_LC_MEMORY_OBJECT_HITS；
對于想縮小 shared_pool_size 共享池大小的需求，可以關注Est LC Mem Obj Hits (K) ，如上例中共享池為352M時Est LC Mem Obj Hits (K) 就為334且之后不動，則可以考慮縮小shared_pool_size到該值，但要注意每個版本/平臺上對共享池的最低需求，包括RAC中gcs resource 、gcs shadow等資源均駐留在shared pool中，增大db_cache_size時要對應關注。
7-8 SGA Target Advisory
SGA Target Advisory Snap: 70723 SGA Target SGA Size Est DB Est Physical Size (M) Factor Time (s) Reads ---------- ---------- ------------ ---------------- 3,752 0.1 1.697191E+09 1.4577142918E+12 7,504 0.3 1.222939E+09 832,293,601,354 11,256 0.4 1.000162E+09 538,390,923,784 15,008 0.5 895,087,191 399,888,743,900 18,760 0.6 840,062,594 327,287,716,803 22,512 0.8 806,389,685 282,881,041,331 26,264 0.9 782,971,706 251,988,446,808 30,016 1.0 765,293,424 228,664,652,276 33,768 1.1 751,135,535 210,005,616,650 37,520 1.3 739,350,016 194,387,820,900 41,272 1.4 733,533,785 187,299,216,679 45,024 1.5 732,921,550 187,299,216,679 48,776 1.6 732,691,962 187,299,216,679 52,528 1.8 732,538,908 187,299,216,679 56,280 1.9 732,538,917 187,299,216,679 60,032 2.0 732,462,391 187,299,458,716 -------------------------------------------------------------
該環節數據來源于WRH$_SGA_TARGET_ADVICE
SGA target Size : 用以評估的sga target大小 (sga_target)
SGA Size Factor: SGA Size的比例因子， (est SGA target Size / Current SGA target Size )
Est DB Time (s): 評估對應于該指定sga target size會產生多少量的DB TIME，單位為秒
Est Physical Reads：評估對應該指定的sga target size 會產生多少的物理讀
7-9 Streams Pool Advisory
Streams Pool Advisory DB/Inst: ITSCMP/itscmp2 Snap: 70723 Size for Size Est Spill Est Spill Est Unspill Est Unspill Est (MB) Factor Count Time (s) Count Time (s) ---------- --------- ----------- ----------- ----------- ----------- 64 0.5 0 0 0 0 128 1.0 0 0 0 0 192 1.5 0 0 0 0 256 2.0 0 0 0 0 320 2.5 0 0 0 0 384 3.0 0 0 0 0 448 3.5 0 0 0 0 512 4.0 0 0 0 0 576 4.5 0 0 0 0 640 5.0 0 0 0 0 704 5.5 0 0 0 0 768 6.0 0 0 0 0 832 6.5 0 0 0 0 896 7.0 0 0 0 0 960 7.5 0 0 0 0 1,024 8.0 0 0 0 0 1,088 8.5 0 0 0 0 1,152 9.0 0 0 0 0 1,216 9.5 0 0 0 0 1,280 10.0 0 0 0 0
該環節只有當使用了Streams 流復制時才會有必要數據， 數據來源 WRH$_STREAMS_POOL_ADVICE
Size for Est (MB) : 用以評估的 streams pool大小
Size Factor ：streams pool大小的比例因子
Est Spill Count ：評估出的 當使用該大小的流池時 message溢出到磁盤的數量 ESTD_SPILL_COUNT
Est Spill Time (s)： 評估出的 當使用該大小的流池時 message溢出到磁盤的耗時，單位為秒 ESTD_SPILL_TIME
Est Unspill Count：評估的 當使用該大小的流池時 message unspill 即從磁盤上讀取的數量 ESTD_UNSPILL_COUNT
Est Unspill Time (s) ： 評估的 當使用該大小的流池時 message unspill 即從磁盤上讀取的耗時，單位為秒 ESTD_UNSPILL_TIME
7-10 Java Pool Advisory
java pool的相關指標與shared pool相似，不再鏖述
8 Wait Statistics
8-1 Buffer Wait Statistics
Buffer Wait Statistics Snaps: 70719-70723 -> ordered by wait time desc, waits desc Class Waits Total Wait Time (s) Avg Time (ms) ------------------ ----------- ------------------- -------------- data block 8,442,041 407,259 48 undo header 16,212 1,711 106 undo block 21,023 557 26 1st level bmb 1,038 266 256 2nd level bmb 540 185 342 bitmap block 90 25 276 segment header 197 13 66 file header block 132 6 43 bitmap index block 18 0 1 extent map 2 0 0
數據來源 ： WRH$_WAITSTAT
該環節是對 緩沖池中各類型(class) 塊 等待的匯總信息， wait的原因一般是 buffer busy waits 和 read by other session
class 數據塊的class， 一個oracle數據塊即有class 屬性 還有type 屬性，數據塊中記錄type屬性(KCBH)， 而在buffer header里存有class屬性(X$BH.class)
Waits: 該類型數據塊的等待次數
Total Wait Time (s) : 該類型數據塊的合計等待時間 單位為秒
Avg Time (ms) : 該類型數據塊 平均每次等待的耗時， 單位 ms
如果用戶正使用 undo_management=AUTO 的SMU 則一般不會因為rollback segment過少而引起undo header block類塊的等待
對于INSERT 而引起的 buffer爭用等待：
1、 對于手動segment 管理MSSM 考慮增加Freelists、Freelist Groups
2、 使用ASSM ，當然ASSM本身沒什么參數可調
對于INSERT ON INDEX 引起的爭用：
使用反向索引key
使用HASH分區和本地索引
可能的情況下 減少index的density
8-2 Enqueue Activity
enqueue 隊列鎖等待
Enqueue Activity Snaps: 70719-70723 -> only enqueues with waits are shown -> Enqueue stats gathered prior to 10g should not be compared with 10g data -> ordered by Wait Time desc, Waits desc Enqueue Type (Request Reason) ------------------------------------------------------------------------------ Requests Succ Gets Failed Gets Waits Wt Time (s) Av Wt Time(ms) ------------ ------------ ----------- ----------- ------------ -------------- TX-Transaction (index contention) 201,270 201,326 0 193,948 97,517 502.80 TM-DML 702,731 702,681 4 1,081 46,671 43,174.08 SQ-Sequence Cache 28,643 28,632 0 17,418 35,606 2,044.19 HW-Segment High Water Mark 9,210 8,845 376 1,216 12,505 10,283.85 TX-Transaction (row lock contention) 9,288 9,280 0 9,232 10,486 1,135.80 CF-Controlfile Transaction 15,851 14,094 1,756 2,798 4,565 1,631.64 TX-Transaction (allocate ITL entry) 471 369 102 360 169 469.28
Enqueue Type (Request Reason) enqueue 隊列的類型，大家在研究 enqueue 問題前 至少搞清楚enqueue type 和enqueue mode ， enqueue type是隊列鎖所要保護的資源 如 TM 表鎖 CF 控制文件鎖， enqueue mode 是持有隊列鎖的模式 (SS、SX 、S、SSX、X)
Requests : 申請對應的enqueue type資源或者隊列轉換(enqueue conversion 例如 S 轉 SSX ) 的次數
Succ Gets ：對應的enqueue被成功 申請或轉換的次數
Failed Gets ：對應的enqueue的申請 或者轉換失敗的次數
Waits ：由對應的enqueue的申請或者轉換而造成等待的次數
Wt Time (s) ： 由對應的enqueue的申請或者轉換而造成等待的等待時間
Av Wt Time(ms) ：由對應的enqueue的申請或者轉換而造成等待的平均等待時間 ， Wt Time (s) / Waits ,單位為ms
主要的enqueue 等待事件：
enq: TX – row lock/index contention、allocate ITL等待事件
enq: TM – contention等待事件
Oracle隊列鎖enq:TS,Temporary Segment (also TableSpace)
9-1 Undo Segment Summary
Undo Segment Summary Snaps: 70719-70723 -> Min/Max TR (mins) - Min and Max Tuned Retention (minutes) -> STO - Snapshot Too Old count, OOS - Out of Space count -> Undo segment block stats: -> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed -> eS - expired Stolen, eR - expired Released, eU - expired reUsed Undo Num Undo Number of Max Qry Max Tx Min/Max STO/ uS/uR/uU/ TS# Blocks (K) Transactions Len (s) Concurcy TR (mins) OOS eS/eR/eU ---- ---------- --------------- -------- -------- --------- ----- -------------- 4 85.0 200,127 55,448 317 1040.2/10 0/0 0/0/0/0/0/0 ------------------------------------------------------------- Undo Segment Stats Snaps: 70719-70723 -> Most recent 35 Undostat rows, ordered by Time desc Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/uU/ End Time Blocks Transactions Len (s) Concy (mins) OOS eS/eR/eU ------------ ----------- ------------ ------- ------- ------- ----- ------------ 29-Aug 05:52 11,700 35,098 55,448 234 1,070 0/0 0/0/0/0/0/0 29-Aug 05:42 12,203 24,677 54,844 284 1,065 0/0 0/0/0/0/0/0 29-Aug 05:32 14,132 37,826 54,241 237 1,060 0/0 0/0/0/0/0/0 29-Aug 05:22 14,379 32,315 53,637 317 1,050 0/0 0/0/0/0/0/0 29-Aug 05:12 15,693 34,157 53,033 299 1,045 0/0 0/0/0/0/0/0 29-Aug 05:02 16,878 36,054 52,428 250 1,040 0/0 0/0/0/0/0/0
數據來源： WRH$_UNDOSTAT ， undo相關的使用信息每10分鐘刷新到v$undostat中
Undo Extent有三種狀態 active 、unexpired 、expired
active => extent中 包括了活動的事務 ，active的undo extent 一般不允許被其他事務重用覆蓋
unexpired => extent中沒有活動的事務，但相關undo 記錄從inactive到目前還未經過undo retention(注意 auto undo retention的問題 因為這個特性 可能在觀察dba_undo_extents時看到大部分block都是unexpired，這是正常的) 指定的時間，所以為unexpired。 對于沒有guarantee retention的undo tablespace而言，unexpired extent可能被 steal 為其他事物重用
expired => extent中沒有活動事務，且超過了undo retention的時間
Undo TS# 在使用的這個undo 表空間的表空間號， 一個實例 同一時間只能用1個undo tablespace ， RAC不同節點可以用不同的undo tablespace
Num Undo Blocks (K) 指被消費的 undo 數據塊的數量, (K)代表要乘以1000才是實際值； 可以用該指標來評估系統對undo block的消費量， 以便基于實際負載情況來評估UNDO表空間的大小
Number of Transactions 指該段時間內該undo表空間上執行過的事務transaction總量
Max Qry Len (s) 該時段內 持續最久的查詢 時間， 單位為秒
Max Tx Concy 該時段內 最大的事務并發量
Min/Max TR (mins) 最小和最大的tuned undo retention ，單位為分鐘； tuned undo retention 是自動undo調優特性，見undo自動調優介紹。
STO/ OOS STO 指 ORA-01555 Snapshot Too Old錯誤出現的次數； OOS – 指Out of Space count 錯誤出現的次數
uS – unexpired Stolen 嘗試從未過期的undo extent中偷取undo space的次數
uR – unexpired Released 從未過期的undo extent中釋放的塊數目
uU – unexpired reUsed 未過期的undo extent中的block被其他事務重用的 塊數目
eS – expired Stolen 嘗試從過期的undo extent中偷取undo space的次數
eR – expired Released 從過期的undo extent中釋放的塊數目
eU – expired reUsed 過期的undo extent中的block被其他事務重用的 塊數目
| UNXPSTEALCNT | NUMBER | Number of attempts to obtain undo space by stealing unexpired extents from other transactions |
| UNXPBLKRELCNT | NUMBER | Number of unexpired blocks removed from certain undo segments so they can be used by other transactions |
| UNXPBLKREUCNT | NUMBER | Number of unexpired undo blocks reused by transactions |
| EXPSTEALCNT | NUMBER | Number of attempts to steal expired undo blocks from other undo segments |
| EXPBLKRELCNT | NUMBER | Number of expired undo blocks stolen from other undo segments |
| EXPBLKREUCNT | NUMBER | Number of expired undo blocks reused within the same undo segments |
| SSOLDERRCNT | NUMBER | Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error. |
10-1 Latch Activity
Latch Activity Snaps: 70719-70723 -> "Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests -> "NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests -> "Pct Misses" for both should be very close to 0.0 Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Name Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ AQ deq hash table latch 4 0.0 0 0 N/A ASM Keyed state latch 9,048 0.1 0.2 0 0 N/A ASM allocation 15,017 0.2 0.8 1 0 N/A ASM db client latch 72,745 0.0 0 0 N/A ASM map headers 5,860 0.6 0.6 1 0 N/A ASM map load waiting lis 1,462 0.0 0 0 N/A ASM map operation freeli 63,539 0.1 0.4 1 0 N/A ASM map operation hash t 76,484,447 0.1 1.0 66 0 N/A
latch name Latch閂的名字
Get Requests latch被以willing-to-wait模式申請并獲得的次數
Pct Get Miss miss是指latch被以willing-to-wait 模式申請但是申請者必須等待的次數， Pct Get Miss = Miss/Get Requests ; miss可以從后面的Latch Sleep Breakdown 獲得
Avg Slps /Miss Sleep 是指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數 ； Avg Slps /Miss = Sleeps/ Misses ; Sleeps可以從后面的Latch Sleep Breakdown 獲得
Wait Time (s) 指花費在等待latch上的時間，單位為秒
NoWait Requests 指latch被以no-wait模式來申請的次數
Pct NoWait Miss 以no-wait模式來申請latch但直接失敗的次數
對于高并發的latch例如cache buffers chains，其Pct Misses應當十分接近于0
一般的調優原則：
如果latch : cache buffers chains是 Top 5 事件，則需要考慮優化SQL減少 全表掃描 并減少Top buffer gets SQL語句的邏輯讀
如果latch : redo copy 、redo allocation 等待較多，則可以考慮增大LOG_BUFFER
如果latch:library cache 發生較多，則考慮增大shared_pool_size
10-2 Latch Sleep Breakdown
Latch Sleep Breakdown DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723 -> ordered by misses desc Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- cache buffers chains 3,365,097,866 12,831,875 130,058 12,683,450 row cache objects 69,050,058 349,839 1,320 348,649 session idle bit 389,437,460 268,285 2,768 265,752 enqueue hash chains 8,698,453 239,880 22,476 219,950 ges resource hash list 8,388,730 158,894 70,728 91,104 gc element 100,383,385 135,759 6,285 129,742 gcs remastering latch 12,213,169 72,373 1 72,371 enqueues 4,662,545 46,374 259 46,155 ASM map operation hash tab 76,484,447 46,231 45,210 1,952 Lsod array latch 72,598 24,224 24,577 1,519
latch name Latch閂的名字
Get Requests latch被以willing-to-wait模式申請并獲得的次數
misses 是指latch被以willing-to-wait 模式申請但是申請者必須等待的次數
9i以后miss之后一般有2種情況 spin gets了 或者sleep一睡不醒直到 被post，具體見全面解析9i以后Oracle Latch閂鎖原理；
8i以前的latch算法可以參考：Oracle Latch:一段描繪Latch運作的偽代碼
所以一般來說9i以后的 misses= Sleeps+ Spin Gets ，雖然不是絕對如此
Sleeps 是指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數
Spin Gets 以willing-to-wait模式去申請latch，在miss之后以spin方式獲得了latch的次數
10-3 Latch Miss Sources
Latch Miss Sources Snaps: 70719-70723 -> only latches with sleeps are shown -> ordered by name, sleeps desc NoWait Waiter Latch Name Where Misses Sleeps Sleeps ------------------------ -------------------------- ------- ---------- -------- ASM Keyed state latch kfksolGet 0 1 1 ASM allocation kfgpnSetDisks2 0 17 0 ASM allocation kfgpnClearDisks 0 5 0 ASM allocation kfgscCreate 0 4 0 ASM allocation kfgrpGetByName 0 1 26 ASM map headers kffmUnidentify_3 0 7 8 ASM map headers kffmAllocate 0 6 0 ASM map headers kffmIdentify 0 6 11 ASM map headers kffmFree 0 1 0 ASM map operation freeli kffmTranslate2 0 15 8 ASM map operation hash t kffmUnidentify 0 44,677 36,784 ASM map operation hash t kffmTranslate 0 220 3,517
數據來源為DBA_HIST_LATCH_MISSES_SUMMARY
latch name Latch閂的名字
where : 指哪些代碼路徑內核函數持有過這些該latch ，而不是哪些代碼路徑要申請這些latch； 例如kcbgtcr函數的作用是Get a block for Consistent read，其持有latch :cache buffers chain是很正常的事情
NoWait Misses: 以no-wait模式來申請latch但直接失敗的次數
Sleeps: 指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數 time of sleeps resulted in making the latch request
Waiter Sleeps：等待者休眠的次數 times of sleeps that waiters did for each where; Sleep 是阻塞者等待的次數 ， Waiter Sleeps是被阻塞者等待的次數
10-4 Mutex Sleep Summary
Mutex Sleep Summary Snaps: 70719-70723 -> ordered by number of sleeps desc Wait Mutex Type Location Sleeps Time (ms) --------------------- -------------------------------- ------------ ------------ Cursor Pin kksfbc [KKSCHLFSP2] 4,364 14,520 Cursor Pin kkslce [KKSCHLPIN2] 2,396 2,498 Library Cache kglpndl1 95 903 475 Library Cache kglpin1 4 800 458 Library Cache kglpnal2 91 799 259 Library Cache kglget1 1 553 1,697 Library Cache kglpnal1 90 489 88 Library Cache kgllkdl1 85 481 1,528 Cursor Pin kksLockDelete [KKSCHLPIN6] 410 666 Cursor Stat kkocsStoreBindAwareStats [KKSSTA 346 497 Library Cache kglhdgn2 106 167 348 Library Cache kglhdgh2 64 26 84 Library Cache kgldtin1 42 19 55 Cursor Pin kksfbc [KKSCHLPIN1] 13 34 Library Cache kglhdgn1 62 11 13 Library Cache kgllkal1 80 9 12 Library Cache kgllkc1 57 6 0 Cursor Pin kksSetBindType [KKSCHLPIN3] 5 5 Library Cache kglGetHandleReference 124 4 20 Library Cache kglUpgradeLock 119 4 0 Library Cache kglget2 2 3 0 Library Cache kglati1 45 1 0 Library Cache kglini1 32 1 0 Library Cache kglobld1 75 1 0 Library Cache kglobpn1 71 1 0
Mutex是10.2.0.2以后引入的新的內存鎖機制，具體對Mutex的描述見 《深入理解Oracle中的Mutex》：http://www.askmaclean.com/archives/understanding-oracle-mutex.html
Mutex Type
Mutex的類型其實就是 mutex對應的客戶的名字， 在版本10.2中基本只有KKS使用Mutex，所以僅有3種:
Cursor Stat (kgx_kks1)
Cursor Parent (kgx_kks2)
Cursor Pin (kgx_kks3)
11g中增加了Library Cache
Location 發起對該Mutex申請的代碼路徑code location，而不是還持有該Mutex的代碼路徑或曰內核函數
10.2中最常見的下面的幾個函數
kkspsc0 -負責解析游標 – 檢測我們正在解析的游標是否有對象的parent cursor heap 0存在
kksfbc – 負責找到合適的子游標 或者創建一個新的子游標
kksFindCursorstat
Sleeps:
當一個Mutex被申請時， 一般稱為一個get request。 若初始的申請未能得到授權， 則該進程會因為此次申請而進入到255次SPIN中(_mutex_spin_count Mutex spin count)，每次SPIN循環迭代過程中該進程都會去看看Mutex被釋放了嗎。
若該Mutex在SPIN之后仍未被釋放，則該進程針對申請的mutex進入對應的mutex wait等待事件中。 實際進程的等待事件和等待方式由mutex的類型鎖決定，例如 Cursor pin、Cursor Parent。 舉例來說，這種等待可能是阻塞等待，也可以是sleep。
但是請注意在V$MUTEX_SLEEP_*視圖上的sleep列意味著等待的次數。相關代碼函數在開始進入等待時自加這個sleep字段。
等待計時從進程進入等待前開始計算等待時間， 當一個進程結束其等待，則等待的時間加入都總和total中。 該進程再次嘗試申請之前的Mutex，若該Mutex仍不可用，則它再次進入spin/wait的循環。
V$MUTEX_SLEEP_HISTORY視圖的GETS列僅在成功申請到一個Mutex時才增加。
Wait Time (ms) 類似于latch，spin time 不算做mutex的消耗時間，它只包含等待消耗的時間。
=====================================================================
11 segment statistics 段級統計
11-1 Segments by Logical Reads
Segments by Logical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Logical Reads: 2,021,476,421 -> Captured Segments account for 83.7% of Total Tablespace Subobject Obj. Logical Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 372,849,920 18.44 CONTENT_OW INDEX_TS MZ_PRODUCT__LS_PK INDEX 329,829,632 16.32 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 218,419,008 10.80 CONTENT_OW PLAYLIST_A MZ_PLAYLIST_ARTIST TABLE 182,426,240 9.02 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 108,597,376 5.37
owner : 數據段的所有者
Tablespace Name: 數據段所在表空間名
Object Name : 對象名
Subobject Name：子對象名，例如一個分區表的某個分區
obj Type: 對象類型 一般為TABLE /INDEX 或者分區或子分區
Logical Reads ：該數據段上發生過的邏輯讀 ， 單位為 塊數*次數
%Total : 占總的邏輯讀的百分比 ， (當前對象上發生過的邏輯讀/ Total DB 邏輯讀)
11-2 Segments by Physical Reads
Segments by Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Reads: 56,839,035 -> Captured Segments account for 51.9% of Total Tablespace Subobject Obj. Physical Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW SONG_TS MZ_SONG TABLE 7,311,928 12.86 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 4,896,554 8.61 CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 3,099,387 5.45 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,529,971 2.69 CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 1,391,735 2.45
Physical Reads: 該數據段上發生過的物理讀 ， 單位為 塊數*次數
%Total : 占總的物理讀的百分比 ， (當前對象上發生過的邏輯讀/ Total DB 邏輯讀)
11-3 Segments by Physical Read Requests
Segments by Physical Read Requests DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Read Requests: 33,936,360 -> Captured Segments account for 45.5% of Total Tablespace Subobject Obj. Phys Read Owner Name Object Name Name Type Requests %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 3,099,346 9.13 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,529,950 4.51 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 1,306,756 3.85 CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE 910,537 2.68 CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 820,459 2.42
Phys Read Requests ： 物理讀的申請次數
%Total ： (該段上發生的物理讀的申請次數/ physical read IO requests)
11-4 Segments by UnOptimized Reads
Segments by UnOptimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total UnOptimized Read Requests: 811,466 -> Captured Segments account for 58.5% of Total Tablespace Subobject Obj. UnOptimized Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 103,580 12.76 CONTENT_OW SONG_TS MZ_SONG TABLE 56,946 7.02 CONTENT_OW DATA_TS MZ_IMAGE TABLE 47,017 5.79 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 40,950 5.05 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 30,406 3.75
UnOptimized Reads UnOptimized Read Reqs = Physical Read Reqts – Optimized Read Reqs
Optimized Read Requests是指 哪些滿足Exadata Smart Flash Cache ( or the Smart Flash Cache in OracleExadata V2 (Note that despite same name, concept and use of
‘Smart Flash Cache’ in Exadata V2 is different from ‘Smart Flash Cache’ in Database Smart Flash Cache)).的物理讀 次數 。 滿足從smart flash cache走的讀取申請唄認為是optimized ，因為這些讀取要比普通從磁盤走快得多。
此外通過smart scan 讀取storage index的情況也被認為是’optimized read requests’ ，源于可以避免讀取不相關的數據。
當用戶不在使用Exadata時，則UnOptimized Read Reqs總是等于 Physical Read Reqts
%Total : (該段上發生的物理讀的UnOptimized Read Reqs / ( physical read IO requests – physical read requests optimized ))
11-5 Segments by Optimized Reads
Segments by Optimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Optimized Read Requests: 33,124,894 -> Captured Segments account for 45.2% of Total Tablespace Subobject Obj. Optimized Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 2,995,766 9.04 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,489,000 4.50 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 1,276,350 3.85 CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE 890,775 2.69 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 816,067 2.46
關于optimizerd read 上面已經解釋過了，這里的單位是 request 次數
%Total : (該段上發生的物理讀的 Optimized Read Reqs/ physical read requests optimized )
11-6 Segments by Direct Physical Reads
Segments by Direct Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Direct Physical Reads: 14,118,552 -> Captured Segments account for 94.2% of Total Tablespace Subobject Obj. Direct Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW SONG_TS MZ_SONG TABLE 7,084,416 50.18 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 4,839,984 34.28 CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 1,361,133 9.64 CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 5,904 .04 CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 1,656 .01
Direct reads 直接路徑物理讀，單位為 塊數*次數
%Total (該段上發生的direct path reads /Total physical reads direct )
11-7 Segments by Physical Writes
Segments by Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Writes: 590,563 -> Captured Segments account for 38.3% of Total Tablespace Subobject Obj. Physical Owner Name Object Name Name Type Writes %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 23,595 4.00 CONTENT_OW DATA_TS MZ_PODCAST TABLE 19,834 3.36 CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX 16,345 2.77 SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE 14,173 2.40 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 9,645 1.63
Physical Writes ，物理寫 單位為 塊數*次數
Total % (該段上發生的物理寫 /Total physical writes )
11-9 Segments by Physical Write Requests
Segments by Physical Write Requests DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Write Requestss: 436,789 -> Captured Segments account for 43.1% of Total Tablespace Subobject Obj. Phys Write Owner Name Object Name Name Type Requests %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 22,581 5.17 CONTENT_OW DATA_TS MZ_PODCAST TABLE 19,797 4.53 CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX 14,529 3.33 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 9,434 2.16 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 8,618 1.97
Phys Write Requests 物理寫的請求次數 ，單位為次數
%Total (該段上發生的物理寫請求次數 /physical write IO requests )
11-10 Segments by Direct Physical Writes
Segments by Direct Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Direct Physical Writes: 29,660 -> Captured Segments account for 18.3% of Total Tablespace Subobject Obj. Direct Owner Name Object Name Name Type Writes %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE 4,601 15.51 CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 620 2.09 CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 134 .45 CONTENT_OW DATA_TS SYS_LOB0000203779C00 LOB 46 .16 CONTENT_OW DATA_TS SYS_LOB0000203796C00 LOB 41 .14
Direct Writes 直接路徑寫， 單位額為塊數*次數
%Total 為(該段上發生的直接路徑寫 /physical writes direct )
11-11 Segments by Table Scans
Segments by Table Scans DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Table Scans: 10,713 -> Captured Segments account for 1.0% of Total Tablespace Subobject Obj. Table Owner Name Object Name Name Type Scans %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 92 .86 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 14 .13 CONTENT_OW SONG_TS MZ_SONG TABLE 3 .03 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 1 .01
Table Scans 來源為dba_hist_seg_stat.table_scans_delta 不過這個指標并不十分精確
11-12 Segments by DB Blocks Changes
Segments by DB Blocks Changes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of DB Block Changes for each top segment compared -> with total DB Block Changes for all segments captured by the Snapshot Tablespace Subobject Obj. DB Block % of Owner Name Object Name Name Type Changes Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX 347,856 10.21 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 269,504 7.91 CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX 251,904 7.39 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 201,056 5.90 CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 199,888 5.86
DB Block Changes ，單位為塊數*次數
%Total : (該段上發生block changes / db block changes )
11-13 Segments by Row Lock Waits
Segments by Row Lock Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of row lock waits for each top segment compared -> with total row lock waits for all segments captured by the Snapshot Row Tablespace Subobject Obj. Lock % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 72,005 43.86 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 13,795 8.40 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 12,383 7.54 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 8,937 5.44 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 8,531 5.20
Row Lock Waits 是指行鎖的等待次數 數據來源于 dba_hist_seg_stat.ROW_LOCK_WAITS_DELTA
11-14 Segments by ITL WAITS
Segments by ITL Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of ITL waits for each top segment compared -> with total ITL waits for all segments captured by the Snapshot Tablespace Subobject Obj. ITL % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 95 30.16 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 48 15.24 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 21 6.67 CONTENT_OW INDEX_TS MZ_SALABLE_FIRST_AVA INDEX 21 6.67 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 20 6.35
關于 ITL的介紹詳見： http://www.askmaclean.com/archives/enqueue-tx-row-lock-index-itl-wait-event.html
ITL Waits 等待 ITL 的次數，數據來源為 dba_hist_seg_stat.itl_waits_delta
11-14 Segments by Buffer Busy Waits
Segments by Buffer Busy Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of Buffer Busy Waits for each top segment compared -> with total Buffer Busy Waits for all segments captured by the Snapshot Buffer Tablespace Subobject Obj. Busy % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 251,073 57.07 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 36,186 8.23 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 31,786 7.23 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 15,663 3.56 CONTENT_OW INDEX_TS MZ_CS_WORK_PENDING_R INDEX 11,087 2.52
Buffer Busy Waits 該數據段上發生 buffer busy wait的次數 數據來源 dba_hist_seg_stat.buffer_busy_waits_delta
11-15 Segments by Global Cache Buffer
Segments by Global Cache Buffer BusyDB/Inst: MAC/MAC2 Snaps: 70719-7072 -> % of Capture shows % of GC Buffer Busy for each top segment compared -> with GC Buffer Busy for all segments captured by the Snapshot GC Tablespace Subobject Obj. Buffer % of Owner Name Object Name Name Type Busy Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 2,135,528 50.07 CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 652,900 15.31 CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 552,161 12.95 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 113,042 2.65 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 98,134 2.30
GC Buffer Busy 數據段上發揮僧gc buffer busy的次數， 數據源 dba_hist_seg_stat.gc_buffer_busy_delta
11-15 Segments by CR Blocks Received
Segments by CR Blocks Received DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total CR Blocks Received: 763,037 -> Captured Segments account for 40.9% of Total CR Tablespace Subobject Obj. Blocks Owner Name Object Name Name Type Received %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 69,100 9.06 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 44,491 5.83 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 36,830 4.83 CONTENT_OW DATA_TS MZ_PODCAST TABLE 36,632 4.80 CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX 19,646 2.57
CR Blocks Received ：是指RAC中本地節點接收到global cache CR blocks 的數量； 數據來源為 dba_hist_seg_stat.gc_cu_blocks_received_delta
%Total : (該段上在本節點接收的Global CR blocks / gc cr blocks received )
11-16 Segments by Current Blocks Received
Segments by Current Blocks ReceivedDB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Current Blocks Received: 704,731 -> Captured Segments account for 61.8% of Total Current Tablespace Subobject Obj. Blocks Owner Name Object Name Name Type Received %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 56,287 7.99 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 45,139 6.41 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 40,350 5.73 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 22,808 3.24 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX 13,343 1.89
Current Blocks Received :是指RAC中本地節點接收到global cache Current blocks 的數量 ，數據來源DBA_HIST_SEG_STAT.gc_cu_blocks_received_delta
%Total : (該段上在本節點接收的 global cache current blocks / gc current blocks received)
12 Dictionary Cache Stats
Dictionary Cache Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> "Pct Misses" should be very low (< 2% in most cases) -> "Final Usage" is the number of cache entries being used Get Pct Scan Pct Mod Final Cache Requests Miss Reqs Miss Reqs Usage ------------------------- ------------ ------ ------- ----- -------- ---------- dc_awr_control 87 2.3 0 N/A 6 1 dc_global_oids 1,134 7.8 0 N/A 0 13 dc_histogram_data 6,119,027 0.9 0 N/A 0 11,784 dc_histogram_defs 1,898,714 2.3 0 N/A 0 5,462 dc_object_grants 175 26.9 0 N/A 0 4 dc_objects 10,254,514 0.2 0 N/A 0 3,807 dc_profiles 8,452 0.0 0 N/A 0 2 dc_rollback_segments 3,031,044 0.0 0 N/A 0 1,947 dc_segments 1,812,243 1.4 0 N/A 10 3,595 dc_sequences 15,783 69.6 0 N/A 15,782 20 dc_table_scns 70 2.9 0 N/A 0 1 dc_tablespaces 1,628,112 0.0 0 N/A 0 37 dc_users 2,037,138 0.0 0 N/A 0 52 global database name 7,698 0.0 0 N/A 0 1 outstanding_alerts 264 99.6 0 N/A 8 1 sch_lj_oids 51 7.8 0 N/A 0 1
Dictionary Cache 字典緩存也叫row cache
數據來源為dba_hist_rowcache_summary
Cache 字典緩存類名kqrstcid <=> kqrsttxt cid=3(dc_rollback_segments)
Get Requests 申請獲取該數據字典緩存對象的次數 gets
Miss : GETMISSES 申請獲取該數據字典緩存對象但 miss的次數
Pct Miss ： GETMISSES /Gets ， Miss的比例 ，這個pct miss應當非常低 小于2%，否則有出現大量row cache lock的可能
Scan Reqs：掃描申請的次數 ，kqrssc 、kqrpScan 、kqrpsiv時發生scan 會導致掃描數增加 kqrstsrq++(scan requests) ，例如migrate tablespace 時調用 kttm2b函數 為了安全刪除uet$中的記錄會callback kqrpsiv (used extent cache)，實際很少見
Pct Miss：SCANMISSES/SCANS
Mod Reqs: 申請修改字典緩存對象的次數，從上面的數據可以看到dc_sequences的mod reqs很高，這是因為sequence是變化較多的字典對象
Final Usage ：包含有有效數據的字典緩存記錄的總數 也就是正在被使用的row cache記錄 USAGE Number of cache entries that contain valid data
Dictionary Cache Stats (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723 GES GES GES Cache Requests Conflicts Releases ------------------------- ------------ ------------ ------------ dc_awr_control 14 2 0 dc_global_oids 88 0 102 dc_histogram_defs 43,518 0 43,521 dc_objects 21,608 17 21,176 dc_profiles 1 0 1 dc_segments 24,974 14 24,428 dc_sequences 25,178 10,644 347 dc_table_scns 2 0 2 dc_tablespaces 165 0 166 dc_users 119 0 119 outstanding_alerts 478 8 250 sch_lj_oids 4 0 4
GES Request kqrstilr total instance lock requests ，通過全局隊列服務GES 來申請instance lock的次數
GES request 申請的原因可能是 dump cache object、kqrbfr LCK進程要background free some parent objects釋放一些parent objects 等
GES Conflicts kqrstifr instance lock forced-releases ， LCK進程以AST方式 釋放鎖的次數 ，僅出現在kqrbrl中
GES Releases kqrstisr instance lock self-releases ，LCK進程要background free some parent objects釋放一些parent objects 時可能自增
上述數據中可以看到僅有dc_sequences 對應的GES Conflicts較多， 對于sequence 使用ordered和non-cache選項會導致RAC中的一個邊際效應，即”row cache lock”等待源于DC_SEQUENCES ROW CACHE。 DC_SEQUENCES 上的GETS request、modifications 、GES requests和GES conflict 與引發生成一個新的 sequence number的特定SQL執行頻率相關。
在Oracle 10g中，ORDERED Sequence還可能在高并發下造成大量DFS lock Handle 等待，由于bug 5209859
13 Library Cache Activity
Library Cache Activity DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> "Pct Misses" should be very low Get Pct Pin Pct Invali- Namespace Requests Miss Requests Miss Reloads dations --------------- ------------ ------ -------------- ------ ---------- -------- ACCOUNT_STATUS 8,436 0.3 0 N/A 0 0 BODY 8,697 0.7 15,537 0.7 49 0 CLUSTER 317 4.7 321 4.7 0 0 DBLINK 9,212 0.1 0 N/A 0 0 EDITION 4,431 0.0 8,660 0.0 0 0 HINTSET OBJECT 1,027 9.5 1,027 14.4 0 0 INDEX 792 18.2 792 18.2 0 0 QUEUE 10 0.0 1,733 0.0 0 0 RULESET 0 N/A 8 87.5 7 0 SCHEMA 8,169 0.0 0 N/A 0 0 SQL AREA 533,409 4.8 -4,246,727,944 101.1 44,864 576 SQL AREA BUILD 71,500 65.5 0 N/A 0 0 SQL AREA STATS 41,008 90.3 41,008 90.3 1 0 TABLE/PROCEDURE 320,310 0.6 1,033,991 3.6 25,378 0 TRIGGER 847 0.0 38,442 0.3 110 0
NameSpace library cache 的命名空間
GETS Requests 該命名空間所包含對象的library cache lock被申請的次數
GETHITS 對象的 library cache handle 正好在內存中被找到的次數
Pct Misses : ( 1- ( GETHITS /GETS Requests)) *100
Pin Requests 該命名空間所包含對象上pin被申請的次數
PINHITS 要pin的對象的heap metadata正好在shared pool中的次數
Pct Miss ( 1- ( PINHITS /Pin Requests)) *100
Reloads 指從object handle 被重建開始不是第一次PIN該對象的PIN ，且該次PIN要求對象從磁盤上讀取加載的次數 ;Reloads值較高的情況 建議增大shared_pool_size
INVALIDATIONS 由于以來對象被修改導致該命名空間所包含對象被標記為無效的次數
Library Cache Activity (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723 GES Lock GES Pin GES Pin GES Inval GES Invali- Namespace Requests Requests Releases Requests dations --------------- ------------ ------------ ------------ ----------- ----------- ACCOUNT_STATUS 8,436 0 0 0 0 BODY 0 15,497 15,497 0 0 CLUSTER 321 321 321 0 0 DBLINK 9,212 0 0 0 0 EDITION 4,431 4,431 4,431 0 0 HINTSET OBJECT 1,027 1,027 1,027 0 0 INDEX 792 792 792 0 0 QUEUE 8 1,733 1,733 0 0 RULESET 0 8 8 0 0 SCHEMA 4,226 0 0 0 0 TABLE/PROCEDURE 373,163 704,816 704,816 0 0 TRIGGER 0 38,430 38,430 0 0
GES Lock Request: dlm_lock_requests Lock instance-lock ReQuests 申請獲得lock instance lock的次數
GES PIN request : DLM_PIN_REQUESTS Pin instance-lock ReQuests 申請獲得pin instance lock的次數
GES Pin Releases DLM_PIN_RELEASES release the pin instance lock 釋放pin instance lock的次數
GES Inval Requests DLM_INVALIDATION_REQUESTS get the invalidation instance lock 申請獲得invalidation instance lock的次數
GES Invali- dations DLM_INVALIDATIONS 接收到其他節點的invalidation pings次數
14 Process Memory Summary
Process Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> B: Begin Snap E: End Snap -> All rows below contain absolute values (i.e. not diffed over the interval) -> Max Alloc is Maximum PGA Allocation size at snapshot time -> Hist Max Alloc is the Historical Max Allocation for still-connected processes -> ordered by Begin/End snapshot, Alloc (MB) desc Hist Avg Std Dev Max Max Alloc Used Alloc Alloc Alloc Alloc Num Num Category (MB) (MB) (MB) (MB) (MB) (MB) Proc Alloc - -------- --------- --------- -------- -------- ------- ------- ------ ------ B Other 16,062.7 N/A 6.1 66.6 3,370 3,370 2,612 2,612 SQL 5,412.2 4,462.9 2.2 89.5 4,483 4,483 2,508 2,498 Freeable 2,116.4 .0 .9 6.3 298 N/A 2,266 2,266 PL/SQL 94.0 69.8 .0 .0 1 1 2,610 2,609 E Other 15,977.3 N/A 6.1 66.9 3,387 3,387 2,616 2,616 SQL 5,447.9 4,519.0 2.2 89.8 4,505 4,505 2,514 2,503 Freeable 2,119.9 .0 .9 6.3 297 N/A 2,273 2,273 PL/SQL 93.2 69.2 .0 .0 1 1 2,614 2,613
數據來源為dba_hist_process_mem_summary， 這里是對PGA 使用的一個小結，幫助我們了解到底誰用掉了PGA
B: 開始快照 E: 結束快照
該環節列出 PGA中各分類的使用量
Category 分類名，包括”SQL”, “PL/SQL”, “OLAP” 和”JAVA”. 特殊分類是 “Freeable” 和”Other”. Free memory是指哪些 OS已經分配給進程，但沒有分配給任何分類的內存。 “Other”是已經分配給分類的內存，但不是已命名的分類
Alloc (MB) allocated_total 該分類被分配的總內存
Used (MB) used_total 該分類已使用的內存
Avg Alloc (MB) allocated_avg 平均每個進程中該分類分配的內存量
Std Dev Alloc (MB) ：該分類分配的內存在每個進程之間的標準差
Max Alloc (MB) ALLOCATED_MAX ：在快照時間內單個進程該分類最大分配過的內存量：Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc (MB) MAX_ALLOCATED_MAX: 目前仍鏈接著的進程該分類最大分配過的內存量：Hist Max Alloc is the Historical Max Allocation for still-connected processes
Num Proc num_processes 進程數目
Num Alloc NON_ZERO_ALLOCS 分配了該類型 內存的進程數目
14 SGA信息
14 -1 SGA Memory Summary
SGA Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723 End Size (Bytes) SGA regions Begin Size (Bytes) (if different) ------------------------------ ------------------- ------------------- Database Buffers 20,669,530,112 Fixed Size 2,241,880 Redo Buffers 125,669,376 Variable Size 10,536,094,376 ------------------- sum 31,333,535,744
粗粒度的sga區域內存使用信息， End Size僅在于begin size不同時打印
14-2 SGA breakdown difference
SGA breakdown difference DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> ordered by Pool, Name -> N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshot Pool Name Begin MB End MB % Diff ------ ------------------------------ -------------- -------------- ------- java free memory 64.0 64.0 0.00 large PX msg pool 7.8 7.8 0.00 large free memory 247.8 247.8 0.00 shared Checkpoint queue 140.6 140.6 0.00 shared FileOpenBlock 2,459.2 2,459.2 0.00 shared KGH: NO ACCESS 1,629.6 1,629.6 0.00 shared KGLH0 997.7 990.5 -0.71 shared KKSSP 312.2 308.9 -1.06 shared SQLA 376.6 370.6 -1.61 shared db_block_hash_buckets 178.0 178.0 0.00 shared dbktb: trace buffer 156.3 156.3 0.00 shared event statistics per sess 187.1 187.1 0.00 shared free memory 1,208.9 1,220.6 0.97 shared gcs resources 435.0 435.0 0.00 shared gcs shadows 320.6 320.6 0.00 shared ges enqueues 228.9 228.9 0.00 shared ges resource 118.3 118.3 0.00 shared init_heap_kfsg 1,063.6 1,068.1 0.43 shared kglsim object batch 124.3 124.3 0.00 shared ksunfy : SSO free list 174.7 174.7 0.00 stream free memory 128.0 128.0 0.00 buffer_cache 19,712.0 19,712.0 0.00 fixed_sga 2.1 2.1 0.00 log_buffer 119.8 119.8 0.00 -------------------------------------------------------------
Pool 內存池的名字
Name 內存池中細分組件的名字 例如KGLH0 存放KEL Heap 0 、SQLA存放SQL執行計劃等
Begin MB 快照開始時該組件的內存大小
End MB 快照結束時該組件的內存大小
% Diff 差異百分比
特別注意 由于AMM /ASMM引起的shared pool收縮 一般在sga breakdown中可以提現 例如SQLA 、KQR等組件大幅縮小 ，可能導致一系列的解析等待 cursor: Pin S on X 、row cache lock等
此處的free memory信息也值得我們關注， 一般推薦shared pool應當有300~400 MB 的free memory為宜
15 Streams統計
Streams CPU/IO Usage DB/Inst: ORCL/orcl1 Snaps: 556-559 -> Streams processes ordered by CPU usage -> CPU and I/O Time in micro seconds Session Type CPU Time User I/O Time Sys I/O Time ------------------------- -------------- -------------- -------------- QMON Coordinator 101,698 0 0 QMON Slaves 63,856 0 0 ------------------------------------------------------------- Streams Capture DB/Inst: CATGT/catgt Snaps: 911-912 -> Lag Change should be small or negative (in seconds) Captured Enqueued Pct Pct Pct Pct Per Per Lag RuleEval Enqueue RedoWait Pause Capture Name Second Second Change Time Time Time Time ------------ -------- -------- -------- -------- -------- -------- -------- CAPTURE_CAT 650 391 93 0 23 0 71 ------------------------------------------------------------- Streams Apply DB/Inst: CATGT/catgt Snaps: 911-912 -> Pct DB is the percentage of all DB transactions that this apply handled -> WDEP is the wait for dependency -> WCMT is the wait for commit -> RBK is rollbacks -> MPS is messages per second -> TPM is time per message in milli-seconds -> Lag Change should be small or negative (in seconds) Applied Pct Pct Pct Pct Applied Dequeue Apply Lag Apply Name TPS DB WDEP WCMT RBK MPS TPM TPM Change ------------ -------- ---- ---- ---- --- -------- -------- -------- -------- APPLY_CAT 0 0 0 0 0 0 0 0 0 -------------------------------------------------------------
Capture Name : Streams捕獲進程名
Captured Per Second ：每秒挖掘出來的message 條數
Enqueued Per Second: 每秒入隊的message條數
lag change: 指日志生成的時間到挖掘到該日志生成 message的時間延遲
Pct Enqueue Time： 入隊時間的比例
Pct redoWait Time : 等待redo的時間比例
Pct Pause Time : Pause 時間的比例
Apply Name Streams 應用Apply進程的名字
Applied TPS : 每秒應用的事務數
Pct DB: 所有的DB事務中 apply處理的比例
Pct WDEP: 由于等待依賴的數據而耗費的時間比例
Pct WCMT: 由于等待commit而耗費的時間比例
Pct RBK: 事務rollback 回滾的比例
Applied MPS: 每秒應用的message 數
Dequeue TPM: 每毫秒出隊的message數
Lag Change:指最新message生成的時間到其被Apply收到的延遲
16 Resource Limit
Resource Limit Stats DB/Inst: MAC/MAC2 Snap: 70723 -> only rows with Current or Maximum Utilization > 80% of Limit are shown -> ordered by resource name Current Maximum Initial Resource Name Utilization Utilization Allocation Limit ------------------------------ ------------ ------------ ---------- ---------- ges_procs 2,612 8,007 10003 10003 processes 2,615 8,011 10000 10000
數據源于dba_hist_resource_limit
注意這里僅列出當前使用或最大使用量>80% *最大限制的資源名，如果沒有列在這里則說明 資源使用量安全
Current Utilization 當前對該資源(包括Enqueue Resource、Lock和processes)的使用量
Maximum Utilization 從最近一次實例啟動到現在該資源的最大使用量
Initial Allocation 初始分配值，一般等于參數文件中指定的值
Limit 實際上限值
17 init.ora Parameters
init.ora Parameters DB/Inst: MAC/MAC2 Snaps: 70719-70723 End value Parameter Name Begin value (if different) ----------------------------- --------------------------------- -------------- _compression_compatibility 11.2.0 _kghdsidx_count 4 _ksmg_granule_size 67108864 _shared_pool_reserved_min_all 4100 archive_lag_target 900 audit_file_dest /u01/app/oracle/admin/MAC/adum audit_trail OS cluster_database TRUE compatible 11.2.0.2.0 control_files +DATA/MAC/control01.ctl, +RECO db_16k_cache_size 268435456 db_block_size 8192 db_cache_size 19327352832 db_create_file_dest +DATA
Parameter Name 參數名
Begin value 開始快照時的參數值
End value 結束快照時的參數值 (僅在發生變化時打印)
18 Global Messaging Statistics
Global Messaging Statistics DB/Inst: MAC/MAC2 Snaps: 70719-70723 Statistic Total per Second per Trans --------------------------------- ---------------- ------------ ------------ acks for commit broadcast(actual) 53,705 14.9 0.2 acks for commit broadcast(logical 311,182 86.1 1.3 broadcast msgs on commit(actual) 317,082 87.7 1.3 broadcast msgs on commit(logical) 317,082 87.7 1.3 broadcast msgs on commit(wasted) 263,332 72.9 1.1 dynamically allocated gcs resourc 0 0.0 0.0 dynamically allocated gcs shadows 0 0.0 0.0 flow control messages received 267 0.1 0.0 flow control messages sent 127 0.0 0.0 gcs apply delta 0 0.0 0.0 gcs assume cvt 55,541 15.4 0.2
全局通信統計信息，數據來源WRH$_DLM_MISC;
20 Global CR Served Stats
Global CR Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 Statistic Total ------------------------------ ------------------ CR Block Requests 403,703 CURRENT Block Requests 444,896 Data Block Requests 403,705 Undo Block Requests 94,336 TX Block Requests 307,896 Current Results 652,746 Private results 21,057 Zero Results 104,720 Disk Read Results 69,418 Fail Results 508 Fairness Down Converts 102,844 Fairness Clears 15,207 Free GC Elements 0 Flushes 105,052 Flushes Queued 0 Flush Queue Full 0 Flush Max Time (us) 0 Light Works 71,793 Errors 117
LMS傳輸CR BLOCK的統計信息，數據來源WRH$_CR_BLOCK_SERVER
21 Global CURRENT Served Stats
Global CURRENT Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Pins = CURRENT Block Pin Operations -> Flushes = Redo Flush before CURRENT Block Served Operations -> Writes = CURRENT Block Fusion Write Operations Statistic Total % <1ms % <10ms % <100ms % <1s % <10s ---------- ------------ -------- -------- -------- -------- -------- Pins 73,018 12.27 75.96 8.49 2.21 1.08 Flushes 79,336 5.98 50.17 14.45 19.45 9.95 Writes 102,189 3.14 35.23 19.34 33.26 9.03
數據來源dba_hist_current_block_server
Time to process current block request = (pin time + flush time + send time)
Pins CURRENT Block Pin Operations ， PIN的內涵是處理一個BAST 不包含對global current block的flush和實際傳輸
The pin time represents how much time is required to process a BAST. It does not include the flush time and
the send time. The average pin time per block served should be very low because the processing consists
mainly of code path and should never be blocked.
Flush 指 臟塊被LMS進程傳輸出去之前，其相關的redo必須由LGWR已經flush 到磁盤上
Write 指fusion write number of writes which were mediated； 節點之間寫臟塊需求相互促成的行為 KJBL.KJBLREQWRITE gcs write request msgs 、gcs writes refused
% <1ms % <10ms % <100ms % <1s % <10s 分別對應為pin、flush、write行為耗時的比例
例如在上例中flush和 write 在1s 到10s之間的有9%，在100ms 和1s之間的有19%和33%，因為flush和write都是IO操作 所以這里可以預見IO存在問題，延遲較高
22 Global Cache Transfer Stats
Global Cache Transfer Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Immediate (Immed) - Block Transfer NOT impacted by Remote Processing Delays -> Busy (Busy) - Block Transfer impacted by Remote Contention -> Congested (Congst) - Block Transfer impacted by Remote System Load -> ordered by CR + Current Blocks Received desc CR Current ----------------------------- ----------------------------- Inst Block Blocks % % % Blocks % % % No Class Received Immed Busy Congst Received Immed Busy Congst ---- ----------- -------- ------ ------ ------ -------- ------ ------ ------ 1 data block 133,187 76.3 22.6 1.1 233,138 75.2 23.0 1.7 4 data block 143,165 74.1 24.9 1.0 213,204 76.6 21.8 1.6 3 data block 122,761 75.9 23.0 1.1 220,023 77.7 21.0 1.3 1 undo header 104,219 95.7 3.2 1.1 941 93.4 5.8 .7 4 undo header 95,823 95.2 3.7 1.1 809 93.4 5.3 1.2 3 undo header 95,592 95.6 3.3 1.1 912 94.6 4.5 .9 1 undo block 25,002 95.8 3.4 .9 0 N/A N/A N/A 4 undo block 23,303 96.0 3.1 .9 0 N/A N/A N/A 3 undo block 21,672 95.4 3.7 .9 0 N/A N/A N/A 1 Others 1,909 92.0 6.8 1.2 6,057 89.6 8.9 1.5 4 Others 1,736 92.4 6.1 1.5 5,841 88.8 9.9 1.3 3 Others 1,500 92.4 5.9 1.7 4,405 87.7 10.8 1.6
數據來源DBA_HIST_INST_CACHE_TRANSFER
Inst No 節點號
Block Class 塊的類型
CR Blocks Received 該節點上 該類型CR 塊的接收數量
CR Immed %: CR塊請求立即接收到的比例
CR Busy%：CR塊請求由于遠端爭用而沒有立即接收到的比例
CR Congst%: CR塊請求由于遠端負載高而沒有立即接收到的比例
Current Blocks Received 該節點上 該類型Current 塊的接收數量
Current Immed %: Current塊請求立即接收到的比例
Current Busy%：Current塊請求由于遠端爭用而沒有立即接收到的比例
Current Congst%: Current塊請求由于遠端負載高而沒有立即接收到的比例
Congst%的比例應當非常低 不高于2%， Busy%很大程度受到IO的影響，如果超過10% 一般會有嚴重的gc buffer busy acquire/release
參考文檔
Statistics Descriptions http://docs.oracle.com/cd/B19306_01/server.102/b14237/stats002.htm
Memory Configuration and Use http://docs.oracle.com/cd/B19306_01/server.102/b14211/memory.htm
Library Cache Hit (%) http://docs.oracle.com/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_instance_efficiency_libcache_hit_pct.html
Oracle? Database Performance Tuning Guide 12c Release 1 (12.1)
How to Interpret the “SQL ordered by Physical Reads (UnOptimized)” Section in AWR Reports (11.2 onwards) [ID 1466035.1]
FILED UNDER: ORACLE, ORACLE SQL性能調優
最新最早最熱
26條評論
不了峰
精彩～～～～～～
2013年9月4日回復頂轉發
Ask_Maclean_liu_Oracle
SELECT DECODE(:B2 , 0, TO_NUMBER(NULL), 100 * SUM(LOGICAL_READS_DELTA)/:B2 ), DECODE(:B1 , 0, TO_NUMBER(NULL), 100 * SUM(PHYSICAL_READS_DELTA)/:B1 ) FROM DBA_HIST_SEG_S
TAT WHERE :B6 < SNAP_ID AND SNAP_ID <= :B5 AND DBID = :B4 AND INSTANCE_NUMBER = :B3
2013年9月7日回復頂轉發
Ask_Maclean_liu_Oracle
SELECT DECODE(B.TOTAL_SQL, 0, 0, 100 * (1 - B.SINGLE_USE_SQL / B.TOTAL_SQL)),
DECODE(E.TOTAL_SQL, 0, 0, 100 * (1 - E.SINGLE_USE_SQL / E.TOTAL_SQL)),
DECODE(B.TOTAL_SQL_MEM,
0,
0,
1 00 * (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_SUMM ARY E
WHERE B.SNAP_ID = :B4
AND E.SNAP_ID = :B3
AND B.INSTANCE_NUMBER = :B2
AND E.INSTANCE_NUMBER = :B2
AND B.DBID = :B1
AND E.DBID = :B1
2013年9月7日回復頂轉發
Rogers.LL
頂！不頂還有天理么？
2013年9月24日回復頂轉發
外網
太厲害了，權威
2013年9月27日回復頂轉發
tiantian
不結合案例來講，光講理論，有個皮用啊。到網上一搜，一大把，太普通了，沒有價值。
2013年10月8日回復頂轉發
Croco
@tiantian
2013年10月10日回復頂轉發
maclean
如果要結合案例的話 ，我想不夠寫一本書，也可以寫一本200頁的小冊子吧？
2013年10月8日回復頂轉發
maclean
PS:文章開頭的 AWR鷹眼是 結合案例講的，可能符合你的要求
2013年10月8日回復頂轉發
Croco
別人公布出來也沒找你要錢，你有能耐就說點有價值的，有建設性的。或者干脆你寫一個結合案例的如何？
嘴里不干不凈的，惹人厭煩
2013年10月10日回復頂轉發
qy
不知道該說你這種人點兒什么……
2013年10月10日回復頂轉發
long
不懂行吧，哥們
1月27日回復頂轉發
rjx
頂
2013年10月10日回復頂轉發
laughing
頂劉大。哈哈。好文章
2013年10月10日回復頂轉發
ballontt
贊
2013年10月10日回復頂轉發
Payne.Zhang
good job!
2013年10月10日回復頂轉發
Leot
2-8 Host CPU
Host CPU (CPUs: 24 Cores: 12 Sockets: 2)
~~~~~~~~ Load Average
Begin End %User %System %WIO %Idle
--------- --------- --------- --------- --------- ---------
8.41 12.84 24.7 7.1 0.2 65.8
“Load Average” begin/end值代表每個CPU的大致運行隊列大小。上例中快照開始到結束，平均 CPU負載增加了。
%User+%System=> 總的CPU使用率，在這里是31.8%
Elapsed Time * NUM_CPUS * CPU utilization= 60.23 (mins) * 24 * 31.8% = 459.67536 mins=Busy Time
與《2-5 Operating System Statistics》中的LOAD相呼應
這部分是如何與LOAD相呼應的？
LOAD在begin是8，end是13
另外，2-5里“所有CPU所能提供總的時間片”是不是敲錯位置了，指的是哪個數值？
2013年10月10日回復頂轉發
Ask_Maclean_liu_Oracle
2-5 Operating System Statistics
LOAD begin 8 end 13
與
2-8 Host CPU
Load Average 8.41 12.84
呼應
所有CPU所能提供總的時間片 這個指標沒有在AWR中，但我覺得有必要說明下這個知識點
2013年10月10日回復頂轉發
rocky_miko
Good job! Thank you for sharing~~:)
2013年10月10日回復頂轉發
TimAkimoff
Good！
2013年10月11日回復頂轉發
dla001
SYS$USERS一般是系統用戶登錄;
SYS$USERS is the default service for user sessions that are not associated with application services.
如果使用oracle_sid連接數據庫的話，那么都是算到 SYS$USERS 中的。
2013年10月12日回復頂轉發
劉洋
Logical Read 指的是次數吧，有時，一個數據塊的內容需要一次Logical Read，有時，一個數據塊的內容要多次Logical Read。
2月15日回復頂轉發
snowdrop
1-4中利用FORCE_MATCHING_SIGNATURE捕獲非綁定變量SQL，Xin提供的方法和劉大提供的方法測試出來的數據不一樣；解釋下原因吧
2月27日回復頂轉發
隨風H
我覺得是好文章，先看看
4月29日回復頂轉發
恰逢90后
請問如何通過awr報告判斷一個系統是OLTP還是OLAP？
7月14日回復頂轉發
Ask_Maclean_liu_Oracle
常見問題:如何使用AWR報告來診斷數據庫性能問題 (Doc ID 1523048.1)
適用于:
Oracle Database - Enterprise Edition - 版本 10.2.0.1 和更高版本
本文檔所含信息適用于所有平臺
目標
本文旨在提供如何解釋跟數據庫性能問題息息相關的AWR信息。
需要注意的是生成 AWR Report 或訪問 AWR 相關的視圖，以及使用任何 AWR 相關的診斷信息，都需要額外的 Diagnostic Pack License。這包括生成 AWR/ADDM/ASH report，也包括當技術支持要求的生成上述報表時。
注意: Oracle Diagnostics Pack (以及 Oracle Tuning Pack) 只在企業版中提供。
詳見:
Oracle? Database Licensing Information
12c Release 1 (12.1)
Part number E17614-08
Chapter 1 1 Oracle Database Editions
Feature Availability by Edition
http://docs.oracle.com/cd/E16655_01/license.121/e17614/editions.htm#DBLIC116
最佳實踐
如何主動避免問題發生及做好診斷信息的收集
有些問題是無法預見的，但大部分其它的問題如果及早發現一些征兆其實是可以避免的。同時，如果問題確實發生了，那么收集問題發生時的信息就非常重要。有關于如何主動避免問題及診斷信息的收集，請參見：
Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues
Document 1477599.1 Best Practices Around Data Collection For Performance Issues
提出問題、獲取幫助并分享您的經驗
您想要與其他 Oracle 客戶、Oracle 員工及業內專家深入探討嗎？
Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.
點擊這里訪問 My Oracle Support Community 數據庫性能優化頁，在這里您可以提出問題、獲取他人的幫助并分享您的經驗。
解決方案
對于數據庫整體的性能問題，AWR的報告是一個非常有用的診斷工具。
一般來說，當檢測到性能問題時，我們會收集覆蓋了發生問題的時間段的AWR報告-但是最好只收集覆蓋1個小時時間段的AWR報告-如果時間過長，那么AWR報告就不能很好的反映出問題所在。
還應該收集一份沒有性能問題的時間段的AWR報告，作為一個參照物來對比有問題的時間段的AWR報告。這兩個AWR報告的時間段應該是一致的，比如都是半個小時的，或者都是一個小時的。
關于如何收集AWR報告，請參照如下文檔：
Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
注：最好一開始我們從ADDM報告入手，因為對應時間段的ADDM報告往往已經指出了問題所在。
參見: Use of ADDM Reports alongside AWR
Interpretation
在處理性能問題時，我們最關注的是數據庫正在等待什么。
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了數據庫的sessions花費時間最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相關的信息。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event占總體call time的百分比來進行排序的。
根 據Top 5 Events部分的信息的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的持續時間和當時數據 庫中的并發用戶數進行評估。如：10分鐘內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個用戶引起的1000萬次的等待事件比 10,000個用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時間是在等待IO相關的事件。
事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）
其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是性能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對于這樣的SQL，過多的IO操作也是一個癥狀。關于CPU使用方面，我們會在之后討論。
在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。
過多的IO相關的等待一般會有兩個主要的原因：
數據庫做了太多的讀操作
每次的IO讀操作都很慢
Top 5 Events部分的顯示的信息會幫助我們檢查：
是否數據庫做了大量的讀操作：
上面的圖顯示了在這段時間里兩類讀操作都分別大于1000萬，這些操作是否過多取決于報告的時間是1小時或1分鐘。我們可以檢查AWR報告的elapsed time
如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL Statistics 部分的信息，因為讀操作都是由SQL語句發起的。
是否是每次的IO讀操作都很慢：
上面的圖顯示了在這段時間里兩類讀操作平均的等待時間是小于8ms的
至于8ms是快還是慢取決于底層的硬件設備；一般來講小于20ms的都可以認為是可以接受的。
我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上圖，我們關心Av Rd(ms)的指標。如果它高于20ms并且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。
注：對于一些比較空閑的tablespace/files,我們可能會得到一個比較大的Av Rd(ms)值；對于這樣的情況，我們應該忽略這樣的tablespace/files;因為這個很大的值可能是由于硬盤自旋(spin)引起的，沒有太大的參考意義。比如對
于一個有1000萬次讀操作而且很慢的系統，引起問題的基本不可能是一個只有10次read的tablespace/file
以下的文檔可以幫助我們進一步調查IO方面的問題：
Note:223117.1 Troubleshooting I/O-related waits
雖 然高"db file scattered read"和"db file sequential read"等待可以是I / O相關的問題，但是很多時候這些等待也可能是正常的；實際上，對一個已經性能很好的數據庫系統，這些等待事件往往在top 5等待事件里，因為這意味著您的數據庫沒有那些真正的“問題”。
訣竅是能夠評估引起這些等待的語句是否使用了最優的訪問路徑。如果"db file scattered read"比較高，那么相關的SQL語句可能使用了全表掃描而沒有使用索引（也許是沒有創建索引，也許是沒有合適的索引）；相應的，如果"db file sequential read"過多，則表明也許是這些SQL語句使用了selectivity不高的索引從而導致訪問了過多不必要的索引塊或者使用了錯誤的索引。這些等待可 能說明SQL語句的執行計劃不是最優的。
接下來就需要通過AWR來檢查這些top SQL是否可以進一步的調優，我們可以查看AWR報告中 SQL Statistics 的部分.
上面的例子顯示了20%的時間花在了等待或者使用CPU上，我們也需要檢查 SQL statistics 部分來進一步的分析。
需要注意，接下來的分析步驟取決于我們在TOP 5部分的發現。在上面的例子里，3個top wait event表明問題可能與SQL語句執行計劃不好有關，所以接下來我們要去分析"SQL Statistics"部分。
同樣的，因為我們并沒有看到latch相關的等待，latch在我們這個例子里并沒有引發嚴重的性能問題；那么我們接下來就完全不需要分析latch相關的信息。
一 般來講，如果數據庫性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比較明顯（不管它們之間的順序如何），我們總是需要檢查Top SQL (by logical and physical reads)部分；調用SQL Tuning Advisor或者手工調優這些SQL來確保它們是有效率的運行。
SQL Statistics
AWR包含了一些不同的SQL統計值：
sql stats
根據Top 5 部分的Top Wait Event不同，我們需要檢查不同的SQL statistic。
在我們這個例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU；我們最需要關心的是SQL ordered by CPU Time, Gets and Reads。
我們會從"SQL ordered by gets"入手，因為引起高buffer gets的SQL語句一般是需要調優的對象。
SQL ordered by Gets
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets: 4,745,943,815
-> Captured SQL account for 122.2% of Total
Gets CPU Elapsed
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id
-------------- ------------ ------------ ------ -------- --------- -------------
1,228,753,877 168 7,314,011.2 25.9 8022.46 8404.73 5t1y1nvmwp2
SELECT ADDRESSID",CURRENT$."ADDRESSTYPEID",CURRENT$URRENT$."ADDRESS3",
CURRENT$."CITY",CURRENT$."ZIP",CURRENT$."STATE",CURRENT$."PHONECOUNTRYCODE",
CURRENT$."PHONENUMBER",CURRENT$."PHONEEXTENSION",CURRENT$."FAXCOU
1,039,875,759 62,959,363 16.5 21.9 5320.27 5618.96 grr4mg7ms81
Module: DBMS_SCHEDULER
INSERT INTO "ADDRESS_RDONLY" ("ADDRESSID","ADDRESSTYPEID","CUSTOMERID","
ADDRESS1","ADDRESS2","ADDRESS3","CITY","ZIP","STATE","PHONECOUNTRYCODE","PHONENU
854,035,223 168 5,083,543.0 18.0 5713.50 7458.95 4at7cbx8hnz
SELECT "CUSTOMERID",CURRENT$."ISACTIVE",CURRENT$."FIRSTNAME",CURRENT$."LASTNAME",CU<
RRENT$."ORGANIZATION",CURRENT$."DATEREGISTERED",CURRENT$."CUSTOMERSTATUSID",CURR
ENT$."LASTMODIFIEDDATE",CURRENT$."SOURCE",CURRENT$."EMPLOYEEDEPT",CURRENT$.
對這些Top SQL,可以手工調優，也可以調用SQL Tuning Advisor。
參照以下文檔：
Document 271196.1 Automatic SQL Tuning - SQL Profiles.
Document 262687.1 How to use the Sql Tuning Advisor.
Document 276103.1 PERFORMANCE TUNING USING ADVISORS AND MANAGEABILITY FEATURES: AWR, ASH, and ADDM and Sql Tuning Advisor.
注: 使用SQL Tuning Advisor需要額外的Oracle Tuning Pack License:
http://docs.oracle.com/cd/E11882_01/license.112/e10594/options.htm#DBLIC170
分析：
-> Total Buffer Gets: 4,745,943,815
假設這是一個一個小時的AWR報告，4,745,943,815是一個很大的值；所以需要進一步分析這個SQL是否使用了最優的執行計劃
Individual Buffer Gets
上面的例子里單個的SQL的buffer get非常多，最少的那個都是8億5千萬。這三個SQL指向了兩個不同的引起過多buffers的原因：
單次執行buffer gets過多
SQL_ID為'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL語句總共被執行了168次，但是每次執行引起的buffer gets超過500萬。這兩個SQL應該是主要的需要調優的候選者。
執行次數過多
SQL_ID 'grr4mg7ms81' 每次執行只是引起16次buffer gets,減少這條SQL每次執行的buffer get可能并不能顯著減少總共的buffer gets。這條語句的問題是它執行的太頻繁了，6500萬次。
改變這條SQL的執行次數可能會更有意義。這個SQL看起來是在一個循環里面被調用，如果可以讓它一次處理的數據更多也許可以減少它執行的次數。
注意：對于某些非常繁忙的系統來講，以上的數字可能都是正常的。這時候我們需要把這些數字跟正常時段的數字作對比，如果沒有什么太大差別，那么這些SQL并不是引起問題的元兇（雖然通過調優這些SQL我們仍然可以受益）
Other SQL Statistic Sections
就像之前提到的那樣，AWR報告中有很多不同的部分用來分析各種不同的問題。如果特定的問題并沒有出現，那么分析AWR報告的這些部分并不能有很大的幫助。
下面提到了一些可能的問題：
Waits for 'Cursor: mutex/pin'
如 果發現了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 類的mutex等待，那么可能是由于parsing引起的問題。檢查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL，這些SQL可能引起這類的問題。
以下文檔可以幫助我們分析這類問題：
Document 1356828.1 FAQ: 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events
Note:1349387.1 Troubleshooting 'cursor: pin S wait on X' waits.
Load Profile
根據Top 5等待事件的不同，"Load Profile"可以提供一些有用的背景資料或潛在問題的細節信息。
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 4,585,414.80 3,165,883.14
Logical reads: 94,185.63 65,028.07
Block changes: 40,028.57 27,636.71
Physical reads: 2,206.12 1,523.16
Physical writes: 3,939.97 2,720.25
User calls: 50.08 34.58
Parses: 26.96 18.61
Hard parses: 1.49 1.03
Sorts: 18.36 12.68
Logons: 0.13 0.09
Executes: 4,925.89 3,400.96
Transactions: 1.45
% Blocks changed per Read: 42.50 Recursive Call %: 99.19
Rollback per transaction %: 59.69 Rows per Sort: 1922.64
在這個例子里，Top 5 Events部分顯示問題可能跟SQL的執行有關，那么我們接下來檢查load profile部分。
如果您檢查AWR report是為了一般性的性能調優，那么可以看到有比較多的redo activity和比較高的physical writes. Physical writes比physical read要高，并且有42%的塊被更改了.
此外，hard parse的次數要少于soft parse.
如果mutex等待事件比較嚴重，如"library cache: mutex X"，那么查看所有parse的比率會更有用。
當然，如果把Load Profile部分跟正常時候的AWR報告做比較會更有用，比如，比較redo size, users calls, 和 parsing這些性能指標。
Instance Efficiency
Instance Efficiency部分更適用于一般性的調優，而不是解決某個具體問題（除非等待事件直接指向這些指標）。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.91 Redo NoWait %: 100.00
Buffer Hit %: 98.14 In-memory Sort %: 99.98
Library Hit %: 99.91 Soft Parse %: 94.48
Execute to Parse %: 99.45 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 71.23 % Non-Parse CPU: 99.00
從我們的這個例子來看，最有用的信息是%Non-Parse CPU，它表明幾乎所有的CPU都消耗在了Execution而不是Parse上，所以調優SQL會對性能有改善。
94.48％ 的soft parse比率顯示hard parse的比例很小，這是可取的。Execute to Parse %很高，說明cursor被很好的重用了。我們總是期望這里的值都是接近100%,但是因為應用的不同，如果這個部分的參數的某些值很小，也是可以認為沒 有問題的；如在數據倉庫環境，hard parse因為使用了物化視圖或histogram而變得很高。所以，重要的是，我們需要把這部分信息和正常時候的AWR報告做比較來判斷是否有問題。
Latch Activity
在我們這個例子里，我們并沒有看到很高的latch相關的等待，所以這部分的信息可以忽略。
但是如果latch相關的等待很嚴重，我們需要查看Latch Sleep Breakdown 部分sleeps很高的latch
Latch Sleep Breakdown
* ordered by misses desc
Latch Name
----------------------------------------
Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3
-------------- ----------- ----------- ---------- -------- -------- --------
cache buffers chains
2,881,936,948 3,070,271 41,336 3,031,456 0 0 0
row cache objects
941,375,571 1,215,395 852 1,214,606 0 0 0
object queue header operation
763,607,977 949,376 30,484 919,782 0 0 0
cache buffers lru chain
376,874,990 705,162 3,192 702,090 0 0 0
這 里top latch是cache buffers chains. Cache Buffers Chains latches是用來保護buffer caches中的buffers。在我們讀取數據時，這個latch是正常需要獲得的。Sleep的數字上升代表session在讀取buffers時開 始等待這個latch。爭用通常來自于不良的SQL要讀取相同的buffers。
在我們這個例子里，雖然讀取buffer的操作發生了 28億次，但是只sleep了41,336次，可以認為是比較低的。Avg Slps/Miss（Sleeps/ Misses）也比較低。這表明當前Server有能力處理這樣多的數據，所以沒有發生Cache Buffers Chains latch的爭用。
關于其他的latch free等待，請參照以下文檔：
Note:413942.1 How to Identify Which Latch is Associated with a "latch free" wait
值得注意的wait events
CPU time events
CPU變為top wait event并不總是代表出現了問題。但是如果同時數據庫性能比較慢，那么就需要進一步分析了。首先，檢查AWR報告的“ SQL ordered by CPU Time ”部分，看是否某個特定的SQL使用了大量的CPU。
SQL ordered by CPU Time
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> % Total is the CPU Time divided into the Total CPU Time times 100
-> Total CPU Time (s): 56,207
-> Captured SQL account for 114.6% of Total
CPU Elapsed CPU per % Total
Time (s) Time (s) Executions Exec (s) % Total DB Time SQL Id
---------- ---------- ------------ ----------- ------- ------- -------------
20,349 24,884 168 121.12 36.2 9.1 7bbhgqykv3cm9
Module: DBMS_SCHEDULER
DECLARE job BINARY_INTEGER := :job; next_date TIMESTAMP WITH TIME ZONE := :myda
te; broken BOOLEAN := FALSE; job_name VARCHAR2(30) := :job_name; job_subname
VARCHAR2(30) := :job_subname; job_owner VARCHAR2(30) := :job_owner; job_start
TIMESTAMP WITH TIME ZONE := :job_start; job_scheduled_start TIMESTAMP WITH TIME
Analysis:
-> Total CPU Time (s): 56,207
它代表了15分鐘的CPU time。但是這個數字是否有問題取決于整個報告的時間。
Top SQL使用的CPU是 20,349秒（大概5分鐘）
整個CPU時間占DB Time的9.1%
執行了168次，這個執行次數跟之前提到的幾個SQL是一樣的，說明這些SQL可能都是被同一個JOB調用的。
其他潛在的CPU相關的問題：
檢查是否有其他等待事件與高CPU 事件同時出現
如cursor: pin S問題可能引起高CPU使用：
Note:6904068.8 Bug 6904068 - High CPU usage when there are "cursor: pin S" waits
數據庫以外的CPU使用率過高
如果一個數據庫以外的進程使用了過多CPU，那么數據庫進程能夠獲得的CPU就會減少，數據庫性能就會受到影響。在這種情況下，運行OSWather或者其他的OS工具去發現是哪個進程使用了過多CPU
Note:433472.1 OS Watcher For Windows (OSWFW) User Guide
診斷CPU使用率
下面的文檔進一步描述了如何進一步分析CPU問題:
Note:164768.1 Troubleshooting: High CPU Utilization
'Log file sync' waits
當 一個user session commit或rollback時，log writer進程會把redo從log buffer中寫入redo logfile文件。AWR報告會幫助我們來確定是否存在這方面的問題，并且確認是否是由物理IO引起。如果”log file sync”事件比較嚴重，下面的文檔詳細描述了如何來處理:
Document 1376916.1 Troubleshooting: "Log File Sync" Waits
Note:34592.1WAITEVENT: "log file sync"
Buffer busy waits
當 一個session從buffer cache讀取一個buffer時，如果這個buffer處于busy的狀態（由于其它session正在向其中讀取數據，或者是由于這個buffer被 其它的session以不兼容模式持有），那么這個session就會等待這個事件。參照下面文檔來找出哪個block處于busy狀態和為什么：
Document 155971.1 Resolving Intense and "Random" Buffer Busy Wait Performance Problems:Note:34405.1 WAITEVENT: "buffer busy waits"
診斷其他問題
關于其他性能問題，請參照文檔:
Document 1377446.1 Troubleshooting Performance Issues
使用ADDM的報告
當分析性能問題時，除了AWR報告，我們還可以同時參照ADDM報告，對于潛在的性能問題，它同時提供了具體的解決方案建議。下面是從如下文檔拿到的一個ADDM報告示例：
Note:250655.1How to use the Automatic Database Diagnostic Monitor:
Example Output:
DETAILED ADDM REPORT FOR TASK 'SCOTT_ADDM' WITH ID 5
----------------------------------------------------
Analysis Period: 17-NOV-2003 from 09:50:21 to 10:35:47
Database ID/Instance: 494687018/1
Snapshot Range: from 1 to 3
Database Time: 4215 seconds
Average Database Load: 1.5 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING 1: 65% impact (2734 seconds)
------------------------------------
PL/SQL execution consumed significant database time.
RECOMMENDATION 1: SQL Tuning, 65% benefit (2734 seconds)
ACTION: Tune the PL/SQL block with SQL_ID fjxa1vp3yhtmr. Refer to
the "Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL
User's Guide and Reference"
RELEVANT OBJECT: SQL statement with SQL_ID fjxa1vp3yhtmr
BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
FINDING 2: 35% impact (1456 seconds)
------------------------------------
SQL statements consuming significant database time were found.
RECOMMENDATION 1: SQL Tuning, 35% benefit (1456 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
gt9ahqgd5fmm2.
RELEVANT OBJECT: SQL statement with SQL_ID gt9ahqgd5fmm2 and
PLAN_HASH 547793521
UPDATE bigemp SET empno = ROWNUM
FINDING 3: 20% impact (836 seconds)
-----------------------------------
The throughput of the I/O subsystem was significantly lower than expected.
RECOMMENDATION 1: Host Configuration, 20% benefit (836 seconds)
ACTION: Consider increasing the throughput of the I/O subsystem.
Oracle's recommended solution is to stripe all data file using
the SAME methodology. You might also need to increase the
number of disks for better performance.
RECOMMENDATION 2: Host Configuration, 14% benefit (584 seconds)
ACTION: The performance of file
D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF was significantly worse
than other files. If striping all files using the SAME
methodology is not possible, consider striping this file over
multiple disks.
RELEVANT OBJECT: database file
"D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF"
SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time.
(34% impact [1450 seconds])
FINDING 4: 11% impact (447 seconds)
-----------------------------------
Undo I/O was a significant portion (33%) of the total database I/O.
NO RECOMMENDATIONS AVAILABLE
SYMPTOMS THAT LED TO THE FINDING:
The throughput of the I/O subsystem was significantly lower than
expected. (20% impact [836 seconds])
Wait class "User I/O" was consuming significant database time.
(34% impact [1450 seconds])
FINDING 5: 9.9% impact (416 seconds)
------------------------------------
Buffer cache writes due to small log files were consuming significant
database time.
RECOMMENDATION 1: DB Configuration, 9.9% benefit (416 seconds)
ACTION: Increase the size of the log files to 796 M to hold at
least 20 minutes of redo information.
ADDM報告相比AWR報告來說，它提供了可讀性更好的建議；當然應該同時參照ADDM報告和AWR報告來得到更準確地診斷。
其他的AWR參考文章
當閱讀AWR報告的其他部分時，可以參照下面的一些文檔:
Document 786554.1 How to Read PGA Memory Advisory Section in AWR and Statspack Reports
Document 754639.1 How to Read Buffer Cache Advisory Section in AWR and Statspack Reports
Document 1301503.1 Troubleshooting: AWR Snapshot Collection issues
Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
Statspack
AWR報告取代了舊有的staspack及bstat/estat報告，下面的這些文檔概述了如何閱讀statspack報告:
http://www.oracle.com/technetwork/database/focus-areas/performance/statspack-opm4-134117.pdf
Additional information can be found in the following articles:
Document 94224.1 FAQ- Statspack Complete Reference
Document 394937.1 Statistics Package (STATSPACK) Guide
Document 149113.1 Installing and Configuring StatsPack Package
Document 149121.1 Gathering a StatsPack snapshot
Document 228913.1 Systemwide Tuning using STATSPACK Reports
關于如何進行Oracle AWR報告指標的解析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
