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

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

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

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

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

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

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

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

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

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

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

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

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

2. 在 relink 之前直接重啟操作系統，操作系統啟動時，自動啟動 CRS ，并且將試圖啟動數據庫以恢復到之前狀態

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

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

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

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

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