mysql awr flush_Oracle ASH内存强制Flush日志解决一例
Oracle ASH(Active Session History)是作為細粒度的AWR報告,經(jīng)常在我們進行性能調優(yōu)過程中被應用到。和所有的監(jiān)控手段一樣,A
Oracle ASH(Active Session History)是作為細粒度的AWR報告,經(jīng)常在我們進行性能調優(yōu)過程中被應用到。和所有的監(jiān)控手段一樣,ASH是建立在定時性能數(shù)據(jù)采樣收集,最后集中匯總分析的基礎上。ASH和AWR相比,采樣頻率更加密集,數(shù)據(jù)以活躍會話active session為中心。
在實際中,我們也可能會遇到與ASH有關的問題故障,本文簡單介紹一個案例,供將來有需要的朋友待查。
1、問題闡述
在巡檢過程中,發(fā)現(xiàn)一個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;
根據(jù)提示信息,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內(nèi)部自動調節(jié)機制的作用。進入11g之后,Oracle alert log的告警提示作用愈加明顯。對于一些自動診斷過程中出現(xiàn)的問題,都會作為提醒出現(xiàn)在日志中。比如swap轉換,ash變化等。今天的ash emergency flush就是比較常見的一個。
筆者管理系統(tǒng)是一個典型的OLAP系統(tǒng),白天DML操作不多,大都是查詢檢索和報表類操作。夜間通過一系列作業(yè)SQL來進行數(shù)據(jù)ETL過程。
上面日志片段正是在夜間作業(yè)過程中生成,作業(yè)過程每兩分鐘生成日志量約為1G。
從分析角度,Oracle在收集ASH過程中,頻度是很高的,通常為分鐘級別。如果收集之后就立即存儲入數(shù)據(jù)庫文件,在性能上損耗是不容易被接受的。一種方法是構建在內(nèi)存共享存儲中的專門buffer。定期或者確定激發(fā)條件將數(shù)據(jù)從內(nèi)存中寫回到數(shù)據(jù)庫中。
從提示信息中看,Oracle在負載比較大的情況下,會出現(xiàn)ASH信息超過系統(tǒng)限制,進行了一次強制的緊急清空動作。Oracle建議,如果反復出現(xiàn)這樣的情況,就建議調整_ash_size參數(shù)大小。
Oracle內(nèi)部的確是存在參數(shù)_ash_size,作為隱含參數(shù)可以使用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為中心的。如果系統(tǒng)處理操作過于頻繁,活躍用戶會話數(shù)量很多,這樣每次采樣的數(shù)據(jù)量就會超過系統(tǒng)空閑狀態(tài)。
隨之而來的就是內(nèi)存中ash buffer的填滿,,進而引發(fā)數(shù)據(jù)庫強制回寫數(shù)據(jù),啟動DBWR進程讀寫動作。DBWR在寫入的時候,會占用一部分系統(tǒng)資源,從整體看是性能瓶頸點。
4、解決問題
根據(jù)Oracle官方推薦的經(jīng)驗做法,我們要調整ash size參數(shù)到一個適合大小范圍。當前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
在第二天夜間作業(yè)執(zhí)行過程中,報警信息沒有再出現(xiàn),故障解決。
5、結論
本文原創(chuàng)發(fā)布php中文網(wǎng),轉載請注明出處,感謝您的尊重!
總結
以上是生活随笔為你收集整理的mysql awr flush_Oracle ASH内存强制Flush日志解决一例的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: java scanner 用不了_jav
- 下一篇: jmap java opts_jmap