您好,登錄后才能下訂單哦!
AWR是DBA了解其運行狀態的重要工具之一,根據AWR報告可以對oracle數據庫性能整體了解并針對性優化,此文章主要是介紹AWR相關部分的內容。
DB Name DB Id Instance Inst Num Startup Time Release RAC
------------ ----------- ------------ -------- --------------- ----------- ---
1 16-Jan-17 09:27 11.2.0.4.0 NO
Host Name Platform CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
Linux x86 64-bit 8 8 2 7.81
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 10848 14-Mar-17 09:00:51 66 1.4
End Snap: 10849 14-Mar-17 10:00:55 66 1.5
Elapsed: 60.07 (mins)
DB Time: 0.93 (mins)
Sessions
采集性能信息時,oracle 實例鏈接的會話數,有助于判斷DB的類
Cursors/Session
單個會話平均打開的游標數
Elapsed
DB實際使用時間
DB Time
數據庫操作花費的時間,包括CPU和Wait Event time,DB Time越高數據庫,數據庫負載越高。
通過DB Time/Elapsed 比值判斷數據庫的繁忙程度,比值越高,數據庫越繁忙。
DB Time = CPU time + Wait time(不包括后臺進程及空閑等待)
對應V$SESSION 中的elapsed_time
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~~~~ --------------- --------------- --------- ---------
DB Time(s): 0.0 0.0 0.00 0.00
DB CPU(s): 0.0 0.0 0.00 0.00
Redo size (bytes): 1,343.6 3,388.8
Logical read (blocks): 394.1 993.9
Block changes: 5.4 13.6
Physical read (blocks): 0.4 1.1
Physical write (blocks): 0.6 1.4
Read IO requests: 0.4 1.1
Write IO requests: 0.4 1.1
Read IO (MB): 0.0 0.0
Write IO (MB): 0.0 0.0
User calls: 64.8 163.4
Parses (SQL): 21.0 52.9
Hard parses (SQL): 0.0 0.1
SQL Work Area (MB): 0.2 0.5
Logons: 0.1 0.2
Executes (SQL): 22.2 55.9
Rollbacks: 0.0 0.0
Transactions: 0.4
DB Time DB CPU
DB Time 3.3s DB CPU 1.4s Wait Event 3.3-1.4=1.9s, DB CPU占DB Time的比重為1.4/3.3=42%
可以看出此DB系統的非CPU等待占比比較大
DB CPU占比42.55%
db file sequential read/db file scattered read//libary cache:mutex X/latch:shared pool為CPU等待的TOP 4 wait event
(DB Time > DB CPU + FG Wait event DB Time 會計算在CPU繁忙時的等待CPU的隊列時間)
繼續分析
redo size 日志的產生量
Logical reads 邏輯讀,單位是塊
良好的OLTP logical reads/ Executes 在50左右
Block Changes
每秒、事務改變的數據塊
Physical reads
物理讀
User Calls
每秒(每個事務)用戶調用次數。User calls/Executes基本上代表了每個語句的請求次數,Executes越接近User calls越好
Pasre
解析次數,不包括快速軟解析(MOS上說執行3次的SQL語句會把游標緩存到PGA,這個游標一直開著,當再有相同的SQL執行時,則跳過解析的所有過程直接去取執行計劃)
軟解析過多說明應用程序的效率不高
Hard Parse
硬解析的次數,此指標過高說明綁定變量沒有做好
Sorts
排序次數
W/A MB processed
單位MB W/A workarea workarea中處理的數據數量 結合 In-memory Sort%, sorts (disk) PGA Aggr一起看
Logon
登入數據庫的次數
Executes
執行次數
Rollbacks
回滾次數
Transactions
事務數
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 100.00
Library Hit %: 99.30 Soft Parse %: 99.79
Execute to Parse %: 5.27 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 78.31 % Non-Parse CPU: 94.25
此模塊記錄oracle instance memory的使用信息,目標為100%,針對OLTP系統,此模塊信息比較重要,對于OLAP系統,意義不大。
Buffer Nowait%
非等待方式獲取數據塊的百分比
這個值偏小,說明發生SQL訪問數據塊時數據塊正在被別的會話讀入內存,需要等待這個操作完成。發生這樣的事情通常就是某些數據塊變成了熱塊。
Buffer Nowait<95%說明,有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)。
Redo Nowait
非等待獲取redo數據
Buffer Hit%
數據緩存命中率
In-memory Sort%
數據排除操作在內存中的百分比
Library Hit%
共享池中SQL解析的命中率
(相關參數SHARED_POOL_SIZE\BINGD VALUE\CURSOR_SHARING)
Soft Parse %
軟解析占解析的比率 value偏低表示DB中多數SQL沒有被重用 <95%考慮綁定變量
Latch Hit%
Latch的命中率
其值低是因為shared_pool_size過大或沒有使用綁定變量導致硬解析過多。要確保>99%,否則存在嚴重的性能問題,比如綁定等會影響該參數。
Parse CPU to Parse Elapsd%
解析總時間中消耗CPU的時間百分比。即:100*(parse time cpu / parse time elapsed)
解析實際運行事件/(解析實際運行時間+解析中等待資源時間),越高越好。
%Non-Parse CPU
CPU非分析時間在整個CPU時間的百分比。
Shared Pool Statistics Begin End
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------ ------
Memory Usage %: 87.44 87.82
% SQL with executions>1: 98.06 97.25
% Memory for SQL w/exec>1: 92.56 92.46
Memory Usage %
共享池內存使用率。
應該穩定在70%-90%間,太小浪費內存,太大則內存不足。
% SQL with executions>1
執行次數大于1的SQL比率。
若太小可能是沒有使用綁定變量。
% Memory for SQL w/exec>1
執行次數大于1的SQL消耗內存/所有SQL消耗的內存(即memory for sql with execution > 1)。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。