因升级 patch 引发的 ORA-01105,ORA-01606 故障记录

今天做Windows 2008 Server数据库升级，从10.2.0.4升到10.2.0.5，开始一切都很顺利，包括2个节点的clusterware软件都顺利地升到了10.2.0.5。但是，在给数据库软件打patch包并装到一半的时候，报了如下的一个错误，节点2的大批文件被进程或程序占用，无法顺利复制到节点2的相关文件：



记得打patch包的时候，也是停了节点2的相关服务和进程的，不知为何还有这么多文件被占用，但是选了“是”忽略该报错，继续执行安装。

然后OUI提示节点一的patch顺利安装完毕，于是也没有在意，对数据库进行下一步的升级，执行升级脚本，一直到顺利升级到10.2.0.5的数据库

如图：



这里zlm用户的zlm1测试表示升级之前新建的，升级完以后，数据库可以正常打开，也能够查询到该表数据依然存在，并无异常

但是，在节点启动实例后发现，报了ORA-01105、ORA-01606故障，无法正常启动实例：



以下是这2个ora错误的相关说明：

Error: ORA 1105

Text: mount is incompatible with mounts by other instances

-------------------------------------------------------------------------------

Cause: An attempt was made to mount the database, but another instance has already mounted

a database by the same name, and the mounts are not compatible.

additional messages will accompany this message to report why the mounts are incompatible.

Action: See the accompanying messages for the appropriate action to take.

Error: ORA 1606

Text: GC_FILES_TO_LOCKS not identical to that of another mounted instance

-------------------------------------------------------------------------------

Cause: The initialization parameter GC_FILES_TO_LOCKS is not the same as

another instance mounted in parallel mode.

This parameter must be the same as that for all shared instances.

Action: Modify the parameter to be compatible with the other instances, then

shut down and restart the instance.

于是尝试SQLPLUS /NOLOG方式登录到实例并启动到mount状态，发现该实例并没有正确升级，依然是10.2.0.4的版本：



猜想有可能是刚才那个满屏的节点2文件被占用，无法复制数据库软件到节点2所致，尝试重新在节点2上重新安装一次patch软件

顺便提一下，如果安装的时候出现以下这个报错：



那么可能是OracleServiceSID服务没有关闭，或crsd.exe和ocssd.exe进程没有关闭所致，手动关闭一下点重试即可，千万注意，如果要在远程操作复制文件到另一节点时，不要去手动结束ocssd.exe进程，否则可能造成目标主机跌点蓝屏重启，要事先都关闭好才行。

在节点2上安装patch软件时，我手动去关闭了节点1上的ocssd.exe进程，造成节点1蓝屏重启，而此时节点2正在进行对节点1的远程操作，包括复制相关文件和写远程注册表。由于节点1之前已经顺利安装并升级过，所以这里先忽略这些远程的操作，点继续安装，直到在节点2上顺利完成patch软件的安装，随后再对其进行升级。

完成以上步骤以后，节点2上的实例是顺利起来了，也可以访问数据库中原来的数据，可以看到，版本也变成了10.2.0.5：



但是查看RAC资源时发现节点1和节点2部分资源状态不正常：



既然能查看到zlm用户下zlm1表中的数据，这里居然显示数据库时OFFLINE的，而且数据库的2个实例也都没有起来，还有一个节点1的ASM资源也是OFFLINE，于是重启节点1的CRS：



此时发现节点2的实例和数据库，节点1上的ASM和数据库实例依然是OFFLINE的，尝试过重新删除资源再重新添加，依旧如故。

觉得该故障可能就是和我分别在2个节点执行patch软件的安装和各自跑一遍升级脚本有关，所以没办法了，至少推倒重来。

总结：安装遇到报错故障时，不要轻易点“是”或“继续”，尤其是生产库，一定要先排查错误，等错误检验通过无报错后，再执行“NEXT”进行下一步操作，否则很可能造成意想不到的错误，看似完成升级，实则不然，今后在部署工作中，要格外注意了。