Oracle AWR內容詳解
1.AWR 報告頭信息
| DB Name | DB Id | Unique Name | Role | Edition | Release | RAC | CDB |
|---|---|---|---|---|---|---|---|
| KTDB | 1107793954 | ktdb | PRIMARY | EE | 19.0.0.0.0 | YES | NO |
| Instance | Inst Num | Startup Time |
|---|---|---|
| ktdb2 | 2 | 02-3月 -20 19:35 |
| Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
|---|---|---|---|---|---|
| hn-ekdb2 | Linux x86 64-bit | 80 | 80 | 4 | 753.98 |
| Snap Id | Snap Time | Sessions | Cursors/Session | Instances | |
|---|---|---|---|---|---|
| Begin Snap: | 5339 | 14-5月 -20 08:00:03 | 159 | .5 | 4 |
| End Snap: | 5342 | 14-5月 -20 11:00:14 | 168 | .6 | 4 |
| Elapsed: | 180.17 (mins) | ||||
| DB Time: | 1.23 (mins) |
• DB Name ：數據庫名字 DBid: 數據庫id
• Elapsed:采樣時間段
• DB Time:用戶操作花費的時間,不包括Oracle后台進程消耗的時間
• DB Time遠小於Elapsed Time說明數據庫比較空閑
在180 分鍾里（其間收集了3 次快照數據），數據庫耗時1.23 分鍾.
可是對於批量系統，數據庫的工作負載總是集中在一段時間內。如果快照周期不在這一段時間內，或者快照周期跨度太長而包含了大量的數據庫空閑時間，所得出的分析結果是沒有意義的。 這也說明選擇分析時間段很關鍵，要選擇能夠代表性能問題的時間段。
2. Load Profile
Load Profile
| Per Second | Per Transaction | Per Exec | Per Call | |
|---|---|---|---|---|
| DB Time(s): | 0.0 | 1.2 | 0.00 | 0.01 |
| DB CPU(s): | 0.0 | 0.6 | 0.00 | 0.01 |
| Background CPU(s): | 0.1 | 21.8 | 0.03 | 0.00 |
| Redo size (bytes): | 1,495.0 | 256,536.7 | ||
| Logical read (blocks): | 384.5 | 65,979.0 | ||
| Block changes: | 29.3 | 5,026.5 | ||
| Physical read (blocks): | 18.0 | 3,095.9 | ||
| Physical write (blocks): | 0.6 | 93.7 | ||
| Read IO requests: | 3.8 | 656.2 | ||
| Write IO requests: | 0.3 | 53.9 | ||
| Read IO (MB): | 0.1 | 24.2 | ||
| Write IO (MB): | 0.0 | 0.7 | ||
| IM scan rows: | 0.0 | 0.0 | ||
| Session Logical Read IM: | 0.0 | 0.0 | ||
| Global Cache blocks received: | 3.9 | 667.2 | ||
| Global Cache blocks served: | 191.8 | 32,906.7 | ||
| User calls: | 0.6 | 98.2 | ||
| Parses (SQL): | 3.5 | 598.3 | ||
| Hard parses (SQL): | 0.0 | 1.4 | ||
| SQL Work Area (MB): | 0.0 | 3.6 | ||
| Logons: | 0.1 | 18.7 | ||
| User logons: | 0.0 | 0.4 | ||
| Executes (SQL): | 3.7 | 639.6 | ||
| Rollbacks: | 0.0 | 0.0 | ||
| Transactions: | 0.0 |
• Per Second 和Per Transaction：這兩部分是數據庫資源負載的一個明細列表，分割成每秒鍾的資源負載和每個事務的資源負載情況
• Redo size：每秒/每個事務 產生的redo量 (單位字節) 標志數據庫的繁忙程度
• logical reads：每秒/每個事務 產生的邏輯讀的塊數
• block changes：每秒/每個事務 改變的數據塊數
• physical reads：每秒/每個事務 產生的物理讀
• physical writes：每秒/每個事務 產生的物理寫的塊數
• user calls：每秒/每個事務 用戶的調用次數
• parses：每秒/每個事務 分析次數
• hard parses: 每秒/每個事務 硬分析次數
• SQL Work Area：每秒/每個事物 排序次數
• logons: 每秒/每個事務 登錄數據庫次數
• executes: 每秒/每個事務 SQL的執行次數
• rollbacks: 每秒/每個事物回滾次數
• transactions: 每秒的事務數
需要注意：
1）logical reads和physical reads，同時也可以得到平均每個邏輯讀導致多少物理讀，即18/384 平均每個事務產生了65979個邏輯讀，這個數字應該越小越好。
2）parses 和hard parses：從表中可以看到cpu平均每秒進行了3.5個解析（超過100個應該注意），每秒進行0（超過10個應該注意）次硬解析，即cpu每秒要處理0個全新的sql，應該說很閑。
3.instance efficiency Percentages：
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 99.99 | Redo NoWait %: | 100.00 |
| Buffer Hit %: | 95.96 | In-memory Sort %: | 100.00 |
| Library Hit %: | 99.57 | Soft Parse %: | 99.76 |
| Execute to Parse %: | 6.46 | Latch Hit %: | 99.95 |
| Parse CPU to Parse Elapsd %: | 25.76 | % Non-Parse CPU: | 99.74 |
| Flash Cache Hit %: | 0.00 |
• Buffer Nowait%：表示在內存獲得數據的未等待比例
（不應低於99%）
• Buffer Hit%：表示進程從內存中找到數據塊的比率，內存數據塊命中率。
（不應低於99%）
• Library Hit%：表示共享池中SQL解析的命中率。
(不應低於95%） 如果過小，說明該數據庫中可能存在library cache的爭用。
• Execute to Parse：是語句執行與 解析 的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。本數據庫為6.46%，說明有93.54%的sql為新sql。
• Parse CPU to Parse Elapsd：解析總時間中消耗總CPU的時間百分比
• Redo NoWait：表示在LOG緩沖區獲得BUFFER的未等待比例。
• In-memory sort%：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。 （考慮調大PGA）
• Soft Parse%：軟解析的百分比（softs/softs+hards），太低 說明SQL重用率不好，則 需要調整應用使用綁定變量。 （不應低於百分之95）
• Latch Hit：Latch是一種保護內存結構的鎖，可以認為是SERVER進程獲取訪問內存數據結構的許可。 （如果此數值低於95%說明數據庫存在嚴重問題）
• Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。
4.shared pool statistics：
Shared Pool Statistics
| Begin | End | |
|---|---|---|
| Memory Usage %: | 85.83 | 85.92 |
| % SQL with executions>1: | 91.54 | 92.23 |
| % Memory for SQL w/exec>1: | 85.45 | 86.42 |
• Memory Usage %：對於一個已經運行一段時間的數據庫來說，共享池內存使用率， 被使用的部分占 shared pool 總尺寸的百分比。這個值應保持適中， ( 如 85% ） , 如果太高，則會引起 shared pool 中的對象被刷出內存，從而導致 sql 語句的硬解析增加，太低則浪費內存；
• SQL with executions>1：執行次數大於1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。
• Memory for SQL w/exec>1：執行次數大於1的SQL消耗內存的占比。
5.event wait
Top 10 Foreground Events by Total Wait Time
| Event | Waits | Total Wait Time (sec) | Avg Wait | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU | 37.8 | 51.4 | |||
| gc cr multi block mixed | 2,606 | 27.5 | 10.55ms | 37.4 | Cluster |
| db file scattered read | 2,217 | 2.8 | 1.27ms | 3.8 | User I/O |
| gc cr block 3-way | 2,674 | 1.3 | 493.28us | 1.8 | Cluster |
| gc cr multi block grant | 2,600 | 1.2 | 461.59us | 1.6 | Cluster |
| db file parallel read | 803 | 1 | 1.25ms | 1.4 | User I/O |
| Sync ASM rebalance | 672 | 1 | 1.47ms | 1.3 | Other |
| IPC send completion sync | 2,206 | .8 | 381.13us | 1.1 | Other |
| enq: PS - contention | 1,173 | .5 | 463.95us | .7 | Other |
| log file sync | 23 | .5 | 19.77ms | .6 | Commit |
按所占等待時間的比例倒序列示。當我們調優時，總希望觀察到最顯著的效果，因此應當從這里入手確定我們下一步做什么。
通常，在沒有問題的數據庫中，CPU time總是列在第一個。
6. SQL 資源消耗定位：
SQL ordered by Elapsed Time：
記錄了執行總和時間的TOP SQL(請注意是監控范圍內該SQL的執行時間總和，而不是單次SQL執行時間） 。
• Elapsed Time(S): SQL語句執行用總時長，此排序就是按照這個字段進行的。注意該時間不是單個SQL跑的時間，而是監控范圍內SQL執行次數的總和時間。單位時間為秒
Elapsed Time = CPU Time + Wait Time
• CPU Time(s): 為SQL語句執行時CPU占用時間總時長，此時間會小於等於Elapsed Time時間。單位時間為秒。
• Executions: SQL語句在監控范圍內的執行次數總計。
• Elap per Exec(s): 執行一次SQL的平均時間。單位時間為秒。
• % Total DB Time: 為SQL的Elapsed Time時間占數據庫總時間的百分比。
• SQL ID: SQL語句的ID編號，點擊之后就能導航到下邊的SQL詳細列表中，點擊IE的返回可以回到當前SQL ID的地方。
• SQL Module: 顯示該SQL是用什么方式連接到數據庫執行的，如果是用SQL*Plus或者PL/SQL鏈接上來的那基本上都是有人在調試程序。一般用前台應用鏈接過來執行的sql該位置為空。
• SQL Text: 簡單的sql提示，詳細的需要點擊SQL ID。
SQL ordered by CPU Time:
記錄了執行占CPU時間總和時間最長的TOP SQL(請注意是監控范圍內該SQL的執行占CPU時間總和，而不是單次SQL執行時間)。
· %Total - CPU Time as a percentage of Total DB CPU
· %CPU - CPU Time as a percentage of Elapsed Time
· %IO - User I/O Time as a percentage of Elapsed Time
SQL ordered by Gets:
記錄了執行占總buffer gets(邏輯IO)的TOP SQL(請注意是監控范圍內該SQL的執行占Gets總和，而不是單次SQL執行所占的Gets).
· %Total - Buffer Gets as a percentage of Total Buffer Gets
SQL ordered by Reads:
記錄了執行占總磁盤物理讀(物理IO)的TOP SQL(請注意是監控范圍內該SQL的執行占磁盤物理讀總和，而不是單次SQL執行所占的磁盤物理讀)。
· %Total - Physical Reads as a percentage of Total Disk Reads
SQL ordered by Executions:
記錄了按照SQL的執行次數排序的TOP SQL。該排序可以看出監控范圍內的SQL執行次數。
SQL ordered by Parse Calls:
記錄了SQL的軟解析次數的TOP SQL。
SQL ordered by Sharable Memory:
記錄了SQL占用library cache的大小的TOP SQL。
Sharable Mem (b)：占用library cache的大小。單位是bytes。
主要針對ordered by Elapsed time,orderedby CPU time,orderedby gets,orderedby read排名前三SQL進行觀察並調優.
7.IO Stats -->Tablespace IO Stats
（在樣例 AWR 中沒有收集該信息，所以使用一個樣例 ）
| Tablespace |
Reads |
Av Reads/s |
Av Rd(ms) |
Av Blks/Rd |
Writes |
Av Writes/s |
Buffer Waits |
Av Buf Wt(ms) |
| SYSAUX |
9,553 |
0 |
4.07 |
1.65 |
19,729 |
0 |
0 |
0.00 |
| UNDOTBS |
7,879 |
0 |
3.21 |
1.00 |
8,252 |
0 |
20 |
5.50 |
| SYSTEM |
2,496 |
0 |
4.74 |
1.62 |
4,469 |
0 |
0 |
0.00 |
| USERS |
364 |
0 |
3.08 |
1.57 |
4 |
0 |
0 |
0.00 |
| TEMP |
34 |
0 |
3.24 |
12.35 |
25 |
0 |
0 |
0.00 |
| TEST2 |
4 |
0 |
47.50 |
1.00 |
4 |
0 |
0 |
0.00 |
1 ）可以找到具有頻繁讀寫活動的表空間或數據文件， 如果臨時表空間的寫入數量最高，說明排序太多太大；
2 ）從 AVG BLKS/RD 列可以看出，哪些表空間上經歷了最多的全表掃描，如果值大於 1 ，則應該將該值與初始化參數db_file_multiblock_read_count 的值進行比較，如果他們越接近，說明在該表空間上進行的大部分是全表掃描；
3 ）檢查 AV RD(MS), 該列表明 I/O 讀的時間，值應該小於 20ms ，如果過大應該檢查是否將讀寫很頻繁的文件放在了同一個磁盤上。
注意：
對於帶緩存的磁盤I/O時間通常少於1ms.
在init.ora文件中可以設置參數DB_FILE_MULTIBLOCK_READ_COUNT有助於磁盤讀取時間，該參數控制在全表掃描時一次I/O中讀入的數據塊數量，這將減少掃描一張表所需的I/O數量，從而提高全表掃描的性能。但是，設置該參數的結果是優化器可能會執行更多的 全表掃描，所以需要將OPTIMIZER_INDEX_COST_ADJ設為一個值，例如10，來消除這個問題，並且驅動索引的使用。
8.Segment Statistics
1） Segments by Logical Reads或Segments by Physical Reads
可以找到邏輯讀或物理讀比較大的對象，並查找原因，是否可以通過創建新索引、或采用分區表等來降低對象的邏輯讀以及物理讀；
2） Segments by Row Lock Waits
通過這個報表可以找到獲得行級鎖最嚴重的對象，需要跟開發人員探討解決方法；
3） Segments by ITL Waits
這個報表可以標明獲得ITL等待最嚴重的對象，如果發現了ITL等待很嚴重的對象，則應該將對象的initrans參數設置為並發操作該對象的進程個數；
4） Segments by Buffer Busy Waits：
| Owner |
Tablespace Name |
Object Name |
Subobject Name |
Obj. Type |
Obj# |
Dataobj# |
Buffer Busy Waits |
% of Capture |
| SYS |
SYSAUX |
SYS_LOB0000007450C00009$$ |
SYS_LOB_P4025 |
LOB PARTITION |
99696 |
99696 |
2 |
66.67 |
| SYS |
SYSTEM |
SEG$ |
TABLE |
14 |
8 |
1 |
33.33 |
獲得buffer busy waits最嚴重的對象。Buffer busy waits產生原因就是數據分布問題。解決的關鍵是優化那些掃描了過多數據塊的sql語句，減少他們要掃描的數據塊。如果已經優化了sql語句，則可以考慮增大pctfree的值，從而減少一個數據塊中能夠包含的數據行數，從而將對象的數據行分部到更多的數據塊里去，或者建立hash分區表，使數據重新分布。
9.實例活動統計數據
比較在內存中和磁盤中的排序量，如果磁盤排序太高就需要增加PGA_AGGREGATE_TARGET(或者舊版本中增大SORT_AREA_SIZE)
如果磁盤的讀操作較高，表明可能執行了全表掃描，如果目前存在大量的較大的對較大表的全表掃描，就應當評估最常用的查詢,並通過增加索引來提高效率。大量的非一致性讀操作意味着使用了過多的索引或者使用了非選擇性索引。如果臟讀緩沖區數量高於所請求的空閑緩沖區的數量（超過5%），那么說明DB_CACHE_SIZE太小，或者沒有建立足夠多的檢查點。如果葉節點的分裂數量很高可以考慮重建已增長或已經碎化的索引。
consistent gets:沒有使用select for update子句的查詢在緩沖中訪問的數據塊數量，這個數量加上DB BLOCK GETS統計信息的值就是邏輯讀操作總數
DB BLOCK GETS:使用了INSERT UPDATE DELETE OR SELECT FOR UPDATE語句在緩存中訪問的數據塊數量。
PHYSICAL READS:沒有從緩存中度取得數據量。可以從磁盤，操作系統緩存或者磁盤緩存中讀取，以滿足SELECT,SELECT FOR UPDATE,INSERT,UPDATE,DELETE語句
LOGICAL READS=CONSISTENT GETS+DB BLOCK GETS.
緩存命中率HIT RATIO=(LOGICAL READS- PHYSICAL READS)/LOGICAL READS *100%
=(CONSISTENT GETS+DB BLOCK GETS- PHYSICAL READS)/(CONSISTENT GETS+DB BLOCK GETS) *100%
緩存命中率應該高於 95%，否則需要增加DB_CACHE_SIZE。
DIRTY BUFFERS INSPECTED:從LRU列表中清除掉的臟讀（經過修改的）數據緩沖區的數量，如果此值超過0，可以考慮增加DB_WR進程。
FREE BUFFER INSPECTED:由於是臟讀數據、被固定或者正忙等原因兒跳過的緩沖區數量。如果數量很大的話就說明緩沖區緩存太小了。
PARSE COUNT:一條SQL語句被解析的次數。
RECURSIVE CALLS:數據庫中遞歸調用的數量。如果某個進程中的遞歸調用數量大於4，就應當檢查數據字典緩存的命中率，以及是否有表或者索引的范圍過大。除非使用了大量PL/SQL，否則在用戶調用中，遞歸調用所占的比例應該低於10%。
REDO SIZE:寫入日志中，以字節為單位的重做信息的數量。該信息將有助於確定重做日志的大小。
SORTS(DISK):磁盤排序的數量。磁盤排序除以內存排序數量不應該高於5%.否則需要調整SORT_AREA_SIZE,PGA_AGGREGATE_TARGET的大小
注意：SORT_AREA_SIZE分配的內存是面向每個用戶的，PGA_AGGREGATE_TARGET分配的內存是面向所有會話的。
SORTS(MEMORY):在內存中排序的數量。
SORTS(ROWS):參加排序的數據行的數量。
TABLE FETCH BY ROWID:通過訪問ROWID訪問的數據行的數量。該值很高通常意味着就獲取數據的操作而言，應用程序調整的不錯。
TABLE FETCH CONTINUED ROW:獲取的數據行的數量，可以是鏈化數據行，也可以是遷移的數據行。
10. 數據字典和庫緩存的統計數據 :
如果報表中PCT MISS值很高，你應當提高應用程序中游標的共享程度或者增加共享池的尺寸。
--原文地址：http://blog.itpub.net/69975956/viewspace-2695270/
| DB Name | DB Id | Unique Name | Role | Edition | Release | RAC | CDB |
|---|---|---|---|---|---|---|---|
| KTDB | 1107793954 | ktdb | PRIMARY | EE | 19.0.0.0.0 | YES | NO |
| Instance | Inst Num | Startup Time |
|---|---|---|
| ktdb2 | 2 | 02-3月 -20 19:35 |
| Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
|---|---|---|---|---|---|
| hn-ekdb2 | Linux x86 64-bit | 80 | 80 | 4 | 753.98 |
| Snap Id | Snap Time | Sessions | Cursors/Session | Instances | |
|---|---|---|---|---|---|
| Begin Snap: | 5339 | 14-5月 -20 08:00:03 | 159 | .5 | 4 |
| End Snap: | 5342 | 14-5月 -20 11:00:14 | 168 | .6 | 4 |
| Elapsed: | 180.17 (mins) | ||||
| DB Time: | 1.23 (mins) |