分析發生在過去的資料庫效能問題

    轉載這篇文章的重點是想強調dba_hist_active_sess_history檢視在分析發生在過去的資料庫效能問題方面的重要性。

    在資料庫執行的過程中,我們有時會碰到資料庫hung住的問題,在這個時候很多人會選擇儘快讓它恢復正常而不是找出問題的root cause. 只有在問題被解決後,才意識到需要找到root cause來避免再次碰到相同的問題; 下面就講講如何分析發生在過去的資料庫效能問題 (這是一篇講方法論的blog,並沒有涉及到具體的案例, 稍後會有更多具體案例的Blog)

1.首先要申明的是, 對於這樣的問題,我們需要有一個正確的期望: 不一定能夠找到root cause, 這取決於發生問題時是否收集到了足夠的資訊.

2.梳理我們可以收集到的資訊, 一般的可以先檢查下面的日誌

    a)作業系統日誌, 參照文件 note 1349613.1 - How To Gather The OS Logs For Each Specific OS Platform

    b)資料庫alert log

    c)作業系統resource(CPU, memory, IO, swapping)使用的狀況, 推薦使用OSWbb (也可以是nmon等第三方工具)

   有的時候可以透過上面的日誌找到一些蛛絲馬跡, 比如有時alert log中會提示當時有過多的swap活動, 或提示生成了 enqueue/ row cache enqueue 等等的trace, 或提示diag後臺程式生成了systemstate dump trace, 那麼進一步就是要分析這些trace了;又比如OSWbb的ps輸出顯示當時有很多和資料庫無關的程式在消耗過多的CPU等等, 那麼這就證明問題和資料庫無關了.

3.接下來要收集發生問題時間段的AWR report和ASH report

    但是往往發生問題後資料庫被重起了,那麼很不幸AWR report很可能沒有發生問題時間段的資訊, 那麼這樣的AWR對我們分析這個問題就沒有意義了.

    ASH在大部分的情況下都是可以收集到發生問題時間段的資訊, 從中可以查到資料庫top的等待事件/session; 然後根據具體的問題,進行進一步的分析

4.如果之前收集到的資訊不足以找出問題的原因, 我們還有一個地方可以查,那就是 dba_hist_active_sess_history.

    這個檢視是用來生成ASH report的, 但是ASH report並沒有充分的利用這個檢視的強大之處,我們透過分析這個檢視的詳細資料,往往可以找到問題發生的原因.

可以從宏觀和微觀兩個維度來分析這個檢視(用11gR2的dba_hist_active_sess_history做例子):

比如

宏觀:

a)       可以按照一段時間內(發生問題的時間段)這些session等待的非空閒等待事件的型別做分類和求和,就可以知道哪種等待事件最嚴重

b)       可以按照一段時間內(發生問題的時間段)等待最嚴重事件的這些session所執行的SQL_ID來彙總求和,可以知道哪個SQL跟這個問題相關

…

微觀:

a). 對於某一條dba_hist_active_sess_history的記錄,我們可以知道這個session的SESSION_STATE是ON CPU還是WAITING, 如果是ON CPU,那麼這個session的event就無意義了; 如果是WAITING, 可以進一步看它的等待事件和BLOCKING_SESSION_STATUS, 如果它是被另一個session阻塞, 那麼BLOCKING_SESSION_STATUS這一列就會顯示為VALID或 GLOBAL. 然後再檢查BLOCKING_INST_ID和BLOCKING_SESSION找到阻塞這個session的是哪裡例項上的哪個session

b). 按照SAMPLE_TIME排序,我們可以找到問題發生的具體的時間點 (還是比較精確的)

c). 對某個session, dba_hist_active_sess_history還能揭示更多有用的資訊, 比如這個session當前執行的SQL語句的型別(SQL_OPCODE, SQL_OPNAME), 這個session是否在PARSE(IN_PARSE, IN_HARD_PARSE等), 它是什麼客戶端(PROGRAM, MODULE, ACTION, CLIENT_ID, MACHINE), 它使用的PGA(PGA_ALLOCATED), 它使用的temp空間大小(TEMP_SPACE_ALLOCATED)等等

    善於使用 dba_hist_active_sess_history能極大地幫助我們分析問題.但是也要注意dba_hist_active_sess_history不是萬能的: 如果最終阻塞別人的session當時並不是active的或者它並沒有被ASH記錄到dba_hist_active_sess_history中, 我們還是不能知道它當時處於一種什麼狀況.

    結語: 總之, 分析類似的問題就是充分挖掘已有的trace/日誌的過程, 但是因為缺少足夠的診斷日誌/資訊,很多時候還是無法找到問題發生的原因. 如果我們確實有需要找到root cause, 那麼在發生問題時就需要收集到足夠多的資訊. 比如hanganalyze, systemstate dump等

    轉載自：https://blogs.oracle.com/Database4CN/entry/%E5%A6%82%E4%BD%95%E5%88%86%E6%9E%90%E5%8F%91%E7%94%9F%E5%9C%A8%E8%BF%87%E5%8E%BB%E7%9A%84%E6%95%B0%E6%8D%AE%E5%BA%93%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98

--end--