去年Oracle 19C发布，作为最新的Oracle发布版，我们的客户也开始有计划将数据库从11G之类的旧版本慢慢迁移到19C上。最近，在客户的现场环境下进行了19C的安装和配置，经历了一系列的坑与填坑过程，本文分享给大家。

先介绍环境：

安装硬件分配入手，先按惯例将操作系统相关参数配置修改了一遍。一切准备就绪，开始安装GI。前面一段相安无事，结果在运行root.sh的时候，问题来了：

运行root.sh在第18步进行节点配置时报启动ora.qosmserver失败。

查看rootcrs日志如下：

日志也只显示qosmserver打不开，并没有其它有效的信息，上网搜索也没有什么相关的案例。另一台机器安装GI也报相同的错误，没办法只好求助于MOS了。

结果还真找到一篇类似的12.2 root.sh fails with CLSRSC-1102: failed to start resource 'qosmserver' (Doc ID 2253718.1)。

但是报错跟我们有点区别：

该文章介绍由于ipv6 ::1/128地址未配置导致，配置即可解决。

看到这里，想到会不会是由于网络配置的原因呢？当即查看了/etc/hosts，发现::1这一行被注释了。

尝试把注释取消，重新运行root.sh成功。

安装完成后，需要安装相应的补丁。安装补丁前，按照多年来因吃过的亏养成的习惯，将OraInventory、Oralce_home、GI_HOME等相关目录统统打个包备份一遍。事后发现这个习惯非常有用，因为在安装补丁这一步又卡住了。

报错如下：

从以上信息我们可以看到补丁在DB HOME已经成功应用，但是在GI HOME应用时失败，报/oracle/app/oraInventory/ContentsXML/oui-patch.xml文件权限问题。我们查看文件权限发现问题所在，同组grid用户该文件无写权限。

将补丁回滚失败后，把之前备份还原回来发现补丁安装之前是没有这个文件的。由此我们可以估计oui-patch.xml是在DB HOME进行补丁升级时派生的。

再次进行补丁升级时，发现oui-patch.xml已生成，用root紧急给oui-patch.xml赋予664权限（注：只要文件一旦生成，需立即赋权），补丁升级成功。

此外，在CRS alert日志中我们发现节点会去检查所有节点的文件。日志中发现部分文件不存在报错信息。前往各节点查看这些文件，确认在所有节点都不存在。

信息如下：

通过核查集群及数据库均确认正常的情况下，估计是我们没用上的一些功能，这些报错暂时先忽略。

客户网络很快开始着手改造为IPV6，趁着这个机会，我们也配置Oracle的IPV6网络。先确认一下操作系统层面是否打开IPV6，下面是Linux下两种常见的方法：

1、通过查看网卡属性确定

ifconfig-a

命令输出有“inet6......“的表示开启了IPV6功能。

2、通过内核模块加载信息查看

lsmod| grep ipv6

确认打开IPV6后，需要自定义地址，修改网卡配置文件，新增内容如下：

我们这里设置了两个地址，一个主用，一个备用。

重启网络生效，通过ping6命令测试是否可以连通，也可以使用ping-6：

查找监听文件listener.ora并进行修改，新增IPV6的监控地址与端口。需要注意监听中IPV6端口须与IPV4端口不一致：

LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))(ADDRESS= (PROTOCOL = TCP)(HOST = 2020:db8:1000::200)(PORT =1601)(IP=FIRST))))

重启监听之后查看结果如下：

接下来我们配个TNS连接串并进行测试连接成功：

至此，IPV6的网络配置完成。

在可见的未来，其实越来越多的数据库会迁移到云上，Oracle近几年也在大张旗鼓地进行云化。这些传统DBA的安装、配置工作量慢慢在减少，但是作为一种基础能力我们还是需要熟练掌握的。