對于數據庫運行期間的各種狀態的實時監控以及相關性能數據捕獲對于解決性能問題，提高整體業務系統運行效率是至關重要的。在Oracle數據庫中，實時捕獲相關性能數據是通過ASH工具來實現的。ASH通過每秒鐘抽取活動會話樣本，為分析在最近時刻的性能問題提供最直接最有效的依據。本文主要講述ASH的用法及使用。
Oracle v$active_session_history視圖提供了實例中的活動會話采樣。通過該視圖提供的最詳細最完整性能數據，可作為定位性能故障的一手證據。任一連接到數據庫時，那些不屬于空閑等待類的事件的會話被認為是活動會話。這包括在采樣時在CPU上的任何會話。
活動會話樣本存儲在SGA中的循環緩沖區中。隨著系統活動的增加，可以存儲在循環緩沖區中的會話活動的秒數將減少。會話樣本的時間保留在v$視圖中。在v$視圖中顯示的會話活動的秒數是完全依賴于數據庫活動的。
當自動工作負載信息庫（AWR）快照的創建，動態性能視圖v$active_session_history的內容被刷新到磁盤。通過只捕獲活動會話，表示一組可管理的數據，它的大小直接關系到正在執行的工作，而不是系統上允許的會話數。
數據字典dba_hist_active_sess_history是視圖v$active_session_history的歷史數據，dba_hist_active_sess_history視圖默認每十秒收集一次信息儲存在磁盤中。也就是說最終保存到磁盤的數據也就是實時收集數量量的1/10。相應地，可用于診斷性能的數據也就沒有v$active_session_history更詳細，更豐富。
活動會話數據流：
?? v$session(ASH Buffer) —>v$active_session_history—>dba_hist_active_sess_history(AWR倉庫)
活動會話歷史樣本通常包括如下：
??SQL語句的SQL標識符
??對象號，文件號和塊號
??等待事件標識符和參數
??會話標識符和會話序列號
??模塊和動作名稱
??會話的客戶端標識符
??服務哈希標識符
??阻塞會話
如上圖所示，ASH從V$SESSION提取信息樣本。每秒提取一個樣本，直接讀取Oracle使用的特定結構數據，而不是使用SQL，因此該方式比較高效。
ASH被設計為內存中的滾動緩沖區，以前的信息在需要時被覆蓋。由于ASH緩沖區中的數據量可能非常大，并且將其全部刷新到磁盤是不可接受的。更有效的方法是過濾歷史數據，同時將其刷新到工作負載存儲庫。每隔60分鐘通過可管理性監視器（MMON）進程自動執行此操作，并且每當緩沖區已滿時，都通過MMNL進程完成。
注意：ASH的存儲器來自系統全局區域（SGA），它在實例的使用壽命期間是固定的。它代表每個CPU 2 MB的內存。 ASH不能超過共享池大小的百分之五，也就是SGA_TARGET的百分之五。
SQL
三、ASM采樣示例
如前所述，ASH代表了近期活動的歷史。 該圖顯示了當活動時如何采樣會話。 每秒鐘，Oracle數據庫服務器查看活動會話，并記錄這些會話正在等待的事件。 非活動會話不被采樣。 采樣非常高效，因為它直接訪問Oracle數據庫內部結構。
如上圖中，活動會話1 Wait I/O以及Wait Block被記錄到v$active_session_history視圖。
四、訪問活動會話數據
檢查當前活動會話歷史：v$active_session_history
檢查活動會話歷史數據：dba_hist_active_sess_history
生成ASH報告
通過OEM 診斷包性能頁面
五、生成ASH報告
SQL> @?/rdbms/admin/ashrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
六、ASH報告結構
ASH報告結構，如下圖所示：
Top Events：
??報告的用戶事件，背景，事件，和事件的參數值
Load Profile：
??報告頂級服務/模塊，頂級客戶端，識別SQL命令和執行SQL的類型
Top SQL：
??報告與首要事件相關SQL語句，與rowsources相關SQL，完整SQL語句，SQL語句綁定變量使用
Top PL/SQL Procedures：
??列出的PL/SQL程序，占百分比最高的采樣會話活動
Top Java Workload：
??描述了在采樣會話活動java程序
Top Sessions：
??首要會話，阻塞會話和并行相關會話
Top Objects/Files/Latches：
??報告對象，文件，或鎖存
Activity Over Time：
??報告前三等待事件為10個同樣大小的時間報告期，該報告可以讓你看到在最后時刻非常詳細的活動。
七、ASH報告分析
1、頭部信息：
注，DataSource 可以有2個來源，一個是V$ACTIVE_SESSION_HISTORY，一個是DBA_HIST_ACTIVE_SESS_HISTORY
2、首要等待事件
首要等待事件部分描述了被抽樣會話活動中由用戶，后臺等產生的首要等待事件，首要等待事件，意味著采樣期間這些事件是產生性能問題的根源。
首要等待事件包含以下部分:
（1）Top User Events首要用戶事件
首要用戶事件，也成為前臺等待事件，信息顯示了在抽樣會話活動中占很高百分比的用戶進程等待事件。
（2）Top Background Events首要后臺事件
這部分信息顯示了在抽樣會話活動中占很高百分比的后臺進程等待事件。
（3）Top Event P1/P2/P3 Values首要等待事件參數P1/P2/P3
這部分信息顯示了在抽樣會話活動中占很高百分比的等待事件的參數值它通過總的等待時間(%Event)百分比進行排序后被顯示.對于每一個等待事件p1，p2，p3的值與等待事件參數parameter 1，parameter 2，parameter 3這三個列相關聯，分別是文件號，塊號，set-id#
如上圖所示，當前的數據庫主要事件為
free buffer waits
??服務器進程掃描LRU列表獲得空閑的緩沖區（例如，從磁盤讀取數據塊，或者構造一致性讀Cr塊等到緩沖區時）。掃描到一個閾值后，如果服務器進程無法找到可用緩沖區，它請DBWR從LRU列表將臟緩沖區寫出到磁盤，等待直到緩沖釋放。在DBWR寫出臟緩沖釋放前的等待，稱為free buffer waits。通常2個主要的情形導致free buffer waits，一個是DBWR寫出臟塊速度不夠快，二是Buffer cache過小。
write complete waits
??DBWR將臟緩沖區記錄到磁盤上的期間，對緩沖區以exclusive模式占有buffer lock，此時，讀取或修改緩沖區的其他進程就需要等待此項工作結束，這時等待write complete waits事件。
buffer busy waits
??緩沖區繁忙等待，發生這個事件的兩個主要情況是：另一個會話正將塊讀到緩沖區中；另一個會話以不兼容的方式持有我們所請求的有緩沖區。
3、Load Profile
4、Top SQL
5、完整SQL列表
6、首要會話
7、首要對象，文件，栓
8、分時活動
該部分內容將報告期間按不同時間片段來展現活動等待事件。
如上圖所示，activity over time被分成8個時段，前3個等待事件會出現在每一個時間段。
從上圖可知，基本上來說，整個采樣期間都是經歷三個和buffer相關的等待事件。%event并沒有出現明顯的尖波。
下面是每列的描述
列 描述
slot time(持續時間) 時段的持續時間
solt count 在時段中抽樣會話的數量
event 在時段中頂級的三個等待事件
event count ash抽樣等待的等待事件的數量
%event ash抽樣等待的等待事件在整個分析期間所占的百分比
9、報告得到的初步結論
1) 整個采樣期間，OLTP特征顯著，主要表現為大量的DML操作
2) 首要的等待事件表現為Buffer相關，很容易聯想到增加Buffer size，但是從報告頭部可知Buffer 僅占用23.5%
3) 對于首要等待事件，DBWR存在調整及優化的可能，例如增加DBWn進程數目，加快寫入，以及優化磁盤IO
4) 優化檢查點，以加快數據寫出到磁盤
5) 優化SQL以減少過多的IO負載，同時也可以考慮優化SQL所在的包，存儲過程
6) 熱對象的分區以及索引分離，反向索引設計等
轉：http://blog.csdn.net/leshami/article/details/73526881
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
