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 实例恢复正常。