19c RAC安装避坑：root.sh、CVU与SCAN/GNS

简介：Oracle 19c RAC on Linux 7.6 安装手册面向需要在 RedHat 7.6 上部署 Oracle 19c 集群的 DBA 与运维工程师，聚焦真实落地过程中的环境准备与网络配置难点。全文围绕 OS 环境检查、关闭 THP 并开启 Hugepages、软件包与内核参数配置、CVU 校验、GNS 配置 SCAN 等关键环节展开，同时介绍 Flex ASM 机制以及 12.2 之后 Standalone Cluster 与 Domain Service Cluster 两种集群模式的差异与版本演进，并给出配置受阻时的排查思路与分析方法。整份资料为单个 docx 文档，压缩包约 160KB，篇幅紧凑、条目清晰，适合作为随时查阅的操作清单。已有 719 人学习下载。读者可据此完成从系统检查、网络规划到集群建库的完整流程梳理，理解 GNS 与固定配置两种网络方案的取舍，并在遇到节点通信、SCAN 解析等异常时按手册中的分析路径定位问题，减少反复试错的时间成本。

1. 装到一半卡在 root.sh：19c RAC 在 Linux 7.6 上最常见的翻车点

19c RAC 在 Linux 7.6 上装到 root.sh 卡住，或者 CVU 预检查一上来就一片红，这类故障比想象中常见得多。很多人以为按手册顺序敲命令就行，结果在 THP、HugePages、SCAN 解析、UDEV 权限这几个地方反复翻车，一折腾就是一两天。这类问题最适合两类人看：第一次在 RedHat 7.6 上独立部署 19c 集群的 DBA，以及装过 11g、12c 但被 19c 的 Flex Cluster 和 GIMR 可选化改动绕晕的老手。下面按「现象—根因—解决」把几个高频坑逐个拆开，命令和配置都能直接抄，参数怎么改、改完看什么日志，也一并说清。

2. CVU 预检查报错：从 PRVE 到 PRVG 的逐条拆解

runcluvfy.sh 一跑，屏幕上刷刷几十条 failed，新手第一反应是重装系统或者换机器重来，其实绝大多数 PRVE/PRVG 类报错都能定位到具体某一项配置没做全。19c 的 CVU 检查比 12c 更细，尤其对 HugePages、THP、网络一致性和 /dev/shm 的校验更严格，先把检查项和实际配置对齐，比盲目重跑有效得多。

2.1 先读懂 CVU 报错码，别急着改

CVU 的输出格式是「检查项 + 节点 + 状态 + 报错码」，报错码前缀决定了排查方向。PRVE 开头的是先决条件校验失败，比如 PRVE-04213 指大页配置不满足，PRVE-04101 指内核参数不符；PRVG 开头的是运行时校验，像 PRVG-1101 是节点连通性问题；PRVF 是文件系统与权限类，比如 PRVF-7532 是缺少软件包。看码比看英文描述快，因为描述经常被截断。

我一般按这个顺序过一遍，把失败项收敛成可执行的清单：

# 以 grid 用户执行，先跑 fixup 让 CVU 尝试自动修复可修复项 ./runcluvfy.sh stage -pre crsinst -fixup -n node1,node2 -verbose # 只看失败项，过滤掉 passed，输出更清爽 ./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose 2>&1 | grep -i "failed" # 单独验证某项，比如验证 SSH 等价性 ./runcluvfy.sh comp nodereach -n node1,node2

-fixup参数会让 CVU 对它能处理的项目直接改系统配置，比如补 sysctl、调 limits，但它不会帮你装 RPM、不会帮你配 DNS，所以带 fixup 跑完还有红色项是正常的。-verbose必须加，否则你只能看到「Pre-check for cluster services setup was unsuccessful」，看不到具体是哪一项。执行用户必须是 grid 或 oracle，用 root 跑会被拒绝，这是很多人第一次就踩的坑。

2.2 THP 与 HugePages：两个经常被混为一谈的参数

19c 安装手册里 THP 和 HugePages 是两节，但实操中经常一起出问题。透明大页开启时，Oracle 的 SGA 会被内核合并成大页管理，导致内存分配抖动、节点驱逐，而 HugePages 又要求 memlock 足够，两个配置互相牵连。

先确认当前状态：

# 看 THP 是否开启，输出带方括号的就是当前生效值 cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag # 看大页配置和实际使用量 grep -i huge /proc/meminfo

输出如果是[always] madvise never，说明 THP 开着，必须关。关的方式不能只 echo 到 /sys，重启就没了，得写进内核参数：

# 备份原 grub 配置，这一步别省 cp /etc/default/grub /etc/default/grub.bak # 在 GRUB_CMDLINE_LINUX 后面追加，注意保留原有内容 vi /etc/default/grub GRUB_CMDLINE_LINUX="... 原有参数 ... transparent_hugepage=never" # 重建 grub 配置，BIOS 和 UEFI 机器路径不同，别搞错 grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器用这条 grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # 重启后验证，输出里能看到 transparent_hugepage=never 才算成功 cat /proc/cmdline

UEFI 和 BIOS 的路径搞混是高频错误，重建错文件重启后参数根本没生效，表现为「明明改了 grub 怎么还是 always」。重建前必须备份，grub2-mkconfig 偶尔会因为磁盘布局识别问题生成错误的 cfg，没备份就只能进救援模式。

HugePages 这边，19c 的 standalone 集群可以选择是否配 GIMR，如果配了 GIMR，那 1G 的 SGA 也要算进大页里，这是摘要里特别提到的一个变化点。计算方式是所有实例 SGA 之和除以大页大小（x86 上一般 2M），再留一点余量：

# 计算所需大页数，假设两个实例各 8G SGA，大页 2M # (8G + 8G) / 2M = 8192，再加 100 页余量 vi /etc/sysctl.conf vm.nr_hugepages = 8292 # 立即生效 sysctl -p # 配 memlock，值要不小于大页总量，单位 KB vi /etc/security/limits.conf oracle soft memlock 8491008 oracle hard memlock 8491008

memlock 单位是 KB，8G+8G 加余量大概是 8292×2M ≈ 16.2G，换算成 KB 就是 16900 左右，但别卡着临界值配，我给的这个数是按略宽裕算的。配完ulimit -l验证一下，grid 和 oracle 用户都要验，只配 oracle 不配 grid 是常见疏漏，grid 的 ASM 实例起不来会直接反映在 root.sh 阶段。

2.3 内核参数与软件包：preinstall RPM 能省事但别全信

手册里写了两种方式，一种用oracle-database-preinstall-19c自动配，一种手工写 sysctl.d 文件。我倾向先用 preinstall RPM，再补它没做全的部分，因为它会自动创建 oracle 用户、oinstall 和 dba 组、调 sysctl、设 limits、加 numa=off，能省掉一大半手工活。

# 配置 yum 源后直接装，注意版本要对上 7.6 cd /etc/yum.repos.d/ wget http://yum.oracle.com/public-yum-ol7.repo yum repolist yum install -y oracle-database-preinstall-19c # 装完确认内核参数落到了哪个文件，19c 一般在 sysctl.d 下 grep -r "kernel.shmmax" /etc/sysctl.d/ /etc/sysctl.conf

preinstall 有个坑：它会改/etc/sysctl.conf或者新建97-oracledatabase-sysctl.conf，但如果你之前在别处也写过同名参数，实际生效值以文件名字典序最后加载的为准，很容易出现「明明配了但 sysctl -a 看到的还是旧值」。查的时候一定要用sysctl -a | grep 参数名看运行时值，而不是只看文件内容。

手工配的话，内核参数至少这几项：

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

kernel.shmmax建议设成物理内存的一半或更大，4294967295 是 4G 上限的通用值，内存大的机器可以往上调。kernel.sem四个数分别是 SEMMSL、SEMMNS、SEMOPM、SEMMNI，改小了会在建库或者大量并发时出现 ORA-27154 之类的信号量错误。改完执行sysctl --system，别只sysctl -p，前者会按目录顺序加载全部文件，后者只读默认文件。

软件包这块，用rpm -q批量验证比一个个装快：

# 用 for 循环批量检查，缺哪个一眼看到 for pkg in bc binutils compat-libcap1 compat-libstdc++ elfutils-libelf \ elfutils-libelf-devel fontconfig-devel glibc glibc-devel ksh libaio \ libaio-devel libX11 libXau libXi libXtst libXrender libXrender-devel \ libgcc librdmacm-devel libstdc++ libstdc++-devel libxcb make \ net-tools nfs-utils smartmontools sysstat; do rpm -q $pkg >/dev/null 2>&1 || echo "MISSING: $pkg" done

compat-libstdc++在 7.6 上经常缺，libaio-devel缺了会直接导致 root.sh 报链接错误，net-tools是 RAC 必需的，少了ifconfig有些脚本会异常。跑完这个循环输出为空，才说明软件包齐了。

3. SCAN 与 GNS 连不上：网络配置类报错的定位路径

SCAN 解析不通、GNS 配完集群起不来，是 19c RAC 安装里最耗时的部分，因为网络问题往往要跨节点、跨 DNS、跨集群三层同时排查。摘要里提到 GNS 配置 SCAN 是这份手册的一个重点，而实际部署中，手工固定配置和 GNS 配置两条路线各有各的坑。

3.1 Public 与 VIP 命名规则引发的解析失败

19c 对名字的限制比老版本严格，Public、VIP 名称只允许字母数字和连字符「-」，下划线「_」不允许。这个规则写在手册里但很容易被忽略，主机名带了下划线，安装时 SCAN 配置页面直接报错，或者解析时能查到但集群不认。

另一个必须守住的红线：Public、VIP、SCAN VIP 必须在同一个子网段。跨子网配 SCAN，scan listener 起不来，客户端连 scan 时会随机超时，这个现象非常迷惑人，因为它不是每次都失败，而是三选一的概率性失败。

手工固定配置的 hosts 写法：

# /etc/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

Private IP 放在独立的 40.40.40 网段，是为了和 Public 分离，private 网络承载 Cache Fusion 流量，两个网段混在一起会导致心跳流量和业务流量抢带宽。VIP 和 Public 同网段，是因为 VIP 本质上是 Public 网卡的漂移地址，跨网段无法正常漂移。

验证解析一致性，两个节点上都要跑：

# 每个节点逐个解析，确保结果一致，顺序不能乱 for h in pub19-node1 pub19-node2 vip19-node1 vip19-node2 priv19-node1 priv19-node2; do echo "=== $h ===" getent hosts $h.rac.libai done

用getent hosts而不是ping，因为 getent 走的是系统解析链路，和集群的行为一致；ping 会受 ICMP 策略影响，网络禁 ping 但解析正常的环境里，ping 失败会误导你以为解析有问题。两个节点的输出必须完全一致，不一致就是某台机器的 hosts 或 DNS 有偏差。

3.2 GNS 配 SCAN：三行 zone 配置决定成败

GNS 的本质是让集群自己维护 VIP 和 SCAN 的 DNS 记录，省掉手工加 hosts 的活。但它对 DNS 的委派结构有硬性要求，配不对的表现是 GNS 起来了但 SCAN 解析不出来，或者 scan 域名解析到了错误的地址。

核心是两条记录，缺一不可：

# 在正解 zone 文件里加这两行 vi /var/named/named.rac.libai vip.rac.libai. IN NS gns.rac.libai. gns.rac.libai. IN A 192.168.204.10

这两行的含义是：vip.rac.libai这个子域的解析权威交给gns.rac.libai，而gns.rac.libai的地址是 192.168.204.10。前面所有 SCAN 域名必须落在这个子域下面，比如scan19.vip.rac.libai，这样集群注册的 SCAN VIP 记录才能被正确委派解析。

在 gridSetup.sh 配置 SCAN 的页面，要填的 GNS IP 就是 192.168.204.10，subdomain 填vip.rac.libai。很多人在这一步把 subdomain 填成rac.libai，结果 GNS 把记录注册到了根域，和委派设置冲突，SCAN 永远解析不出来。

反解 zone 也别漏，集群和部分诊断工具会做反向查询：

# named.192.168.204 中至少要有这些 PTR 12 IN PTR pub19-node2.rac.libai. 21 IN PTR vip19-node1.rac.libai. 22 IN PTR vip19-node2.rac.libai. 33 IN PTR scan19-vip.rac.libai. 34 IN PTR scan19-vip.rac.libai. 35 IN PTR scan19-vip.rac.libai.

SCAN 要三个 A 记录加三个 PTR，因为 19c 的 SCAN 默认三个地址，少配会导致 scan listener 数量不对，客户端连着连着就报连接池异常。

配完 DNS 一定要验证，别直接去跑安装：

# 正向解析，两个节点都要验 nslookup scan19.vip.rac.libai 192.168.204.12 # 反向解析 nslookup 192.168.204.33 192.168.204.12 # 检查 GNS 委派是否生效 dig @192.168.204.12 gns.rac.libai NS

nslookup时显式指定 DNS 服务器地址，避免系统默认的 resolver 缓存掩盖问题。三个 SCAN 地址全部解析成功、反解也成功，才去跑 gridSetup。

3.3 Private 网络与 HAIP：超过四块网卡会怎样

手册里提到安装过程最多支持四个 private interface 配 HAIP，超过四个的部分自动作为冗余。实际部署里双网卡 bond 和双独立网卡都能跑，但要注意一个细节：private 网络的 MTU 在两个节点上必须一致，且要和交换机配置匹配。MTU 不一致的典型现象是集群心跳偶尔超时，节点驱逐日志里出现IPC Send timeout，但网络 ping 大包又时好时坏。

验证 MTU 和连通性：

# 查 private 网卡 MTU，两节点必须相同 ip link show | grep -A1 priv # 用大包测试，-M do 禁止分片，能测出 MTU 不匹配 ping -M do -s 8972 -c 3 40.40.40.42

-s 8972是按 9000 MTU 算的载荷，减去 ICMP 头 28 字节。如果小包通大包不通，基本就是 MTU 或者交换机 jumbo frame 没开。这个坑在物理机直连和虚拟机环境下都遇到过，比解析问题更隐蔽，因为ifconfig看着一切正常。

4. UDEV 与 gridSetup 阶段的安装报错

网络和系统参数都过了之后，最容易被低估的是 UDEV 磁盘配置和 gridSetup 的图形界面阶段。19c 的 ASM 磁盘用 UDEV 绑定，权限不对或者规则没生效，安装程序在扫描磁盘那一步会空着列表，怎么点下一步都不行。

4.1 ASM 磁盘 UDEV 规则不生效的三种表现

UDEV 规则的坑有三种典型表现：一是 gridSetup 里 ASM 磁盘候选列表为空；二是能看到磁盘但权限是 root，grid 用户读不到；三是磁盘名在重启后变了，集群起不来。本质上都是规则文件的写法或加载时机有问题。

标准写法：

# /etc/udev/rules.d/99-oracle-asmdevices.rules # 用 blkid 查出磁盘 WWID，wwid 比 sd 名字稳定，不会随插槽变化 KERNEL=="sd*", SUBSYSTEM=="block", ENV{ID_WWID}=="3600xxxx", SYMLINK+="asm-disk1", OWNER="grid", GROUP="asmadmin", MODE="0660"

关键是三点：用ID_WWID或ID_SERIAL而不是/dev/sdb这类名字；OWNER必须是 grid，组用 asmadmin；MODE至少 0660。用 sdb 这类名字的问题在于服务器插槽或控制器顺序变化后，sd 名会变，规则就绑错磁盘，表现就是挂了的集群起不来。

应用规则：

# 加载并触发，注意先 reload 再 trigger udevadm control --reload-rules udevadm trigger --type=devices --action=change # 验证，下来要用 ls -l 看属主 ls -l /dev/asm-disk*

udevadm trigger必须带--action=change，只 reload 不 trigger，规则不会对已存在的设备生效。另外改完规则文件如果用的是vi直接覆盖，inode 变化可能导致某些场景下不重载，稳妥做法是先touch一下再 reload。

如果候选列表还是空，用lsblk和blkid交叉核对：

# 对比实际磁盘和规则里的 WWID 是否一致 blkid | grep -i "asm\|3600" lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

常见原因是磁盘被做了分区或被 LVM 占着，安装程序只能看到空闲块设备。另外多路径环境下，规则要绑到 multipath 设备而不是物理盘，绑错了会在 gridSetup 里看到一堆重复的空闲盘。

4.2 gridSetup.sh 报 INS- 类错误的排查顺序

gridSetup.sh 的 INS- 报错是最让人头疼的，因为它往往发生在图形界面跑到一半的时候，界面还退不出去。按这几个顺序看：

第一步，别急着关界面，先看$ORACLE_BASE/oraInventory/logs/下最新的 installActions 日志，里面有完整的调用栈。第二步，判断是环境问题还是挂载问题，INS-30011 一般是密码或口令复杂度不合规，INS-20802 是插件配置失败，多半跟前面说的 THP、memlock 有关。第三步，如果报错是「Failed to execute the root script」，去/u01/app/grid/oraInventory/logs/或者对应 grid home 下找rootcrs.sh的日志，那里面才有真正的原因。

有个很值得强调的做法：安装前先让 grid 用户跑一遍环境自检，而不是等安装器报错：

# 检查 grid 用户的环境变量和目录权限 id grid echo $ORACLE_BASE $ORACLE_HOME ls -ld /u01/app/grid /u01/app/19c/grid # 检查 /tmp 空间，19c 要求至少 1G df -h /tmp /dev/shm

/dev/shm的权限和大小经常被忽略，df -h /dev/shm看挂载类型，如果不是 tmpfs 或者权限不对，安装器会在配置阶段莫名其妙失败。/tmp至少 1G 是硬要求，很多精简安装的系统/tmp很小，跑 gridSetup 会卡在解压阶段。

4.3 runInstaller 与 dbca 阶段的衔接问题

grid 装完再跑 runInstaller 装数据库软件，这个阶段最常见的问题是 ORACLE_HOME 的路径和 grid home 冲突，或者环境变量残留。两个 home 不能同路径，也不能一个包含另一个，/u01/app/grid和/u01/app/19c/dbhome这种平行结构最稳。另外装完 grid 后，root.sh 执行完要验证 CRS 起来了再继续：

# 用 grid 用户验证集群状态 crsctl stat res -t # 检查节点和 VIP 是否正常 olsnodes -n -s srvctl config scan

crsctl stat res -t里所有资源都是 ONLINE 才算集群正常，如果有 OFFLINE 或者 INTERMEDIATE，先别急着装库，否则 dbca 建库时找不到 ASM 或者 OCR。srvctl config scan能看到三个 SCAN VIP 和 scan listener 数量，和你在 DNS 里配的对不上，说明 GNS 或固定配置有问题，这时候回头查第 3 章。

5. 排查避坑：五个反复踩的坑和它们的真面目

这一节把实际部署中最容易重复踩的坑集中写一下，每个都按「看到什么—为什么—怎么办」来，方便下次直接对照。

5.1 改了 sysctl 但 sysctl -a 显示旧值

现象：明明/etc/sysctl.conf里写了vm.nr_hugepages，sysctl -a看到的还是 0 或者旧值。

原因：19c preinstall RPM 会在/etc/sysctl.d/下放文件，加载顺序按文件名字典序，97-oracledatabase-sysctl.conf会覆盖/etc/sysctl.conf里的同名项。另外sysctl -p只读默认文件，sysctl --system才遍历目录。

解决：用sysctl --system重载，然后用sysctl -a | grep 参数名看运行时值。要改就统一改 sysctl.d 下的文件，别两处都写。

5.2 root.sh 卡在「Adding daemon to inittab」或 ASM 相关步骤

现象：grid 的 root.sh 跑到某一步直接卡住十几分钟不动，界面没有任何输出。

原因：八成是 memlock 或者 HugePages 配了但 grid 用户没生效，ASM 实例起不来在等资源；也可能是 /dev/shm 太小，集群通信初始化受阻。

解决：另开一个终端ps -ef | grep -i asm看有没有 asm 进程，没有就去/u01/app/grid/oraInventory/logs/找对应日志。顺手ulimit -l在 grid 用户下验一遍，df -h /dev/shm看大小。

5.3 SCAN 能 ping 通但客户端连不上

现象：ping scan19.vip.rac.libai通，但应用连 SCAN 时好时坏或者直接超时。

原因：SCAN 的三个 VIP 必须在同一子网且都在 public 网段上，如果反解记录不全或者 scan listener 数量少于三个，部分连接会落到没有监听的地址上。

解决：srvctl config scan核对三个地址，srvctl status scan_listener看 listener 状态，nslookup 反向解析逐个验 PTR 记录。三个地址的监听器都 ONLINE 才对。

5.4 UDEV 规则重启后失效

现象：第一次装的时候 ASM 磁盘都认到了，机器重启过一次后，集群起不来，ls -l /dev/asm-disk*报 No such file。

原因：要么规则里绑的是/dev/sdX名字，磁盘顺序变了；要么规则文件权限不对，udev 加载失败；要么用了多路径但规则没绑 multipath 设备。

解决：全改用 WWID 绑定，udevadm info --query=all --name=/dev/sdX查出稳定标识，改完udevadm control --reload-rules && udevadm trigger --action=change，再ls -l验证属主是 grid:asmadmin。

5.5 GNS 配了但 SCAN 域名不在委派子域下

现象：gridSetup 里 GNS 配置通过了，但装完客户端解析 SCAN 域名失败，dig返回 NXDOMAIN。

原因：SCAN 域名没有落在vip.rac.libai这个委派子域下面，比如配成了scan19.rac.libai，GNS 只对自己被委派的子域有权威，根域下的记录它管不到。

解决：SCAN 域名统一用<前缀>.vip.<域>格式，DNS 里确认vip.<域> IN NS gns.<域>和gns.<域> IN A <ip>两行都在，gridSetup 里 subdomain 填vip.rac.libai。

6. 下次再装，用这套顺序把问题拦在安装之前

装 RAC 这类集群，最省时间的做法不是装得快，而是把验证前置，让每个阶段的失败都能在几秒内定位到具体子系统。我自己的习惯是写一个粗略的分层检查顺序，按「系统参数—网络解析—存储可见性—集群状态」四层，装之前过一遍，装之后再过一遍。

系统参数层，看三个文件和一个命令：

网络解析层，两个节点各跑一遍getent hosts，结果必须完全一致，然后dig验正向、反解和 GNS 委派。存储层用blkid对比规则文件，再看ls -l /dev/asm-disk*的属主。集群层就一条crsctl stat res -t，全 ONLINE 再往下走。

真正值钱的是「安装器报错了先看哪里」这个顺序感。INS- 类错误先翻 oraInventory 下的 installActions 日志，root.sh 卡住先看 ASM 进程和 memlock，SCAN 连不上先验三个 VIP 和反解，ASM 磁盘看不到先 blkid 对 WWID。这四条路径覆盖了绝大多数现场情况，剩下的才是真正需要深挖的疑难杂症。

还有一个小习惯值得坚持：每改完一项配置，立刻用对应的验证命令确认一次，别攒着到最后一起验。装 RAC 的血泪经验就是，一次性改十项再重启，出问题时根本不知道是哪一项引起的，老老实实改一项验一项，虽然慢，但整体返工率低得多。这份手册把每个阶段该配的项、该落的文件、该验的点都列全了，按它的章节顺序走，中间别跳步，比自己拼凑资料省心。希望帮到你。

本文还有配套的精品资源，点击获取