中亦科技黃遠(yuǎn)邦技術(shù)人生（16） ——紅色警報(bào)--Oracle宕機(jī)潮來(lái)臨，快快行動(dòng)起來(lái)！

1

前言

2月14日，情人節(jié)前夕，某數(shù)據(jù)中心一套Oracle 11.2.0.4 RAC宕了！

隔了幾天，又有一套R(shí)AC宕了！

幾天后，緊接著又有一套R(shí)AC宕了...

作為運(yùn)維的你，聽到其他客戶出現(xiàn)這樣的宕機(jī)潮時(shí)，是不是心底會(huì)泛起一陣莫名的恐慌?

那么問(wèn)題來(lái)了，貴司的數(shù)據(jù)中心到會(huì)不會(huì)也將出現(xiàn)類似的宕機(jī)潮呢？

這些故障是什么原因引起的呢？

這股宕機(jī)潮會(huì)繼續(xù)瘋狂延續(xù)下去么…

如果不能及時(shí)找到問(wèn)題真相，那么小y相信，這股宕機(jī)潮還會(huì)繼續(xù)延續(xù)下去！

貴中心的Oracle數(shù)據(jù)庫(kù)也許正在越來(lái)越接近宕機(jī)了！可怕的是，你可能還沒(méi)有察覺到…

這絕對(duì)不是危言聳聽!

這是在一家超大型數(shù)據(jù)中心發(fā)生的真實(shí)故障，在不到兩周的時(shí)間里，三套不同Oracle數(shù)據(jù)庫(kù)先后出現(xiàn)了實(shí)例異常終止的情況！

無(wú)獨(dú)有偶，小y服務(wù)的其他客戶那也陸續(xù)出現(xiàn)了宕機(jī)的前兆!好在及時(shí)發(fā)現(xiàn)并處理。

眼看宕機(jī)潮來(lái)臨，看小y如何化繁為簡(jiǎn)，幫助客戶一起解開問(wèn)題的真相。

真相揭開后，您也許不難發(fā)現(xiàn)，這是一個(gè)共性的問(wèn)題！

因此小y不敢怠慢，趕緊拿出來(lái)與大家分享，拉響了這次紅色警報(bào)！

十六期，小y將帶領(lǐng)大家一起去經(jīng)歷一場(chǎng)數(shù)據(jù)中心Oracle數(shù)據(jù)庫(kù)宕機(jī)潮的分析之旅。

文章的最后，提供具體的警報(bào)和核查方法，還在猶豫什么呢？趕緊查一查吧！

2

問(wèn)題來(lái)啦

小y,出事了，今天有個(gè)系統(tǒng)，早上RAC宕了一個(gè)節(jié)點(diǎn)，晚上又宕了一個(gè)節(jié)點(diǎn)，操作系統(tǒng)沒(méi)有重啟，只是數(shù)據(jù)庫(kù)實(shí)例crash掉了！目前已經(jīng)開了SR，但現(xiàn)在原因還沒(méi)確定，領(lǐng)導(dǎo)很重視這個(gè)問(wèn)題，明天你能過(guò)來(lái)一趟一起查下么？領(lǐng)導(dǎo)希望明天就能查清問(wèn)題原因。

對(duì)了，這是一套11.2.0.4 RAC,打了最新的PSU的！

接到電話，小y來(lái)了精神。

來(lái)電的是國(guó)內(nèi)一家超大型的國(guó)有銀行，本身就擁有一批水準(zhǔn)很高的ORACLE DBA。

通常找到小y的問(wèn)題，都是些奇奇怪怪的復(fù)雜問(wèn)題，如果只懂?dāng)?shù)據(jù)庫(kù)，而對(duì)操作系統(tǒng)/中間件/存儲(chǔ)等方面缺乏足夠的了解的話，很多時(shí)候是無(wú)法解決他們的復(fù)雜問(wèn)題的。

看來(lái)，一場(chǎng)硬仗，在所難免...

3

開始分析

先看看數(shù)據(jù)庫(kù)alert日志:

第二天早上，到了客戶現(xiàn)場(chǎng)，首先客戶向我介紹了昨天發(fā)生故障的情況：2月12日早上9點(diǎn)左右，11.2.0.4的RAC節(jié)點(diǎn)1宕了，晚上22點(diǎn)，節(jié)點(diǎn)2 宕了。

客戶幫助登陸到系統(tǒng)后，小y首先檢查了數(shù)據(jù)庫(kù)的alert日志，如下圖所示：

不難看到：

2017/2/128:53:49,由于數(shù)據(jù)庫(kù)的后臺(tái)進(jìn)程ASMB與ASM實(shí)例通訊失敗，ASMB進(jìn)程終止了數(shù)據(jù)庫(kù)實(shí)例,因此，小y需要繼續(xù)檢查ASM的alert日志，以便查看asm實(shí)例是否先出現(xiàn)了問(wèn)題，才導(dǎo)致數(shù)據(jù)庫(kù)crash了。

緊接著查看ASM alert日志：

不難看到：

在數(shù)據(jù)庫(kù)crash前的幾十秒之前， 8:53:15,ASM實(shí)例的rbal后臺(tái)進(jìn)程，遇到了ORA-07445的錯(cuò)誤，rbal進(jìn)程core dump,因此pmon進(jìn)程終止了ASM實(shí)例。

也就是說(shuō)，ASM實(shí)例rbal進(jìn)程出現(xiàn)ORA-7445錯(cuò)誤，導(dǎo)致ASM實(shí)例終止，由于數(shù)據(jù)庫(kù)實(shí)例依賴ASM實(shí)例，因此數(shù)據(jù)庫(kù)實(shí)例被終止。ASM實(shí)例具體的ORA-7445錯(cuò)誤是：

小y剛一開始看到這個(gè)錯(cuò)誤的時(shí)候，無(wú)奈的搖了搖頭，遇上麻煩了！

為什么小y會(huì)有如此感慨呢？資深的DBA，也許看到這個(gè)錯(cuò)誤時(shí)，可能會(huì)同樣的感慨！

因?yàn)檫@個(gè)錯(cuò)誤出錯(cuò)的調(diào)用lwp_kill是一個(gè)太普通不過(guò)的調(diào)用了，在該函數(shù)core Dump的原因可能有一萬(wàn)種，甚至都不止，metalink上不會(huì)記錄所有的可能…..

不過(guò)，小y還是很有信心的，只要調(diào)整到修正學(xué)院派模式，未知問(wèn)題也可以很快查清。

不錯(cuò)，只要集中精力分析出這個(gè)ORA-7445 [__lwp_kill()+48] [SIGIOT]錯(cuò)誤的原因，也就解開了宕機(jī)潮系列問(wèn)題的真相。

4

不妙的開始

看到這里，小y和之前看過(guò)該問(wèn)題的幾個(gè)工程師做了一下簡(jiǎn)單的溝通。

溝通的結(jié)果是兩個(gè)字，不妙。

之前他們幾個(gè)比較資深的工程師已經(jīng)看過(guò)該問(wèn)題，也在metalink上找過(guò)是否有類似的問(wèn)題，結(jié)果顯示，通過(guò)call stack匹配，一樣的case有過(guò)一些，但case沒(méi)有直接的結(jié)論，客戶已經(jīng)開了一個(gè)SR到gcs，目前正在分析中..

客戶希望今天出一個(gè)大概的結(jié)果，時(shí)間緊急。

客戶他們了解小y的習(xí)慣，再緊急，也會(huì)先抽空去抽上一根煙…

小y和客戶打了個(gè)招呼后，便下樓抽煙去了。

5

正經(jīng)的科普一下

趁著抽煙的縫隙，小y縷了一下思路。

也許有些同學(xué)對(duì)上面的有些術(shù)語(yǔ)比較困惑，什么是call stack，什么是ora-600和ora-7445錯(cuò)誤。小y發(fā)現(xiàn)，很多DBA都是人云亦云，這里，小y稍微給大家科普下:

知識(shí)點(diǎn)大普及

知識(shí)點(diǎn)1：什么是ORA-600錯(cuò)誤？

有同學(xué)會(huì)說(shuō)，ORA-7445錯(cuò)誤和ORA-600錯(cuò)誤一樣，屬于ORACLE內(nèi)部錯(cuò)誤。依小y來(lái)看，這么理解其實(shí)并不準(zhǔn)確！ORA-600錯(cuò)誤是內(nèi)部錯(cuò)誤，但7445錯(cuò)誤則不盡然！

ORA-600是ORACLE源碼中捕獲的異常，通常發(fā)生在某個(gè)特定的函數(shù)，相對(duì)比較具體，通常是ORACLE BUG。

知識(shí)點(diǎn)2：什么是ORA-7445錯(cuò)誤？

ORA-7445錯(cuò)誤和ORA-600錯(cuò)誤就不一樣了。

當(dāng) ORACLE進(jìn)程在運(yùn)行過(guò)程中收到來(lái)自操作系統(tǒng)一個(gè)嚴(yán)重的信號(hào)signal，則會(huì)報(bào)ORA-7445錯(cuò)誤。操作系統(tǒng)自身會(huì)捕獲進(jìn)程的一些非法的操作，例如當(dāng)一個(gè)進(jìn)程嘗試往無(wú)效的內(nèi)存位置去寫，出于保護(hù)操作系統(tǒng)的目的，操作系統(tǒng)將會(huì)向進(jìn)程發(fā)送一個(gè)嚴(yán)重的信號(hào)，常見的例如SIGBUS和SIGSEGV信號(hào)，所以會(huì)看到進(jìn)程core Dump現(xiàn)象的出現(xiàn)。

ORA-7445錯(cuò)誤可以發(fā)生在代碼的任意位置，出錯(cuò)的精確位置需要通過(guò)core文件來(lái)定位 。

從這段話不難看出，ORA-7445錯(cuò)誤的可能性較多，本質(zhì)是操作系統(tǒng)向進(jìn)程發(fā)送一個(gè)嚴(yán)重的信號(hào)，那么原因既可能是數(shù)據(jù)庫(kù)的BUG，也有很大可能是來(lái)自操作系統(tǒng)的某些異常。

這也就是ORA-7445錯(cuò)誤的分析比ORA-600錯(cuò)誤更難的原因。

知識(shí)點(diǎn)3：什么是call stack?

我們?cè)谡務(wù)揵ug或缺陷defect的時(shí)候，都會(huì)有一個(gè)疑問(wèn)，這個(gè)BUG的觸發(fā)條件是什么呢?

BUG通常都是某一種特殊的場(chǎng)景下觸發(fā)的，call stack就是函數(shù)的調(diào)用軌跡，這個(gè)調(diào)用軌跡就表示了BUG的具體觸發(fā)場(chǎng)景。

這就是小y前面提到的，在小y之前，他們已經(jīng)通過(guò)核對(duì)call stack去匹配BUG了。

只不過(guò)可惜的是，MOS上出現(xiàn)過(guò)相同call stack的case沒(méi)有最后下結(jié)論，因此無(wú)法參考…

6

從call stack開始查找真相

小y接下來(lái)打開出現(xiàn)ORA-7445錯(cuò)誤的rbal進(jìn)程的trace文件，找到call stack部分,如下所示

首先找到ORA-7445錯(cuò)誤的第一個(gè)中括號(hào)出現(xiàn)的函數(shù)，即lwp_kill

也就是說(shuō)rbal進(jìn)程core dump是在__lwp_kill這個(gè)系統(tǒng)調(diào)用中發(fā)生的。

Lwp就是Light Weight process即輕量級(jí)進(jìn)程，kill就是終止。

細(xì)心的同學(xué)，可以看到，lwp_kill前面帶了兩個(gè)下劃線，說(shuō)明不是oracle代碼中自己調(diào)用的函數(shù)，而是函數(shù)內(nèi)部調(diào)用的函數(shù)，屬于遞歸的函數(shù)了。

那么小y是如何知道這些調(diào)用是什么意思的呢？

其實(shí)很簡(jiǎn)單，這些都是來(lái)自操作系統(tǒng)的標(biāo)準(zhǔn)調(diào)用，度娘或者google一下就好了。

Trace文件中，call stack的調(diào)用是從下往上看，下面的函數(shù)先執(zhí)行，上面的函數(shù)后執(zhí)行。這個(gè)錯(cuò)誤太普遍了！是一個(gè)廣義的錯(cuò)誤！很多地方異常，都可能調(diào)用lwp_kill來(lái)終止進(jìn)程。因此分析這個(gè)函數(shù)，沒(méi)有什么意義，我們需要繼續(xù)往下看，如下圖所示

1) 調(diào)起lwp_kill的函數(shù)是pthread_kill,這個(gè)函數(shù)的作用向某個(gè)線程傳遞一個(gè)信號(hào)，也是一個(gè)遞歸函數(shù)，繼續(xù)往下看

2) _raise，向正在執(zhí)行的程序發(fā)送一個(gè)信號(hào),raise調(diào)起了pthread_kill

3)abort()函數(shù),從名字看就是終止， abort()函數(shù)會(huì)導(dǎo)致進(jìn)程的異常終止，除非來(lái)自操作系統(tǒng)的進(jìn)程終止信號(hào)即SIGABRT信號(hào)被捕捉并且信號(hào)處理句柄沒(méi)有返回 _assert(),其作用是如果它的條件返回錯(cuò)誤,則終止程序執(zhí)行，簡(jiǎn)單來(lái)說(shuō)就是程序做某件事情，遇到了錯(cuò)誤，需要終止程序執(zhí)行。

到這里，不難看到，函數(shù)的調(diào)用軌跡是

這段call stack，用大白話來(lái)說(shuō)，就是:

rbal進(jìn)程在執(zhí)行過(guò)程中遇到了錯(cuò)誤，因此終止了rbal進(jìn)程。

那么到底遇到了什么錯(cuò)誤呢？為什么需要繼續(xù)往下看其他call stack

不難看到：

_Assert()是一個(gè)遞歸的調(diào)用，將其調(diào)起來(lái)的函數(shù)是clsuassertmsg。

這個(gè)函數(shù)不帶下劃線，是oracle代碼中自己的函數(shù)名，顯然在度娘或google就查不到了..

那么不妨就跟著小y來(lái)猜一猜吧。

拆開來(lái)看，即clsu+assertMsg,也就是遇到了某個(gè)錯(cuò)誤，assert表示遇到了某個(gè)錯(cuò)誤。

再往下看，是clsgpnp_oramemAlloc，不難看出，oramemAlloc就是分配內(nèi)存，和gpnp相關(guān)模塊分配內(nèi)存有關(guān)系。

結(jié)合前面的call stack,我們來(lái)總結(jié)一下:

Rbal進(jìn)程在執(zhí)行clsgpnp_oramemAlloc函數(shù)來(lái)進(jìn)行分配內(nèi)存的時(shí)候遇到了某個(gè)錯(cuò)誤，因此發(fā)生了coreDump,也就是ORA-7445錯(cuò)誤，繼而導(dǎo)致ASM和數(shù)據(jù)庫(kù)實(shí)例先后crash。

7

為什么內(nèi)存無(wú)法分配呢？

到這里，我們實(shí)際上已經(jīng)知道了，oracle在執(zhí)行到clsgpnp_oramemAlloc這處代碼的時(shí)候，出現(xiàn)了錯(cuò)誤，具體是什么錯(cuò)誤呢？這個(gè)才是關(guān)鍵??！但是，有辦法知道是什么錯(cuò)誤么？

oracle為我們拋出了一個(gè)lwp_kill的ORA-7445錯(cuò)誤，但是我們真正關(guān)心的是clsgpnp_oramemAlloc這個(gè)函數(shù)到底遇到了什么錯(cuò)誤！

如果trace里要告訴我們是什么錯(cuò)誤，那有多好??！太可惜了!?

很多人也許分析到了這里，就陷入僵局了!

實(shí)際上小y只讀了幾分鐘的trace文件，就找到問(wèn)題的真相了。

大家不防也可以停下來(lái)思考下一兩分鐘，如果是你，你會(huì)怎么往下查…

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

思考時(shí)間....別著急往下翻哦..

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

8

慢慢接近真相

小y的方法很簡(jiǎn)單，用正常人的思維/生活化的語(yǔ)言來(lái)分析就可以。

表面上，出現(xiàn)core dump時(shí)的調(diào)用是lwp_kill,但真正出現(xiàn)問(wèn)題的oracle函數(shù)是clsgpnp_oramemAlloc。顯然，我們需要知道這個(gè)函數(shù)去分配內(nèi)存的時(shí)候到底報(bào)了什么錯(cuò)誤??！記住，需要證據(jù)，而不是猜！

有人會(huì)說(shuō)，我們?cè)趖race中以clsgpnp_oramemAlloc關(guān)鍵字查找不就可以了么…

可惜的是，那你也許這么查找，最終會(huì)發(fā)現(xiàn)一無(wú)所獲…

是你錯(cuò)了么？

不是的！是你方法不對(duì)！

小y采用的方法是將clsgpnp_oramemAlloc關(guān)鍵字截取前半截（一會(huì)您就知道為什么了），

這里查找clsgpnp_oram關(guān)鍵字，結(jié)果如下

可以看到：

真正出現(xiàn)問(wèn)題的oracle函數(shù)是clsgpnp_oramemAlloc,

這個(gè)函數(shù)去分配內(nèi)存的時(shí)候報(bào)了無(wú)法分配120K內(nèi)存的錯(cuò)誤！failed to allocate 120024 bytes.

看到這張圖，大家理解為什么需要截?cái)嗾嬲e(cuò)誤的函數(shù)名來(lái)作為查找的關(guān)鍵字了吧！

因?yàn)楹瘮?shù)名字換行了，如果以整個(gè)函數(shù)作為關(guān)鍵字，則可能查找不到！

這算是小y為大家貢獻(xiàn)的一點(diǎn)小技巧和經(jīng)驗(yàn)提示吧。

這里，也許也有人說(shuō)：

為什么不能直接猜clsgpnp_oramemAlloc這個(gè)函數(shù)去分配內(nèi)存的時(shí)候報(bào)的錯(cuò)誤呢？

最可能的不就是無(wú)法分配內(nèi)存么？確實(shí)如此，但也不僅如此。

因?yàn)榉峙鋬?nèi)存出錯(cuò)，可能性太多了，絕不是你想象的無(wú)法分配內(nèi)存的那幾種可能！

還記得小y以前文章中曾經(jīng)提到過(guò)的修正學(xué)院派模式么？

如果采用猜的方法，結(jié)果是無(wú)法說(shuō)服客戶和自己，無(wú)法形成完整的證據(jù)鏈，是“野路子”的典型表現(xiàn)之一。小y這些年面試過(guò)不少人，結(jié)果不理想，絕大部分人其實(shí)都是野路子，野路子的解決問(wèn)題，典型的就是在解決問(wèn)題時(shí)東一榔頭，西一棒子，靠運(yùn)氣。而不是學(xué)院派的步步為營(yíng)。面對(duì)復(fù)雜問(wèn)題時(shí)，野路子就會(huì)抓襟見肘了。

9

真相浮出水面

Oracle的函數(shù)clsgpnp_oramemAlloc,去分配內(nèi)存的時(shí)候報(bào)了無(wú)法分配120K內(nèi)存的錯(cuò)誤！failedto allocate 120024 bytes.

到這里，相信大家一定躍躍欲試了！想試試自己的身手，畢竟看到了這個(gè)錯(cuò)誤后，問(wèn)題被進(jìn)一步縮小范圍了！

1） 是不是機(jī)器內(nèi)存不足導(dǎo)致clsgpnp_oramemAlloc函數(shù)無(wú)法分配內(nèi)存？

答案是NO，首先從監(jiān)控?cái)?shù)據(jù)/oswatcher中可以看到，機(jī)器內(nèi)存還很富余。

       2）是不是操作系統(tǒng)ulimit內(nèi)存方面設(shè)置的比較小呢？

       答案是NO，ulimit配置正常

難道我們方向錯(cuò)了？

有時(shí)候，看上去，我們快接近了事情的真相，但又可能與真相插肩而過(guò)？為什么呢

在這里，小y賣個(gè)關(guān)子，答案就在下方的空白后，讀者可自行選擇什么時(shí)候往下翻…

小y說(shuō)過(guò)，如果只懂?dāng)?shù)據(jù)庫(kù)，而對(duì)操作系統(tǒng)/中間件/存儲(chǔ)等方面缺乏足夠的了解的話，很多時(shí)候是無(wú)法解決大型數(shù)據(jù)中心那些復(fù)雜問(wèn)題的。

查看宕機(jī)前的RBAL進(jìn)程的內(nèi)存消耗，如下圖所示

這是一個(gè)HPUX 11.31 ia64的操作系統(tǒng)(實(shí)際上該問(wèn)題與操作系統(tǒng)無(wú)關(guān))，

我們調(diào)出glance的歷史，不難看到，Res Mem達(dá)到了4209480K，即4G左右。

聽到4G這個(gè)詞，是不是想到了些什么呢？沒(méi)錯(cuò)，像是一個(gè)限制！

從上圖可以看到，操作系統(tǒng)的maxdsize_64bit參數(shù)設(shè)置的正是4G，即單個(gè)進(jìn)程的data最大只能到4G！

為什么RBAL進(jìn)程內(nèi)存用那么多內(nèi)存？

顯然，RBAL進(jìn)程存在內(nèi)存泄露的情況。正常而言，rbal進(jìn)程的內(nèi)存在100M以上。

我們通過(guò)檢查歷史數(shù)據(jù)，確認(rèn)了rbal進(jìn)程存在內(nèi)存該情況！

是什么觸發(fā)rbal進(jìn)程內(nèi)存泄露呢？

通過(guò)分析和比對(duì)，發(fā)現(xiàn)該庫(kù)數(shù)據(jù)庫(kù)有一個(gè)和其他數(shù)據(jù)庫(kù)不一樣的地方：

ASMalert日志中頻繁的發(fā)生voting File relocation的情況，如下所示。

最終，在解決了voting File relocation的情況后，rbal進(jìn)程的內(nèi)存不再繼續(xù)增加，問(wèn)題得到了根本解決。之后，客戶自己也申請(qǐng)到了一個(gè)patch.。

10

宕機(jī)潮事件還原

通過(guò)閱讀ORA-7445的call stack,小y化繁為簡(jiǎn)，還原了事件的發(fā)生過(guò)程。

1、為什么ASM rbal進(jìn)程出現(xiàn) ORA-7445[lwp_kill]錯(cuò)誤后進(jìn)程core Dump?

因此ASM實(shí)例 rbal后臺(tái)進(jìn)程存在內(nèi)存泄露，當(dāng)內(nèi)存泄露到OS對(duì)單個(gè)進(jìn)程的限制之后，進(jìn)程無(wú)法分配內(nèi)存而crash，繼而先后導(dǎo)致asm實(shí)例和數(shù)據(jù)庫(kù)實(shí)例crash

2、為什么會(huì)導(dǎo)致宕機(jī)潮

因?yàn)閞bal進(jìn)程內(nèi)存泄露的速度差不多,在一個(gè)維護(hù)日中啟動(dòng)的多套數(shù)據(jù)庫(kù)，經(jīng)過(guò)小一年的時(shí)間后，也就差不多同時(shí)到了OS對(duì)單個(gè)進(jìn)程的限制,因此先后發(fā)生了“宕機(jī)潮”

事實(shí)上，在第一套出現(xiàn)宕機(jī)的時(shí)候，小y已經(jīng)協(xié)助客戶查明了ASM rbal進(jìn)程內(nèi)存泄露的問(wèn)題，只是沒(méi)來(lái)得及全面梳理和整改所有系統(tǒng)，在此期間又先后發(fā)生了另外兩套R(shí)AC的宕機(jī)。

3、一定會(huì)出現(xiàn)宕機(jī)么？

不一定，如果操作系統(tǒng)對(duì)單個(gè)系統(tǒng)的使用沒(méi)有上限，則不會(huì)出現(xiàn)宕機(jī)，但會(huì)出現(xiàn)rbal進(jìn)程將整個(gè)系統(tǒng)內(nèi)存耗盡的情況，如果不及時(shí)監(jiān)控，可能導(dǎo)致性能和無(wú)法telnet/ssh的情況。

簡(jiǎn)而言之，同一個(gè)問(wèn)題，但在不同的OS配置下會(huì)表現(xiàn)出不同的故障現(xiàn)象！

4、rbal進(jìn)程core dump一定是出現(xiàn)在clsgpnp_oramemAlloc整個(gè)函數(shù)么？

顯然，如果內(nèi)存泄露到了OS單個(gè)進(jìn)程的限制，無(wú)論哪個(gè)需要分配內(nèi)存的函數(shù)，都可能遇到無(wú)法分配內(nèi)存繼而coreDump的情況！因此，答案是不一定。這就是一個(gè)故障，可能有多個(gè)不同故障現(xiàn)象，但本質(zhì)都是一回事！

5、rbal進(jìn)程內(nèi)存泄露只發(fā)生在HPUX么？

NO！我們不僅在HPUX上發(fā)現(xiàn)了該問(wèn)題，其他客戶的AIX環(huán)境下，RBAL進(jìn)程的內(nèi)存已經(jīng)使用了8G，并且還在持續(xù)上升。這個(gè)問(wèn)題不區(qū)分平臺(tái)，目前確認(rèn)受到影響的版本是11.2.0.4!其他版本我們還在陸續(xù)確認(rèn)。

11

紅色警報(bào)響起！

詳細(xì)原因見上文“宕機(jī)潮事件還原”章節(jié)的分析

1、小y在這里代表中亦科技向大家鄭重提示一個(gè)較大的風(fēng)險(xiǎn)：

Oracle 11.2.0.4版本的RAC，ASM的rbal后臺(tái)進(jìn)程存在內(nèi)存泄露的情況，將可能導(dǎo)致宕機(jī)潮，目前已經(jīng)有多個(gè)客戶出現(xiàn)該情況，影響了包括HPUX/AIX/LINUX等在內(nèi)的操作系統(tǒng)。

2、建議

建議按照下列方法全面梳理是否存在該情況，并增加進(jìn)程一級(jí)內(nèi)存使用情況的監(jiān)控。

3、解決問(wèn)題的方法：

如果檢查有類似問(wèn)題，欲了解問(wèn)題的解決方法，

可以添加小y的微信，shadow-huang-bj

注明：加入中亦科技Oracle微信群

小y將在后續(xù)分享中第一時(shí)間在微信群以及”中亦安圖”公眾號(hào)中揭曉