Oracle ODA X4-2 升级及故障处理

客户有一套Oracle ODA X4-2一体机，使用了近8年多时间，期间从未做过升级操作，目前该一体机处于暂时闲置状态，客户希望对该ODA一体机进行一次升级工作，打算升级完成后再重新投入生产使用。

通过升级前的检查工作，我们发现该ODA一体机的当前版本为2.8.0.0.0，而MOS文档《Oracle Database Appliance Platform Software Qualification (Doc ID 2228502.1)》针对ODA各个型号所支持的版本进行了详细说明，ODA X4-2支持的最高版本为18.8。具体如下图所示：

经过考虑，我们计划将整个升级工作分两个阶段完成，第一阶段先升级到12.1.2.12.0版本。由于当前的ODA版本太老，不支持从2.8.0.0.0直接升级到12.1.2.12.0，需要先升级到几个过渡版本，具体的版本过渡如下图所示：

所以，第一阶段的最终升级路线为：2.8.0.0.0 -> 12.1.2.0.0 -> 12.1.2.5.0 -> 12.1.2.6.0 -> 12.1.2.12.0。

本文主要介绍从2.8.0.0.0版本升级到12.1.2.12.0版本期间，升级步骤的一些主要变化，以及升级过程中一些故障处理过程。

ODA从逻辑层面主要分为三大组件，分别为：INFRA、GI、DATABASE。

• INFRA主要包括：磁盘固件、控制器固件、操作系统、ILOM、BIOS、HMP、IPMI、OAK、ASR，如果当前的ODA是虚拟化环境，则INFRA还包括Dom0 。

• GI主要包括：GI集群、ASM和TFA。

• DATABASE主要包括：RDBMS。

ODA升级时，要求先升级INFRA，再升级GI，最后升级DATABASE。ODA 12.1.2.0.0这个版本，会强制地将GI集群的版本从11.2.0.4.0升级到12.1.0.2.0，而GI集群大版本的升级工作，往往会产生一些问题。

1、从2.8.0.0.0升级至12.1.2.0.0，主要的升级步骤如下所示：

(1).将ODA升级包复制到两个计算节点上，升级包的具体位置如下所示。

(2).在两个计算节点上，分别对升级包进行unpack操作，然后删除升级包，释放空间，具体命令如下所示：

(3).正式升级infra，具体命令如下所示：

(4).正式升级GI，具体命令如下所示：

(5).正式升级DB，具体命令如下所示：

2、在升级到12.1.2.0.0版本的过程中，遭遇了多次故障，具体如下。

故障1：

从2.8.0.0.0 升级到12.1.2.0.0版本，执行oakcli update -patch 12.1.2.0.0 --gi升级GI集群时，节点1的GI升级成功，但节点2的GI升级异常。如下内容是升级日志中的报错部分：

但是，通过crsctl status resource -t命令检查发现，此时整个集群的状态都是正常的，所有的资源都处于online状态。另外，执行oakcli show version -detail命令，也显示GI_HOME当前已经Up-to-date，这说明GI集群已经升级成功。

针对该故障，搜索到MOS文档《ODA (Oracle Database Appliance): GI Patching Troubleshooting (Doc ID 1665754.1)》，文中的（Case Studies 3）部分已经有详细说明，只需要手动处理inventory.xml文件即完成GI升级的后续工作。

故障2：

从2.8.0.0.0 升级到12.1.2.0.0版本，升级GI集群成功后，oakd服务却无法启动，报错信息如下：Failed to connect to oakd。检查oakd.log日志文件，一直在提示Waiting for /odadatafs……

搜索到MOS文档《OAKD Does Not Start After Upgrading to ODA 12.1.2 with Messages Checking/Waiting for ACFS /odadatafs (Doc ID 1932651.1)》，该文档所描述的情况与当前的现象还是非常相似的，这篇文章中提到这个故障是由于BUG（18977793）,这个BUG会造成ODADATAFS没有配置。文档中给出的解决方案是再次执行GI升级工作，具体命令如下：

当天下班之前，执行postpatch命令，心想着，让它跑一晚上，第二天肯定就完成了。结果发现，第二天上班时，该postpatch命令仍然未结束，一直hang了十几个小时，没有办法，只能手动中止postpatch命令。

此时，思考着oakd服务无法启动是由于没有/odadatafs文件系统，那么如果手动创建这个文件系统，oakd服务是否就能够启动呢？抱着试一试的想法，参考MOS文档《ODA (Oracle Database Appliance): How To Setup ACFS Post Deploy (Doc ID 1435019.1)》，手动创建了/odadatafs ACFS文件系统。

/odadatafs文件系统创建成功后，okad.log日志文件开始输出大量的日志，感觉好像有戏，再次使用oakcli show ismaster命令检查oakd服务状态时，oakd服务成功启动。

升级到12.1.2.5.0版本时，升级方法与以前的版本完全一样。

1、从12.1.2.0.0升级至12.1.2.5.0，主要的升级步骤如下所示：

(1).将ODA升级包复制到两个计算节点上，升级包的具体位置如下所示。

(2).在两个计算节点上，分别对升级包进行unpack操作，然后删除升级包，释放空间，具体命令如下所示：

(3).正式升级infra，具体命令如下所示：

(4).正式升级GI，具体命令如下所示：

(5).正式升级DB，具体命令如下所示：

2、在升级到12.1.2.5.0版本的过程中，遭遇了如下故障。

故障1：

从12.1.2.0.0 升级到12.1.2.5.0版本，执行oakcli update -patch 12.1.2.5.0 --gi升级GI集群时异常，查看升级时的日志文件，提示无法获取当前集群的活动版本。

手动执行crsctl query crs activeversion命令，查看当前的GI活动版本时，能成功返回当前的GI版本信息，但是命令输出的最开始部分，有如下提示信息。

怀疑是这些额外的提示信息，导致GI集群升级时，无法获取当前集群的活动版本。那只需要关闭这些提示信息，应该就可以解决问题。

搜索到MOS文档《ODAVP: Create or delete shared repo failed with 'OAKERR:8022' and 'OAKERR:5003' (Doc ID 2206743.1)》，当前所遇到的故障现象，与这篇文档所描述比较相似，主要的原因是由于在sqlnet.ora文件中设置了DIAG_ADR_ENABLED=off。检查客户当前的环境，发现客户环境中同样设置了DIAG_ADR_ENABLED=off参数，参考文档中的解决方案，注释掉sqlnet.ora文件中的DIAG_ADR_ENABLED参数：

再次手动执行crsctl query crs activeversion命令时，没有多余的日志输出。再次执行oakcli update -patch 12.1.2.5.0 --gi命令升级GI集群，此时成功升级。

升级到12.1.2.6.0版本时，升级方法仍然与以前的版本基本上一样。但12.1.2.6.0版本发生了一些变化，具体如下所示：

• 操作系统的版本从OEL5 升级到了OEL6.7。

• 引入了local参数，在滚动升级时，用来控制何时进行第二个节点的升级操作。

1、从12.1.2.5.0升级至12.1.2.6.0，主要的升级步骤如下所示：

(1).将ODA升级包复制到两个计算节点上，升级包的具体位置如下所示。

(2).在两个计算节点上，分别对升级包进行unpack操作，然后删除升级包，释放空间，具体命令如下所示：

(3).正式升级infra，具体命令如下所示：

注意：

从这个版本开始，infra的升级是local方式，也即每次只对当前节点升级，升级完成后，再登陆到另外一个节点执行另外那个节点的升级，不允许同时并行升级。

(4).正式升级GI，具体命令如下所示：

(5).正式升级DB，具体命令如下所示：

在这个版本的升级过程中，一切顺利，没有遇到任何的故障。

升级到12.1.2.12.0版本时，升级方法与以前的版本对比，发生了一些变化，主要是由于ODA的组件重新进行了逻辑划分，分别为：SERVER、STORAGE、DATABASE。

• SERVER主要包括：操作系统、ILOM、BIOS、HMP、IPMI、OAK、ASR、本地磁盘固件、GI集群、ASM和TFA，如果当前的ODA是虚拟化环境，则SERVER还包括Dom0 。

• STORAGE主要包括：共享存储柜中的HDD固件、SSD固件、控制器固件、扩展卡固件。

• DATABASE主要包括：RDBMS。

1、从12.1.2.6.0升级至12.1.2.12.0，主要的升级步骤如下所示：

(1).将ODA升级包复制到两个计算节点上，升级包的具体位置如下所示。

(2).在两个计算节点上，分别对升级包进行unpack操作，然后删除升级包，释放空间，具体命令如下所示：

(3).正式升级SERVER，具体命令如下所示：

4. 正式升级Storage，具体命令如下所示：

5. 正式升级DB，具体命令如下所示：

2、在升级到12.1.2.12.0版本的过程中，遭遇了如下故障。

故障1：

从12.1.2.6.0 升级到12.1.2.12.0版本，执行oakcli update -patch 12.1.2.12.0 --database命令来升级数据库时异常，数据库启动失败。

检查数据库的alert日志文件，发现在数据库启动过程中报ORA-600 [kfdJoin3]错误，实例异常中止。

搜索MOS网站，找到MOS文档《Database Instance Will Not Start ORA-600 [kfdJoin3] [20] [65535] [100] After Patch 12.1.2.12.0 Including the ODA (Doc ID 2341707.1)》，该故障是由于遭遇Bug（18948177），针对GI集群和数据库，安装18948177补丁后，数据库成功启动。

数据库启动后，手动执行catbundle.sql脚本，完成PSU的升级工作。

本次ODA升级，在升级之前虽然做了充足的准备工作，翻阅了大量的MOS资料，对升级中所涉及版本的Know Issue已经提前规避，但仍然遭遇了大量的故障。虽然这些故障最后都一一解决，但同样也消耗了大量的数据库停机时间。

升级工作，责任重大，前期的准备工作无论多细致都不为过，以最好的心态，提前做好最坏的打算。