简介：《Oracle 19c RAC on Linux 7.6安装手册》是一份针对Red Hat 7.6环境部署Oracle 19c RAC的实战文档，面向需要搭建高可用集群的DBA、系统管理员及运维工程师。文档以图文步骤完整覆盖从系统环境检查、关闭THP并开启Hugepages、安装依赖包、配置内核参数到网络规划（固定IP及GNS+固定）的关键环节，目录结构清晰，依次涉及OS检查、内核与软件包准备、网络配置、杂项配置、时钟同步等模块。同时穿插介绍Flex ASM特性、12.2集群模式（Standalone与Domain Service）的演进差异，并给出配置过程中常见问题的定位与排查方法。整份资料为单个docx文件，约160KB，内容高度浓缩，适合希望少走弯路、快速掌握RAC+GNS部署要点的实践者。目前已有716人学习下载。
1. 先搞懂集群模式再动手：19c RAC 与 Linux 7.6 的系统准备量
装 Oracle 19c RAC on Linux 7.6，真正费时间的从来不是 gridSetup.sh 那两个小时，而是进安装程序之前那一小时的系统巡检——THP、Hugepages、内核参数、DNS、UDEV，任何一项没弄干净，预检就会以各种诡异的方式报警。这份资源把 Red Hat 7.6 / Oracle Linux 7.4+ 上 19c RAC 的完整落地流程串起来了，三个关键点：Standalone 与 Domain Services Cluster 怎么选、GNS 配置 SCAN 的完整链路、以及装完之后的排障手法。适合正在搭两节点 RAC 的 DBA，也适合刚接手集群环境、想知道哪些配置能偷懒、哪些必须手工盯住的系统管理员。
顺便说一句：19c 安装前别急着敲命令，先把集群模式想清楚。从 12.2 开始，集群分 Standalone Cluster 与 Domain Services Cluster（DSC）两种模式，前者最多 64 节点、每节点直连共享存储、GIMR 在 19c 变成可选项；后者则是中心化的服务集群，由 DSC 提供 ASM 存储、MGMTDB 和 TFA，成员集群通过物理直连或 ASM IO Service 网络路径访问分片存储。这一步选错，后面拆一半重来是常有的事。
2. 系统环境准备：THP、Hugepages 与内核参数的落地配置
从拆过的安装记录看，RAC 预检失败八成集中在操作系统层，而且报错往往不在真正的问题上——内存不足的提示可能来自 SWAP 没算 Hugepages，包缺失的提示可能来自内核参数没生效。所以系统准备阶段宁可多花半小时一条条对着看，也不要装了三个小时再回来返工。
2.1 环境检查清单：内存、SWAP 与 /dev/shm 的 10 分钟核对
原手册开头有一张环境检查表，我把最关键的几项压成下面这张表，动手前逐条过掉。
| 检查项 | 要求 | 命令 |
|---|---|---|
| RAM | 至少 8G | grep MemTotal /proc/meminfo |
| 运行级别 | 3 或 5 | runlevel |
| Linux 版本 | OL 7.4（UEK4/UEK5/RHCK）或 RHEL 7.4+ | uname -rm; cat /etc/redhat-release |
| /tmp | 至少 1G | du -h /tmp |
| SWAP | 4G~16G 取等于 RAM，超过 16G 取 16G | grep SwapTotal /proc/meminfo |
| /dev/shm | 挂载类型与权限正常 | df -h /dev/shm |
| 软件空间 | grid 至少 12G，Oracle 至少 10G，建议预留 100G | df -h /u01 |
Red Hat 7.6 的内核是 3.10.0-957 起步，高于手册里 7.4 的基线（3.10.0-693.5.2.0.1.el7），所以内核版本这条直接满足。SWAP 那条有个容易忽略的联动：如果启用了 Hugepages，校验 SWAP 前要先算出 Hugepages 占用的内存并从 SWAP 总量里减掉，否则按物理内存等配 SWAP 会偏小。19c Standalone 的 GIMR 是可选项，不配 GIMR 时 Hugepages 预算不用额外留；但按 Domain Services Cluster 装时，GIMR 的 SGA 会占 1G 左右，这 1G 要提前算进 Hugepages 里，不然启动后会有一截共享内存被换出去，性能很难看。
2.2 关闭 THP 开启 Hugepages：从 GRUB 到 memlock 的完整链路
为什么非关不可：THP 在 RHEL/OEL 7 默认是 enabled（[always]），它会在后台自动把 4KB 页合并成大页，对数据库来说是黑匣子——你以为自己在管理 SGA，其实 kernel 在替你改内存布局。很多「负载一高就卡一下」的诡异现场，最后都落在 khugepaged 碎片整理上。生产环境建议明确关闭并换用标准 Hugepages。
# 先确认当前状态，[always] 表示透明大页正开启 cat /sys/kernel/mm/transparent_hugepage/enabled # [always] madvise never # 编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 末尾追加参数 # GRUB_CMDLINE_LINUX="... transparent_hugepage=never" vi /etc/default/grub参数追加后别急着重启，先重建引导配置：
# BIOS 机器 grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器（路径不同，别抄错） grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg shutdown -r now # 重启后唯一有效的验证：看 /proc/cmdline 里有没有失效参数 cat /proc/cmdline | tr ' ' '\n' | grep transparent # 期望输出 transparent_hugepage=never注意：只改 /etc/default/grub 而不重建 grub.cfg，重启后参数不会进内核 cmdline，这类「改了等于没改」是 THP 环节最常见的翻车。另外 RHEL 7 默认的 tuned 服务会在启动阶段重新应用调优 profile，个别 profile 会反手把 THP 打开，所以验证时要连同 enabled 文件一起看，不要只看 cmdline。
提示：Hugepages 与 THP 是两套机制。THP 是内核自动管理的透明页，Hugepages 是你预分配、应用独占的大页。RAC 里这两者并存时，THP 必须关，Hugepages 必须开，顺序不能反。
然后配置标准大页：
# 按实例内存计算后写入 vim /etc/sysctl.conf vm.nr_hugepages = 512 sysctl -p grep HugePages_Total /proc/meminfo # memlock 上限：单位 KB，建议直接给 unlimited vim /etc/security/limits.conf oracle soft memlock unlimited oracle hard memlock unlimited grid soft memlock unlimited grid hard memlock unlimitedhugepages 数量的估算公式，我一般把 SGA+PGA 上界加起来，除以 2MB，向上取整后加 2~4 页余量；如果这台机器还跑别的数据库实例，把所有实例的内存都加进再算。memlock 设 unlimited 省得反复对齐 KB 数——很多同学把 memlock 设成具体数值后发现 hugepages 只能起来一部分，就是 KB 换算错了。
2.3 内核参数：Preinstall RPM 自动配置与手工 sysctl 的取舍
如果你用的是 Oracle Linux 7，最省事的路子是直接装 preinstall 包：
cd /etc/yum.repos.d/ wget http://yum.oracle.com/public-yum-ol7.repo yum repolist yum install -y oracle-database-preinstall-19c这个包会把内核参数、limits、numa=off、用户和组一次性配好，省得手工一项项对。但注意它只存在于 Oracle Linux，Red Hat 7.6 上没有官方对应的包，纯 RHEL 环境只能手工来。另外装了 preinstall 不等于万事大吉——它配的 shmmax 偏保守，如果你的 SGA 计划超过 4G，还是得自己改。
手工配置内核参数，先把文件建出来：
vim /etc/sysctl.d/97-oracledatabase-sysctl.conf| 参数 | 推荐值 | 说明 |
|---|---|---|
| fs.aio-max-nr | 1048576 | 异步 I/O 请求上限，RAC 跑在 ASM 上必须够大 |
| fs.file-max | 6815744 | 全局文件句柄数 |
| kernel.shmall | 2097152 | 共享内存页数，与 shmmax 联动 |
| kernel.shmmax | 4294967295 | 单段共享内存上限，SGA 超 4G 时建议放大到物理内存的一半 |
| kernel.shmmni | 4096 | 共享内存段数量 |
| kernel.sem | 250 32000 100 128 | 信号量四元组，照抄即可 |
| net.ipv4.ip_local_port_range | 9000 65500 | RAC 节点间通信端口范围，默认 32768 起步偏窄 |
| net.core.rmem_default / rmem_max | 262144 / 4194304 | socket 接收缓冲区 |
| net.core.wmem_default / wmem_max | 262144 / 1048576 | socket 发送缓冲区 |
改完必须重载并验证：
sysctl --system sysctl -a | grep -E "kernel.sem|kernel.shmmax|ip_local_port_range"顺带一提，原手册里 CVU 也是这个阶段的可选动作：把 GRID_HOME/cv/rpm 下的 cvuqdisk 包装到每个节点，再跑 runcluvfy.sh stage -pre crsinst -fixup -n node1,node2 做预检。这个工具的输出当正式安装前的最后一次体检，预检不过别硬装，回来看上面那张表。
3. 网络规划是 RAC 的灵魂：固定 IP 与 GNS 两种方案怎么选
网络规划决定 RAC 装完是省心还是折腾。两节点 RAC 最少要三种 IP：Public（业务）、Private（心跳）、VIP；SCAN 又分固定三个 IP 或交给 GNS 自动生成。选固定还是 GNS，其实取决于你手头有没有一个愿意配合的 DNS 管理员——如果你所在的团队掌控 DNS，GNS 能省掉后面大量 hosts 维护；如果控制不了，就走固定配置，稳稳当当。
3.1 固定 IP 方案：手工写全 hosts，DNS 只解析 SCAN
固定方案的定位：Public/Private/VIP 全部手工分配并写进各节点 /etc/hosts，DNS 只负责解析 SCAN，gridSetup.sh 里全部手工指定。19c 的 VIP 规则先划重点：从 18c 开始 VIP 可选，但必须全员配或全员不配，不能这台配那台不配；VIP 在故障切换时依赖漂移，不配的话就要靠客户端重连逻辑兜底。
# /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固定方案里 SCAN 三个 IP 必须在 DNS 里做 A 记录，不要只写进 hosts。如果 DNS 暂时不可用，可以把 SCAN 也写进 hosts 顶一阵，但所有节点的 hosts 必须完全一致，且 SCAN 解析出的三个 IP 顺序不影响工作——DNS 轮询效果更好。
3.2 GNS 子域委托：named.conf 正反解与 SCAN 域名的写法
GNS 的原理一句话：你告诉 DNS「vip.rac.libai 这个子域由 GNS 服务器负责」，然后 VIP、Private、SCAN 这些地址由 GNS 自动分配和注册，不用再手工写死。它的前提是你有一个可控的 DNS 服务器来做子域委托，原手册用的是 bind + chroot。
先装 bind：
yum install -y bind bind-chroot vi /etc/named.confnamed.conf 里最少要定义四个 zone：一个根提示，一个正解域，外加两个反解域（public 网段一个、private 网段一个）：
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 { type master; file "named.192.168.204"; }; zone "40.40.40.in-addr.arpa" IN { type master; file "named.40.40.40"; };正解文件是 GNS 配置的戏眼，最后两行千万别漏：
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 pub19-node1.rac.libai. IN A 192.168.204.11 pub19-node2.rac.libai. IN A 192.168.204.12 priv19-node1.rac.libai. IN A 40.40.40.41 priv19-node2.rac.libai. IN A 40.40.40.42 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 本身有一个固定地址。稍后在 gridSetup.sh 里填 GNS 地址 192.168.204.10、子域 vip.rac.libai，SCAN 名字填 scan19.vip.rac.libai——注意 SCAN 的完整域名必须落在委托子域内，这是 GNS 配置的硬前提。固定方案里你可能会写 scan19-vip.rac.libai，GNS 方案里必须是 scan19.vip.rac.libai 这种带圆点子域的格式，别混。
反解文件同样要配：
vi /var/named/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. 11 IN PTR pub19-node1.rac.libai. 21 IN PTR vip19-node1.rac.libai. 22 IN PTR vip19-node2.rac.libai.我在实际配置里踩过一个无语的问题：bind 的 zone 文件权限不对（root 创建、named 用户读不了）导致区加载失败，日志里报 permission denied，排了半天。所以配完之后养成习惯用 named-checkzone 先验：
named-checkzone rac.libai /var/named/named.rac.libai systemctl restart named dig @127.0.0.1 scan19.vip.rac.libaidig 能返回三个 A 记录、没有 SERVFAIL，才说明子域委托链路通了。
3.3 命名与网段约定：安装程序不会告诉你的四个注意点
从原手册的网络配置说明里提炼几条容易在前期规划踩坑的规则：
- 网卡命名走字母数字加中划线，「-」可以，「_」不行——Public/VIP/SCAN 的名字含下划线，gridSetup 直接不认。
- Public/VIP/SCAN 必须同一子网；Private 独立网段，不建议跟业务网段混。
- Private 网卡可以不绑定 bond。过去总觉得心跳必须链路聚合，实际上 Grid Infrastructure 的 HAIP 机制最多支持 4 个私网 interface 做冗余，配多了的网卡自动当备用，减少一层 bond 维护负担。
- 要么全员 IPv4，要么全员 IPv6，混用会让 GNS 生成的地址陷入解析混乱；GNS 虽然能生成 IPv6 地址，但生产环境我一般保持 IPv4 单栈。
4. 安装前杂项一次做齐：用户组、limits、时钟与 UDEV 磁盘
原手册把这一堆配置散在「其他配置」一节里，但它们其实是同一件事：让安装程序在干净、可预测的系统状态里跑完。Flex ASM 从 12.1 起就成了 Grid Infrastructure 的一部分，意思是某个节点的 ASM 实例异常时可以由另一个节点的实例接管，每个节点不再需要单独维护一套 ASM 配置。正因如此，ASM 磁盘的设备名和权限必须在所有节点上完全一致——这就是 UDEV 规则的用武之地。
4.1 用户组、目录与 limits.conf
先建组再建用户：
groupadd -g 54318 oinstall groupadd -g 54319 dba groupadd -g 54320 oper groupadd -g 54321 asmadmin groupadd -g 54322 asmdba groupadd -g 54323 asmoper useradd -u 54318 -g oinstall -G dba,oper grid useradd -u 54319 -g oinstall -G dba,oper,asmadmin,asmdba oracle注意：grid 用户只加 dba 和 oper；oracle 用户才需要 asmadmin/asmdba 组合，用于数据库实例注册到 ASM。组 ID 与用户 ID 用 54318/54319 这类大号 UID 是为了与别的系统用户错开，避免 NFS 场景下的 UID 冲突，生产上建议固定。
目录结构 19c 与 12c 一脉相承：
mkdir -p /u01/app/19c/grid mkdir -p /u01/app/oracle chown -R grid:oinstall /u01/app/19c chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u01/applimits.conf 是原手册单独列了一节的配置，我在两个节点上分别做同一套：
vim /etc/security/limits.d/99-oracle-rac.conforacle soft nofile 65536 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384 grid soft nofile 65536 grid hard nofile 65536 grid soft nproc 16384 grid hard nproc 16384 oracle soft memlock unlimited oracle hard memlock unlimited grid soft memlock unlimited grid hard memlock unlimitedmemlock 这项在 THP 那节提过，这里再次强调它与 Hugepages 的联动：memlock 小于 hugepages 总容量时，大页只起一部分，且启动后没有报错提示，属于典型的「看起来正常、实际没吃到」配置。
4.2 时钟同步、I/O Scheduler 与 SSH 超时
RAC 节点间通信依赖时钟一致性，时间差过大会引起 reconfiguration 甚至脑裂。19c 推荐用 chrony 而不是老掉牙的 ntpd：
yum install -y chrony systemctl enable --now chronyd chronyc sources -v每个节点都要指向同一组时间源，跑一轮 chronyc makestep 把初始偏差抹平，再装 grid 前把两个节点时间差控制在秒级以内。
I/O Scheduler 这道配置很多人会跳过去——ASM 磁盘直连裸盘时，内核 IO 调度器默认是 CFQ，对数据库这种随机 IO 负载不公平。改成 deadline：
echo deadline > /sys/block/sdb/queue/scheduler # 永久生效写进 udev 规则 echo 'ACTION=="add|change", KERNEL=="sd*", ATTR{queue/scheduler}="deadline"' >> /etc/udev/rules.d/60-io-scheduler.rulesSSH 超时属于「装到一半才想起」型问题。gridSetup 在配置互信时会建立多段 SSH 会话，如果 sshd 默认的空闲超时太短，长时间停在图形界面思考人生，会话断了，安装程序会报连接重置。我在 /etc/ssh/sshd_config 里加了：
ClientAliveInterval 300 ClientAliveCountMax 2改完重启 sshd 不影响现有会话，grid 进程自己会建新会话。
4.3 UDEV 手工配置 ASM 磁盘：共享盘权限的根治方案
ASM 实例发现磁盘走的是 /dev/asm* 这种固定设备名，而不是 /dev/sdb，所以必须用 UDEV 或 ASMLIB 统一命名并赋权。原手册给的 UDEV 方案适用 Red Hat 7.6（ASMLIB 在 RHEL 上不好装，UDEV 是更通用路线）。
第一步拿到每个共享盘的稳定标识：
# 常见做法：用 scsi_id 拿 WWID /usr/lib/udev/scsi_id -g -u -d /dev/sdb # 或直接看 /dev/disk/by-id/ 下的软链 ls -l /dev/disk/by-id/第二步写规则：
vim /etc/udev/rules.d/99-oracle-asm.rulesKERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d $devnode", \ RESULT=="3600508b1001c1234567890abcdef", NAME="asm-disk1", OWNER="grid", GROUP="asmadmin", MODE="0660" KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d $devnode", \ RESULT=="3600508b1001c1234567890abcdef2", NAME="asm-disk2", OWNER="grid", GROUP="asmadmin", MODE="0660"规则生效：
udevadm control --reload udevadm trigger ls -l /dev/asm*两个坑先记下：一是 PROGRAM 路径在 RHEL 7 是完整路径 /usr/lib/udev/scsi_id，写成 /sbin/scsi_id 会导致规则静默失败，这是老文档里最常见的历史遗留写法；二是如果共享存储走 multipath 或者存储厂商的多路径工具，设备节点是 dm-，规则却匹配 sd，结果就是磁盘在 ASM 里「看得到厂商型号、看不到设备」。多路径环境要把规则建立在 multipath 之后的映射设备上，规则里 KERNEL=="dm-*"，再用 /dev/mapper 或 multipath 的 WWID 做匹配。
4.4 图形界面、X11 Forward 与 Direct NFS：安装入口的三个现实问题
gridSetup.sh 和 runInstaller 都要图形界面。不少人习惯 ssh -X 到节点上直接跑，结果卡白屏或者窗口弹不出来。原手册里专门建议关闭 X11 Forward，实际经验是：不是 X11 不能用，而是转发链路上的字体和窗口管理器缺失会让安装程序渲染出问题。更稳的做法是用 VNC 或者在装有图形桌面的本机控制台上跑。
Direct NFS（dNFS）用在 NAS/NFS 共享存储场景。19c 的 Standalone 集群允许把 OCR 和投票文件直接放在共享文件系统上，这时候启用 Direct NFS 能绕过系统 NFS 客户端的锁定问题。配置方法不复杂：在 grid 的 ORACLE_HOME 下放一个 oranfstab 文件，逐行写 NFS 服务器和导出路径，再重启 ocssd 让配置生效。如果没做这一步，共享文件系统上的 OCR 在节点重启时偶发 hang 也不是没遇到过。
5. 避坑排查：19c RAC 安装最容易翻车的 5 个现场
系统准备的每个环节都检查过了，不代表安装一定顺畅。下面 5 个现场是拆这份资源时最常遇到的，前两个出现在预检，后三个出现在安装中后期，按顺序排查能省很多时间。
5.1 预检反复报警：内存、软件包与 sysctl 单项不过
现象：runcluvfy.sh stage -pre crsinst 打印一串 FAILED，逐条看下来既有内存不足，又有缺少软件包，还有 kernel.sem 的值偏小。单独修完某一项，重跑预检又冒出新的失败，仿佛在跟它打地鼠。
原因：多数是系统准备阶段没有「一个节点过一个节点」地落地，比如改 sysctl 只改了第一个节点就复制 hosts 去装第二个；或者手册里列的包名是 Oracle Linux 的，RHEL 7.6 上对应包名不同导致 yum 安装实际没生效。sem 值偏小则通常是早期某个脚本临时改过 /proc/sys/kernel/sem，sysctl.conf 里却没有对应条目。
解决：把第二章那张环境检查表当清单，两个节点逐项打完勾再跑预检；RHEL 环境用 rpm -qa 核对已装包而不是只信 yum install 的返回值；sysctl 改完一定 sysctl --system 重载。跑预检时如果看到 fixup 提示，逐条确认它要修的是什么再让它执行，别盲目接受所有自动修复。
5.2 THP 关了又「复活」：tuned 服务与内核参数两条链路的拉扯
现象：/proc/cmdline 里已经有 transparent_hugepage=never，重启之后 /sys/kernel/mm/transparent_hugepage/enabled 显示的却还是 always，或者 HugePages_Total 一直起不来。
原因：RHEL 7 的 tuned 服务在系统启动尾声会实施它的 profile，常见的 throughput-performance 配置会把 THP 重新打开，覆盖了 GRUB 传入的内核参数；另外 Hugepages 起不来往往不是 THP 的问题，而是 memlock 或 vm.nr_hugepages 里写的数值不对。
解决：先检查 tuned 是否在跑（systemctl status tuned），在跑就把 THP 相关参数写进对应的 tuned profile，或者生产环境直接禁用 tuned。Hugepages 那侧按 2.2 的公式重新核算 nr_hugepages，再 grep HugePages_Total 确认数量。两者都检查完再重启一次——RAC 集群初始化阶段重启最划算，装到一半再重启才叫事故。
5.3 ASM 磁盘设备不生成：UDEV 的 PROGRAM 路径与 multipath 场景
现象：udevadm trigger 执行完，ls /dev/asm* 什么也没有；或者某些节点有、某些节点没有；或者 ASM 磁盘组创建时设备能枚举但权限不足。
原因：最常见的是 PROGRAM 写成了 /sbin/scsi_id，RHEL 7 实际路径是 /usr/lib/udev/scsi_id，规则静默失败；另一种是用存储多路径后，设备在 /dev/mapper 下面，而规则还是按 sd* 匹配，触发条件压根对不上。
解决：先把规则简化到最小可运行：一条磁盘、一个规则，PROGRAM 和 RESULT 严格对应 scsi_id 输出；跑 udevadm test /block/sdb 看规则有没有被应用；确认 multipath 设备改用 dm-* 匹配并指向 /dev/mapper 路径。我在多个环境里踩过这条路，简化规则比一口气写十条更管用。
5.4 GNS 与 SCAN 域名解析失败：子域委托没生效
现象：gridSetup.sh 走到 GNS 配置那步，输入子域 vip.rac.libai 和 GNS 地址后报错，说 SCAN 名 scan19.vip.rac.libai 无法解析；或者前期测试正常，安装完成后客户端连接数据库偶发失败。
原因：第一，正解文件里少了委托记录（vip.rac.libai. IN NS gns.rac.libai. 和 gns.rac.libai. IN A ...）或 NS 记录的域名缺根点；第二，gridSetup 里填的 SCAN 域名没有真正落在委托子域内，比如写成 scan19-vip.rac.libai（中划线）而委托的子域是 vip.rac.libai（圆点），当然解析不了；第三，反解域没配或者 PTR 记录缺失，GNS 启动时的反向验证失败。
解决：在 DNS 服务器上用 dig @127.0.0.1 scan19.vip.rac.libai 确认能返回 3 个 A 记录；再 dig -x 192.168.204.162 确认反解存在；最后检查 SCAN 全名格式，GNS 方案必须是 scan19.vip.rac.libai 而不是 scan19-vip.rac.libai。安装程序这步卡住的十有八九是第三种，填域名前先自己拿 dig 测一遍，不要指望安装程序帮你判断。
5.5 图形界面弹不出来：DISPLAY、X11 与 VNC 的选择
现象：ssh -X 到节点执行 ./gridSetup.sh，窗口显示几秒就消失，或者画面空白、按钮不可点，有时还伴随字体报错。
原因：图形转发链路上的 X 客户端组件不全（xorg-x11-fonts 缺失），DISPLAY 环境变量没有传递到目标节点，或 X11 Forward 与 sshd 配置的交互问题。原手册建议关闭 X11 Forward 不是禁用图形安装，而是让你换一条更稳的显示链路。
解决：本机有显示器和桌面环境就直接在控制台跑；远程环境我用 VNC 起一个固定桌面再跑安装，比 ssh -X 稳得多。如果非用 X11 不可，至少 export DISPLAY=:0.0 并确认目标机器装了 xterm 和 xorg-x11-fonts-*。
6. 装完别急着下班：节点重启回归与集群健康验证
安装程序跑完 gridSetup.sh、root.sh 和 dbca 只是第一步，这时的「装完能起」和上线后的「重启还能起」是两件完全不同的事。我的习惯是把下面这套验证流程跑完，才算真正交付。
先看集群资源全景：
crsctl status resource -t # 期望输出：ora.network、ora.asm、ora.cssd、ora.diskmon 等全部 ONLINE检查 OCR 完整性：
ocrcheck # 期望输出中出现 Status of Oracle Cluster Registry is as follows，Version 正常验证 SCAN 与 VIP 解析：
dig +short scan19.vip.rac.libai # 期望返回 3 个不同的 IP crsctl status resource ora.scan1.type -v然后强制做一次节点重启回归：将 node2 shutdown -r now，等它启动后 30 分钟内持续观察，让集群自动做资源接管和恢复。回归完再查一遍 crsctl status resource -t，同时用 asmcmd lsdg 确认磁盘组还是 MOUNTED，srvctl status database -d orcl 确认实例在两个节点上都 OPEN。
最后跑一次正式的 post-check：
$GRID_HOME/bin/cluvfy stage -post crsinst -n node1,node2 $GRID_HOME/bin/cluvfy comp ocr这套流程帮我拦下过不止一次问题：有一个环境就是节点重启后一个 VIP 卡在 UNKNOWN 状态，另一个实例自动注册失败，而重启前所有检查都是绿的。从那以后，每次装完 RAC 我都强制走一遍节点重启回归，把「装完能起」和「重启还能起」两件事分开验收，再没被这类问题半夜叫醒过。希望帮到你。
本文还有配套的精品资源，点击获取
