oracle ash介绍,Oracle ---- 性能调查之ASH（一）
在ORACLE性能問題調查時，有價值的診斷情報有很多：STATSPACK，AWR，ASH，SYSTEMSTATE DUMP等等。每一種都在特定的場景起到重要的作用。其中最多的一個場景就是問題發生后采用了緊急對應，暫時回避了問題，但是問題的原因需要詳細的調查。這時候，ASH就是一個非常有效的情報。
為什么呢？
因為在這種情況下，無論是客戶還是Support工程師,最想知道的就是到底發生了啥問題。
ASH就是為了滿足這個需要而產生的，它可以提供兩種時間間隔(1秒和10秒)的Active Session的幾乎所有相關的信息。
下面先說一下ASH的內部設計吧。
參照上面的圖，我們來整理一下ASH情報的來源和處理過程。1. ?后臺進程MMNL(MMON Lite 即輕量化的MMON進程)，每1秒鐘1次(采集間隔由隱藏參數“_ash_sampling_interval”控制)把V$SESSION 和V$SESSION_WAIT的數據里的ACTIVE SESSION(非IDLE待機SESSION)轉存到V$ACTIVE_SESSION_HISTORY里。
2. ?V$ACTIVE_SESSION_HISTORY的數據存儲在SGA中的一個循環使用的Buffer里，大小用隱藏參數“_ash_size”控制。
3. ?Buffer里的記錄按照比例( 由隱藏參數“_ash_disk_filter_ratio”控制)被寫到磁盤上，可以通過DBA_HIST_ACTIVE_SESS_HISTORY查詢。
4. ?存到磁盤上的數據遵守AWR的保存Policy。
關于ASH機能一些隱藏參數，可以參照以下：Parameter Value
-------------------------------------------------- ----------
Description
----------------------------------------------------------------------------------------------------
_ash_sampling_interval 1000
Time interval between two successive Active Session samples in millisecs
_ash_size 1048618
To set the size of the in-memory Active Session History buffers
_ash_enable TRUE
To enable or disable Active Session sampling and flushing
_ash_disk_write_enable TRUE
To enable or disable Active Session History flushing
_ash_disk_filter_ratio 10
Ratio of the number of in-memory samples to the number of samples actually written to disk
_ash_eflush_trigger 66
The percentage above which if the in-memory ASH is full the emergency flusher will be triggered
_ash_sample_all FALSE
To enable or disable sampling every connected session including ones waiting for idle waits
_ash_dummy_test_param 0
Oracle internal dummy ASH parameter used ONLY for testing!
_ash_min_mmnl_dump 90
Minimum Time interval passed to consider MMNL Dump
_ash_compression_enable TRUE
To enable or disable string compression in ASH
_ash_progressive_flush_interval 300
ASH Progressive Flush interval in secs
那么如何利用ASH情報分析性能問題呢？
這個問題沒有固定答案，因為ASH是一種原始數據，只負責記錄SESSION在采樣時的狀態。所以ASH并不直接反映問題，只提供分析問題的材料。
也就是說，DBA或Support工程師必須先對問題分析，想定一個或多個問題發生的原因和劇本。然后在利用ASH數據找到支持自己設想的證據。
今天舉一個簡單的例子。
客戶報告3個APP Servers和兩個節點的RAC環境中，有一個APP Server的處理比另外兩個APP Servers的處理慢，但是發往3個APP Servers的處理本身沒有任何區別。
因為客戶是在APPLICATION 的畫面上確認到的這個問題，所以首先調查了APP Server端，但是沒有找到原因，于是APP Server的Support工程師懷疑DB端的問題，就向我們DB的Support發出了調查要求。
基于前面問題的描述，最直觀的反應就是這個問題和DB沒有關系，原因有二：第一是3個APP Servers發出的處理(SQL文)本身沒有區別；第二是DB端處理SQL文時只關注SQL的請求內容，不會關注是哪一臺APP Server發來的請求。
為了找到證據來證明上面的觀點，我首先假設這個問題慢的地方不在DB，而是APP Server本身或網絡延遲，而在DB端實際沒有任何延遲，3臺APP Servers的處理速度是一樣的。
然后我用下面的SQL文對延遲時間段內3臺APP Servers發出的所有SQL文進行了抽取和比較，結果如下：SQL> select SQL_ID,SQL_PLAN_HASH_VALUE,SQL_EXEC_ID,count(*)
from m_dba_hist_active_sess_history
where PROGRAM='JDBC Thin Client'
and MACHINE='APP Server Name'
group by SQL_ID,SQL_PLAN_HASH_VALUE,SQL_EXEC_ID
order by count(*) desc;
◆1號機(Slow Node)
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777258 115
aaaaaaaaaaaa 2617621828 16777220 69
bbbbbbbbbbbb 1192575627 33554439 34
cccccccccccc 1878459779 16777216 13
dddddddddddd 2703624694 16777216 7
dddddddddddd 2703624694 33554432 6
eeeeeeeeeeee 876643066 33554438 4
eeeeeeeeeeee 876643066 33554439 4
eeeeeeeeeeee 876643066 16777238 4
eeeeeeeeeeee 876643066 16777237 4
eeeeeeeeeeee 876643066 16777240 4
◆2號機
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777223 150
aaaaaaaaaaaa 2617621828 16777221 150
aaaaaaaaaaaa 2617621828 16777224 30
aaaaaaaaaaaa 2617621828 16777222 30
aaaaaaaaaaaa 2617621828 16777225 27
aaaaaaaaaaaa 2617621828 16777219 16
aaaaaaaaaaaa 2617621828 16777218 16
bbbbbbbbbbbb 3425641204 16777222 32
bbbbbbbbbbbb 3425641204 16777221 31
bbbbbbbbbbbb 3425641204 16777223 28
bbbbbbbbbbbb 3425641204 16777220 16
bbbbbbbbbbbb 3425641204 16777219 15
dddddddddddd 2703624694 33554437 7
dddddddddddd 2703624694 33554436 6
eeeeeeeeeeee 876643066 33554450 4
eeeeeeeeeeee 876643066 16777219 4
eeeeeeeeeeee 876643066 16777220 4
eeeeeeeeeeee 876643066 33554440 4
eeeeeeeeeeee 876643066 16777221 4
eeeeeeeeeeee 876643066 33554452 4
eeeeeeeeeeee 876643066 16777222 3
eeeeeeeeeeee 876643066 33554441 3
eeeeeeeeeeee 876643066 16777241 3
eeeeeeeeeeee 876643066 16777224 3
eeeeeeeeeeee 876643066 33554453 3
◆３號機
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777217 7
bbbbbbbbbbbb 3425641204 16777218 8
eeeeeeeeeeee 876643066 16777216 6
eeeeeeeeeeee 876643066 33554449 4
eeeeeeeeeeee 876643066 33554446 4
eeeeeeeeeeee 876643066 16777239 4
eeeeeeeeeeee 876643066 16777244 4
eeeeeeeeeeee 876643066 16777223 4
eeeeeeeeeeee 876643066 16777243 4
eeeeeeeeeeee 876643066 33554443 4
eeeeeeeeeeee 876643066 16777217 4
eeeeeeeeeeee 876643066 16777245 3
eeeeeeeeeeee 876643066 33554445 3
eeeeeeeeeeee 876643066 33554444 3
eeeeeeeeeeee 876643066 16777218 3
eeeeeeeeeeee 876643066 33554442 3
eeeeeeeeeeee 876643066 33554448 3
eeeeeeeeeeee 876643066 33554451 3
eeeeeeeeeeee 876643066 33554447 3
eeeeeeeeeeee 876643066 16777242 3
通過上面的比較，我們會發現相同的SQL文在客戶報告處理慢的1號機和不慢的2號機3號機相比，采樣時并沒有明顯的區別。因為一個采樣基本可以看作SQL文執行了10秒鐘。
這就證明了我們對DB端沒有區別，問題點也不在DB端的設想，剩下的就得讓APP Server和網絡的Support去調查了。
今天只是用一個小例子來簡單說明一下ASH的用法，以后我會分享更多的例子，歡迎關注。
2021/03/17 @ Dalian
總結
以上是生活随笔為你收集整理的oracle ash介绍,Oracle ---- 性能调查之ASH（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 汇编基础(三)
- 下一篇： Opencv 图片缩小尺寸原理