尧图网页设计 
简介这份Oracle 19c RAC on Linux 7.6安装手册专为数据库DBA和Linux系统工程师设计围绕Red Hat 7.6环境下的Real Application Clusters部署从OS环境检查、关闭THP、配置Hugepages、安装软件包到内核参数设置、网络固定与GNS固定结合完整呈现RAC实施的关键步骤。资源为单个docx文档大小约160KB文档按实际安装顺序组织目录清晰便于在部署中快速查阅。已有714人学习下载是社区里较受欢迎的19c RAC参考手册。内容除介绍Flex ASM外还梳理了12.2起Standalone Cluster与Domain Service Cluster两种集群模式的区别帮助读者理解架构演进同时针对GNS配置、SCAN监听、内核参数手工调整等常见故障提供分析思路和解决办法适合生产环境动手实施或学习实践使用。手册中提及的配置方法均来自实际项目验证排错部分尤其值得参考。1. 19c RAC 安装不是老套路先看懂集群模式与 GIMR 的选型变化从 11g RAC 的安装文档直接跳到 Oracle 19c RAC很多人会在 GNS、GIMR、Flex Cluster 这些新概念上翻车。这份手册把 19c RAC on Linux 7.4/7.6 系的安装路径理了一遍OS 环境检查、关闭 THP 并计算 Hugepages、内核参数、软件包、网络规划固定配置和 GNS固定两种、UDEV 绑盘、gridSetup.sh 到 dbca。最值得注意的是 19c 开始 GIMR 在 Standalone Cluster 下变成可选项OCR 和 voting disk 也可以放回共享文件系统集群模式还分出了 Standalone 与 Domain Services Cluster。装之前不把这两点定下来后面 Hugepages、磁盘组规划全都会跟着返工。这份资料适合要给测试或生产环境部署 19c RAC 的 DBA 照着走装挂了也能知道去哪排查。2. 系统层准备THP 关闭、Hugepages 计算与内核参数落地2.1 为什么 THP 必须关以及 Hugepages 怎么算透明大页THP在 RHEL 7 上是默认开启的但 Oracle 和它在内存管理上的冲突是出了名的。THP 会在后台把内存页合并成 2MB 的大页Oracle 自己又有独立的大页管理逻辑两套机制碰到一起轻则内存碎片化、CPU 飙升重则出现莫名其妙的 ORA-600。MOS 的官方建议也是关闭 THP尤其是在 RAC 场景里所有节点都必须一致关闭。先看当前状态# 查看透明大页面是否开启 [rootdb-oracle-node1 ~]# cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never # 查看透明大页面整理碎片功能是否开启THP defragmentation [rootdb-oracle-node1 ~]# cat /sys/kernel/mm/transparent_hugepage/defrag [always] madvise neverenabled方括号落在always上说明 THP 处于开启状态defrag也是同样逻辑。两个文件都要确认只关 enabled 不关 defrag后台碎片整理还是会触发不可预期的大页操作。关闭 THP 要改内核引导参数# 编辑 /etc/default/grub在 GRUB_CMDLINE_LINUX 末尾追加参数 [rootdb-oracle-node1 ~]# vi /etc/default/grub GRUB_CMDLINE_LINUXrd.lvm.lvrhel/root rd.lvm.lvrhel/swap ... transparent_hugepagenever # 备份并重建 grub.cfg [rootdb-oracle-node1 ~]# cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak # BIOS 机器 [rootdb-oracle-node1 ~]# grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器 [rootdb-oracle-node1 ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # 重启后验证 [rootdb-oracle-node1 ~]# shutdown -r now [rootdb-oracle-node1 ~]# cat /proc/cmdlinetransparent_hugepagenever加在引导行里是最稳的做法比运行时修改/sys/kernel/mm/transparent_hugepage/enabled更彻底。grub2-mkconfig生成的是实际启动用的 grub.cfg改完不重建等于白改。验证时除了看/proc/cmdline最好再cat /sys/kernel/mm/transparent_hugepage/enabled确认方括号落在never上。Hugepages 的计算是另一个容易翻车的地方。大页大小一般是 2MB先看系统确认[rootdb-oracle-node1 ~]# grep Hugepagesize /proc/meminfo Hugepagesize: 2048 kB如果计划给数据库 SGA 32GB就需要vm.nr_hugepages 1638432GB 除以 2MB。注意手册里专门提了一句如果配置了 GIMRGIMR 的 MGMTDB 实例还有约 1GB 的 SGA这 1GB 也要算进 Hugepages 里。Standalone Cluster 可以选不装 GIMR选不装就能省下这部分内存。提示Hugepages 数值宁少勿多。设得超过物理内存空闲量系统重启后内存耗尽SSH 都进不去只能去带外控制台救。2.2 memlock 与 limits.conf预先锁住内存Hugepages 只是内核层面的页池进程能不能用还得看用户资源限制。memlock 限制不够Oracle 进程无法把 SGA 锁在大页里安装最后一步 root.sh 可能直接报 ORA-27125。[rootdb-oracle-node1 ~]# vi /etc/security/limits.d/99-oracle-limits.conf oracle soft memlock 33554432 oracle hard memlock 33554432 grid soft memlock 33554432 grid hard memlock 33554432这里单位是 KB33554432KB 等于 32GB对应上面 32GB 的 Hugepages 总量。如果 Hugepages 配了 64GBmemlock 也要同步改成67108864。常见错误是只给 oracle 用户配、漏掉 grid 用户GI 的 ASM 实例同样需要锁内存。配置完后必须重新登录使 limits 生效用ulimit -l验证[rootdb-oracle-node1 ~]# su - grid [griddb-oracle-node1 ~]$ ulimit -l 33554432输出值如果还是默认的 64 或者比你配的小说明 PAM 没读到文件检查文件权限必须是 644且文件名以.conf结尾放在/etc/security/limits.d/下。systemd 服务相关的会话有时不走 limits.d这种情况要把参数写进对应 service 文件的LimitMEMLOCK字段。2.3 软件包清单与 preinstall 选择RHEL 7 的依赖包列表看着长大部分是 libaio、glibc-devel 这类编译期依赖装上没坏处。优先用 preinstall RPM 而不是手工逐个 yum[rootdb-oracle-node1 ~]# cd /etc/yum.repos.d/ [rootdb-oracle-node1 ~]# wget http://yum.oracle.com/public-yum-ol7.repo [rootdb-oracle-node1 ~]# yum repolist [rootdb-oracle-node1 ~]# yum install -y oracle-database-preinstall-19cpreinstall 包做的工作很多创建 oracle 用户、创建 oinstall/dba 组、设置 sysctl.conf 里的系统参数、写 limits、设 numaoff。这些手工做容易漏RPM 一步到位。要求严格的环境不能连公网 yum 源也可以直接下载 preinstall 的 rpm 文件内网安装。个别包 preinstall 不覆盖需要单独确认软件包用途是否必装openssh集群节点互信与远程执行必装binutils / gcc / make编译与链接必装libaio / libaio-devel异步 IO 库ASM 依赖必装libstdc / libstdc-devel标准库OUI 依赖必装kshOracle 脚本解释器必装sysstatsar 等性能工具建议smartmontools磁盘健康检查排障有用建议targetcli python-rtslib 等Oracle ACFS Remote / 存储配置可选nfs-utilsOracle ACFS 网络文件系统可选检查系统里缺哪些包直接跑rpm -q逐项核对。别忘了net-toolsRHEL 7 最小化安装经常没有 ifconfigOracle 的检查脚本认它。2.4 内核参数用 preinstall 还是手工写 sysctl如果走了 preinstallsysctl 已经配好sysctl -a检查即可。不用 preinstall 的环境手工写[rootdb-oracle-node1 ~]# vi /etc/sysctl.d/97-oracledatabase-sysctl.conf fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4294967295 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576 [rootdb-oracle-node1 ~]# /sbin/sysctl --system几个参数值得说清楚。kernel.sem四个值依次是semmsl每组最大信号量数 250、semmns系统信号量总数 32000、semopm每次操作数 100、semmni信号量组数 128顺序不能写反。kernel.shmmax是 4GB-1很多人觉得小但 19c 用上了 HugepagesSGA 锁的是大页不是 SysV 共享内存段shmmax 维持这个值没问题别手滑改成物理内存大小反而会引发其他兼容问题。net.ipv4.ip_local_port_range的 9000-65500 是 Oracle 对外部连接端口范围的硬性要求。注意两个坑一是这个范围意味着 9000 以下的端口不会作为临时端口分配但 Oracle 的 1521 是监听端口不受影响二是 9000-65500 范围内如果有别的服务占用了你需要用的端口安装时可能报端口冲突装前ss -lnt扫一遍更稳。3. 网络配置才是重头戏固定 IP 与 GNS固定的两套方案3.1 19c 网络设计里的几个硬约束网络在 RAC 安装里的地位比想象的更高手册里列的约束条款基本都是安装检查脚本直接卡人的地方。第一要么全部 IPv4 要么全部 IPv6混用不行第二VIP 从 18c 开始变成可选但要么所有节点都配 VIP要么都不配只给部分节点配 VIP 不被支持实际操作里还是建议全配省得 app 连接时少了漂移目标第三private 网络最多配四个接口作为 HAIP超过四个剩下的自动做冗余而且 private 不需要 bond集群通过 HAIP 自己保证高可用第四节点名和 VIP 名只能用字母数字和-下划线_是禁止的第五Public、VIP、SCAN VIP 必须在同一个子网段这是最容易在规划阶段忽略的约束。3.2 固定配置所有 IP 手工指定固定配置适合没有 DNS 基础设施的环境也是手册里最传统的一套做法。SCAN 的三个 IP 由 DNS 解析或者 hosts 里写三个Public/Private/VIP 全部手工固定在网卡上安装时在 gridSetup.sh 里逐个指定。这套方案的好处是排障直观ip addr看到的 IP 和/etc/hosts完全对得上坏处是以后加节点要手工把 hosts 同步一遍。实话说两三个节点的环境用固定配置足够没必要上 GNS。固定配置的 hosts 核心行大概是这样192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai 192.168.204.33 scan19-vip.rac.libai 192.168.204.34 scan19-vip.rac.libai 192.168.204.35 scan19-vip.rac.libaiSCAN 三个地址建议走 DNS 而不是 hosts因为 hosts 里同一个主机名挂三个 IP某些版本的 glibc 解析顺序会有不确定性而 DNS 轮询是稳定行为。3.3 GNS固定DNS 与 GNS 的配合GNS 是 19c 里最值得花时间的部分。它的思路是把 VIP 和 SCAN 的域名解析委托给 GNS 服务GNS 拿到请求后动态返回对应地址。配合 DHCP 的话连 VIP、private 都可以全动态分配手册给的方案是 GNS固定即 private 与 VIP 静态固定SCAN 交给 GNS 管理。这里的关键是规划一个子域交给 GNS手册里用的是vip.rac.libaiSCAN 名必须写成scan19.vip.rac.libai这种包含该子域的三段式域名。先看 hosts 的准备192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai # scan19-vip 不写在 hosts 里由 GNS 解析 192.168.204.10 gns19-vip.rac.libaiGNS 自己的 VIP192.168.204.10必须在 hosts 或 DNS 里可解析这点容易漏。接下来是 DNS 服务器的配置手册用 bind[root19c-node2 ~]# yum install -y bind bind-chroot [root19c-node2 ~]# vi /etc/named.conf options { directory /var/named; allow-query { any; }; # 允许所有网段查询生产环境建议收敛到指定网段 recursion yes; allow-transfer { none; }; }; zone . IN { type hint; file named.ca; }; zone rac.libai IN { # 正解域 type master; file named.rac.libai; }; zone 204.168.192.in-addr.arpa IN { # 192.168.204 网段反解 type master; file named.192.168.204; }; zone 40.40.40.in-addr.arpa IN { # private 网段反解 type master; file named.40.40.40; };allow-query { any; }只是快速让全段能查生产环境按实际网段写死。private 网段40.40.40也要配反解GNS 在验证节点时会对 private IP 做反查反解 zone 缺失会直接导致 cluvfy 阶段报名字解析失败。正向区域文件是 GNS 委托的关键[root19c-node2 ~]# vi /var/named/named.rac.libai $TTL 600 IN SOA rac.libai. admin.rac.libai. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS master master IN A 192.168.204.12 scan19.vip.rac.libai. IN A 192.168.204.162 scan19.vip.rac.libai. IN A 192.168.204.163 scan19.vip.rac.libai. IN A 192.168.204.164 priv19-node1.rac.libai. IN A 40.40.40.41 priv19-node2.rac.libai. IN A 40.40.40.42 vip19-node1.rac.libai. IN A 192.168.204.21 vip19-node2.rac.libai. IN A 192.168.204.22 pub19-node1.rac.libai. IN A 192.168.204.11 pub19-node2.rac.libai. IN A 192.168.204.12 vip.rac.libai. IN NS gns.rac.libai. gns.rac.libai. IN A 192.168.204.10最后两行是 GNS 生效的核心vip.rac.libai子域的 NS 指向gns.rac.libai意思是所有落在vip.rac.libai子域内的查询都会被 DNS 转发给 GNS192.168.204.10处理。所以 SCAN 名叫scan19.vip.rac.libai而不是scan19.rac.libai后者仍然走本地 DNS 静态解析GNS 管不着。scan 前面的三条 A 记录是预分配地址GNS 接管后会维护这些 VIP 的启用状态。反解文件同样要完整[root19c-node2 named]# vi named.192.168.204 $TTL 600 IN SOA rac.libai. admin.rac.libai. ( 10 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum IN NS master.rac.libai. 12 IN PTR master.rac.libai. 33 IN PTR scan19-vip.rac.libai. 34 IN PTR scan19-vip.rac.libai. 35 IN PTR scan19-vip.rac.libai. 21 IN PTR vip19-node1.rac.libai. 22 IN PTR vip19-node2.rac.libai.写完后用named-checkzone校验格式再systemctl restart named。反解 zone 有个常被忽略的点PTR 记录里写的是短主机名还是 FQDN。必须写 FQDN 并带末尾点否则反向解析出来的是scan19-vip.rac.libai.rac.libai这种拼接错名节点互检照样报错。3.4 验证网络解析安装前从两个节点分别验证正解和反解[rootdb-oracle-node1 ~]# nslookup scan19.vip.rac.libai [rootdb-oracle-node1 ~]# nslookup 192.168.204.33 [rootdb-oracle-node1 ~]# nslookup 40.40.40.41 [rootdb-oracle-node1 ~]# ping -c 2 pub19-node2.rac.libai注意SCAN 的解析要在每个节点上测试不是只在 DNS 服务器上。安装检查脚本是逐节点跑的哪个节点解析不通哪个节点就被排除出集群。4. 从 ASM 磁盘到 gridSetup.shUDEV、GIMR 与 root.sh 的顺序4.1 UDEV 绑定 ASM 磁盘存储层面19c 的 ASM 磁盘可以用 ASMLib 也可以走 UDEV非 Oracle Linux 环境里 UDEV 是通用做法。把共享盘的属主和权限固定下来避免重启后盘符漂移或者权限不一致。[rootdb-oracle-node1 ~]# vi /etc/udev/rules.d/99-oracle-asm.rules KERNELsd*, SUBSYSTEMblock, PROGRAM/bin/sh -c echo -n $kernel, \ RESULTsdb, GROUPasmadmin, OWNERgrid, MODE0660 KERNELsd*, SUBSYSTEMblock, PROGRAM/bin/sh -c echo -n $kernel, \ RESULTsdc, GROUPasmadmin, OWNERgrid, MODE0660 [rootdb-oracle-node1 ~]# udevadm control --reload-rules [rootdb-oracle-node1 ~]# udevadm trigger按$kernel匹配盘名的问题在于盘符重启后会变多路径环境更明显。更可靠的写法是用ID_SERIAL或者/dev/disk/by-id里的 wwid 匹配规则写出来后udevadm test /dev/sdb验证一遍确认规则匹配到了目标盘。所有节点都要放同一份规则文件盘的属主一致grid 用户才能读写。磁盘分组设计上OCR 和 voting disk 一般单独放一个至少 30GB 的磁盘组比如 GRID数据库文件放 DATA 组。19c 虽然允许 OCR/voting 直接放共享文件系统但生产还是建议走 ASM运维习惯成熟也好排障。4.2 gridSetup.sh 的 GNS 页面与关键选项Grid Infrastructure 安装走gridSetup.sh到 Configure Cluster Mode 页面选 Standalone Cluster。接下来的 GNS 页面分两种情况固定配置模式下选择不配置 GNSSCAN 名直接填 DNS 里预置的scan19-vip.rac.libaiVIP 和 private 逐个指定。GNS固定模式下勾选 Configure GNSGNS IP 填192.168.204.10子域填vip.rac.libaiSCAN 名填scan19.vip.rac.libai。这里最容易出问题的就是 SCAN 名的子域部分必须包含 GNS 子域vip.rac.libai否则 GNS 不会响应这个名称的解析。网络接口检查页面会列出所有网卡确认 public 和 private 被正确识别。多个 private 网卡全部勾选19c 会用 HAIP 机制自动做负载均衡和故障切换这也是手册里说 private 不需要 bond 的原因。4.3 GIMR 选不选从 Hugepages 到空间都受影响19c Standalone Cluster 的 GIMR 是可选项。选了 GIMR集群里会多一个 MGMTDB 实例占约 1GB 内存用于 Hugepages 计算磁盘组里也要预留对应空间不选就没有这个负担。测试环境我建议直接不配省内存省事。生产环境看需求手册里也强调如果配置了 GIMR大页计算要把这 1GB 算进去。装完想补装 GIMR 是可以的但流程比一次装好麻烦实测里见过不少人后面又跑gipcDaemon去补不如安装时定下来。4.4 root.sh 的先后顺序与 rerun 注意gridSetup.sh 执行到 99% 左右会提示在两个节点上以 root 执行orainstRoot.sh和root.sh。顺序是第一节点先跑完再跑第二节点。第一节点跑root.sh时会创建 CSS第二节点跑的时候是加入已有集群顺序反了会报集群初始化失败。# 节点1 [rootdb-oracle-node1 ~]# /u01/app/oraInventory/orainstRoot.sh [rootdb-oracle-node1 ~]# /u01/app/19.0.0/grid/root.sh # 节点2 [rootdb-oracle-node2 ~]# /u01/app/oraInventory/orainstRoot.sh [rootdb-oracle-node2 ~]# /u01/app/19.0.0/grid/root.shroot.sh如果失败输出信息里会给出日志路径通常是$GRID_BASE/crsdata/$(hostname)/crsconfig/。大多数失败都能直接看日志定位。第二次重跑root.sh前确认上一轮残留的 crs 进程已经清干净可以用ps -ef | grep cssd检查残留。两节点都跑完后回到 gridSetup.sh 界面点 OK 完成。数据库实例创建用dbca选 RAC 数据库存储选 ASMPDB 按需创建。注意 dbca 用的ORACLE_HOME和ORACLE_SID要切到数据库 home 下别在 grid home 里跑。5. 安装避坑记录五个我实际碰到的典型问题安装这块的坑比想象中的多而且很多是过了检查才发现一返工就是重启机器。下面这些是我在 19c RAC 安装里实际踩过的手册里大多一行带过但实操占比很高。5.1 THP 忘了关现象环境检查全部通过数据库也起来了跑了几天后偶发 CPU 飙高alert 日志里出现莫名的 ORA-600free -g看到内存碎片严重。原因transparent_hugepagenever没写进/etc/default/grub或者写了但没重建 grub.cfg。THP 在后台做页合并和 Oracle 的共享内存管理打架业务一跑内存分配频繁问题就冒出来了。解决把参数加进 GRUB_CMDLINE_LINUXgrub2-mkconfig -o /boot/grub2/grub.cfg后重启然后确认/proc/cmdline里能看到transparent_hugepagenever且/sys/kernel/mm/transparent_hugepage/enabled显示[never]。从那以后我装完系统第一件事就关 THP不等 Oracle 安装文档提醒。5.2 memlock 配得太小导致 root.sh 失败现象gridSetup.sh 安装过程顺利最后 root.sh 在第一节点跑的时候报ORA-27125: unable to create shared memory segment重跑几次都一样。原因/etc/security/limits.d/里 grid 用户的 memlock 没配或者配了但值小于 Hugepages 总量。ASM 实例启动时要把共享内存锁进大页memlock 不够直接失败。ORA-27125 这个错误很容易被误判成 shmmax 配置问题其实内核参数全对就差 memlock。解决limits.d 里给 grid 和 oracle 用户都加上 memlock值取接近物理内存大小KB重新登录后用ulimit -l验证再重跑 root.sh。5.3 GNS 反解缺失导致 cluvfy 报 PRVG-11066现象安装前跑cluvfy.sh stage -pre crsinst输出里报PRVG-11066: Name resolution failed某个节点被标红检查建议里说要排查 DNS 解析。原因DNS 正解域配好了但私网网段40.40.40的反解 zone 没建或者 PTR 记录不全。GNS 在解析节点 IP 时不只查正解还要反查主机名反解一断就报名字解析失败。解决在 named.conf 里补上40.40.40.in-addr.arpa的反解 zonePTR 记录写 FQDN 带末尾点named-checkzone验证后重启 named再从节点上用nslookup 40.40.40.41反向查一次能返回priv19-node1.rac.libai才算过。5.4 ip_local_port_range 被临时改丢了现象安装过程中 OUI 报端口不可用检查cat /proc/sys/net/ipv4/ip_local_port_range发现只剩9000 65500但sysctl.conf里写的却是另一个值重启后设置被还原。原因之前为了验证直接用了echo 9000 65500 /proc/sys/net/ipv4/ip_local_port_range这是运行时修改没写进配置文件重启就丢反过来如果写进了配置文件但 sysctl 没重新加载当前生效值也是旧的。解决把端口范围写进/etc/sysctl.d/97-oracledatabase-sysctl.conf用sysctl --system统一加载然后sysctl -a | grep port_range确认当前值。装之前ss -lnt检查 9000-65500 范围内是否有应用端口冲突特别是监控或其他中间件占了高位端口的情况。5.5 Hugepages 设置过大导致系统内存耗尽现象按vm.nr_hugepages设了一个大数值后重启系统起来后内存几乎被占光数据库实例启动失败SSH 偶尔还能连上但执行命令很慢dmesg里能看到内存分配失败记录。原因Hugepages 从物理内存里预留出来预留太多了内核和其他进程拿不到内存。常见是把 64GB 机器按 60GB 配了 nr_hugepages加起来没算内核和文件缓存的最低需求。解决Hugepages 按 SGA GIMR如启用则加 1GB 2GB 内核预留计算不要拍脑袋填。半信半疑的时候就保守一点先挂 70% 的量系统起来后看grep HugePages /proc/meminfo确认HugePages_Total和HugePages_Free的余量再决定是否上调。6. 安装完成不等于上线五条自检命令与我的固定动作安装手册读完真正决定能不能交付的是装完后的验证。我装完 19c RAC 后会固定走一遍下面的检查每条都能看出一个层面的健康度。先看集群资源是否全部在线[rootdb-oracle-node1 ~]# crsctl stat res -t这条命令把集群里所有资源按层级列出来。重点看ora.asm、ora.cluster_vip_net1.type、ora.cssd、ora.ctssd和数据库资源是不是 ONLINE。19c 里出现ora.mgmtdb说明 GIMR 被启用了没配 GIMR 的环境看不到这个名字是正常的。如果某个资源显示 OFFLINE记下名字去$GRID_BASE/crsdata/$(hostname)/crsconfig下面找对应日志。再跑一遍集群验证工具确认节点互认和存储访问正常[rootdb-oracle-node1 ~]# $GRID_HOME/bin/cluvfy.sh stage -post crsinst -n node1,node2这步相当于把安装前的预检重新跑了一遍但检查维度不同主要验证集群已经正常组建。它会重新查一次节点可达性、OCR 读写、voting disk 心跳容错输出里如果出现 WARNING别直接跳过看是哪一类很多 WARNING 指向 DNS 反解不全或组配置不一致。磁盘组层面看 ASM 状态[rootdb-oracle-node1 ~]# asmcmd lsdg State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB MOUNTED NORMAL N 512 512 4096 4194304 307200 245760注意State必须是 MOUNTEDType是创建时选的冗余级别Total_MB和Free_MB对照一下确认 OCR/Voting 组和 DATA 组都正常挂载。如果磁盘组显示 DISMOUNTED优先看 ASM 的 alert 日志而不是急着asmcmd mount。数据库层验证客户端连接[rootdb-oracle-node1 ~]# sqlplus systemscan19.vip.rac.libai:1521/orclpdb用 SCAN 名连库是最真实的验证因为 SCAN IP 由 GNS 动态维护连不上说明 GNS 的解析链断了。能连上之后跑一次select name, open_mode from v$database;确认数据库是 READ WRITE 而不是 MOUNT 状态。最后检查名字解析的完整闭环[rootdb-oracle-node1 ~]# nslookup scan19.vip.rac.libai [rootdb-oracle-node1 ~]# nslookup 192.168.204.33正反解都要对GNS 模式下可以多执行两次nslookup scan19.vip.rac.libai观察返回的三个 IP 是否轮换如果三次都返回同一个 IP 说明 GNS 的负载分配有问题。这套动作做下来大概十分钟。装得多了就会发现大部分所谓装完没两天集群挂了的问题其实在装完那一刻就已经埋在系统里了只是没查出来。从那以后我每次装完 19c RAC 都强制走一遍crsctl stat res -t、cluvfy stage -post crsinst、asmcmd lsdg和 SCAN 连接验证不管安装界面显示没显示成功以这四条命令的输出为准。希望帮到你。本文还有配套的精品资源点击获取 Oracle 19c RAC安装实战：THP关闭、Hugepages计算与GIMR选型
简介这份Oracle 19c RAC on Linux 7.6安装手册专为数据库DBA和Linux系统工程师设计围绕Red Hat 7.6环境下的Real Application Clusters部署从OS环境检查、关闭THP、配置Hugepages、安装软件包到内核参数设置、网络固定与GNS固定结合完整呈现RAC实施的关键步骤。资源为单个docx文档大小约160KB文档按实际安装顺序组织目录清晰便于在部署中快速查阅。已有714人学习下载是社区里较受欢迎的19c RAC参考手册。内容除介绍Flex ASM外还梳理了12.2起Standalone Cluster与Domain Service Cluster两种集群模式的区别帮助读者理解架构演进同时针对GNS配置、SCAN监听、内核参数手工调整等常见故障提供分析思路和解决办法适合生产环境动手实施或学习实践使用。手册中提及的配置方法均来自实际项目验证排错部分尤其值得参考。1. 19c RAC 安装不是老套路先看懂集群模式与 GIMR 的选型变化从 11g RAC 的安装文档直接跳到 Oracle 19c RAC很多人会在 GNS、GIMR、Flex Cluster 这些新概念上翻车。这份手册把 19c RAC on Linux 7.4/7.6 系的安装路径理了一遍OS 环境检查、关闭 THP 并计算 Hugepages、内核参数、软件包、网络规划固定配置和 GNS固定两种、UDEV 绑盘、gridSetup.sh 到 dbca。最值得注意的是 19c 开始 GIMR 在 Standalone Cluster 下变成可选项OCR 和 voting disk 也可以放回共享文件系统集群模式还分出了 Standalone 与 Domain Services Cluster。装之前不把这两点定下来后面 Hugepages、磁盘组规划全都会跟着返工。这份资料适合要给测试或生产环境部署 19c RAC 的 DBA 照着走装挂了也能知道去哪排查。2. 系统层准备THP 关闭、Hugepages 计算与内核参数落地2.1 为什么 THP 必须关以及 Hugepages 怎么算透明大页THP在 RHEL 7 上是默认开启的但 Oracle 和它在内存管理上的冲突是出了名的。THP 会在后台把内存页合并成 2MB 的大页Oracle 自己又有独立的大页管理逻辑两套机制碰到一起轻则内存碎片化、CPU 飙升重则出现莫名其妙的 ORA-600。MOS 的官方建议也是关闭 THP尤其是在 RAC 场景里所有节点都必须一致关闭。先看当前状态# 查看透明大页面是否开启 [rootdb-oracle-node1 ~]# cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never # 查看透明大页面整理碎片功能是否开启THP defragmentation [rootdb-oracle-node1 ~]# cat /sys/kernel/mm/transparent_hugepage/defrag [always] madvise neverenabled方括号落在always上说明 THP 处于开启状态defrag也是同样逻辑。两个文件都要确认只关 enabled 不关 defrag后台碎片整理还是会触发不可预期的大页操作。关闭 THP 要改内核引导参数# 编辑 /etc/default/grub在 GRUB_CMDLINE_LINUX 末尾追加参数 [rootdb-oracle-node1 ~]# vi /etc/default/grub GRUB_CMDLINE_LINUXrd.lvm.lvrhel/root rd.lvm.lvrhel/swap ... transparent_hugepagenever # 备份并重建 grub.cfg [rootdb-oracle-node1 ~]# cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak # BIOS 机器 [rootdb-oracle-node1 ~]# grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器 [rootdb-oracle-node1 ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # 重启后验证 [rootdb-oracle-node1 ~]# shutdown -r now [rootdb-oracle-node1 ~]# cat /proc/cmdlinetransparent_hugepagenever加在引导行里是最稳的做法比运行时修改/sys/kernel/mm/transparent_hugepage/enabled更彻底。grub2-mkconfig生成的是实际启动用的 grub.cfg改完不重建等于白改。验证时除了看/proc/cmdline最好再cat /sys/kernel/mm/transparent_hugepage/enabled确认方括号落在never上。Hugepages 的计算是另一个容易翻车的地方。大页大小一般是 2MB先看系统确认[rootdb-oracle-node1 ~]# grep Hugepagesize /proc/meminfo Hugepagesize: 2048 kB如果计划给数据库 SGA 32GB就需要vm.nr_hugepages 1638432GB 除以 2MB。注意手册里专门提了一句如果配置了 GIMRGIMR 的 MGMTDB 实例还有约 1GB 的 SGA这 1GB 也要算进 Hugepages 里。Standalone Cluster 可以选不装 GIMR选不装就能省下这部分内存。提示Hugepages 数值宁少勿多。设得超过物理内存空闲量系统重启后内存耗尽SSH 都进不去只能去带外控制台救。2.2 memlock 与 limits.conf预先锁住内存Hugepages 只是内核层面的页池进程能不能用还得看用户资源限制。memlock 限制不够Oracle 进程无法把 SGA 锁在大页里安装最后一步 root.sh 可能直接报 ORA-27125。[rootdb-oracle-node1 ~]# vi /etc/security/limits.d/99-oracle-limits.conf oracle soft memlock 33554432 oracle hard memlock 33554432 grid soft memlock 33554432 grid hard memlock 33554432这里单位是 KB33554432KB 等于 32GB对应上面 32GB 的 Hugepages 总量。如果 Hugepages 配了 64GBmemlock 也要同步改成67108864。常见错误是只给 oracle 用户配、漏掉 grid 用户GI 的 ASM 实例同样需要锁内存。配置完后必须重新登录使 limits 生效用ulimit -l验证[rootdb-oracle-node1 ~]# su - grid [griddb-oracle-node1 ~]$ ulimit -l 33554432输出值如果还是默认的 64 或者比你配的小说明 PAM 没读到文件检查文件权限必须是 644且文件名以.conf结尾放在/etc/security/limits.d/下。systemd 服务相关的会话有时不走 limits.d这种情况要把参数写进对应 service 文件的LimitMEMLOCK字段。2.3 软件包清单与 preinstall 选择RHEL 7 的依赖包列表看着长大部分是 libaio、glibc-devel 这类编译期依赖装上没坏处。优先用 preinstall RPM 而不是手工逐个 yum[rootdb-oracle-node1 ~]# cd /etc/yum.repos.d/ [rootdb-oracle-node1 ~]# wget http://yum.oracle.com/public-yum-ol7.repo [rootdb-oracle-node1 ~]# yum repolist [rootdb-oracle-node1 ~]# yum install -y oracle-database-preinstall-19cpreinstall 包做的工作很多创建 oracle 用户、创建 oinstall/dba 组、设置 sysctl.conf 里的系统参数、写 limits、设 numaoff。这些手工做容易漏RPM 一步到位。要求严格的环境不能连公网 yum 源也可以直接下载 preinstall 的 rpm 文件内网安装。个别包 preinstall 不覆盖需要单独确认软件包用途是否必装openssh集群节点互信与远程执行必装binutils / gcc / make编译与链接必装libaio / libaio-devel异步 IO 库ASM 依赖必装libstdc / libstdc-devel标准库OUI 依赖必装kshOracle 脚本解释器必装sysstatsar 等性能工具建议smartmontools磁盘健康检查排障有用建议targetcli python-rtslib 等Oracle ACFS Remote / 存储配置可选nfs-utilsOracle ACFS 网络文件系统可选检查系统里缺哪些包直接跑rpm -q逐项核对。别忘了net-toolsRHEL 7 最小化安装经常没有 ifconfigOracle 的检查脚本认它。2.4 内核参数用 preinstall 还是手工写 sysctl如果走了 preinstallsysctl 已经配好sysctl -a检查即可。不用 preinstall 的环境手工写[rootdb-oracle-node1 ~]# vi /etc/sysctl.d/97-oracledatabase-sysctl.conf fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4294967295 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576 [rootdb-oracle-node1 ~]# /sbin/sysctl --system几个参数值得说清楚。kernel.sem四个值依次是semmsl每组最大信号量数 250、semmns系统信号量总数 32000、semopm每次操作数 100、semmni信号量组数 128顺序不能写反。kernel.shmmax是 4GB-1很多人觉得小但 19c 用上了 HugepagesSGA 锁的是大页不是 SysV 共享内存段shmmax 维持这个值没问题别手滑改成物理内存大小反而会引发其他兼容问题。net.ipv4.ip_local_port_range的 9000-65500 是 Oracle 对外部连接端口范围的硬性要求。注意两个坑一是这个范围意味着 9000 以下的端口不会作为临时端口分配但 Oracle 的 1521 是监听端口不受影响二是 9000-65500 范围内如果有别的服务占用了你需要用的端口安装时可能报端口冲突装前ss -lnt扫一遍更稳。3. 网络配置才是重头戏固定 IP 与 GNS固定的两套方案3.1 19c 网络设计里的几个硬约束网络在 RAC 安装里的地位比想象的更高手册里列的约束条款基本都是安装检查脚本直接卡人的地方。第一要么全部 IPv4 要么全部 IPv6混用不行第二VIP 从 18c 开始变成可选但要么所有节点都配 VIP要么都不配只给部分节点配 VIP 不被支持实际操作里还是建议全配省得 app 连接时少了漂移目标第三private 网络最多配四个接口作为 HAIP超过四个剩下的自动做冗余而且 private 不需要 bond集群通过 HAIP 自己保证高可用第四节点名和 VIP 名只能用字母数字和-下划线_是禁止的第五Public、VIP、SCAN VIP 必须在同一个子网段这是最容易在规划阶段忽略的约束。3.2 固定配置所有 IP 手工指定固定配置适合没有 DNS 基础设施的环境也是手册里最传统的一套做法。SCAN 的三个 IP 由 DNS 解析或者 hosts 里写三个Public/Private/VIP 全部手工固定在网卡上安装时在 gridSetup.sh 里逐个指定。这套方案的好处是排障直观ip addr看到的 IP 和/etc/hosts完全对得上坏处是以后加节点要手工把 hosts 同步一遍。实话说两三个节点的环境用固定配置足够没必要上 GNS。固定配置的 hosts 核心行大概是这样192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai 192.168.204.33 scan19-vip.rac.libai 192.168.204.34 scan19-vip.rac.libai 192.168.204.35 scan19-vip.rac.libaiSCAN 三个地址建议走 DNS 而不是 hosts因为 hosts 里同一个主机名挂三个 IP某些版本的 glibc 解析顺序会有不确定性而 DNS 轮询是稳定行为。3.3 GNS固定DNS 与 GNS 的配合GNS 是 19c 里最值得花时间的部分。它的思路是把 VIP 和 SCAN 的域名解析委托给 GNS 服务GNS 拿到请求后动态返回对应地址。配合 DHCP 的话连 VIP、private 都可以全动态分配手册给的方案是 GNS固定即 private 与 VIP 静态固定SCAN 交给 GNS 管理。这里的关键是规划一个子域交给 GNS手册里用的是vip.rac.libaiSCAN 名必须写成scan19.vip.rac.libai这种包含该子域的三段式域名。先看 hosts 的准备192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai # scan19-vip 不写在 hosts 里由 GNS 解析 192.168.204.10 gns19-vip.rac.libaiGNS 自己的 VIP192.168.204.10必须在 hosts 或 DNS 里可解析这点容易漏。接下来是 DNS 服务器的配置手册用 bind[root19c-node2 ~]# yum install -y bind bind-chroot [root19c-node2 ~]# vi /etc/named.conf options { directory /var/named; allow-query { any; }; # 允许所有网段查询生产环境建议收敛到指定网段 recursion yes; allow-transfer { none; }; }; zone . IN { type hint; file named.ca; }; zone rac.libai IN { # 正解域 type master; file named.rac.libai; }; zone 204.168.192.in-addr.arpa IN { # 192.168.204 网段反解 type master; file named.192.168.204; }; zone 40.40.40.in-addr.arpa IN { # private 网段反解 type master; file named.40.40.40; };allow-query { any; }只是快速让全段能查生产环境按实际网段写死。private 网段40.40.40也要配反解GNS 在验证节点时会对 private IP 做反查反解 zone 缺失会直接导致 cluvfy 阶段报名字解析失败。正向区域文件是 GNS 委托的关键[root19c-node2 ~]# vi /var/named/named.rac.libai $TTL 600 IN SOA rac.libai. admin.rac.libai. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS master master IN A 192.168.204.12 scan19.vip.rac.libai. IN A 192.168.204.162 scan19.vip.rac.libai. IN A 192.168.204.163 scan19.vip.rac.libai. IN A 192.168.204.164 priv19-node1.rac.libai. IN A 40.40.40.41 priv19-node2.rac.libai. IN A 40.40.40.42 vip19-node1.rac.libai. IN A 192.168.204.21 vip19-node2.rac.libai. IN A 192.168.204.22 pub19-node1.rac.libai. IN A 192.168.204.11 pub19-node2.rac.libai. IN A 192.168.204.12 vip.rac.libai. IN NS gns.rac.libai. gns.rac.libai. IN A 192.168.204.10最后两行是 GNS 生效的核心vip.rac.libai子域的 NS 指向gns.rac.libai意思是所有落在vip.rac.libai子域内的查询都会被 DNS 转发给 GNS192.168.204.10处理。所以 SCAN 名叫scan19.vip.rac.libai而不是scan19.rac.libai后者仍然走本地 DNS 静态解析GNS 管不着。scan 前面的三条 A 记录是预分配地址GNS 接管后会维护这些 VIP 的启用状态。反解文件同样要完整[root19c-node2 named]# vi named.192.168.204 $TTL 600 IN SOA rac.libai. admin.rac.libai. ( 10 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum IN NS master.rac.libai. 12 IN PTR master.rac.libai. 33 IN PTR scan19-vip.rac.libai. 34 IN PTR scan19-vip.rac.libai. 35 IN PTR scan19-vip.rac.libai. 21 IN PTR vip19-node1.rac.libai. 22 IN PTR vip19-node2.rac.libai.写完后用named-checkzone校验格式再systemctl restart named。反解 zone 有个常被忽略的点PTR 记录里写的是短主机名还是 FQDN。必须写 FQDN 并带末尾点否则反向解析出来的是scan19-vip.rac.libai.rac.libai这种拼接错名节点互检照样报错。3.4 验证网络解析安装前从两个节点分别验证正解和反解[rootdb-oracle-node1 ~]# nslookup scan19.vip.rac.libai [rootdb-oracle-node1 ~]# nslookup 192.168.204.33 [rootdb-oracle-node1 ~]# nslookup 40.40.40.41 [rootdb-oracle-node1 ~]# ping -c 2 pub19-node2.rac.libai注意SCAN 的解析要在每个节点上测试不是只在 DNS 服务器上。安装检查脚本是逐节点跑的哪个节点解析不通哪个节点就被排除出集群。4. 从 ASM 磁盘到 gridSetup.shUDEV、GIMR 与 root.sh 的顺序4.1 UDEV 绑定 ASM 磁盘存储层面19c 的 ASM 磁盘可以用 ASMLib 也可以走 UDEV非 Oracle Linux 环境里 UDEV 是通用做法。把共享盘的属主和权限固定下来避免重启后盘符漂移或者权限不一致。[rootdb-oracle-node1 ~]# vi /etc/udev/rules.d/99-oracle-asm.rules KERNELsd*, SUBSYSTEMblock, PROGRAM/bin/sh -c echo -n $kernel, \ RESULTsdb, GROUPasmadmin, OWNERgrid, MODE0660 KERNELsd*, SUBSYSTEMblock, PROGRAM/bin/sh -c echo -n $kernel, \ RESULTsdc, GROUPasmadmin, OWNERgrid, MODE0660 [rootdb-oracle-node1 ~]# udevadm control --reload-rules [rootdb-oracle-node1 ~]# udevadm trigger按$kernel匹配盘名的问题在于盘符重启后会变多路径环境更明显。更可靠的写法是用ID_SERIAL或者/dev/disk/by-id里的 wwid 匹配规则写出来后udevadm test /dev/sdb验证一遍确认规则匹配到了目标盘。所有节点都要放同一份规则文件盘的属主一致grid 用户才能读写。磁盘分组设计上OCR 和 voting disk 一般单独放一个至少 30GB 的磁盘组比如 GRID数据库文件放 DATA 组。19c 虽然允许 OCR/voting 直接放共享文件系统但生产还是建议走 ASM运维习惯成熟也好排障。4.2 gridSetup.sh 的 GNS 页面与关键选项Grid Infrastructure 安装走gridSetup.sh到 Configure Cluster Mode 页面选 Standalone Cluster。接下来的 GNS 页面分两种情况固定配置模式下选择不配置 GNSSCAN 名直接填 DNS 里预置的scan19-vip.rac.libaiVIP 和 private 逐个指定。GNS固定模式下勾选 Configure GNSGNS IP 填192.168.204.10子域填vip.rac.libaiSCAN 名填scan19.vip.rac.libai。这里最容易出问题的就是 SCAN 名的子域部分必须包含 GNS 子域vip.rac.libai否则 GNS 不会响应这个名称的解析。网络接口检查页面会列出所有网卡确认 public 和 private 被正确识别。多个 private 网卡全部勾选19c 会用 HAIP 机制自动做负载均衡和故障切换这也是手册里说 private 不需要 bond 的原因。4.3 GIMR 选不选从 Hugepages 到空间都受影响19c Standalone Cluster 的 GIMR 是可选项。选了 GIMR集群里会多一个 MGMTDB 实例占约 1GB 内存用于 Hugepages 计算磁盘组里也要预留对应空间不选就没有这个负担。测试环境我建议直接不配省内存省事。生产环境看需求手册里也强调如果配置了 GIMR大页计算要把这 1GB 算进去。装完想补装 GIMR 是可以的但流程比一次装好麻烦实测里见过不少人后面又跑gipcDaemon去补不如安装时定下来。4.4 root.sh 的先后顺序与 rerun 注意gridSetup.sh 执行到 99% 左右会提示在两个节点上以 root 执行orainstRoot.sh和root.sh。顺序是第一节点先跑完再跑第二节点。第一节点跑root.sh时会创建 CSS第二节点跑的时候是加入已有集群顺序反了会报集群初始化失败。# 节点1 [rootdb-oracle-node1 ~]# /u01/app/oraInventory/orainstRoot.sh [rootdb-oracle-node1 ~]# /u01/app/19.0.0/grid/root.sh # 节点2 [rootdb-oracle-node2 ~]# /u01/app/oraInventory/orainstRoot.sh [rootdb-oracle-node2 ~]# /u01/app/19.0.0/grid/root.shroot.sh如果失败输出信息里会给出日志路径通常是$GRID_BASE/crsdata/$(hostname)/crsconfig/。大多数失败都能直接看日志定位。第二次重跑root.sh前确认上一轮残留的 crs 进程已经清干净可以用ps -ef | grep cssd检查残留。两节点都跑完后回到 gridSetup.sh 界面点 OK 完成。数据库实例创建用dbca选 RAC 数据库存储选 ASMPDB 按需创建。注意 dbca 用的ORACLE_HOME和ORACLE_SID要切到数据库 home 下别在 grid home 里跑。5. 安装避坑记录五个我实际碰到的典型问题安装这块的坑比想象中的多而且很多是过了检查才发现一返工就是重启机器。下面这些是我在 19c RAC 安装里实际踩过的手册里大多一行带过但实操占比很高。5.1 THP 忘了关现象环境检查全部通过数据库也起来了跑了几天后偶发 CPU 飙高alert 日志里出现莫名的 ORA-600free -g看到内存碎片严重。原因transparent_hugepagenever没写进/etc/default/grub或者写了但没重建 grub.cfg。THP 在后台做页合并和 Oracle 的共享内存管理打架业务一跑内存分配频繁问题就冒出来了。解决把参数加进 GRUB_CMDLINE_LINUXgrub2-mkconfig -o /boot/grub2/grub.cfg后重启然后确认/proc/cmdline里能看到transparent_hugepagenever且/sys/kernel/mm/transparent_hugepage/enabled显示[never]。从那以后我装完系统第一件事就关 THP不等 Oracle 安装文档提醒。5.2 memlock 配得太小导致 root.sh 失败现象gridSetup.sh 安装过程顺利最后 root.sh 在第一节点跑的时候报ORA-27125: unable to create shared memory segment重跑几次都一样。原因/etc/security/limits.d/里 grid 用户的 memlock 没配或者配了但值小于 Hugepages 总量。ASM 实例启动时要把共享内存锁进大页memlock 不够直接失败。ORA-27125 这个错误很容易被误判成 shmmax 配置问题其实内核参数全对就差 memlock。解决limits.d 里给 grid 和 oracle 用户都加上 memlock值取接近物理内存大小KB重新登录后用ulimit -l验证再重跑 root.sh。5.3 GNS 反解缺失导致 cluvfy 报 PRVG-11066现象安装前跑cluvfy.sh stage -pre crsinst输出里报PRVG-11066: Name resolution failed某个节点被标红检查建议里说要排查 DNS 解析。原因DNS 正解域配好了但私网网段40.40.40的反解 zone 没建或者 PTR 记录不全。GNS 在解析节点 IP 时不只查正解还要反查主机名反解一断就报名字解析失败。解决在 named.conf 里补上40.40.40.in-addr.arpa的反解 zonePTR 记录写 FQDN 带末尾点named-checkzone验证后重启 named再从节点上用nslookup 40.40.40.41反向查一次能返回priv19-node1.rac.libai才算过。5.4 ip_local_port_range 被临时改丢了现象安装过程中 OUI 报端口不可用检查cat /proc/sys/net/ipv4/ip_local_port_range发现只剩9000 65500但sysctl.conf里写的却是另一个值重启后设置被还原。原因之前为了验证直接用了echo 9000 65500 /proc/sys/net/ipv4/ip_local_port_range这是运行时修改没写进配置文件重启就丢反过来如果写进了配置文件但 sysctl 没重新加载当前生效值也是旧的。解决把端口范围写进/etc/sysctl.d/97-oracledatabase-sysctl.conf用sysctl --system统一加载然后sysctl -a | grep port_range确认当前值。装之前ss -lnt检查 9000-65500 范围内是否有应用端口冲突特别是监控或其他中间件占了高位端口的情况。5.5 Hugepages 设置过大导致系统内存耗尽现象按vm.nr_hugepages设了一个大数值后重启系统起来后内存几乎被占光数据库实例启动失败SSH 偶尔还能连上但执行命令很慢dmesg里能看到内存分配失败记录。原因Hugepages 从物理内存里预留出来预留太多了内核和其他进程拿不到内存。常见是把 64GB 机器按 60GB 配了 nr_hugepages加起来没算内核和文件缓存的最低需求。解决Hugepages 按 SGA GIMR如启用则加 1GB 2GB 内核预留计算不要拍脑袋填。半信半疑的时候就保守一点先挂 70% 的量系统起来后看grep HugePages /proc/meminfo确认HugePages_Total和HugePages_Free的余量再决定是否上调。6. 安装完成不等于上线五条自检命令与我的固定动作安装手册读完真正决定能不能交付的是装完后的验证。我装完 19c RAC 后会固定走一遍下面的检查每条都能看出一个层面的健康度。先看集群资源是否全部在线[rootdb-oracle-node1 ~]# crsctl stat res -t这条命令把集群里所有资源按层级列出来。重点看ora.asm、ora.cluster_vip_net1.type、ora.cssd、ora.ctssd和数据库资源是不是 ONLINE。19c 里出现ora.mgmtdb说明 GIMR 被启用了没配 GIMR 的环境看不到这个名字是正常的。如果某个资源显示 OFFLINE记下名字去$GRID_BASE/crsdata/$(hostname)/crsconfig下面找对应日志。再跑一遍集群验证工具确认节点互认和存储访问正常[rootdb-oracle-node1 ~]# $GRID_HOME/bin/cluvfy.sh stage -post crsinst -n node1,node2这步相当于把安装前的预检重新跑了一遍但检查维度不同主要验证集群已经正常组建。它会重新查一次节点可达性、OCR 读写、voting disk 心跳容错输出里如果出现 WARNING别直接跳过看是哪一类很多 WARNING 指向 DNS 反解不全或组配置不一致。磁盘组层面看 ASM 状态[rootdb-oracle-node1 ~]# asmcmd lsdg State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB MOUNTED NORMAL N 512 512 4096 4194304 307200 245760注意State必须是 MOUNTEDType是创建时选的冗余级别Total_MB和Free_MB对照一下确认 OCR/Voting 组和 DATA 组都正常挂载。如果磁盘组显示 DISMOUNTED优先看 ASM 的 alert 日志而不是急着asmcmd mount。数据库层验证客户端连接[rootdb-oracle-node1 ~]# sqlplus systemscan19.vip.rac.libai:1521/orclpdb用 SCAN 名连库是最真实的验证因为 SCAN IP 由 GNS 动态维护连不上说明 GNS 的解析链断了。能连上之后跑一次select name, open_mode from v$database;确认数据库是 READ WRITE 而不是 MOUNT 状态。最后检查名字解析的完整闭环[rootdb-oracle-node1 ~]# nslookup scan19.vip.rac.libai [rootdb-oracle-node1 ~]# nslookup 192.168.204.33正反解都要对GNS 模式下可以多执行两次nslookup scan19.vip.rac.libai观察返回的三个 IP 是否轮换如果三次都返回同一个 IP 说明 GNS 的负载分配有问题。这套动作做下来大概十分钟。装得多了就会发现大部分所谓装完没两天集群挂了的问题其实在装完那一刻就已经埋在系统里了只是没查出来。从那以后我每次装完 19c RAC 都强制走一遍crsctl stat res -t、cluvfy stage -post crsinst、asmcmd lsdg和 SCAN 连接验证不管安装界面显示没显示成功以这四条命令的输出为准。希望帮到你。本文还有配套的精品资源点击获取