Oracle AWR內容有哪些

本篇內容主要講解“Oracle AWR內容有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Oracle AWR內容有哪些”吧!

1.AWR報告頭信息

? 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：這兩部分是數據庫資源負載的一個明細列表，分割成每秒鐘的資源負載和每個事務的資源負載情況
? 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%）? 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

? 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

 按所占等待時間的比例倒序列示。當我們調優時，總希望觀察到最顯著的效果，因此應當從這里入手確定我們下一步做什么。
通常，在沒有問題的數據庫中，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中沒有收集該信息，所以使用一個樣例）

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：

獲得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值很高，你應當提高應用程序中游標的共享程度或者增加共享池的尺寸。

到此，相信大家對“Oracle AWR內容有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！