前言
時(shí)間過的真快，技術(shù)人生系列·我和數(shù)據(jù)中心的故事已經(jīng)來到了第六期，小y又和大家見面了！
小y今天要和大家分享的是一個(gè)綜合型問題的的分析和解決過程。
解決該類問題，只懂?dāng)?shù)據(jù)庫(kù)是不夠的，還需要掌握比較扎實(shí)的操作系統(tǒng)技能。
同時(shí)引出了另外一種不太常見形式的優(yōu)化，內(nèi)存優(yōu)化。
由于今天要分享的問題具有普遍性，建議大家可以按照文中方法檢查自己的系統(tǒng)中有無類似問題。分享的最后將對(duì)該共性的風(fēng)險(xiǎn)進(jìn)行總結(jié)和提示。
如果覺得分享的案例還不錯(cuò)，麻煩親們抬手轉(zhuǎn)發(fā)一下,希望可以提醒和幫助到更多的客戶。
更多Oracle數(shù)據(jù)庫(kù)實(shí)戰(zhàn)經(jīng)驗(yàn)分享和風(fēng)險(xiǎn)提醒的首發(fā)，盡在“中亦安圖”公眾號(hào)！歡迎關(guān)注。
另外，近期有不少朋友問，小y所在團(tuán)隊(duì)是否可以做一些線下的分享？
確實(shí)，如果可以把大家組織起來，哪怕是一個(gè)會(huì)議室或者一個(gè)咖啡廳，除了面對(duì)面的技術(shù)分享，還可以聊聊人生，興致來了還可以一起燒烤啤酒，結(jié)識(shí)更多的朋友，也是人生幸事！
既然大家有興趣，那我們就開始第一期線下分享吧！
有興趣參加北京、上海、廣州、深圳等地線下分享的朋友，可以給小y發(fā)郵件，郵箱是51994106@qq.com,或者加小y的微信(shadow-huang-bj),提供城市、姓名、電話、單位、職位等信息即可，當(dāng)報(bào)名人數(shù)超過20人，我們就開始啟動(dòng)北京、上海、廣州、深圳、杭州、南京等地的免費(fèi)線下分享活動(dòng)。另外，有興趣的可以加入QQ群227189100，我們以后會(huì)定期做一些線上的分享。
Part 1
問題來了
2015年12月28日，北京。
晚上8點(diǎn)，剛吃完晚飯，電話響起，是一位運(yùn)營(yíng)商客戶的電話。
“小y,出事了，今天下午17點(diǎn)到18點(diǎn)，xx數(shù)據(jù)庫(kù)監(jiān)聽和實(shí)例crash，不過現(xiàn)在庫(kù)已經(jīng)起來了。這個(gè)業(yè)務(wù)系統(tǒng)很重要，領(lǐng)導(dǎo)非常重視，務(wù)必要求查明原因。其他廠商都已經(jīng)到了，暫時(shí)沒有查到問題。你們能不能馬上派個(gè)工程師到現(xiàn)場(chǎng)分析一下？爭(zhēng)取今晚就有個(gè)結(jié)論！”
接到電話后，小y立刻安排兄弟趕往現(xiàn)場(chǎng)。之后還了解到，上周也出現(xiàn)過類似的問題。
環(huán)境介紹：
操作系統(tǒng) AIX 6.1 TL8, 64-bit
數(shù)據(jù)庫(kù) ORACLE 11.2.0.3,2節(jié)點(diǎn)RAC
配置：16CPU 50G內(nèi)存
Part 2
分析過程
過一會(huì)兒，收到日志，一下子來了精神，我們先來看看日志，確認(rèn)下客戶提到的數(shù)據(jù)庫(kù)crash和監(jiān)聽crash的問題。
2.1.1
數(shù)據(jù)庫(kù)alert.log
可以看到：
>>17:42:39，數(shù)據(jù)庫(kù)alert日志有關(guān)鍵報(bào)錯(cuò)信息，負(fù)責(zé)GCS的進(jìn)程LMS的調(diào)用有89秒沒有得到響應(yīng)。意味著從17:41:10秒開始，數(shù)據(jù)庫(kù)就開始出現(xiàn)問題了。
>>接下來，就來到了18:02:48，直接轉(zhuǎn)到啟動(dòng)數(shù)據(jù)庫(kù)的日志，沒有數(shù)據(jù)庫(kù)停止、被異常終止的日志，這20分鐘內(nèi)alert日志沒有任何輸出。期間操作系統(tǒng)并沒有發(fā)生重啟現(xiàn)象。
原因初步分析：
導(dǎo)致LMS的調(diào)用沒有響應(yīng)的最常見的原因是數(shù)據(jù)庫(kù)所在的Lpar的系統(tǒng)資源如內(nèi)存/CPU出現(xiàn)瓶頸。而通常在操作系統(tǒng)資源緊張的情況下，會(huì)伴隨著以下表現(xiàn)：
>> CRS作為集群資源管理的進(jìn)程，在檢測(cè)資源時(shí)可能也會(huì)出現(xiàn)超時(shí)的情況，從而啟動(dòng)異常處理，例如將資源自動(dòng)重啟
>> RAC節(jié)點(diǎn)之間的某些心跳檢測(cè)得不到響應(yīng)的情況下，為了恢復(fù)整個(gè)RAC集群的對(duì)外服務(wù)能力，11g后將優(yōu)先啟動(dòng)MemberKill,即終止數(shù)據(jù)庫(kù)實(shí)例的方式嘗試恢復(fù)，如果memberKill無法解決問題，則升級(jí)為NodeKill,即重啟OS的方式來恢復(fù)整個(gè)集群的對(duì)外服務(wù)能力
接下來檢查CRSD進(jìn)程的日志
從中可以看到，包括VIP/監(jiān)聽等在內(nèi)的資源，由于OS資源緊張的問題，檢測(cè)超時(shí)，繼而啟動(dòng)了異常處理。
2.1.2
節(jié)點(diǎn)1 CRSD.LOG
從下圖可以看到：
17:42:30,CRSD檢測(cè)VIP的健康情況，10秒后，檢測(cè)超時(shí)，于是狀態(tài)變UNKNOWN（然后被CRSD嘗試重啟）
從下圖可以看到：
17:51:18秒，由于VIP宕，而監(jiān)聽依賴于VIP，因此監(jiān)聽被請(qǐng)求停止。
從下圖可以看到：
17:54:34,檢測(cè)到數(shù)據(jù)庫(kù)資源ora.XXDB.db被異常終止
2.1.3
ocssd.log
從上圖可以看到：
其實(shí)在2015-12-28 17:47:17，OCSSD進(jìn)程就收到了節(jié)點(diǎn)2的Member kill request的請(qǐng)求，需要?dú)⒌魯?shù)據(jù)庫(kù)實(shí)例。實(shí)際上，到了18:02:48，數(shù)據(jù)庫(kù)才開始啟動(dòng)。
這期間經(jīng)過了長(zhǎng)達(dá)15分鐘，說明數(shù)據(jù)庫(kù)服務(wù)器資源已經(jīng)很緊張，能導(dǎo)致性能如此緩慢的，通常只有內(nèi)存出現(xiàn)大量換頁(yè)。
從上述分析可以知道，事實(shí)上從17:41:10到17:42:39，數(shù)據(jù)庫(kù)節(jié)點(diǎn)1系統(tǒng)資源就開始出現(xiàn)了緊張，開始變得緩慢了！
2.2.1
查看CPU使用情況
可以看到：
CPU資源不是問題，CPU峰值并不高
2.2.2
查看內(nèi)存換頁(yè)情況（pi/po）
可以看到:
NMON每5分鐘采樣一次，
17點(diǎn)39分的下一次采樣是17點(diǎn)44分，但是這次采樣根本沒有被采集出來！
這說明系統(tǒng)資源已經(jīng)非常緊張！這是最重要的一個(gè)證據(jù)！
問題出在17點(diǎn)42分，由于采集間隔的緣故，沒有被采集到，也比較正常。
但不影響本次分析的總體判斷。
另外，不難發(fā)現(xiàn)，在出問題以前，pageSpace的利用率達(dá)到12.44！說明以前就出現(xiàn)了內(nèi)存不足！小y建議大家，如果發(fā)現(xiàn)自家AIX平臺(tái)上出現(xiàn)pageSpace被使用的情況時(shí)，務(wù)必好好分析下內(nèi)存的使用情況，否則將是一個(gè)大雷。
2.2.2
為什么會(huì)出現(xiàn)內(nèi)存換頁(yè)？
小y看到該數(shù)據(jù)的時(shí)候，嚇了一跳！
出問題前，如16:24到17:29之間，數(shù)據(jù)庫(kù)服務(wù)器的計(jì)算內(nèi)存（%comp）就已經(jīng)長(zhǎng)時(shí)間處于90%的高位了！這對(duì)于AIX來說，是非常危險(xiǎn)的！對(duì)于計(jì)算內(nèi)存，我們要盡量控制在80%以下，這樣的系統(tǒng)才是出于健康狀態(tài)的系統(tǒng)！
90%的計(jì)算內(nèi)存已經(jīng)接近內(nèi)存換頁(yè)的臨界點(diǎn)！
當(dāng)出現(xiàn)一些稍微大的內(nèi)存的使用需求，則會(huì)使得系統(tǒng)出現(xiàn)內(nèi)存換頁(yè)。
那么到底是誰(shuí)觸發(fā)了換頁(yè)呢？
在小y看來，如果一面墻快倒了，那么誰(shuí)碰倒了這面墻不重要了！所以這不是問題的關(guān)鍵。
同樣的17點(diǎn)44分本該顯示有一條記錄，卻沒打出來！
說明17點(diǎn)44分左右系統(tǒng)確實(shí)處于內(nèi)存緊張狀態(tài)。
17點(diǎn)49分時(shí)，計(jì)算內(nèi)存更是達(dá)到了97%?。?4分已經(jīng)異常，必定導(dǎo)致進(jìn)程堆積，繼而加大內(nèi)存的使用）
數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存大小為50G，客戶最開始的內(nèi)存規(guī)劃如下
>> SGA配置25G
>> PGA配置為5G
>> 數(shù)據(jù)庫(kù)參數(shù)processes為2000，日常運(yùn)行在1000個(gè)進(jìn)程
數(shù)據(jù)庫(kù)對(duì)內(nèi)存的占用可以使用下面的簡(jiǎn)單公式來計(jì)算：
SGA + PGA+進(jìn)程在OS級(jí)的消耗
正常情況下，11G版本數(shù)據(jù)庫(kù)，單個(gè)ORACLE服務(wù)進(jìn)程的內(nèi)存占用在3M，
因此平時(shí)內(nèi)存的使用為25G+5G+1000*3M=33G，占Lpar內(nèi)存的66%。
如果按照出現(xiàn)異常等待，2000個(gè)進(jìn)程被調(diào)起來的情況，則內(nèi)存的使用為25G+5G+2000*3M=36G，規(guī)劃偏大。
由于數(shù)據(jù)庫(kù)對(duì)內(nèi)存的占用可以使用下面的簡(jiǎn)單公式來計(jì)算：
SGA + PGA+進(jìn)程在OS級(jí)的消耗
這里，SGA是個(gè)硬限制,PGA不是硬限制（無論工作區(qū)或非工作區(qū)都不是硬限制）
小y通過dba_hist_pgastat獲得pga的峰值，發(fā)現(xiàn)也就是5個(gè)G，沒有突破PGA的參數(shù)限制，那么最有可能的就是“進(jìn)程在OS級(jí)的消耗”占的內(nèi)存比較多了。
因此，小y馬上通過 procmap命令檢查單個(gè)進(jìn)程的內(nèi)存消耗:
發(fā)現(xiàn)ORACLE單個(gè)內(nèi)存占用到了10M（將第二列加起來）
到了這里，小y已經(jīng)知道答案了！
讀者朋友們，也可以停一下，把上述現(xiàn)象總結(jié)一下，再思考個(gè)幾分鐘，如果是你來接這個(gè)CASE，你會(huì)怎么繼續(xù)往下查呢？
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
不要走開后邊還有.....
那么內(nèi)存用到了哪里呢？小y的做法很簡(jiǎn)單，通過svmon –P命令可以看到內(nèi)存占用的細(xì)節(jié)。
可以看到：
每個(gè)ORACLE服務(wù)進(jìn)程work類型的獨(dú)占內(nèi)存中， USLA heap部分占了1642個(gè)內(nèi)存頁(yè)，而每頁(yè)4K，即多占6-7M。
事實(shí)上這是一個(gè)操作系統(tǒng)和數(shù)據(jù)庫(kù)的已知BUG。
中亦科技在其他數(shù)據(jù)中心已經(jīng)遇到過好幾次該問題。
數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存大小為50G，客戶最開始的內(nèi)存規(guī)劃如下
>> SGA配置25G
>> PGA配置為5G
>> 數(shù)據(jù)庫(kù)參數(shù)processes為2000，日常運(yùn)行在1000個(gè)進(jìn)程
我們現(xiàn)在再來看一下：
正常情況下：
11G版本數(shù)據(jù)庫(kù)，單個(gè)ORACLE服務(wù)進(jìn)程的內(nèi)存占用是10M而非3M！
因此平時(shí)內(nèi)存的使用為25G+5G+1000*10M=40G，光數(shù)據(jù)庫(kù)就占了內(nèi)存的80%！這是比較危險(xiǎn)的！對(duì)于AIX平臺(tái)，數(shù)據(jù)庫(kù)占內(nèi)存建議在50%-60%之間，因?yàn)椴僮飨到y(tǒng)kernel等還會(huì)使用內(nèi)存，最多可使用到40%，比較常見的是kernel inode cache的使用。
如果按照出現(xiàn)異常等待，2000個(gè)進(jìn)程被調(diào)起來的情況，則內(nèi)存的使用為25G+5G+2000*10M=50G
到這里后，就簡(jiǎn)單了。
小y在mos上以USLA做關(guān)鍵字搜索，以下就找到了對(duì)應(yīng)的BUG.
下面的這篇note,是ORACLE官網(wǎng)上對(duì)于USLA heap導(dǎo)致單個(gè)進(jìn)程多占7M內(nèi)存，
從3M變成10M的BUG 13443029的描述。
11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)
這個(gè)問題是操作系統(tǒng)的一個(gè)缺陷，需要操作系統(tǒng)和數(shù)據(jù)庫(kù)同時(shí)安裝補(bǔ)丁才可以解決:
>> 對(duì)于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統(tǒng)和數(shù)據(jù)庫(kù)同時(shí)安裝補(bǔ)丁才可以解決。
>> 對(duì)于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統(tǒng)已經(jīng)修復(fù)，只需在數(shù)據(jù)庫(kù)端安裝補(bǔ)丁13443029。
數(shù)據(jù)庫(kù)補(bǔ)丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復(fù)。
Part 3
原因總結(jié)和建議
數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存大小為50G，內(nèi)存規(guī)劃如下
SGA配置25G
PGA配置為5G
數(shù)據(jù)庫(kù)參數(shù)processes為2000
28日平均數(shù)據(jù)庫(kù)服務(wù)進(jìn)程數(shù)為1000個(gè)左右
由于操作系統(tǒng)和數(shù)據(jù)庫(kù)的一個(gè)已知缺陷-- 11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)，導(dǎo)致一個(gè)空閑的數(shù)據(jù)庫(kù)服務(wù)進(jìn)程在USLA部分多占了7M左右的私有內(nèi)存。
因此數(shù)據(jù)庫(kù)整體占到了 25 G + 5G + 1000*10M=40G，即40G左右的計(jì)算內(nèi)存，數(shù)據(jù)庫(kù)已經(jīng)占到80%以上的內(nèi)存（通常要控制在60%），加上kernel等內(nèi)存的使用，數(shù)據(jù)庫(kù)平時(shí)運(yùn)行在接近90%的計(jì)算內(nèi)存的狀態(tài)。這使得數(shù)據(jù)庫(kù)服務(wù)器運(yùn)行在內(nèi)存高位下，當(dāng)出現(xiàn)進(jìn)程數(shù)增多、排序哈希等內(nèi)存需求的時(shí)候，繼而出現(xiàn)內(nèi)存換頁(yè)情況，將整體系統(tǒng)拖的異常緩慢。
內(nèi)存緊張時(shí)本次故障的原因，最直接的證據(jù)如下：
NMON每5分鐘采樣一次，
17點(diǎn)39分的下一次采樣是17點(diǎn)44分，但是這次采樣沒有被采集出來！
這說明系統(tǒng)資源已經(jīng)非常緊張！這是最重要的一個(gè)證據(jù)！
數(shù)據(jù)庫(kù)集群自身檢測(cè)到VIP/數(shù)據(jù)庫(kù)資源無響應(yīng)的情況下，進(jìn)行了異常處理，繼而導(dǎo)致監(jiān)聽、VIP、數(shù)據(jù)庫(kù)實(shí)例宕的故障。
通過解決“操作系統(tǒng)和數(shù)據(jù)庫(kù)關(guān)于USLA的缺陷“以及對(duì)數(shù)據(jù)庫(kù)內(nèi)存參數(shù)進(jìn)行規(guī)劃，可減少內(nèi)存的使用，使得系統(tǒng)運(yùn)行在更健康的內(nèi)存狀況下，從而從根本上解決該問題。
1） 安裝數(shù)據(jù)庫(kù)補(bǔ)丁13443029，使數(shù)據(jù)庫(kù)重新以shrsymtab這個(gè)選項(xiàng)來編譯，將USLA部分的7M內(nèi)存減至幾十K，從而多騰出來7G左右的內(nèi)存（如果以2000個(gè)進(jìn)程算，則騰出來14G內(nèi)存）
2） 將數(shù)據(jù)庫(kù)SGA內(nèi)存sga_target參數(shù)從25G調(diào)小到20G。
調(diào)整說明：
經(jīng)過兩個(gè)調(diào)整后，在沒有為lpar添加內(nèi)存的情況下，
數(shù)據(jù)庫(kù)的內(nèi)存規(guī)劃是 20G+5G+1000*3M=28G，如果算2000個(gè)進(jìn)程跑滿的情況下，數(shù)據(jù)庫(kù)的內(nèi)存規(guī)劃是 20G+5G+2000*3M=31G
從而使得系統(tǒng)內(nèi)存資源更富余，不會(huì)因?yàn)橐恍┧接袃?nèi)存的需求而出現(xiàn)換頁(yè)的情況。
Part 4
共性風(fēng)險(xiǎn)提醒
小y通過該案例，做出一些共性的風(fēng)險(xiǎn)提示：
不要低估一個(gè)空閑的Oracle服務(wù)進(jìn)程所占用的內(nèi)存帶來的影響！
大家再做內(nèi)存規(guī)劃時(shí)，往往忽略了這一點(diǎn)！
如果您的數(shù)據(jù)庫(kù)版本是11GR2，并且運(yùn)行在AIX6/7的版本上，那么您的系統(tǒng)中很可能存在過度消耗內(nèi)存的問題，即一個(gè)Oracle服務(wù)進(jìn)程比10G版本的時(shí)候要多出7M左右的內(nèi)存，從而使得單個(gè)ORACLE進(jìn)程從3M變到10M。這對(duì)于Oracle服務(wù)進(jìn)程數(shù)較多的數(shù)據(jù)庫(kù)來說，是致命的。
例如，對(duì)于一個(gè)運(yùn)行著2000個(gè)Oracle服務(wù)進(jìn)程的數(shù)據(jù)庫(kù)而言，所占用的內(nèi)存不是2000*3=6G，而是2000*10=20G，多出14G。多出的14G將會(huì)超出你的內(nèi)存規(guī)劃，使數(shù)據(jù)庫(kù)運(yùn)行在危險(xiǎn)狀態(tài)下。是否命中該問題，可以參考文中分享的案例！
以下是ORACLE官網(wǎng)上對(duì)于USLA heap導(dǎo)致單個(gè)進(jìn)程多占7M內(nèi)存，
從3M變成10M的BUG 13443029的描述。
11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)
這個(gè)問題是操作系統(tǒng)的一個(gè)缺陷，需要操作系統(tǒng)和數(shù)據(jù)庫(kù)同時(shí)安裝補(bǔ)丁才可以解決:
>> 對(duì)于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統(tǒng)和數(shù)據(jù)庫(kù)同時(shí)安裝補(bǔ)丁才可以解決。
>> 對(duì)于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統(tǒng)已經(jīng)修復(fù)，只需在數(shù)據(jù)庫(kù)端安裝補(bǔ)丁13443029。
數(shù)據(jù)庫(kù)補(bǔ)丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復(fù)。
For AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later, apply patch 13443029
For AIX 6.1 TL07 or AIX 7.1 TL01, install AIX 6.1 TL-07 APAR
IV09580, AIX 7.1 TL-01 APAR IV09541, and apply patch 13443029
For other AIX level, apply patch 10190759, this will disable Oracle's online patching mechanism
Note: as of 06/21/2012, fix for bug 13443029 or bug 10190759 are not included in any PSU and the interim patch is needed. Interim patch 10190759 exists on top of most PSU, and patch 13443029 on top of 11.2.0.3 does not conflict with 11.2.0.3.1 PSU and can be applied on top of both 11.2.0.3 base and 11.2.0.3.1 PSU.
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
