【DB筆試面試822】在Oracle中，AWR報告中主要關注哪些方面內容？

♣          題目         部分

【DB筆試面試822】在Oracle中，AWR報告中主要關注哪些方面內容？

     




♣          答案部分          

AWR報告中經常須要關注以下的內容：

（一）DB Time/Elapsed

該部分位於AWR報告的頭部，以下圖所示，須要特別關注DB Time和Elapsed的比值：

Elapsed：60.03(mins)代表採樣時間大約是60分鐘，任何數據都要經過這個時間來衡量，離開了這個採樣時間，任何數據都毫無意義，Elapsed爲該AWR性能報告的天然時間跨度，所謂天然時間的跨度，例如前一個快照是4點生成的，後一個快照是6點生成的，若是使用「@?/rdbms/admin/awrrpt」腳本中指定這2個快照的話，那麼其Elapsed=(6-4)=2個小時。一個AWR報告至少須要2個AWR快照才能生成（注意在這2個快照之間實例不能重啓過，不然指定這2個快照生成AWR報告會報錯）。AWR性能報告中的指標每每是後一個快照和前一個快照的指標的delta值，這是由於累計值並不能反映某段時間內的系統負載狀況。若是爲了診斷特定時段性能問題，那麼採用時間不宜過長。若是是看全天負載，那麼能夠長一些。最多見是60分鐘或120分鐘。

DB Time：427.44(mins)代表用戶操做花費的時間，包括CPU時間和活動的非後臺進程的等待時間，也許有人會以爲奇怪，爲何在採樣的60分鐘過程當中，用戶操做時間居然有427分鐘呢？遠遠超過了採樣時間，緣由是AWR報告是一個數據的集合，例如在一分鐘以內，一個用戶等待了30秒，那麼10個用戶就等待了300秒。對於CPU的話，一個CPU處理了30秒，16個CPU就是480秒。這些時間都是以累積的方式記錄在AWR報告中的。DB Time不包括Oracle後臺進程消耗的時間。通常來講，若是DB Time除以CPU個數大於Elapsed時間，那麼說明數據庫比較繁忙。

（二）Load Profile

該部分位於AWR報告的總覽部分（Report Summary），AWR報告總覽部分包括了五個部分：緩存尺寸（Cache Sizes）、負載性能（Load Profile）、數據庫效率（Instance Efficiency Percentages）、共享池統計（Shared Pool Statistics）、TOP5事件（Top 5 Timed Events）。這五個部分是整個AWR報告的核心部分，記錄了數據庫系統的關鍵性能參數和情況。其中，Load Profile表明負載性能，即系統負載信息，從每秒鐘和每一個事務兩個維度統計的，單純的數字也無太大意義，須要與Baseline（基線）作比較纔有意義。

下表是Load Profile部分的內容：

	Per Second			Per Transaction
Redo size:	918,805.72			775,912.72
Logical reads:	3,521.77			2,974.06
Block changes:	1,817.95			1,535.22
Physical reads:	68.26			57.64
Physical writes:	362.59			306.20
User calls:	326.69			275.88
Parses:	38.66			32.65
Hard parses:	0.03			0.03
Sorts:	0.61			0.51
Logons:	0.01			0.01
Executes:	354.34			299.23
Transactions:	1.18
% Blocks changed per Read:		51.62	Recursive Call %:		51.72
Rollback per transaction %:		85.49	Rows per Sort:		16.18

對Load Profile中的每一個指標的解析以下所示：

v Redo size：每秒/每事務產生的日誌大小（單位是字節），可標誌數據變動頻率，數據庫任務的繁重與否。

v Logical reads：平均每秒/每事務產生的邏輯讀的塊數（單位是Block）。Logical Reads= Consistent Gets + DB Block Gets。

v Block changes：每秒/每事務修改的塊數，即數據庫事務改變數據塊的數量。

v Physical reads：每秒/每事務物理讀（磁盤讀）的塊數（單位是Block）。

v Physical writes：每秒/每事務物理寫的塊數。

v User calls：每秒/每事務用戶調用次數。

v Parses：SQL每秒/每事務解析的次數，包括Fast Parse、Soft Parse和Hard Parse三種解析的綜合。

v Hard parses：每秒/每事務硬解析的次數，硬解析太多，說明SQL重用率不高。每秒產生的硬解析次數超過100次，就可能說明綁定變量使用地很差，也多是共享池設置不合理。

v Sorts：每秒/每事務的排序次數，對於Sorts大於每秒100，代表排序過多，須要減小SQL代碼中排序操做，或調整排序空間。

v Logons：每秒/每事務登陸的次數，大於每秒1~2個，代表可能有爭用問題。

v Executes：每秒/每事務SQL執行次數，反應負載大小。

v Transactions：每秒事務數，反映數據庫任務繁重與否。

v Blocks changed per Read：表示邏輯讀用於修改數據塊的比例，在每一次邏輯讀中更改的塊的百分比。

v Recursive Call：遞歸調用佔全部操做的比率。

v Rollback per transaction：每個事務的回滾率。用來觀察回滾率是否是很高，由於回滾很佔用資源，若是回滾率太高，那麼可能說明數據庫有太多的無效操做，過多的回滾可能還會帶來Undo Block的競爭。

v Rows per Sort：每次排序的行數。

（三）Instance Efficiency Percentages (Target 100%)

該部分包含了Oracle關鍵指標的內存命中率及其它數據庫實例操做的效率。其中，Buffer Hit Ratio也稱Cache Hit Ratio，Library Hit Ratio也稱Library Cache Hit Ratio。同Load Profile一節相同，這一節也沒有所謂「正確」的值，而只能根據應用的特色判斷是否合適。在一個使用大型並行查詢的DSS（Decision Support System，決策支持系統）環境中，20%的Buffer Hit Ratio是能夠接受的，而這個值對於一個OLTP系統是徹底不能接受的。根據針對Oracle的經驗，對於OLTP系統，Buffer Hit Ratio理想應該在90%以上。

下表是該部分的一個示例表格：

Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	98.72	In-memory Sort %:	99.86
Library Hit %:	99.97	Soft Parse %:	99.92
Execute to Parse %:	89.09	Latch Hit %:	99.99
Parse CPU to Parse Elapsd %:	7.99	% Non-Parse CPU:	99.95

該部分的各個指標解析以下所示：

v 緩衝區未等待率（Buffer Nowait %）：表示在內存得到數據的未等待比率。Buffer Nowait的這個值通常須要大於99%。不然可能存在爭用，能夠在後面的等待事件中進一步確認。若是該值較低，那麼可能要增大BUFFER CACHE，指望值是100%，不該該低於99%。

v 緩衝區命中率（Buffer Hit %）：表示進程從內存中找到數據塊的比率，即數據塊在數據緩衝區中的命中率，一般應在95%以上。監視這個值是否發生重大變化比僅僅觀察這個值自己更重要。若是小於95%，那麼就須要調整重要的參數，若是小於90%，那麼就可能需要加DB_CACHE_SIZE。對於通常的OLTP系統，若是此值低於80%，那麼應該給數據庫分配更多的內存。命中率的突變，每每是一個很差的信息。若是命中率忽然增大，那麼能夠檢查top buffer get SQL，查看致使大量邏輯讀的語句和索引；若是命中率忽然減少，那麼能夠檢查top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的SQL語句。

v Redo緩衝區未等待率（Redo Nowait %）：表示在LOG緩衝區（Redo Log Buffer）得到BUFFER的未等待比率，該指標的值應接近100%。若是該值較低，那麼有兩種可能的狀況：1）聯機Redo日誌文件沒有足夠的空間；2）LOG切換速度較慢。若是過低（可參考90%閥值），那麼考慮增長LOG_BUFFER。

v 庫緩存命中率（Library Hit%）：表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查Library Cache肯定是否存在解析過的版本，若是存在，那麼Oracle當即執行語句；若是不存在，那麼Oracle解析此語句，並在Library Cache中爲它分配共享SQL區。該值太低說明有過多的解析，CPU消耗增長，性能下降。若是該值低於90%，那麼可能須要調大Shared Pool區。

v 閂鎖命中率（Latch Hit %）：Latch是一種保護內存結構的鎖，能夠認爲是SERVER進程獲取訪問內存數據結構的許可。要確保Latch Hit大於99%，不然意味着Shared Pool latch爭用，可能因爲未共享的SQL或Library Cache過小，可以使用綁定變動或調大Shared Pool解決。當該值出現問題的時候，能夠藉助後面的等待事件和Latch來分析查找解決問題。

v CPU時間佔整個解析時間比率（Parse CPU to Parse Elapsd %）：表示在解析SQL語句過程當中，CPU佔整個的解析時間比例，指望值是100%，說明解析沒有產生等待，計算公式爲：解析實際運行時間/（解析實際運行時間+解析中等待資源時間），該值越大越好。若是該值爲100%，那麼意味着CPU等待時間爲0，沒有任何等待。

v CPU非解析時間百分比（Non-Parse CPU %）：即SQL實際運行時間/(SQL實際運行時間+SQL解析時間)。該值太小表示解析消耗CPU時間過多，該值越大越好，說明計算機執行的大部分工做是執行查詢的工做，而不是分析查詢的工做。

v 解析與執行的比率（Execute to Parse %）：指的是SQL語句解析與執行的比例，若是SQL重用率高，那麼這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。該值越大越好，說明一次解析，處處執行。計算公式爲：Execute to Parse=100*(1-PARSES/EXECUTIONS)。若是系統PARSES大於EXECUTIONS，那麼就可能出現該比率小於0的狀況。若該值小於0，則一般說明Shared Pool設置或者語句效率存在問題，形成反覆解析，REPARSE可能較嚴重。

v 內存排序率（In-memory Sort %）：表示在內存中排序的比率，若是太低，那麼說明有大量的排序在臨時表空間中進行，此時能夠考慮調大PGA。該指標的值應接近100%，若是低於95%，那麼能夠經過適當調大初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意，這兩個參數設置做用的範圍是不一樣的，SORT_AREA_SIZE是針對每一個SESSION設置的，PGA_AGGREGATE_TARGET則是針對全部的SESSION的。

v 軟解析的百分比（Soft Parse %）：表示軟解析的百分比，近似看成SQL在共享區的命中率。若該值小於95%，則須要考慮綁定變量，若是低於80%，那麼就能夠認爲SQL基本沒有被重用。該指標的值一般應在95%以上，指望值是100%，有一點要說明的是，不要單方面的追求軟解析的高比例，而去綁定變量，要看性能的瓶頸在哪裏。

（四）Top 5 Timed Events

該部分的一個示例以下所示：

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
CPU time		515		77.6
SQL*Net more data from client	27,319	64	2	9.7	Network
log file parallel write	5,497	47	9	7.1	System I/O
db file sequential read	7,900	35	4	5.3	User I/O
db file parallel write	4,806	34	7	5.1	System I/O

該部分顯示了系統中最嚴重的5個等待事件，按所佔等待時間的比例倒序顯示。當調優時，該部分是必需要分析的，應當從這裏入手肯定下一步作什麼。例如，「buffer busy waits」是較嚴重的等待事件，那麼應當繼續研究報告中Buffer Wait和File/Tablespace I/O區的內容，識別哪些文件致使了問題。若是最嚴重的等待事件是I/O事件，那麼應當研究按物理讀排序的SQL語句區以識別哪些語句在執行大量I/O，並研究Tablespace和I/O區觀察較慢響應時間的文件。若是有較高的LATCH等待，那麼就須要察看詳細的LATCH統計識別哪些LATCH產生的問題。

一個性能良好的系統，CPU TIME應該在TOP 5的前面，不然說明系統大部分時間都用在等待上。

（五）SQL Statistics

SQL Statistics分別從執行時間、物理讀、邏輯讀、子游標個數、執行次數等方面羅列出TOP語句，從該部分能夠迅速獲取有性能問題的SQL語句，以下所示：

l SQL ordered by Elapsed Time

l SQL ordered by CPU Time

l SQL ordered by Gets

l SQL ordered by Reads

l SQL ordered by Executions

l SQL ordered by Parse Calls

l SQL ordered by Version Count

以「lSQL ordered by Elapsed Time」爲例，該部分記錄了執行總時間的SQL語句，記錄的是監控範圍內該SQL的執行時間總和，須要綜合分析CPU時間（CPU Time）和執行次數（Executions）才能獲得單個SQL的代價。單次執行開銷較大的SQL屬於重點優化之列。

該部分的一個示例表以下所示：

Elapsed Time (s)	Executions	Elapsed Time per Exec (s)	%Total	%CPU	%IO	SQL Id	SQL Module	SQL Text
12,418,953.35	2,376,222	5.23	99.49	0.03	0.00	1cmnjddakrqbv	JDBC Thin Client	update orgtion o set o.qu...
3,791.90	2,129,113	0.00	0.03	24.33	2.73	26ad9zvt5xgb3	JDBC Thin Client	insert into tran_success...
2,882.78	3,267,011	0.00	0.02	16.76	13.88	an08dyryjns25	JDBC Thin Client	select t.trans_id, t.id_type, ...
1,100.69	2,129,218	0.00	0.01	18.21	0.01	g8mxscbjf4t8f	JDBC Thin Client	select count(0) from tra_boo...
861.17	541,558	0.00	0.01	22.34	2.40	5ww8x9u15a90y	JDBC Thin Client	insert into transuccess...
675.32	19,773,101	0.00	0.01	55.62	0.00	dzmtc8dyfsv0v	JDBC Thin Client	select sysdate from dual

對於每一個指標的解析以下：

v Elapsed Time(s)：SQL語句執行總時長，此排序就是按照這個字段進行的。注意該時間不是單個SQL運行的時間，而是監控範圍內SQL執行次數的總和時間。單位爲秒。Elapsed Time = CPU Time + Wait Time。

v CPU Time(s)：SQL語句執行時CPU佔用總時長，此時間會小於等於Elapsed Time時間。單位爲秒。

v Executions：SQL語句在監控範圍內的執行次數總和。若Executions爲0，則說明語句沒有正常執行完成，被中間中止，須要關注。

v Elapsed Time per Exec (s)：執行一次SQL的平均時間。單位爲秒。

v %Total：SQL的Elapsed Time時間佔數據庫總時間（DB Time）的百分比。

v SQL Id：SQL語句的ID編號，點擊以後就能導航到下面的SQL詳細列表中，點擊瀏覽器的返回按鈕能夠回到當前SQL Id的地方。

v SQL Module：顯示該SQL是用什麼方式鏈接到數據庫的。

v SQL Text：簡單的SQL文本。

（六）Segment Statistics

該部分從段（表段、索引段）的角度描述了數據庫的繁忙程度，包含了邏輯讀、物理讀、ITL等方面。若等待事件「enq: TX - row lock contention」發生次數比較多，則能夠查看「Segments by Row Lock Waits」部份內容，找到發生行鎖的表。若等待事件「enq: TX - allocate ITL entry」發生次數比較多，則能夠查看「Segments by ITL Waits」部份內容，找到發生ITL等待的表。若等待事件「Buffer Busy Waits」發生次數比較多，則能夠查看「Segments by Buffer Busy Waits」部份內容，找到那些對象訪問頻繁，從而致使熱塊的產生。

還有其它的一些須要關注的內容，這裏就不詳細介紹了。

& 說明：

有關每一種等待事件的解釋，能夠關注做者微信公衆號（參考附錄部分）。

有關如何閱讀AWR報告能夠參考個人BLOG：http://blog.itpub.net/26736162/viewspace-2121787/

本文選自《Oracle程序員面試筆試寶典》，做者：小麥苗

==================================================================================================================【乾貨來了|小麥苗IT資料分享】★小麥苗DB職場乾貨：https://mp.weixin.qq.com/s/Vm5PqNcDcITkOr9cQg6T7w★小麥苗數據庫健康檢查：https://share.weiyun.com/5lb2U2M★小麥苗微店：https://weidian.com/?userid=793741433★各類操做系統下的數據庫安裝文件（Linux、Windows、AIX等）：https://pan.baidu.com/s/1hqff3Evv6oj2-Tn87MpFkQ★小麥苗分享的資料：https://share.weiyun.com/57HUxNi★小麥苗課堂資料：https://share.weiyun.com/5fAdN5m★小麥苗課堂試聽資料：https://share.weiyun.com/5HnQEuL★小麥苗出版的相關書籍：https://share.weiyun.com/5sQBQpY★小麥苗博客文章：https://share.weiyun.com/5ufi4Dx★數據庫系列（Oracle、MySQL、NoSQL）：https://share.weiyun.com/5n1u8gv★公開課錄像文件：https://share.weiyun.com/5yd7ukG★其它經常使用軟件分享：https://share.weiyun.com/53BlaHX★其它IT資料（OS、網絡、存儲等）：https://share.weiyun.com/5Mn6ESi★Python資料：https://share.weiyun.com/5iuQ2Fn★已安裝配置好的虛擬機：https://share.weiyun.com/5E8pxvT★小麥苗騰訊課堂：https://lhr.ke.qq.com/★小麥苗博客：http://blog.itpub.net/26736162/★OCP培訓：https://mp.weixin.qq.com/s/2cymJ4xiBPtTaHu16HkiuA★12c的OCP培訓：https://mp.weixin.qq.com/s/hMLHlyjMHhLmA0xN4hLvfw★OCM培訓：https://mp.weixin.qq.com/s/7-R6Cz8RcJKduVv6YlAxJA★高可用（RAC+DG+OGG）培訓：https://mp.weixin.qq.com/s/4vf042CnOdAD8zDyjUueiw★小麥苗課堂騰訊視頻：http://v.qq.com/vplus/71f69a319a24c6808cd6e6189ae90664
==================================================================================================================

 

---

● 本文做者：小麥苗，只專一於數據庫的技術，更注重技術的運用

● 做者博客地址：http://blog.itpub.net/26736162/abstract/1/

● 本系列題目來源於做者的學習筆記，部分整理自網絡，如有侵權或不當之處還請諒解

● 版權全部，歡迎分享本文，轉載請保留出處

● QQ：646634621  QQ羣：23016159九、618766405

● 微信：lhrbestxh

● 微信公衆號：DB寶

● 提供Oracle OCP、OCM、高可用（rac+dg+ogg）和MySQL最實用的技能培訓

● 題目解答如有不當之處，還望各位朋友批評指正，共同進步

長按下圖識別二維碼或微信掃描下圖二維碼來關注小麥苗的微信公衆號：DB寶，學習最實用的數據庫技術。

本文分享自微信公衆號 - DB寶（lhrdba）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。