如何進行ORACLE AWR性能報告和ASH性能報告的解讀

今天就跟大家聊聊有關如何進行ORACLE AWR性能報告和ASH性能報告的解讀，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

數據庫的性能分析可分為會話級和系統級：如果確定某個會話存在性能問題，最常見的分析方式是對這個會話做一個SQL_TRACE或者10046事件，通過分析trace文件來定位問題所在。如果無法確定哪個會話性能有問題，就需要從實例級別來分析問題所在。

awr是oracle 10g下提供的一種性能收集和分析工具，它能夠提供一個時間段內整個系統資源使用情況的報告。
awr默認收集最近7天的采集信息，也可通過以下方法修改快照收集時間間隔信息。


awr由運行在oracle的后臺進程自動、定期收集數據庫的性能數據并保存，每一個小時，awr都生成一次性能數據快照，為DBA提供某個時刻數據庫性能分析的數據信息。
執行$ORACLE_HOME/RDBMS/ADMIN/awrrpt.sql生成awr報告。

awr報告要根據系統實際情況(OLAP or OLTP)來進行分析,例如對于一個OLTP系統，library hit和buffer hit應比較關注。而對于OLAP不甚重要。

awr報告不需要全面閱讀，全面閱讀可能思路會更亂，如果性能問題由某個原因引起，那么會在報表的各個部分都會有相應呈現。

在RAC結構的數據庫里做性能分析，通常需要對每個實例做一個awr性能報告，原因是無法知道每個用戶連接到哪個實例當中去。

對于一個系統，需要多做幾次awr報告，以便得到所有時間段的系統性能數據。在查看awr報告時，如果了解數據庫業務,應該有針對性
的看一些可能存在性能問題的部分，并結合業務的實際情況來判斷；也可以從TOP5的等待事件觸發，按照等待事件的類型，
到相應的部分獲取詳細的信息來對系統性能問題作出判斷。

通過awr報告可以：1）查看系統的負載和繁忙程度；2）查看系統的瓶頸，發生的等待事件；3）查看可優化的sql；

一、Report Summary:
1、SESSIONS：實例連接的會話數，數據庫大概的并發用戶數；
2、cursors/session：每個會話平均打開的游標數；
3、DB time：用戶操作花費的時間的合集，包括CPU時間和等待事件；
4、cache sizes：列舉awr在性能采集開始和結束的時候，數據緩沖池和共享池的大小，可以了解系統內存消耗的變化，可以判斷SGA的內存分配是否合理；
5、load profile：數據庫資源負載的一個明細列表，用來判斷系統的繁忙程度。分割為每秒鐘的資源負載和每個事務的資源負載情況。
6、Instance Efficiency Percentages：內存效率的統計信息，對于OLTP系統，應盡可能的接近100%。如果哪個數據偏低，就要做相關的分析研究。
    1）buffer nowait：非等待方式獲取數據庫；
    2）redo nowait：非等待方式獲取redo數據；
    3）buffer hit：內存數據塊命中率；
    4）in-memory sort：數據塊在內存中排序的百分比；
    5）library hit：共享池中sql解析的命中率；
    6）execute to parse：執行次數對分析次數的百分比；
    7）latch Hit：latch命中率百分比；
    8）parse cpu to parse elapsed：解析總時間中消耗CPU的時間百分比；
    9）non-parse cpu：cpu非分析時間在整個cpu時間的百分比；
7、TOP 5 TIMED EVENTS：查看最高5個耗費時間及等待事件，要聯系報告的采集周期來看耗費時間是否合理。一般來說，CPU time出現在TOP5中的第一位，并且消耗時間占總時間的大部分比例。可以說明系統在正常運行。
對于ORACLE常見的等待事件可參考http：//blog.itpub.net/29371470/viewspace-1063994/
以上這部分就是awr報告的總體概要，是需要重點關注的部分，根據這些信息可以知道等待時間比較長的事件，然后根據這些事件，去下面具體的部分查找問題原因。

二、Wait Events Statistics：
1、Time Model Statistics列出了各種操作占用的數據庫時間比例；
2、Foreground Wait Class列出了等待事件類型，可以看到等待時間最長的事件；
3、Foreground Wait Events是第一部分TOP 5 TIMED EVENTS的詳細部分；
4、Background Wait Events實例的后臺進程等待事件；

三、SQL Statistics：
1、SQL ordered by Elapsed Time：按照sql的執行時間從長到短的排序；
   1）CPU time：sql消耗的CPU時間；
   2）elapsed time：sql執行時間；
   3）executions：sql執行的次數；
   4）elapsed per exec：每次執行消耗的執行時間；
2、SQL ordered by CPU Time：按照sql的CPU時間從長到短排序：
3、SQL ordered by User I/O Wait Time：
4、SQL ordered by Gets：按照sql獲取的內存數據塊的數量排序： 
5、SQL ordered by Reads按照sql執行物理讀排序： 
6、SQL ordered by Physical Reads (UnOptimized)：
7、SQL ordered by Executions：按照sql的執行次數的排序；
8、SQL ordered by Parse Calls：按照sql被分析次數（不區分軟解析還是硬解析）的信息排序；
9、SQL ordered by Version Count：sql產生多版本的信息；version count是sql的版本數；
以上指標孤立起來看都沒有實際意義，需要看系統的類型和性能問題是什么方面，有側重的進行分析。例如SQL ordered by Executions和SQL ordered by Parse Calls對OLTP比較重要，而OLAP系統不需要太關注。

四、Instance Activity Statistics：
cpu used by this session：oracle消耗的cpu單位,可以看出cpu的負載情況；如果total為1000，per sec 為80，cpu個數為2；
那么就是整個統計周期消耗了1000個cpu單位，每秒鐘消耗了80個cpu單位，對應實際的時間是80/100=0.8秒；每秒鐘每個cpu消耗80/2=40個cpu單位；每秒鐘中每個cpu處理使用的時間是40/100=0.4秒。

五、IO Stats：
Tablespace IO Stats：表空間的IO性能統計；
File IO Stats：
   1）reads：發生了多少次物理讀；
   2）writes：發生了多少次寫；
   3）Av reads：每秒鐘物理讀的次數；
   4）Av Rd：平均一次物理讀的時間；
   5）Blks/Rd：每次讀多少個數據塊；
   6）Av writes：每秒鐘寫的次數；
   7）buffer waits：獲取內存數據塊等待的次數；
segments by logical reads和segment by physical reads從對象角度來展現了IO情況，分析這兩部分信息，可以具體知道哪些對象的訪問導致了IO性能下降。


ASH側重于當前數據中活動會話的信息分析，被長期保存在數據字典中，可以通過查詢視圖V$ACTIVE_SESSION_HISTROY來得到。
運行腳本為$ORACLE_HOME/RDBMS/ADMIN/ashrpt.sql
使用同目錄下的ashrpti.sql腳本可以生成其他數據庫或者實例的ASH性能報告，也可以對一個session ID、SQL_ID、某個程序或者某一類等待事件
來生成ASH報告，如下圖：

ASH報告分析如下：
DATA SOURCE如果來自DBA_HIST_ACTIVE_SESS_HISTORY,那么說明這些信息來自于AWR的快照；如果來自于V$ACTIVE_SESSION_HISTORY,那么
視圖的信息就意味著性能數據存放到內存中的信息。
1、top user events:用戶會話的等待事件的信息；
2、top event p1/p2/p3 values:等待事件的具體描述；
3、top service/module:按照活動頻率列出前五位的應用程序；
4、top sql command types:列出了數據庫中活動最頻繁的操作；
5、top sql statements:按活動頻繁程度列出sql語句；
6、top session:列出活動最頻繁的會話或進程；
7、top sessions running PQs:列出活動頻繁的前幾位并行執行的會話信息；
8、top DB files：IO最頻繁的數據文件；
9、activity over time:按照一個時間間隔對采集時間周期分組后，生成的每個時間間隔里的等待事件信息。

看完上述內容，你們對如何進行ORACLE AWR性能報告和ASH性能報告的解讀有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。