春風輕輕吹走了冬日里的寒氣，又到了一年最美的花季，伴隨著溫暖的陽光 老K 再次與大家相見！此次的回歸老K不僅會繼續(xù)和大家分享一些自己處理過的小案例，更優(yōu)化了技術交流模塊，希望在探討的過程中大家可以提高技術等級的同時，也能領略到中亦DBA團隊獨有的匠人精神。

發(fā)展壯大離不開廣大客戶長期以來的信賴與支持，我們將始終秉承“誠信為本、服務至上”的服務理念，堅持“二合一”的優(yōu)良服務模式，真誠服務每家企業(yè)，認真做好每個細節(jié)，不斷完善自我，成就企業(yè)，實現(xiàn)共贏。行業(yè)涉及成都木制涼亭等，在重慶網(wǎng)站建設公司、成都營銷網(wǎng)站建設、WAP手機網(wǎng)站、VI設計、軟件開發(fā)等項目上具有豐富的設計經(jīng)驗。

問題來了

      某一日的清晨，客戶打來電話稱巡檢時發(fā)現(xiàn)關鍵系統(tǒng)數(shù)據(jù)庫節(jié)點無法連接，原數(shù)據(jù)庫為 4 節(jié)點 RAC ，現(xiàn)少一節(jié)點，擔心業(yè)務高峰 3 個節(jié)點數(shù)據(jù)庫無法承擔業(yè)務高峰的壓力。這種情況需要盡快處理，所以老 K 選擇以最快的遠程支持方式解決問題。

問題分析

環(huán)境描述

系統(tǒng)： linux

數(shù)據(jù)庫：服務器上存在多個數(shù)據(jù)庫實例 p1 和 x1 （此處 p1 和 x1 為化名）

現(xiàn)象描述

本地使用 sqlplus 登錄到 x1 數(shù)據(jù)庫發(fā)現(xiàn)無法登錄到正常狀態(tài)：

而我 們在本地登錄 到 p1 數(shù)據(jù)庫，則一切正常，無明顯問題 ：

分析步驟小1：

   查看 alert 日志，了解到數(shù)據(jù)庫從前一天 18 點就開始有報錯；

   從日志看起來，問題似乎很簡單， oracle 運行過程中，組發(fā)生了改變：啟動時的組為 501 （ oinstall ），當前組卻變?yōu)榱? 503 （ asmadmin ）；同時，我們也可以從 alert 所在目錄相關 trace 文件的屬性變化來確認這一點：

   在 18:43 產(chǎn)生或更新的 trace 文件還是 oracle:oinstall 的屬主，而到了 18:44 ，新產(chǎn)生或更新的 trace 文件便成了 oracle:asmadmin 屬主。

知識點：

問： 在 UNIX/LINUX 環(huán)境中， oracle 數(shù)據(jù)庫啟動后存在許多后臺進程和前臺進程，雖然相關進程產(chǎn)生一些 trace 文件也是常有的事情，但是真正是什么決定了 oracle 相關進程的屬性呢？

答：通常來說，oracle的后臺進程的調用是依賴于$ORACLE_HOME/bin/oracle這個二進制文件，但它從遠端連入而分配的服務器進程（server process）相關屬主的屬性則是繼承自listener進程，而listener進程的屬主屬性同樣是進程自其啟動的用戶（分oracle用戶和grid用戶）$ORACLE_HOME/bin/oracle的屬主屬性。

分析步驟小2：

   這樣，我們就可以查看 $ORACLE_HOME/bin/oracle 這個文件的屬主情況：

   老 K 在 2 月 10 日查看發(fā)現(xiàn) oracle 文件的屬主是 oracle ，屬組是 asmadmin ，它的上次修改時間是 12 月 10 日，對比起來相隔久遠；然而我們關注的文件屬組 / 屬主的變化，是不會影響到其顯示的修改時間的，只有修改內容或替換文件才會出現(xiàn)文件修改時間的變化。下一步我們就可以使用如圖中命令來查看文件屬性變化的時間：

   顯而易見，文件屬主 / 屬組的改變正是在 2 月 9 日，這樣基本全部對應，就可以合理的推斷出： oracle 文件的屬主在 2 月 9 日發(fā)生了變化，隨后數(shù)據(jù)庫即產(chǎn)生報錯，也就是實際上這個數(shù)據(jù)庫實例自前一天的晚上就不可用了，只是到第二天早上才發(fā)現(xiàn)問題，那解決問題的方式就簡單多了，重啟數(shù)據(jù)庫！因為無法正常登錄數(shù)據(jù)庫（連 sysdba 也無法登錄），就不得不直接 kill 掉數(shù)據(jù)庫實例的關鍵進程，然后再正常啟動數(shù)據(jù)庫，一切又再次恢復正常。

   按照上述步驟分析起來也不是什么麻煩問題，大家或許會想即使我們不懂詳細原因，看到數(shù)據(jù)庫沒法用了，直接使用重啟大法，這個問題不也輕易的就解決了嗎？難道還需要理解這個問題的本質嗎？

在這里，老K有話說！ ↓↓↓↓↓↓↓↓

         既然大家選擇要走技術的道路，最重要的是保持一顆持久的好奇心，尋找答案的過程予我們也是進益，不斷的研究即是不斷的提高，永無止境的探索，才是前進路上的唯一指引。當然最重要的是在保證生產(chǎn)環(huán)境安全并且合規(guī)操作的前提下 ！

難題首現(xiàn)

        OK ，言歸正傳我們繼續(xù)來說問題，前面雖然簡述了一些，其實不難發(fā)現(xiàn)這里有兩個重要的疑問還沒有解答 ：

為什么 x1 實例存在問題，而 p1 實例卻沒有受到影響呢？

  老 K 首先猜想到的就是：“是不是 p1 實例的啟動是在 oracle 文件的屬組改變之后呢”？于是查看發(fā)現(xiàn) p1 實例的啟動時間：

        p1 數(shù)據(jù)庫實例的啟動時間是似乎就在 $ORACLE_HOME/bin/oracle 文件的屬組改變的前后，這真的是巧合嗎？這里引出了第二個疑問

  是誰改變了 oracle 文件的屬組，為什么要去這么做呢？

  如圖顯示 p1 實例的 trace 文件也曾在 2016 年的 12 月 10 日發(fā)生過改變，而且改變后，一直保持為 oracle:oinstall 的屬主屬性，而在 2 月 9 日重啟完成后恢復為 oracle:asmadmin 的屬主屬性（圖片中沒有顯示出來），也就是說在更早之前，我們可以推斷 $ORACLE_HOME/bin/oracle 文件的屬組是 asmadmin ，在 12 月 10 日更改為 oinstall ，而在 2 月 9 日再次更改為 asmadmin 。

老K的回憶沙龍~

  事情似乎又變的復雜起來了，這里讓老 K想起 遇到過的一段經(jīng)驗， CASE 是這樣的：我們在打完數(shù)據(jù)庫補丁之后，經(jīng)常會出現(xiàn) $ORACLE_HOME/bin/oracle 文件的屬組發(fā)生改變，導致本地的非 dba 用戶不通過監(jiān)聽連接數(shù)據(jù)庫時報無法訪問 ASM 磁盤的情況（ asm 磁盤的屬組一般是 grid:asmadmin 的），而我們只需要通過使用 srvctl start database   的方式來重新啟動數(shù)據(jù)庫就可以解決該問題（當然在數(shù)據(jù)庫停止的情況下直接 chown 的方式也可以） ;

  那么在這個問題里是不是也前一天重啟 p1 實例也是用的 srvctl 命令呢？

  正是因為前一天使用 srvctl 的方式啟動了 p1 節(jié)點，改變了 oracle 文件的屬組，導致了 x1 節(jié)點出現(xiàn)報錯；至于為什么要改變 oracle 文件的屬組，那就是 oracle 的機制的原因了。這里我們需要理解的一點，使用 srvctl/crsctl 命令來啟停數(shù)據(jù)庫和使用 sqlplus 登錄到數(shù)據(jù)庫中啟停數(shù)據(jù)庫的區(qū)別是， srvctl/crsctl 命令調用的是 crs 中 oraagent 來執(zhí)行的，而 sqlplus 是在 oracle 用戶下直接執(zhí)行的。

小結

1 .      數(shù)據(jù)庫實例 p1 和 x1 在正常運行；

2.   $ORACLE_HOME/bin/oracle 文件的屬組是 oinstall 的；

3.   2 月 9 日，運維人員重啟了 p1 實例，啟動時的方式是 srvctl     startinstance -d p -i p1 ，這個過程中將 $ORACLE_HOME/bin/oracle 的屬組改為 asmadmin ；

4.   數(shù)據(jù)庫實例 x1 開始報錯運行時屬組與啟動時屬組不一致 。

難題再現(xiàn)！

   到這里，前面的兩個難題已經(jīng)解開，不過我們在與客戶的溝通過程中就不免多問一句，為什么會去重啟 p1 實例呢？給出的答案又引起了我們的思考：前一天客戶發(fā)現(xiàn) p1 實例無法登錄，由于 p1 數(shù)據(jù)庫實際上已經(jīng)不作生產(chǎn)使用，平時可能會有一些簡單的測試使用到這個數(shù)據(jù)庫，所以客戶的現(xiàn)場維護人員直接重啟了 p1 實例解決問題。但是 為何 p1 實例會無法登錄呢？ 如果僅僅是測試庫的話，正常是不應該有壓力大的情況，還是說也是類似 x1 的情況？就此，我們再從分析 p1 實例之前的運行情況。另外，從前面的過程來看，我們可以看到 oracle 文件屬組曾經(jīng)從 asmadmin 變?yōu)? oinstall ，這樣我們就還需要解釋一個問題， 如果說 srvctl 的方式啟停數(shù)據(jù)庫會將 $ORACLE_HOME/bin/oracle 文件的屬組改為 asmadmin 的話，那么，又是什么讓這個文件的屬組改為 oinstall 的呢 ? 帶著這兩個新的疑惑，老 K 再次踏上解惑的征程，先來看 p1 實例的 alert 日志：

   看到日志老 K 才發(fā)現(xiàn)，原來 p1 實例在 12 月 10 號 09:18:09 開始啟動，啟動到 09:23:33 的時候就已經(jīng)開始報錯，并一直持續(xù)到 2 月 9 日重啟之前，通過重啟的方式最終解決。 P1 為什么會存在這樣的問題呢？那么 X1 實例呢，之前為什么沒有問題呢？我們再來看看 x1 實例之前的 alert 日志：

          x1 實例在啟動時也經(jīng)歷過啟動報錯的過程，只不過很不幸， x1 實例在啟動后臺進程 RSMN 時，就已經(jīng)出錯，導致實例啟動失敗，而后在 09:23 再次啟動，則啟動成功，后續(xù)因為 $ORACLE_HOME/bin/oracle 文件沒有修改過屬組，直到 2 月 9 日 18 點，也沒有再報過錯。細心的同學可以看到   x1 實例和 p1 實例在 12 月 10 日的 shutdown 和初次 startup 的時間是基本一致的，于是我們猜測，這個動作應該是使用 crsctl stop crs 和 crsctl start crs 的方式來啟停 CRS 的過程中順帶將數(shù)據(jù)庫啟停了， 那么為什么 p1 實例啟動完成了，而 x1 實例啟動失敗了呢？事實上這里 p1 也就只是啟動了實例，并沒有打開數(shù)據(jù)庫，而 x1 實例啟動失敗是因為其關鍵進程 RSMN 的啟動時間正好在 $ORACLE_HOME/bin/oracle 的屬組修改的時間（ 09:19:22 ）之后導致啟動失敗，而再次啟動時， x1 實例相關進程的屬組也就都一致了不再存在啟動時和運行時屬組不一致的問題了。

   現(xiàn)在，我們還剩下最后一個難題，那就是 12 月 10 日，客戶現(xiàn)場的維護人員做了什么才導致 $ORACLE_HOME/bin/oracle 文件的屬組變?yōu)榱瞬徽_的 oinstall 屬組？這里，我們查看了該節(jié)點上數(shù)據(jù)庫打補丁的信息，發(fā)現(xiàn)自安裝以來并沒有再打過補?。ㄈ罩具^長，這里就不再列出）；不過很幸運，我們通過歷史命令記錄查到了蛛絲馬跡：

   之前存在對 oracle 文件的 relink 操作，并將日志記錄在了 $ORACLE_HOME/install/relink.log 里，在我們查看 relink.log 的信息時就能定位到這條命令的操作時間了：

   基于老 K 日常積累的經(jīng)驗，才可以這么認定 relink 操作就會改變 oracle 文件的屬組信息。在 opatch 打完一些數(shù)據(jù)庫補丁后，通常會改變 oracle 文件的屬組信息，如果我們細看 opatch 過程中的詳細日志，我們就會發(fā)現(xiàn)，這個過程中實際上使用的底層命令就是 relink ，也就認為 relink 實際上會修改 oracle 文件的內容，同時也會修改 oracle 文件的屬組（因為做這個操作的用戶是 oracle:oinstall ）。得出結論后繼續(xù)與客戶進行溝通，對話如下：↓↓↓↓↓

現(xiàn)場運維商確實在之前處理其它問題時，使用過 relink 命令重現(xiàn)編譯 oracle 文件，但是當時沒有啟動數(shù)據(jù) 庫。

是不是當時先重啟了操作系統(tǒng)呢？ 請輸入

厄。。。好像是的！

到底發(fā)生了什么？

1. 12 月 10 日 ，客戶的現(xiàn)場運維商需要使用 relink 命令解決問題；

2. 在 relink 之前直接重啟操作系統(tǒng)，操作系統(tǒng)啟動時，自動啟動 CRS ，并且將試圖啟動數(shù)據(jù)庫以恢復到之前狀態(tài)

3. 在啟動數(shù)據(jù)庫的過程中，維護商沒有關注到是否有數(shù)據(jù)庫正在運行即已開始執(zhí)行 relink 操作；

4. 在 relink 操作的過程中， p1 完成了實例啟動，而 x1 實例則因為 RSMN 啟動時 oracle 文件的屬組已經(jīng)發(fā)生改變， RSMN 啟動失敗，繼而導致 x1 實例失敗，而 p1 實例雖然啟動成功，但是一直報錯，數(shù)據(jù)庫也未能打開；

5. 在此期間 p1 實例實際上是不可用的，在 2 月 9 日維護商發(fā)現(xiàn) p1 實例不可用，因為認為 p 1庫不重要，在未核查原因的情況下直接重啟了 p1 實例， p1 實例正常 ；

6. 因為在啟動 p1 實例是使用的 srvctl start 的命令，導致啟動時修改了 $ORACLE_HOME/bin/oracle 的屬組，導致 x1 實例不可用 ；

7. 最終通過重啟 x1 實例恢復正常。

  最后總結：

     通過詳細的分析，我們發(fā)現(xiàn)從 p1 實例的處理方式能很快的解決，但是問題的根本是 有一系列的操作上的失誤導致， 所以老 K 想再一次安利下自己的觀點：我們在解決問題的過程中，對于任何小疑點都不能輕易濾過，現(xiàn)在發(fā)生的問題也許就是由多個小的問題愈演愈烈最終影響正常業(yè)務，我們只要對整體分析透徹，自然可以從本質上解決問題。所以大家一定時刻保持探索精神，不忽略任何一個細節(jié)，這也是我們作為中亦人一直在堅持的精神??！

   好啦，本期就到這里， 今年 我們中亦 DBA 團隊將全力以赴，用詼諧和嚴謹?shù)姆绞綄⑽覀兊慕?jīng)驗進行分享， 希望大家多多支持，伙伴們的轉發(fā)分享是對我們大的鼓勵！

新聞標題：技術人生系列·我和數(shù)據(jù)中心的故事（第十一期）-一次啟停引發(fā)的故障-創(chuàng)新互聯(lián)
URL分享：http://weahome.cn/article/eehph.html