Oracle ---- 性能調查之ASH（一）

時間 2021-03-19

標籤網絡 session ide 性能 spa 設計 code blog 進程欄目 Oracle 简体版

原文原文鏈接

在ORACLE性能問題調查時，有價值的診斷情報有不少：STATSPACK，AWR，ASH，SYSTEMSTATE DUMP等等。每一種都在特定的場景起到重要的做用。其中最多的一個場景就是問題發生後採用了緊急對應，暫時迴避了問題，可是問題的緣由須要詳細的調查。這時候，ASH就是一個很是有效的情報。網絡

爲何呢？session

由於在這種狀況下，不管是客戶仍是Support工程師,最想知道的就是到底發生了啥問題。
ASH就是爲了知足這個須要而產生的，它能夠提供兩種時間間隔（1秒和10秒）的Active Session的幾乎全部相關的信息。ide

下面先說一下ASH的內部設計吧。性能

參照上面的圖，咱們來整理一下ASH情報的來源和處理過程。spa

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情報分析性能問題呢？code

這個問題沒有固定答案，由於ASH是一種原始數據，只負責記錄SESSION在採樣時的狀態。因此ASH並不直接反映問題，只提供分析問題的材料。blog

也就是說，DBA或Support工程師必須先對問題分析，想定一個或多個問題發生的緣由和劇本。而後在利用ASH數據找到支持本身設想的證據。進程

今天舉一個簡單的例子。ip

客戶報告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