資料庫的效能分析可分為會話級和系統級：如果確定某個會話存在效能問題，最常見的分析方式是對這個會話做一個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效能報告的解讀

相關文章