Oracle中的AWR，全稱為Automatic Workload Repository，自動負載信息庫。?

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)。?

轉載于:https://blog.51cto.com/kevinora/1906368

總結

以上是生活随笔為你收集整理的浅谈ORACLE AWR single instance 一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。