关于shutdown的时候存在active进程的问题

oracle在shutdown immediate的时候，如果遇到活动的事务，比如job还在跑，那么该shutdown操作就会挂起，直到job完成为止。我们在alertlog中可以看到：

如果在一小时内，job没有跑完，那么该shutdown的操作就会自动被取消。这些动作，在alertlog中为：

这是一个非常令人头痛的问题，尤其是在没有dba介入的双机热备切换操作中。

上周就出现了这样一个故障，某省做4506的交换机切换测试，交换机是核心交换机，有2台，是主备模式的架构，用于连接应用服务器和数据库服务器，数据库服务器的架构为HP SG的双机热备。每个数据库主机有2个网卡，lan1和lan3做冗余，lan1接4506-1，lan3接4506-2。此次切换测试的操作是：
1、先down掉4506-1，工作在4506-2，
2、再启动4506-1，down掉4506-2，工作在4506-1，
3、最后再启动4506-2。
本来，这次操作和数据库没什么关系，因为在同一时间点内，肯定有至少1台交换机在线。

但是问题出现了，由于在进程切换测试时，当第2步的时候，估计启动4506-1时间太短，还没启动完整，就把4506-2 down掉了。于是就出现了同一时间内，没有交换机在线了。在syslog中，我们可以看到：

我们在log中看到 00:56，发生lan1 fail，准备切换到做冗余的lan3上。到01:18，lan3 fail，因此sg认为此时没有一个正常的网络环境，做冗余的2个网卡都down了，需要切换到数据库备机。01:19 lan1恢复，工作在lan 1上；在02:14 lan3恢复。

根据syslog，我怀疑网络工程师在操作上述的第2步时，在01：18不是先起4506-1，再down 4506-2，而是操作成了先down 4506-2（造成01：18 lan3 fail），再起4506-1（在01：19 lan1 恢复）。因此，syslog中是先出现lan3 fail——此时却没有在线的交换机，所以发生sg mc切换。

发生mc切换，如果数据库里面没有active事务，那也就没事了，但是偏偏有active事务，于是，shutdown命令发起1小时后，数据库自动取消了此次shutdown操作。

如果数据库自动取消了shutdown操作，那也就没事了，偏偏在mc切换的脚本中有这样一个判断：

我们这里看到$? != 0 的判断，这个判断是上述最后一个语句执行成功的话，返回为0，如果不成功，返回为非0。而在上面的mc切换脚本中，先后包含了2个操作步骤，先是shutdown数据库，再是stop 侦听。
在前一步，我们确实因为active事务，在运行shutdown命令1小时后失败，但是后续的操作stop侦听却是成功的，于是$? != 0根据最后一个语句判断返回值为0为真，认为语句执行成功（含数据库shutdown成功和stop侦听成功），准备切换到备机！

于是mc的log中：

在切换时由于数据库没down下去，vg还是激活状态，因此对vg的操作失败。mc也就没切到db02上去。于是在db02上的vg没挂过去，数据库没起来，浮动IP也没起来，侦听也没起来。

当前实际的情况是：在db01上oracle是启动的，但是浮动IP没有启动——因为切换包的时候，浮动IP会从db01切换到db02上，但是由于切换出现问题，数据库没有切换过去，浮动IP切换失败——浮动IP在2个db主机上都没有了。

再次启动mc的包，将浮动IP启动在db01上。原本以为没事，结果又发现job的守护进程cjq0不见了：

这个问题倒是以前没发现过，原来active进程prevent shutdown操作，等待1小时之后，数据库自动取消shutdown操作，会导致job的守护进程消失！

没办法，用cmhaltcl的方式down掉整个cluster，在cmruncl的方式重新启动cluster，带起数据库，cjq0的进程恢复。

故障总结：
1、进行网络测试的时候，可能没有按照事先做好方案，没有严格按照步骤执行，操作错了执行步骤。——根据syslog判断。
2、mc切换的脚本有缺陷，对$? != 0的判断，导致数据库没down下去，mc却认为数据库已经shutdown成功。去做后续的操作，包括去激活vg和虚拟IP的切换。——根据mc的切换log和切换shell判断。
3、shutdown immediate时如果有active事务，如果事务无法完成，等1小时后，数据库自动取消shutdown操作，会导致cjq0进程消失。需要重启数据库。——根据alertlog判断。对付这个，最好就是去kill在alertlog中显示的active process（会有进程号显示）。