技術(shù)人生系列 · 我和數(shù)據(jù)中心的故事（第十一期）- 一次啟停引發(fā)的故障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 因?yàn)樵趩? p1 實(shí)例是使用的 srvctl start 的命令，導(dǎo)致啟動時(shí)修改了 $ORACLE_HOME/bin/oracle 的屬組，導(dǎo)致 x1 實(shí)例不可用 ；

7. 最終通過重啟 x1 實(shí)例恢復(fù)正常。