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

作者為:?

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

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

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

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

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

2. 現(xiàn)場號脈

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

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

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

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

可見，新應用軟件問題可能是導致RAC宕機的重要因素！

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

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

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

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

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

可是，待我仔細觀察，發(fā)現(xiàn)開發(fā)人員其實已經(jīng)設(shè)計了UPPER函數(shù)索引，而且也采集了統(tǒng)計信息，但為什么Oracle不走函數(shù)索引呢？正納悶之際，印度工程師主動告訴我Oracle Bug 14630247會導致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中修復，并且該Bug若爆發(fā)，應該有ORA-7445錯誤。但是，上述語句并沒有導致ORA-7445錯誤，而且該系統(tǒng)已經(jīng)是11.2.0.4版本，因此是否由于是Bug 14630247或Bug 14828235導致，我在現(xiàn)場尚無法判斷。于是建議針對該問題，請客戶再創(chuàng)建一個SR，由 Oracle GCS和研發(fā)部門確認這些Bug是否已經(jīng)在11.2.0.4 for Solaris平臺修復，或者是Bug再次爆發(fā)。但作為ACS現(xiàn)場服務團隊，我建議在應用層面采取一些Workaround措施來規(guī)避該問題，例如是否取消upper函數(shù)，或者取消or運算。

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

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

除了上述不良應用可能導致內(nèi)存消耗殆盡的問題之外，RAC環(huán)境本身是否有問題呢？于是，我接下來通過Oracle的cluvfy工具對RAC環(huán)境進行檢查，很快就發(fā)現(xiàn)更嚴重問題了！部分細節(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:~$

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

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

連環(huán)境參數(shù)都沒有配置好，就強行把11g RAC給安裝上去了，并帶病開始工作了。真牛啊，誰做的？客戶領(lǐng)導的回答有點支支吾吾，一會兒說是Oracle公司產(chǎn)品售前部門做的，一會兒又說是Oracle公司硬件部門做的。好了，別深究了，別讓領(lǐng)導難堪了。我猜想很可能是找一個第三方本地公司做的安裝，而該公司技術(shù)人員很可能連Oracle安裝文檔都沒有仔細閱讀，具體就是《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è)服務團隊和原廠專業(yè)服務團隊的差別，原廠技術(shù)人員起碼會仔細閱讀Oracle官方安裝文檔，更會以O(shè)racle RAC實施方法論為指導，結(jié)合Oracle若干最佳實踐經(jīng)驗，在RAC軟件和補丁安裝、高可用性配置、應用部署等方面展開全面深入的實施，確保數(shù)據(jù)庫RAC實施的高質(zhì)量。

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

于是，一方面我提出了重新安裝的建議，另一方面為降低對生產(chǎn)系統(tǒng)停機的影響，進一步提出了先安裝一個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)導一陣嘆息和苦衷：“系統(tǒng)剛上線還不到一個月，重新安裝如何給領(lǐng)導解釋？”“唉，你們要是早來一個月，上線前就發(fā)現(xiàn)環(huán)境問題就好了，那時候重新安裝沒問題?！?/p>

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

5. 更多的感和悟

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

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é)點使用不同的gcs_server_processes參數(shù)可能導致gc cr multi block request等待事件
6. Understand Oracle Validated Configurations
7. How many LMS processes for Oracle Rac 9i?
8. Oracle database 11g r2最新安裝體驗
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ù)核心感悟：又一次臭顯擺之后的感悟, 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com