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

作者為:?

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

1. 現場直播救火過程

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

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

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

2. 現場號脈

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

運行在2節點的SUN Solaris平臺；數據庫版本為11.2.0.4 RAC；數據庫容量達到1.6TB。

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

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

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

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

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

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

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

事實上，當我們去掉UPPER函數，或者將OR操作修改為in操作之后，Oracle執行計劃非常合理，語句效率非常之高。

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

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

3. 發現了更嚴重問題

除了上述不良應用可能導致內存消耗殆盡的問題之外，RAC環境本身是否有問題呢？于是，我接下來通過Oracle的cluvfy工具對RAC環境進行檢查，很快就發現更嚴重問題了！部分細節如下：

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:~$

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

4. 客戶的糾結和痛苦

連環境參數都沒有配置好，就強行把11g RAC給安裝上去了，并帶病開始工作了。真牛啊，誰做的？客戶領導的回答有點支支吾吾，一會兒說是Oracle公司產品售前部門做的，一會兒又說是Oracle公司硬件部門做的。好了，別深究了，別讓領導難堪了。我猜想很可能是找一個第三方本地公司做的安裝，而該公司技術人員很可能連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”等小節。唉，很可能是第三方公司技術人員在百度、Google中隨便找了篇簡潔版的RAC安裝短文，就在航空公司這么重要的系統上開練了。

這就是非專業服務團隊和原廠專業服務團隊的差別，原廠技術人員起碼會仔細閱讀Oracle官方安裝文檔，更會以Oracle RAC實施方為指導，結合Oracle若干最佳實踐經驗，在RAC軟件和補丁安裝、高可用性配置、應用部署等方面展開全面深入的實施，確保數據庫RAC實施的高質量。

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

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

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

5. 更多的感和悟

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

2014年10月6日

Related posts:

1. Oracle Acs資深顧問羅敏 老羅技術核心感悟：Clusterware是成熟產品嗎?
2. Oracle Acs資深顧問羅敏 老羅技術核心感悟：自動掃描SQL語句工具？
3. Oracle Acs資深顧問羅敏 老羅技術核心感悟：分表還是分區？
4. Oracle Acs資深顧問羅敏 老羅技術核心感悟：牛! 11g的自動調優和SQL Profile
5. 【Oracle RAC調優】RAC多節點使用不同的gcs_server_processes參數可能導致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資深顧問羅敏 老羅技術核心感悟：又一次臭顯擺之后的感悟, 感謝原作者分享。

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