溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
前言
時間過的真快，技術人生系列·我和數據中心的故事已經來到了第六期，小y又和大家見面了！
小y今天要和大家分享的是一個綜合型問題的的分析和解決過程。
解決該類問題，只懂數據庫是不夠的，還需要掌握比較扎實的操作系統技能。
同時引出了另外一種不太常見形式的優化，內存優化。
由于今天要分享的問題具有普遍性，建議大家可以按照文中方法檢查自己的系統中有無類似問題。分享的最后將對該共性的風險進行總結和提示。
如果覺得分享的案例還不錯，麻煩親們抬手轉發一下,希望可以提醒和幫助到更多的客戶。
更多Oracle數據庫實戰經驗分享和風險提醒的首發，盡在“中亦安圖”公眾號！歡迎關注。
另外，近期有不少朋友問，小y所在團隊是否可以做一些線下的分享？
確實，如果可以把大家組織起來，哪怕是一個會議室或者一個咖啡廳，除了面對面的技術分享，還可以聊聊人生，興致來了還可以一起燒烤啤酒，結識更多的朋友，也是人生幸事！
既然大家有興趣，那我們就開始第一期線下分享吧！
有興趣參加北京、上海、廣州、深圳等地線下分享的朋友，可以給小y發郵件，郵箱是51994106@qq.com,或者加小y的微信(shadow-huang-bj),提供城市、姓名、電話、單位、職位等信息即可，當報名人數超過20人，我們就開始啟動北京、上海、廣州、深圳、杭州、南京等地的免費線下分享活動。另外，有興趣的可以加入QQ群227189100，我們以后會定期做一些線上的分享。
Part 1
問題來了
2015年12月28日，北京。
晚上8點，剛吃完晚飯，電話響起，是一位運營商客戶的電話。
“小y,出事了，今天下午17點到18點，xx數據庫監聽和實例crash，不過現在庫已經起來了。這個業務系統很重要，領導非常重視，務必要求查明原因。其他廠商都已經到了，暫時沒有查到問題。你們能不能馬上派個工程師到現場分析一下？爭取今晚就有個結論！”
接到電話后，小y立刻安排兄弟趕往現場。之后還了解到，上周也出現過類似的問題。
環境介紹：
操作系統 AIX 6.1 TL8, 64-bit
數據庫 ORACLE 11.2.0.3,2節點RAC
配置：16CPU 50G內存
Part 2
分析過程
過一會兒，收到日志，一下子來了精神，我們先來看看日志，確認下客戶提到的數據庫crash和監聽crash的問題。
2.1.1
數據庫alert.log
可以看到：
>>17:42:39，數據庫alert日志有關鍵報錯信息，負責GCS的進程LMS的調用有89秒沒有得到響應。意味著從17:41:10秒開始，數據庫就開始出現問題了。
>>接下來，就來到了18:02:48，直接轉到啟動數據庫的日志，沒有數據庫停止、被異常終止的日志，這20分鐘內alert日志沒有任何輸出。期間操作系統并沒有發生重啟現象。
原因初步分析：
導致LMS的調用沒有響應的最常見的原因是數據庫所在的Lpar的系統資源如內存/CPU出現瓶頸。而通常在操作系統資源緊張的情況下，會伴隨著以下表現：
>> CRS作為集群資源管理的進程，在檢測資源時可能也會出現超時的情況，從而啟動異常處理，例如將資源自動重啟
>> RAC節點之間的某些心跳檢測得不到響應的情況下，為了恢復整個RAC集群的對外服務能力，11g后將優先啟動MemberKill,即終止數據庫實例的方式嘗試恢復，如果memberKill無法解決問題，則升級為NodeKill,即重啟OS的方式來恢復整個集群的對外服務能力
接下來檢查CRSD進程的日志
從中可以看到，包括VIP/監聽等在內的資源，由于OS資源緊張的問題，檢測超時，繼而啟動了異常處理。
2.1.2
節點1 CRSD.LOG
從下圖可以看到：
17:42:30,CRSD檢測VIP的健康情況，10秒后，檢測超時，于是狀態變UNKNOWN（然后被CRSD嘗試重啟）
從下圖可以看到：
17:51:18秒，由于VIP宕，而監聽依賴于VIP，因此監聽被請求停止。
從下圖可以看到：
17:54:34,檢測到數據庫資源ora.XXDB.db被異常終止
2.1.3
ocssd.log
從上圖可以看到：
其實在2015-12-28 17:47:17，OCSSD進程就收到了節點2的Member kill request的請求，需要殺掉數據庫實例。實際上，到了18:02:48，數據庫才開始啟動。
這期間經過了長達15分鐘，說明數據庫服務器資源已經很緊張，能導致性能如此緩慢的，通常只有內存出現大量換頁。
從上述分析可以知道，事實上從17:41:10到17:42:39，數據庫節點1系統資源就開始出現了緊張，開始變得緩慢了！
2.2.1
查看CPU使用情況
可以看到：
CPU資源不是問題，CPU峰值并不高
2.2.2
查看內存換頁情況（pi/po）
可以看到:
NMON每5分鐘采樣一次，
17點39分的下一次采樣是17點44分，但是這次采樣根本沒有被采集出來！
這說明系統資源已經非常緊張！這是最重要的一個證據！
問題出在17點42分，由于采集間隔的緣故，沒有被采集到，也比較正常。
但不影響本次分析的總體判斷。
另外，不難發現，在出問題以前，pageSpace的利用率達到12.44！說明以前就出現了內存不足！小y建議大家，如果發現自家AIX平臺上出現pageSpace被使用的情況時，務必好好分析下內存的使用情況，否則將是一個大雷。
2.2.2
為什么會出現內存換頁？
小y看到該數據的時候，嚇了一跳！
出問題前，如16:24到17:29之間，數據庫服務器的計算內存（%comp）就已經長時間處于90%的高位了！這對于AIX來說，是非常危險的！對于計算內存，我們要盡量控制在80%以下，這樣的系統才是出于健康狀態的系統！
90%的計算內存已經接近內存換頁的臨界點！
當出現一些稍微大的內存的使用需求，則會使得系統出現內存換頁。
那么到底是誰觸發了換頁呢？
在小y看來，如果一面墻快倒了，那么誰碰倒了這面墻不重要了！所以這不是問題的關鍵。
同樣的17點44分本該顯示有一條記錄，卻沒打出來！
說明17點44分左右系統確實處于內存緊張狀態。
17點49分時，計算內存更是達到了97%！（44分已經異常，必定導致進程堆積，繼而加大內存的使用）
數據庫服務器內存大小為50G，客戶最開始的內存規劃如下
>> SGA配置25G
>> PGA配置為5G
>> 數據庫參數processes為2000，日常運行在1000個進程
數據庫對內存的占用可以使用下面的簡單公式來計算：
SGA + PGA+進程在OS級的消耗
正常情況下，11G版本數據庫，單個ORACLE服務進程的內存占用在3M，
因此平時內存的使用為25G+5G+1000*3M=33G，占Lpar內存的66%。
如果按照出現異常等待，2000個進程被調起來的情況，則內存的使用為25G+5G+2000*3M=36G，規劃偏大。
由于數據庫對內存的占用可以使用下面的簡單公式來計算：
SGA + PGA+進程在OS級的消耗
這里，SGA是個硬限制,PGA不是硬限制（無論工作區或非工作區都不是硬限制）
小y通過dba_hist_pgastat獲得pga的峰值，發現也就是5個G，沒有突破PGA的參數限制，那么最有可能的就是“進程在OS級的消耗”占的內存比較多了。
因此，小y馬上通過 procmap命令檢查單個進程的內存消耗:
發現ORACLE單個內存占用到了10M（將第二列加起來）
到了這里，小y已經知道答案了！
讀者朋友們，也可以停一下，把上述現象總結一下，再思考個幾分鐘，如果是你來接這個CASE，你會怎么繼續往下查呢？
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
不要走開后邊還有.....
那么內存用到了哪里呢？小y的做法很簡單，通過svmon –P命令可以看到內存占用的細節。
可以看到：
每個ORACLE服務進程work類型的獨占內存中， USLA heap部分占了1642個內存頁，而每頁4K，即多占6-7M。
事實上這是一個操作系統和數據庫的已知BUG。
中亦科技在其他數據中心已經遇到過好幾次該問題。
數據庫服務器內存大小為50G，客戶最開始的內存規劃如下
>> SGA配置25G
>> PGA配置為5G
>> 數據庫參數processes為2000，日常運行在1000個進程
我們現在再來看一下：
正常情況下：
11G版本數據庫，單個ORACLE服務進程的內存占用是10M而非3M！
因此平時內存的使用為25G+5G+1000*10M=40G，光數據庫就占了內存的80%！這是比較危險的！對于AIX平臺，數據庫占內存建議在50%-60%之間，因為操作系統kernel等還會使用內存，最多可使用到40%，比較常見的是kernel inode cache的使用。
如果按照出現異常等待，2000個進程被調起來的情況，則內存的使用為25G+5G+2000*10M=50G
到這里后，就簡單了。
小y在mos上以USLA做關鍵字搜索，以下就找到了對應的BUG.
下面的這篇note,是ORACLE官網上對于USLA heap導致單個進程多占7M內存，
從3M變成10M的BUG 13443029的描述。
11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)
這個問題是操作系統的一個缺陷，需要操作系統和數據庫同時安裝補丁才可以解決:
>> 對于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統和數據庫同時安裝補丁才可以解決。
>> 對于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統已經修復，只需在數據庫端安裝補丁13443029。
數據庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復。
Part 3
原因總結和建議
數據庫服務器內存大小為50G，內存規劃如下
SGA配置25G
PGA配置為5G
數據庫參數processes為2000
28日平均數據庫服務進程數為1000個左右
由于操作系統和數據庫的一個已知缺陷-- 11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)，導致一個空閑的數據庫服務進程在USLA部分多占了7M左右的私有內存。
因此數據庫整體占到了 25 G + 5G + 1000*10M=40G，即40G左右的計算內存，數據庫已經占到80%以上的內存（通常要控制在60%），加上kernel等內存的使用，數據庫平時運行在接近90%的計算內存的狀態。這使得數據庫服務器運行在內存高位下，當出現進程數增多、排序哈希等內存需求的時候，繼而出現內存換頁情況，將整體系統拖的異常緩慢。
內存緊張時本次故障的原因，最直接的證據如下：
NMON每5分鐘采樣一次，
17點39分的下一次采樣是17點44分，但是這次采樣沒有被采集出來！
這說明系統資源已經非常緊張！這是最重要的一個證據！
數據庫集群自身檢測到VIP/數據庫資源無響應的情況下，進行了異常處理，繼而導致監聽、VIP、數據庫實例宕的故障。
通過解決“操作系統和數據庫關于USLA的缺陷“以及對數據庫內存參數進行規劃，可減少內存的使用，使得系統運行在更健康的內存狀況下，從而從根本上解決該問題。
1） 安裝數據庫補丁13443029，使數據庫重新以shrsymtab這個選項來編譯，將USLA部分的7M內存減至幾十K，從而多騰出來7G左右的內存（如果以2000個進程算，則騰出來14G內存）
2） 將數據庫SGA內存sga_target參數從25G調小到20G。
調整說明：
經過兩個調整后，在沒有為lpar添加內存的情況下，
數據庫的內存規劃是 20G+5G+1000*3M=28G，如果算2000個進程跑滿的情況下，數據庫的內存規劃是 20G+5G+2000*3M=31G
從而使得系統內存資源更富余，不會因為一些私有內存的需求而出現換頁的情況。
Part 4
共性風險提醒
小y通過該案例，做出一些共性的風險提示：
不要低估一個空閑的Oracle服務進程所占用的內存帶來的影響！
大家再做內存規劃時，往往忽略了這一點！
如果您的數據庫版本是11GR2，并且運行在AIX6/7的版本上，那么您的系統中很可能存在過度消耗內存的問題，即一個Oracle服務進程比10G版本的時候要多出7M左右的內存，從而使得單個ORACLE進程從3M變到10M。這對于Oracle服務進程數較多的數據庫來說，是致命的。
例如，對于一個運行著2000個Oracle服務進程的數據庫而言，所占用的內存不是2000*3=6G，而是2000*10=20G，多出14G。多出的14G將會超出你的內存規劃，使數據庫運行在危險狀態下。是否命中該問題，可以參考文中分享的案例！
以下是ORACLE官網上對于USLA heap導致單個進程多占7M內存，
從3M變成10M的BUG 13443029的描述。
11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)
這個問題是操作系統的一個缺陷，需要操作系統和數據庫同時安裝補丁才可以解決:
>> 對于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統和數據庫同時安裝補丁才可以解決。
>> 對于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統已經修復，只需在數據庫端安裝補丁13443029。
數據庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復。
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.
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
