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大小調整,應對不足情況。而且每天系統作業負載情況相同。所以,如果調整之後出現報錯,就會一直存在。這也就是為什麼筆者急於開始處理的原因。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28258625/viewspace-2072366/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Swift 5強制獨佔記憶體Swift記憶體
- mongodb釋放記憶體-切換日誌MongoDB記憶體
- 針對持久記憶體的後寫日誌記憶體
- Oracle聯機日誌檔案丟失解決方法一例Oracle
- Active Session History (ASH) performed an emergency flushSessionORM
- 日誌分析一例
- Redis 記憶體淘汰機制詳解Redis記憶體
- ARC記憶體管理機制詳解記憶體
- 圖解Java記憶體回收機制圖解Java記憶體
- alert日誌中出現ash size的警告
- DataGuard需要使用強制日誌的理由
- Oracle 日誌管理一例Oracle
- jvm記憶體設定及記憶體溢位、解決方案JVM記憶體溢位
- Redis的記憶體回收機制和記憶體過期淘汰策略詳解Redis記憶體
- 日誌導致jvm記憶體溢位相關問題JVM記憶體溢位
- 非同步日誌 vs. 記憶體對映檔案非同步記憶體
- JavaScript 記憶體機制JavaScript記憶體
- Swift 5將強制執行記憶體獨佔訪問Swift記憶體
- mysql之 日誌體系(錯誤日誌、查詢日誌、二進位制日誌、事務日誌、中繼日誌)MySql中繼
- 告別記憶體OOM,解決MySQL記憶體增長問題記憶體OOMMySql
- vertica記憶體不足的解決方案記憶體
- mongodb記憶體不足怎麼解決?MongoDB記憶體
- Java記憶體洩漏解決之道Java記憶體
- 一文解決記憶體屏障記憶體
- 解決記憶體溢位九法記憶體溢位
- LayaAir引擎學習日誌15----LayaAir記憶體效能分析AI記憶體
- MRv2記憶體監控強殺Container問題解決薦記憶體AI
- c語言強制記憶體轉化引發的問題C語言記憶體
- js記憶體回收機制JS記憶體
- javaScript 記憶體管理機制JavaScript記憶體
- Java記憶體管理機制Java記憶體
- 【AIX】AIX記憶體機制AI記憶體
- linux記憶體機制Linux記憶體
- Qt 記憶體管理機制QT記憶體
- jvm記憶體管理機制JVM記憶體
- object-c(oc)記憶體管理機制詳解Object記憶體
- mysql二進位制日誌詳解MySql
- shell指令碼:自動記憶體監控及日誌備份指令碼記憶體