Oracle等待事件分析與AWR和ASH報告_鯊魚胃的博客-程序員資料_ash報告和awr報告的區別
文章目錄
1 ASH和AWR
1.1 ASH
用戶的連接將產生會話，當前會話記錄保存在v$session中，通過該視圖，DBA可以查看用戶實際執行的操作，或者當前的等待事件等。
處於等待狀態的會話會被復制一份放在v$session_wait中。
但是，一旦連接斷開，其原來的連接信息在v$session和v$session_wait中就會被刪除。這是10g之前的狀況。
若是一個普通的會話一般沒有大量地耗費資源，則對於性能調整來說無足輕重。但若該會話在活動時大量占用了資源（比如：CPU，內存，I/O等），該會話信息的丟失，將無法評測當時的系統瓶頸究竟是什么。令DBA高興的是，Oracle 10g中保留下了v$session_wait中的這些信息。
在Oracle 10g以后新出現了一個視圖：v$session_wait_history。這個視圖保存了每個活動session在v$session_wait中最近10次的等待事件。但這對於一段時期內的數據庫性能狀況的監測是遠遠不夠的，為了解決這個問題，在10g中還新添加了一個視圖：v$active_session_history，活動會話的歷史記錄。即使用戶操作完成后，斷開了連接也不怕，因為其會話的情況已經被記錄了下來，這項特性就是ASH了，全稱與視圖名相同，正是：ACTIVE SESSION HISTORY。
典型的情況下，為了診斷當前數據庫的狀態，需要最近的五到十分鍾的詳細信息。然而，由於記錄session的活動信息是很費時間和空間的，ASH采用的策略是：保存處於等待狀態的活動session的信息，每秒從v$session_wait中采樣一次，並將采樣信息保存在內存中。
1.1.1 ash占用的內存大小
ASH的采集信息保存在內存中，在舊的信息被采樣到AWR中后，可被新采集的信息覆蓋，重啟oracle后該信息被清除。動態性能視圖其實上是ORACLE自行構造的一堆存在於SGA內存區的虛表，就是說，ASH的數據是保存在內存里的，實際上，ORACLE分配給ASH的空間並不是無限大(更何況ORACLE自身管理的內存空間也不是無限大)，分配給ASH的內存大小可以查詢到：
SQL> select pool,name,bytes/1024/1024 Mb From v$sgastat where name like 'ASH%';
POOL NAME MB
------------ -------------------------- ----------
shared pool ASH buffers 96
直白的講 ，v$active_session_history中能夠記錄多少會話信息， 一方面取決於該數據庫的SGA分配給ASH buffers的大小 ，另一方面取決於數據庫的啟動和關閉(重啟數據庫時將重構SGA內存區)。這兩方面的因素制約了v$active_session_history中能夠保存的會話信息的能力，我們肯定是希望ASH盡可能多的保留關於會話的信息，但目前來看單純依靠v$active_session_history肯定無法實現這點，ORACLE又提供了AWR特性，ASH收集到的會話信息，是做為AWR中快照信息的一部分，被保存到了硬盤上。
1.2 AWR
ASH的采樣數據是保存在內存中。而分配給ASH的內存空間是有限的，當所分配空間占滿后，舊的記錄就會被覆蓋掉；而且數據庫重啟后，所有的這些ASH信息都會消失。這樣，對於長期檢測oracle的性能是不可能的。在Oracle10g中，提供了永久保留ASH信息的方法，這就是AWR-Automatic Workload Repository：自動負載信息庫。
由於全部保存ASH中的信息是非常耗費時間和空間的，AWR采用的策略是：每小時對v$active_session_history進行采樣一次，並將信息保存到磁盤中，並且保留7天，7天后舊的記錄才會被覆蓋。這些采樣信息被保存在視圖wrh$_active_session_history中。而這個采樣頻率（1小時）和保留時間（7天）是可以根據實際情況進行調整的，這就給DBA們提供了更加有效的系統監測工具。
要想讓AWR收集到准確的統計信息，從而生成可靠的性能分析報告，必須將初始化參數
STATISTICS_LEVEL的值設置為TYPICAL或ALL。
SQL> show parameter STATISTICS_LEVEL
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
AWR永久地保存系統的性能診斷信息，由SYS用戶擁有。一段時間后，可能想清除掉這些信息；有時候為了性能診斷，可能需要自己定義采樣頻率來獲取系統快照信息。Oracle 10g在包dbms_workload_repository中提供了很多過程，通過這些過程，可以管理快照並設定基線(baselines)。
注意
其實，AWR記錄的信息不僅是ASH，還可以收集到數據庫運行的各方面統計信息和等待信息，用以診斷分析。
AWR的采樣方式是，以固定的時間間隔為其所有重要的統計信息和負載信息執行一次采樣，並將采樣信息保存在AWR中。
可以這樣說：ASH中的信息被保存到了AWR中的視圖wrh$_active_session_history中。ASH是AWR的真子集。
1.3 等待事件分析
這樣，我們就知道了ASH和AWR產生的原因和功能。
- ASH保存了系統最新的處於等待的會話記錄，可以用來診斷數據庫的當前狀態
- AWR中的信息最長可能有1小時的延遲，所以其采樣信息並不能用於診斷數據庫的當前狀態，但可以用來作為一段時期內數據庫性能調整的參考。
對於這些視圖間的繼承關系，eygle給出了一個關系圖：
其中視圖dba_hist_active_sess_history是wrh$_active_session_history和其他幾個視圖的聯合展現，通常通過這個視圖進行歷史數據的訪問。
1.4 MMON進程與MMNL進程
快照由一個稱為MMON 的新的后台進程（及其從進程）以及MMNL后台進程自動地每隔固定時間采樣一次。
1.4.1 MMON進程
MMON進程負責執行多種和管理相關（manageability-related）的后台任務：
- 當某個測量值（metrics）超過了預設的限定值（threshold value）后提交警告。
- 創建新的 MMON 隸屬進程（MMON slave process）來進行快照（snapshot）。
- 捕獲最近修改過的 SQL 對象的統計信息。
1.4.2 MMML進程
MMNL進程負責執行輕量級的且頻率較高的和可管理性相關的后台任務，例如捕獲會話歷史信息，測量值計算等。
AWR的采樣工作由MMON進程每個1小時執行一次，ASH信息同樣會被采樣寫出到AWR負載庫中。雖然ASH buffer被設計為保留1小時的信息，但很多時候這個內存是不夠的，當ASH buffer寫滿后，后台進程MMNL將會主動將ASH信息寫出。
1.5 SYSAUX表空間
這些采樣數據都存儲在SYSAUX表空間中，並且以WRM$_*和 WRH$_*的格式命名。前一種類型存儲元數據信息（如檢查的數據庫和采集的快照），后一種類型保存實際采集的統計數據。
SQL> SELECT TABLE_NAME FROM DBA_TABLES WHERE TABLE_NAME LIKE 'WRM$%';
TABLE_NAME
------------------------------
WRM$_BASELINE
WRM$_BASELINE_DETAILS
WRM$_BASELINE_TEMPLATE
WRM$_COLORED_SQL
WRM$_DATABASE_INSTANCE
WRM$_SNAPSHOT
WRM$_SNAPSHOT_DETAILS
WRM$_SNAP_ERROR
WRM$_WR_CONTROL
WRM$_WR_USAGE
10 rows selected.
當SYSAUX表空間滿后，AWR將自動覆蓋掉舊的信息，並在警告日志中記錄一條相關信息：
ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX
1.6 采樣頻率和保留時間
可以通過查詢視圖dba_hist_wr_control或wrm$_wr_control來查詢AWR的采樣頻率和保留時間。默認為每1小時采樣一次，采樣信息保留時間為7天。
2 生成AWR和ASH報告
2.1 生成AWR報告
- sqlplus下執行：
@?/rdbms/admin/awrrpt.sql
或者
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
- 輸入要生成報告的文件格式
Type Specified: html
- 輸入要生成報告相隔的天數
Enter value for num_days: 1
- 輸入相隔的快照之間的Snap Id開始號和結束號
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 101
Enter value for end_snap: 102
End Snapshot Id specified: 102
- 輸入生成報告的名字：
Enter value for report_name: 0531awr.html
- 查看awr報告方式：
生成報告后，退出sqlplus，文件存儲在當前目錄下，可以拷貝到電腦上查看；或者打開linux自帶瀏覽器，輸入目錄
file:///home/oracle/0531awr.html
2.2 AWR的主要參數
AWR報告要根據系統實際情況(OLAP or OLTP)來進行分析,例如對於一個OLTP系統，library hit和buffer hit應比較關注。而對於OLAP不甚重要。
AWR報告不需要全面閱讀，全面閱讀可能思路會更亂，如果性能問題由某個原因引起，那么會在報表的各個部分都會有相應呈現。
在RAC結構的數據庫里做性能分析，通常需要對每個實例做一個AWR性能報告，原因是無法知道每個用戶連接到哪個實例當中去。
對於一個系統，需要多做幾次AWR報告，以便得到所有時間段的系統性能數據。在查看AWR報告時，如果了解數據庫業務,應該有針對性的看一些可能存在性能問題的部分，並結合業務的實際情況來判斷；也可以從TOP 10的等待事件觸發，按照等待事件的類型，到相應的部分獲取詳細的信息來對系統性能問題作出判斷。
通過AWR報告可以：
1）查看系統的負載和繁忙程度；
2）查看系統的瓶頸，發生的等待事件；
3）查看可優化的sql；
1.Summary:
- SESSIONS：實例連接的會話數，數據庫大概的並發用戶數；
- cursors/session：每個會話平均打開的游標數；
2.Report Summary:
-
load profile：數據庫資源負載的一個明細列表，用來判斷系統的繁忙程度。分割為每秒鍾的資源負載和每個事務的資源負載情況。
1）DB time：用戶操作花費的時間的合集，包括CPU時間和等待事件；
-
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）Soft Parse %：軟解析比例
Execute to Parse %-sql 語句解析后被重復執行的次數， 計算公式=100*（1-Parses/Executions），很明顯，如果SQL重用率比較高，那么該比例就很高。如果過低，可以考慮設置session_cached_cursors 參數
Soft Parse %-軟解析比例， 公式=softs/softs+hards，近似於sql在共享區的命中率，小於95%,需要考
慮使用綁定變量，如果低於80%，那么就可能sql 基本沒有被重用；
8）latch Hit：latch命中率百分比；
9）parse cpu to parse elapsed：解析總時間中消耗CPU的時間百分比；
10）non-parse cpu：cpu非分析時間在整個cpu時間的百分比；
-
cache sizes：列舉awr在性能采集開始和結束的時候，數據緩沖池和共享池的大小，可以了解系統內存消耗的變化，可以判斷SGA的內存分配是否合理；
-
TOP 10 Foreground Events by Total Wait Time：查看最高10個耗費時間及等待事件，要聯系報告的采集周期來看耗費時間是否合理。一般來說，CPU time出現在TOP10中的第一位，並且消耗時間占總時間的大部分比例。可以說明系統在正常運行。
以上這部分就是awr報告的總體概要，是需要重點關注的部分，根據這些信息可以知道等待時間比較長的事件，然后根據這些事件，去下面具體的部分查找問題原因。
3.Wait Events Statistics：
- Time Model Statistics列出了各種操作占用的數據庫時間比例；
- Foreground Wait Class列出了等待事件類型，可以看到等待時間最長的事件；
- Foreground Wait Events是第一部分 Top 10 Foreground Events by Total Wait Time的詳細部分；
- Background Wait Events實例的后台進程等待事件；
4.SQL Statistics：
- SQL ordered by Elapsed Time：按照sql的執行時間從長到短的排序；
1）elapsed time：sql執行時間；
2）executions：sql執行的次數；
3）elapsed per exec：每次執行消耗的執行時間；
- SQL ordered by CPU Time：按照sql的CPU時間從長到短排序：
- SQL ordered by User I/O Wait Time：
- SQL ordered by Gets：按照sql獲取的內存數據塊的數量排序：
- SQL ordered by Reads按照sql執行物理讀排序：
- SQL ordered by Physical Reads (UnOptimized)：
- SQL ordered by Executions：按照sql的執行次數的排序；
- SQL ordered by Parse Calls：按照sql被分析次數（不區分軟解析還是硬解析）的信息排序；
- SQL ordered by Version Count：sql產生多版本的信息；version count是sql的版本數；
以上指標孤立起來看都沒有實際意義，需要看系統的類型和性能問題是什么方面，有側重的進行分析。例如SQL ordered by Executions和SQL ordered by Parse Calls對OLTP比較重要，而OLAP系統不需要太關注。
5.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秒。
6.I\O 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性能下降。
2.3 生成AWR報告
ASH側重於當前數據中活動會話的信息分析，被長期保存在數據字典中，可以通過查詢視圖V$ACTIVE_SESSION_HISTROY來得到。
也可以運行腳本。
使用同目錄下的ashrpti.sql腳本可以生成其他數據庫或者實例的ASH性能報告，也可以對一個session ID、SQL_ID、某個程序或者某一類等待事件
- sqlplus下執行：
@?/rdbms/admin/ashrpt.sql
或者
@$ORACLE_HOME/rdbms/admin/ashrpt.sql
- 輸入要生成報告的文件格式,默認html
Enter value for report_type: - 輸入開始時間，默認15min之前,手動輸入數字是以分鍾為單位
Enter begin time for report:
-- Valid input formats:
-- To specify absolute begin time:
-- [MM/DD[/YY]] HH24:MI[:SS]
-- Examples: 02/23/03 14:30:15
-- 02/23 14:30:15
-- 14:30:15
-- 14:30
-- To specify relative begin time: (start with '-' sign)
-- -[HH24:]MI
-- Examples: -1:15 (SYSDATE - 1 Hr 15 Mins)
-- -25 (SYSDATE - 25 Mins)
Defaults to -15 mins
Enter value for begin_time:
- 輸入間隔，默認至現在
Enter duration in minutes starting from begin time:
Defaults to SYSDATE - begin_time
Press Enter to analyze till current time
Enter value for duration:
- 輸入生成報告的名字：
Enter value for report_name: ash0601.html
- 查看ash報告方式：
生成報告后，退出sqlplus，文件存儲在當前目錄下。
2.4 ASH報告主要參數
ASH報告分析如下：
DATA SOURCE如果來自DBA_HIST_ACTIVE_SESS_HISTORY,那么說明這些信息來自於AWR的快照；如果來自於V$ACTIVE_SESSION_HISTORY,那么
視圖的信息就意味着性能數據存放到內存中的信息。
- top user events:用戶會話的等待事件的信息；
- top event p1/p2/p3 values:等待事件的具體描述；
- top service/module:按照活動頻率列出前五位的應用程序；
- top sql command types:列出了數據庫中活動最頻繁的操作；
- top sql with top events:按活動頻繁程度列出sql語句；
- top session:列出活動最頻繁的會話或進程；
- top sessions running PQs:列出活動頻繁的前幾位並行執行的會話信息；
- top DB files：IO最頻繁的數據文件；
- activity over time:按照一個時間間隔對采集時間周期分組后，生成的每個時間間隔里的等待事件信息。
