作者為:? SHOUG成員 – ORACLE ACS高級顧問羅敏 現(xiàn)場直播救火過程 2014年8月初的某一天，突然接到東區(qū)服務(wù)銷售經(jīng)理電話：“老羅，你明天到上海出差，能否先到XX航空公司去一趟，他們一個(gè)重要系統(tǒng)宕機(jī)了。”據(jù)了解，該客戶沒有采購Oracle現(xiàn)場ACS服務(wù)，按Oracl

作者為:?

SHOUG成員 – ORACLE ACS高級顧問羅敏

1. 現(xiàn)場直播救火過程

2014年8月初的某一天，突然接到東區(qū)服務(wù)銷售經(jīng)理電話：“老羅，你明天到上海出差，能否先到XX航空公司去一趟，他們一個(gè)重要系統(tǒng)宕機(jī)了。”據(jù)了解，該客戶沒有采購Oracle現(xiàn)場ACS服務(wù)，按Oracle公司先有雞后有蛋的政策，我們是不能去現(xiàn)場做任何實(shí)質(zhì)性的服務(wù)工作的。但從國情出發(fā)，更考慮客戶感受和客戶關(guān)系，作為ACS服務(wù)售前顧問去現(xiàn)場協(xié)助分析和解決問題，并進(jìn)一步了解客戶現(xiàn)狀和需求，也是合情合理的，并不是趁火打劫哦，呵呵。于是，我決定調(diào)整行程，改簽第二天頭個(gè)航班，中午就飛到了上海。

在虹橋機(jī)場上了出租車之后，一個(gè)勁兒給師傅說抱歉的話，因?yàn)閹煾悼赡艿攘藥讉€(gè)小時(shí)，碰上我這個(gè)倒霉鬼，去機(jī)場附近的客戶現(xiàn)場只需要起步價(jià)。師傅還是非常敬業(yè)，頂著中午火熱的太陽，10分鐘就把我拉到了該航空公司的信息中心大樓。

待我到達(dá)現(xiàn)場時(shí)，客戶運(yùn)維部門領(lǐng)導(dǎo)早已是翹首以待，把我熱情引到會議室，更是把整個(gè)運(yùn)維部門和開發(fā)單位的幾十號人都召集到會議室，而且還有負(fù)責(zé)應(yīng)用開發(fā)的印度專家。于是，在客戶簡短地介紹了系統(tǒng)概況和故障情況之后，就讓我直接連入該系統(tǒng)，并把我電腦連接到大屏幕上，幾十雙眼睛開始齊刷刷地現(xiàn)場觀摩Oracle顧問如何救火了，老羅同志又要開始一次臭顯擺了，呵呵。

2. 現(xiàn)場號脈

說實(shí)在的，盡管已經(jīng)身經(jīng)百戰(zhàn)，但I(xiàn)T系統(tǒng)如此復(fù)雜，應(yīng)用更是如此變化多端，IT新技術(shù)也是層出不窮，沒有一個(gè)專家敢牛烘烘地說手到病除的。但是，分析診斷問題的思路和方式還是相通的，那就是先了解系統(tǒng)概況，然后再了解故障情況，特別是收集故障相關(guān)數(shù)據(jù)，再詢問故障前是否有應(yīng)用或環(huán)境的重大變更，再逐步分析和定位問題，并給出最終解決問題方式。以下就是與該系統(tǒng)和故障相關(guān)的上述幾方面具體情況：

• 平臺及架構(gòu)情況

運(yùn)行在2節(jié)點(diǎn)的SUN Solaris平臺；數(shù)據(jù)庫版本為11.2.0.4 RAC；數(shù)據(jù)庫容量達(dá)到1.6TB。

• 故障現(xiàn)象分析

2014-08-01 14：14左右， 實(shí)例1重啟；2014-08-01 14:28 實(shí)例2重啟；2014-08-01 15:15:44 節(jié)點(diǎn)一被驅(qū)逐。故障發(fā)生之前，節(jié)點(diǎn)1的內(nèi)存消耗非常高，達(dá)到了100%，并產(chǎn)生了大量SWAP操作。節(jié)點(diǎn)2的內(nèi)存消耗也達(dá)到了90%。但客戶沒有安裝OSWatcher，也就是沒有采集到故障前后的操作系統(tǒng)數(shù)據(jù)。同時(shí)，RAC、GI的alert.log、crsd.log等日志文件也沒有記錄下明顯的錯誤數(shù)據(jù)。

• 故障前變更情況

經(jīng)客戶介紹，該系統(tǒng)在8月1日之前應(yīng)用軟件安裝了新補(bǔ)丁，即新部署了一些應(yīng)用軟件。通過對宕機(jī)之前的13：00 – 14：00 AWR報(bào)告分析，這些新應(yīng)用軟件中的3條SQL語句非常消耗資源。RAC重啟之后，新部署的應(yīng)用軟件進(jìn)行了回退，目前RAC系統(tǒng)運(yùn)行平穩(wěn)。

可見，新應(yīng)用軟件問題可能是導(dǎo)致RAC宕機(jī)的重要因素！

• 應(yīng)用深入分析

由于新應(yīng)用很可能是導(dǎo)致RAC宕機(jī)的重要原因，而且負(fù)責(zé)該應(yīng)用模塊開發(fā)的印度專家也在現(xiàn)場，于是我們首先對其中一條SQL語句共同進(jìn)行了深入分析。限于篇幅，我們只摘取如下的主要部分：

首先，該語句非常消耗資源，Buffer Gets和Disk Reads都非常之高，運(yùn)行時(shí)間更是長達(dá)555秒。通過對該語句執(zhí)行計(jì)劃的分析，我們發(fā)現(xiàn)該語句對三個(gè)大表進(jìn)行全表掃描。而導(dǎo)致全表掃描的直接原因是語句中如下部分的UPPER函數(shù)的使用：

AND ((CUSDOCINF.DOCTYP = :2 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:3)) OR

(CUSDOCINF.DOCTYP = :4 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:5)))

事實(shí)上，當(dāng)我們?nèi)サ鬠PPER函數(shù)，或者將OR操作修改為in操作之后，Oracle執(zhí)行計(jì)劃非常合理，語句效率非常之高。

可是，待我仔細(xì)觀察，發(fā)現(xiàn)開發(fā)人員其實(shí)已經(jīng)設(shè)計(jì)了UPPER函數(shù)索引，而且也采集了統(tǒng)計(jì)信息，但為什么Oracle不走函數(shù)索引呢？正納悶之際，印度工程師主動告訴我Oracle Bug 14630247會導(dǎo)致Oracle優(yōu)化器不選擇函數(shù)索引，而是采用全表掃描。于是，我馬上通過Oracle相關(guān)網(wǎng)站分析了Bug 14630247及相關(guān)的Bug 14828235 ,特別是閱讀了《Bug 14828235 ORA-7445 [evaopn3] from query with Function based index and ORDER BY clause》之后，發(fā)現(xiàn)該Bug已經(jīng)在11.2.0.4中修復(fù)，并且該Bug若爆發(fā)，應(yīng)該有ORA-7445錯誤。但是，上述語句并沒有導(dǎo)致ORA-7445錯誤，而且該系統(tǒng)已經(jīng)是11.2.0.4版本，因此是否由于是Bug 14630247或Bug 14828235導(dǎo)致，我在現(xiàn)場尚無法判斷。于是建議針對該問題，請客戶再創(chuàng)建一個(gè)SR，由 Oracle GCS和研發(fā)部門確認(rèn)這些Bug是否已經(jīng)在11.2.0.4 for Solaris平臺修復(fù)，或者是Bug再次爆發(fā)。但作為ACS現(xiàn)場服務(wù)團(tuán)隊(duì)，我建議在應(yīng)用層面采取一些Workaround措施來規(guī)避該問題，例如是否取消upper函數(shù)，或者取消or運(yùn)算。

好了，與應(yīng)用相關(guān)的問題在現(xiàn)場只能暫時(shí)分析到此了。但這是否是導(dǎo)致上述故障的唯一因素呢？即是不是因?yàn)檫@些語句消耗了太多資源，而導(dǎo)致宕機(jī)呢？由于客戶沒有安裝OSWatcher，也就是無法獲取系統(tǒng)宕機(jī)時(shí)的操作系統(tǒng)數(shù)據(jù)，特別是內(nèi)存和進(jìn)程數(shù)據(jù)，因此，尚無法做出準(zhǔn)確判斷。

3. 發(fā)現(xiàn)了更嚴(yán)重問題

除了上述不良應(yīng)用可能導(dǎo)致內(nèi)存消耗殆盡的問題之外，RAC環(huán)境本身是否有問題呢？于是，我接下來通過Oracle的cluvfy工具對RAC環(huán)境進(jìn)行檢查，很快就發(fā)現(xiàn)更嚴(yán)重問題了！部分細(xì)節(jié)如下：

grid@ffpdb01:-bash:~$cluvfy comp sys -n all -p crs -verbose

Verifying system requirement

Check: Total memory

Node Name???? Available???????????????? Required????????????????? Status

————? ————————? ————————? ———-

ffpdb02?????? 96GB (1.00663296E8KB)???? 2GB (2097152.0KB)???????? passed

ffpdb01?????? 96GB (1.00663296E8KB)???? 2GB (2097152.0KB)???????? passed

Result: Total memory check passed

… …

Check: Hard limits for “maximum open file descriptors”

Node Name???????? Type????????? Available???? Required????? Status

—————-? ————? ————? ————? —————-

ffpdb02?????????? hard????????? 8192??? ??????65536???????? failed

ffpdb01?????????? hard????????? 8192????????? 65536???????? failed

Result: Hard limits check failed for “maximum open file descriptors”

… …

Check: Kernel parameter for “tcp_smallest_anon_port”

Node Name???? Current?????????????????? Required????????????????? Status

————? ————————? ————————? ———-

ffpdb02?????? 32768???????????????????? 9000????????????????????? failed (ignorable)

ffpdb01? ?????32768???????????????????? 9000????????????????????? failed (ignorable)

Result: Kernel parameter check failed for “tcp_smallest_anon_port”

Check: Kernel parameter for “tcp_largest_anon_port”

Node Name???? Current?????????????????? Required???????? ?????????Status

————? ————————? ————————? ———-

ffpdb02?????? 65535???????????????????? 65500???????????????????? failed (ignorable)

ffpdb01?????? 65535???????????????????? 65500???????????????????? failed (ignorable)

Result: Kernel parameter check failed for “tcp_largest_anon_port”

Check: Kernel parameter for “udp_smallest_anon_port”

Node Name???? Current?????????????????? Required????????????????? Status

————? ————————? ————————? ———-

ffpdb02?????? 32768???????????????????? 9000????????????????????? failed (ignorable)

ffpdb01?????? 32768???????????????????? 9000????????????????????? failed (ignorable)

Result: Kernel parameter check failed for “udp_smallest_anon_port”

Check: Kernel parameter for “udp_largest_anon_port”

Node Name???? Current?????????????????? Required????????????????? Status

————? ————————? ————————? ———-

ffpdb02?????? 65535???????????????????? 65500???????????????????? failed (ignorable)

ffpdb01?????? 65535???????????????????? 65500???????????????????? failed (ignorable)

Result: Kernel parameter check failed for “udp_largest_anon_port”

… …

Verification of system requirement was unsuccessful on all the specified nodes.

grid@ffpdb01:-bash:~$

我的媽呀，原來這個(gè)系統(tǒng)的操作系統(tǒng)核心參數(shù)和網(wǎng)絡(luò)參數(shù)都沒有滿足Oracle RAC安裝需求，這將嚴(yán)重導(dǎo)致Oracle GI和RAC運(yùn)行不正常！這很可能是導(dǎo)致RAC宕機(jī)的更重要原因。當(dāng)然，準(zhǔn)確而言，應(yīng)該是外部應(yīng)用壓力陡增，與RAC環(huán)境的上述內(nèi)部存在問題共同導(dǎo)致了宕機(jī)故障。

4. 客戶的糾結(jié)和痛苦

連環(huán)境參數(shù)都沒有配置好，就強(qiáng)行把11g RAC給安裝上去了，并帶病開始工作了。真牛啊，誰做的？客戶領(lǐng)導(dǎo)的回答有點(diǎn)支支吾吾，一會兒說是Oracle公司產(chǎn)品售前部門做的，一會兒又說是Oracle公司硬件部門做的。好了，別深究了，別讓領(lǐng)導(dǎo)難堪了。我猜想很可能是找一個(gè)第三方本地公司做的安裝，而該公司技術(shù)人員很可能連Oracle安裝文檔都沒有仔細(xì)閱讀，具體就是《Oracle? Grid Infrastructure Installation Guide11g Release 2 (11.2) for Oracle Solaris》，更具體就是該文檔中的“2.10 Verifying UDP and TCP Kernel Parameters”、“2.11 Checking Resource Limits for Solaris”等小節(jié)。唉，很可能是第三方公司技術(shù)人員在百度、Google中隨便找了篇簡潔版的RAC安裝短文，就在航空公司這么重要的系統(tǒng)上開練了。

這就是非專業(yè)服務(wù)團(tuán)隊(duì)和原廠專業(yè)服務(wù)團(tuán)隊(duì)的差別，原廠技術(shù)人員起碼會仔細(xì)閱讀Oracle官方安裝文檔，更會以O(shè)racle RAC實(shí)施方法論為指導(dǎo)，結(jié)合Oracle若干最佳實(shí)踐經(jīng)驗(yàn)，在RAC軟件和補(bǔ)丁安裝、高可用性配置、應(yīng)用部署等方面展開全面深入的實(shí)施，確保數(shù)據(jù)庫RAC實(shí)施的高質(zhì)量。

現(xiàn)在怎么辦？是否直接修改幾個(gè)內(nèi)存unlimited參數(shù)和TCP、UDP參數(shù)就能解決問題，確保RAC不宕機(jī)了嗎？作為現(xiàn)場工程師，畢竟不是產(chǎn)品直接研發(fā)者，我無法給出這種承諾。于是，建議客戶通過SR進(jìn)一步尋求Oracle后臺服務(wù)團(tuán)隊(duì)和產(chǎn)品研發(fā)部門的確認(rèn)。但是基于個(gè)人以往類似經(jīng)驗(yàn)，最好的辦法是把環(huán)境參數(shù)重新配置好之后，把RAC系統(tǒng)重新安裝一遍。

于是，一方面我提出了重新安裝的建議，另一方面為降低對生產(chǎn)系統(tǒng)停機(jī)的影響，進(jìn)一步提出了先安裝一個(gè)Data Guard 環(huán)境，將現(xiàn)有生產(chǎn)系統(tǒng)數(shù)據(jù)切換到Data Guard環(huán)境，再重新安裝現(xiàn)有生產(chǎn)系統(tǒng)的11g RAC，并切換回11g RAC的建議。但我這些重新安裝建議一出口，立馬引來客戶領(lǐng)導(dǎo)一陣嘆息和苦衷：“系統(tǒng)剛上線還不到一個(gè)月，重新安裝如何給領(lǐng)導(dǎo)解釋？”“唉，你們要是早來一個(gè)月，上線前就發(fā)現(xiàn)環(huán)境問題就好了，那時(shí)候重新安裝沒問題。”

還有更糾結(jié)、更痛苦的問題：“羅工，你們Oracle公司能提供這種證據(jù)嗎？證明我們這次RAC宕機(jī)，就是因?yàn)榄h(huán)境參數(shù)配置不合理導(dǎo)致的？”。這如何證明啊？OSWatcher也沒有安裝，其它日志文件也沒有捕獲到有價(jià)值的信息。更重要的是，根據(jù)以往經(jīng)驗(yàn)，若發(fā)現(xiàn)Oracle軟件安裝都有問題，Oracle后臺根本不會繼續(xù)進(jìn)行進(jìn)一步的分析和診斷，一定會建議客戶重新安裝軟件之后再說。是啊，若A本身就錯了，基于A的B也跟著出錯了。那Oracle停止分析B，要求先糾正A，再看B的運(yùn)行情況，太符合邏輯了。

5. 更多的感和悟

除了上述對原廠和第三方廠商在RAC安裝和實(shí)施方面的專業(yè)性和非專業(yè)性感慨之外，更多的感悟還有：

• 千萬別小看Oracle軟件安裝，特別是集群和RAC安裝，這的確是一項(xiàng)非常專業(yè)化的工作。一個(gè)環(huán)境參數(shù)配置不合理，很可能給系統(tǒng)埋下深深的隱患。
• 遇到問題和故障的時(shí)候，還是應(yīng)該求真務(wù)實(shí)，尊重客觀規(guī)律。不應(yīng)該過多考慮面子，尤其是領(lǐng)導(dǎo)的評價(jià)。把一個(gè)事情做得扎扎實(shí)實(shí)、完完美美，雖然可能付出很大的代價(jià)，但最終還是很有面子，領(lǐng)導(dǎo)也會滿意的，呵呵。
• 為Oracle服務(wù)部門再做個(gè)推銷，呵呵。Oracle各種專業(yè)化的服務(wù)部門，無論是后臺提供標(biāo)準(zhǔn)服務(wù)的PS部門，還是前臺提供現(xiàn)場服務(wù)的ACS部門，都是專業(yè)化的團(tuán)隊(duì)，既相互合作，又相互補(bǔ)充，對客戶都是有價(jià)值的，都是不可或缺的。以該案例為例，后臺PS部門可以充分發(fā)揮產(chǎn)品實(shí)施分析和與研發(fā)部門溝通的優(yōu)勢，而前臺ACS部門則通過現(xiàn)場與客戶溝通，了解更多系統(tǒng)和應(yīng)用背景，并幫助客戶與PS部門溝通，共同推進(jìn)問題的分析和解決。
• 更多的感和悟留給大家… …

2014年10月6日

Related posts:

1. Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟：Clusterware是成熟產(chǎn)品嗎?
2. Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟：自動掃描SQL語句工具？
3. Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟：分表還是分區(qū)？
4. Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟：牛! 11g的自動調(diào)優(yōu)和SQL Profile
5. 【Oracle RAC調(diào)優(yōu)】RAC多節(jié)點(diǎn)使用不同的gcs_server_processes參數(shù)可能導(dǎo)致gc cr multi block request等待事件
6. Understand Oracle Validated Configurations
7. How many LMS processes for Oracle Rac 9i?
8. Oracle database 11g r2最新安裝體驗(yàn)
9. Oracle RDBMS Server 11gR2 Preinstall RPM For Oracle Linux 6
10. Oracle Recommended Kernel Parameter settings for HP Itanium v3 11.31

原文地址：Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟：又一次臭顯擺之后的感悟, 感謝原作者分享。

總結(jié)

以上是生活随笔為你收集整理的Oracle Acs资深顾问罗敏 老罗技术核心感悟：又一次臭显摆之后的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。