![Oracle 19c安装配置中的填坑实录](https://static001.infoq.cn/resource/image/53/ce/5339330d55e1028b390bd153ffbe54ce.png)
本文由 dbaplus 社群授权转载。
背景
去年 Oracle 19C 发布,作为最新的 Oracle 发布版,我们的客户也开始有计划将数据库从 11G 之类的旧版本慢慢迁移到 19C 上。最近,在客户的现场环境下进行了 19C 的安装和配置,经历了一系列的坑与填坑过程,本文分享给大家。
先介绍环境:
操作系统:Redhat 7.6
Oracle 数据库版本:19.7
是否 RAC:是
奇妙的网络配置
安装硬件分配入手,先按惯例将操作系统相关参数配置修改了一遍。一切准备就绪,开始安装 GI。前面一段相安无事,结果在运行 root.sh 的时候,问题来了:
运行 root.sh 在第 18 步进行节点配置时报启动 ora.qosmserver 失败。
![](https://static001.infoq.cn/resource/image/ac/b0/ac18f11843411802851256406c1a0eb0.png)
查看 rootcrs 日志如下:
![](https://static001.infoq.cn/resource/image/45/d2/45b9b71c38a32c404ca51723a33a40d2.png)
日志也只显示 qosmserver 打不开,并没有其它有效的信息,上网搜索也没有什么相关的案例。另一台机器安装 GI 也报相同的错误,没办法只好求助于 MOS 了。
结果还真找到一篇类似的 12.2 root.sh fails with CLSRSC-1102: failed to start resource ‘qosmserver’ (Doc ID 2253718.1)。
但是报错跟我们有点区别:
![](https://static001.infoq.cn/resource/image/56/e3/56a31d320646b79d0320aba6966b51e3.png)
该文章介绍由于 ipv6 ::1/128 地址未配置导致,配置即可解决。
![](https://static001.infoq.cn/resource/image/47/6e/477e6cebcd9212ca03e345571ee72c6e.png)
看到这里,想到会不会是由于网络配置的原因呢?当即查看了/etc/hosts,发现::1 这一行被注释了。
![](https://static001.infoq.cn/resource/image/3a/96/3af0d78325a8c62467553645a21bef96.png)
尝试把注释取消,重新运行 root.sh 成功。
诡异的文件权限
安装完成后,需要安装相应的补丁。安装补丁前,按照多年来因吃过的亏养成的习惯,将 OraInventory、Oralce_home、GI_HOME 等相关目录统统打个包备份一遍。事后发现这个习惯非常有用,因为在安装补丁这一步又卡住了。
报错如下:
![](https://static001.infoq.cn/resource/image/da/bd/da083f983ae6d2fb910ca9567d26d7bd.png)
从以上信息我们可以看到补丁在 DB HOME 已经成功应用,但是在 GI HOME 应用时失败,报/oracle/app/oraInventory/ContentsXML/oui-patch.xml 文件权限问题。我们查看文件权限发现问题所在,同组 grid 用户该文件无写权限。
![](https://static001.infoq.cn/resource/image/31/14/31beb3748526f8ee4fbaba34e39e0b14.png)
将补丁回滚失败后,把之前备份还原回来发现补丁安装之前是没有这个文件的。由此我们可以估计 oui-patch.xml 是在 DB HOME 进行补丁升级时派生的。
![](https://static001.infoq.cn/resource/image/e9/43/e91a5ccd432c1d95ef4f6934a4622643.png)
再次进行补丁升级时,发现 oui-patch.xml 已生成,用 root 紧急给 oui-patch.xml 赋予 664 权限(注:只要文件一旦生成,需立即赋权),补丁升级成功。
![](https://static001.infoq.cn/resource/image/e4/7b/e40dd0935587fd7b09c210965e27dc7b.png)
此外,在 CRS alert 日志中我们发现节点会去检查所有节点的文件。日志中发现部分文件不存在报错信息。前往各节点查看这些文件,确认在所有节点都不存在。
信息如下:
![](https://static001.infoq.cn/resource/image/17/00/1777174yye4b2fd06fb521f28599b600.png)
通过核查集群及数据库均确认正常的情况下,估计是我们没用上的一些功能,这些报错暂时先忽略。
IPV6
客户网络很快开始着手改造为 IPV6,趁着这个机会,我们也配置 Oracle 的 IPV6 网络。先确认一下操作系统层面是否打开 IPV6,下面是 Linux 下两种常见的方法:
1、通过查看网卡属性确定
ifconfig-a
命令输出有“inet6…“的表示开启了 IPV6 功能。
![](https://static001.infoq.cn/resource/image/0a/fa/0a59f1c20bbb519095cf824e64d1a2fa.png)
2、通过内核模块加载信息查看
lsmod| grep ipv6
![](https://static001.infoq.cn/resource/image/15/c0/15cb0204cc120e64776ecd58b4555dc0.png)
确认打开 IPV6 后,需要自定义地址,修改网卡配置文件,新增内容如下:
![](https://static001.infoq.cn/resource/image/69/a6/6963d5db038697438700b93yyae833a6.png)
我们这里设置了两个地址,一个主用,一个备用。
重启网络生效,通过 ping6 命令测试是否可以连通,也可以使用 ping-6:
![](https://static001.infoq.cn/resource/image/aa/78/aabe7872f26492a81aafd8c6f6cf0578.png)
查找监听文件 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))))
重启监听之后查看结果如下:
![](https://static001.infoq.cn/resource/image/e8/8d/e8f0ddcc3618c2321296169ea1733b8d.png)
接下来我们配个 TNS 连接串并进行测试连接成功:
![](https://static001.infoq.cn/resource/image/b6/dc/b65453471fd9f3b7943c5113a4efc8dc.png)
至此,IPV6 的网络配置完成。
小结
在可见的未来,其实越来越多的数据库会迁移到云上,Oracle 近几年也在大张旗鼓地进行云化。这些传统 DBA 的安装、配置工作量慢慢在减少,但是作为一种基础能力我们还是需要熟练掌握的。
作者介绍:
梁铭图,新炬网络首席架构师,十多年数据库运维、数据库设计、数据治理以及系统规划建设经验,拥有 Oracle OCM、Togaf 企业架构师(鉴定级)、IBM CATE 等认证,曾获 dbaplus 年度 MVP 以及华为云 MVP 等荣誉,并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。
原文链接:
评论