Oracle ASH記憶體強制Flush日誌解決一例

Oracle ASH（Active Session History）是作為細粒度的AWR報告，經常在我們進行效能調優過程中被應用到。和所有的監控手段一樣，ASH是建立在定時效能資料採樣收集，最後集中匯總分析的基礎上。ASH和AWR相比，採樣頻率更密碼編譯集，資料以活躍會話active session為中心。
 
在實際中，我們也可能會遇到與ASH有關的問題故障，本文簡單介紹一個案例，供將來有需要的朋友待查。

 

1、問題闡述

 

在巡檢過程中，發現一個11gR2庫夜間運行警示日誌異常。

 

SQL> select * from v$version;

 

BANNER

-----------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

CORE 11.2.0.3.0 Production

 

警示日誌資訊：

 

Wed Apr 16 02:54:04 2014

Archived Log entry 42964 added for thread 1 sequence 26964 ID 0x408fa96f dest 1:
 
Archived Log entry 42965 added for thread 1 sequence 26964 ID 0x408fa96f dest 5:
 
Wed Apr 16 02:54:28 2014

Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 67108864 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:
 
 select total_size,awr_flush_emergency_count from v$ash_info;

 

根據提示資訊，SQL檢查結果如下：

 

 

SQL> select total_size/1024/1024,awr_flush_emergency_count from v$ash_info;

 

TOTAL_SIZE/1024/1024 AWR_FLUSH_EMERGENCY_COUNT

-------------------- -------------------------

                  64                        1

 

2、問題分析

 

從警示日誌情況看，應該是Oracle內部自動調節機制的作用。進入11g之後，Oracle alert log的警示提示作用愈加明顯。對於一些自動診斷過程中出現的問題，都會作為提醒出現在日誌中。比如swap轉換，ash變化等。今天的ash emergency flush就是比較常見的一個。
 
 

筆者管理系統是一個典型的OLAP系統，白天DML操作不多，大都是查詢檢索和報表類操作。夜間通過一系列作業SQL來進行資料ETL過程。

上面日誌片段正是在夜間作業過程中產生，作業過程每兩分鐘組建記錄檔量約為1G。

從分析角度，Oracle在收集ASH過程中，頻度是很高的，通常為分鐘層級。如果收集之後就立即儲存入資料庫檔案，在效能上損耗是不容易被接受的。一種方法是構建在記憶體共用儲存中的專門buffer。定期或者確定激發條件將資料從記憶體中寫回到資料庫中。
 
從提示資訊中看，Oracle在負載比較大的情況下，會出現ASH資訊超過系統限制，進行了一次強制的緊急清空動作。Oracle建議，如果反覆出現這樣的情況，就建議調整_ash_size參數大小。
 
Oracle內部的確是存在參數_ash_size，作為隱含參數可以使用SQL進行查看。

 

SQL> select

  2  　　x.ksppinm name,

  3  　　y.ksppstvl value,

  4  　　y.ksppstdf isdefault,

  5  　　decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,

  6  　　decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj

  7  　　from

  8  　　sys.x$ksppi x,

  9  　　sys.x$ksppcv y

 10  　　where

 11  　　x.inst_id = userenv('Instance') and

 12  　　y.inst_id = userenv('Instance') and

 13  　　x.indx = y.indx and

 14      x.ksppinm ='_ash_size'

 15  　　order by

 16  　　translate(x.ksppinm, ' _', ' ');

 

NAME      VALUE      ISDEFAULT ISMOD      ISADJ

---------- ---------- --------- ---------- -----

_ash_size  1048618    TRUE      FALSE      FALSE

 

Ash size大小用於指定ash buffer（shared pool）。預設給定的是1048618 bytes，也就是1M。ASH工作採樣是以Active Session為中心的。如果系統處理操作過於頻繁，活躍使用者會話數量很多，這樣每次採樣的資料量就會超過系統空閑狀態。
 
隨之而來的就是記憶體中ash buffer的填滿，進而引發資料庫強制回寫資料，啟動DBWR進程讀寫動作。DBWR在寫入的時候，會佔用一部分系統資源，從整體看是效能瓶頸點。
 
 

4、解決問題

 

根據Oracle官方推薦的經驗做法，我們要調整ash size參數到一個適合大小範圍。當前ASH total size是64MB，按照適度寬鬆的原則，另外加入一半的冗餘量，也就是設定96M大小。
 
 

SQL> alter system set "_ash_size"=100663296;

System altered

 

判斷調整情況：

 

SQL> select

  2  　　x.ksppinm name,

  3  　　y.ksppstvl value,

  4  　　y.ksppstdf isdefault,

  5  　　decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,

  6  　　decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj

  7  　　from

  8  　　sys.x$ksppi x,

  9  　　sys.x$ksppcv y

 10  　　where

 11  　　x.inst_id = userenv('Instance') and

 12  　　y.inst_id = userenv('Instance') and

 13  　　x.indx = y.indx and

 14      x.ksppinm ='_ash_size'

 15  　　order by

 16  　　translate(x.ksppinm, ' _', ' ');

 

NAME      VALUE      ISDEFAULT ISMOD      ISADJ

---------- ---------- --------- ---------- -----

_ash_size  100663296  TRUE      SYSTEM_MOD FALSE

 

在第二天夜間作業執行過程中，警示資訊沒有再出現，故障解決。

 

5、結論

 

這個問題本身不大，而且根據Oracle的提示也比較容易解決問題。應該說，這種提示資訊不一定一出現就進行調整，Oracle一般建議ash強制重新整理在多次出現的時候才嘗試解決。但是，這個錯誤出現前，筆者曾經進行過SGA和PGA大小調整，應對不足情況。而且每天系統作業負載情況相同。所以，如果調整之後出現報錯，就會一直存在。這也就是為什麼筆者急於開始處理的原因。