简介：《Oracle 19c RAC on Linux 7.6 安装手册》面向需要在 Red Hat Enterprise Linux 7.6 上搭建 19c RAC 的数据库工程师与运维人员，重点解决 GNS 配置 SCAN、Flex ASM 使用以及集群模式选型三类实际问题，适合具备一定 Linux 与 Oracle 基础、希望独立完成整套集群部署的中高级读者参考。包内为 1 个 docx 文档，约 160KB，按操作系统环境检查、关闭 THP 并开启 Hugepages、安装软件包与内核参数配置、网络配置、时钟同步等章节逐步展开；网络部分同时给出固定配置与 GNS 加固定配置两种方案，并附 CVU 校验说明。除标准安装流程外，文档还说明了 12.2 之后 Standalone Cluster 与 Domain Service Cluster 两种集群模式的差别，梳理各版本演进，并记录了配置过程中遇到问题的分析思路与解决办法，可作为部署时的对照清单与排错参考。目前已有 719 人学习下载。
1. 从 Flex Cluster 说起：这套 19c RAC 安装手册解决什么问题
两台机器、Linux 7.6、要装一套 19c RAC——听上去是标准动作，真到动手，卡人的常常是 gridSetup.sh 前面的那些基础动作：THP 有没有关干净、hugepages 算没算对、SCAN 的域名到底该委托给谁。这份《Oracle 19c RAC on Linux 安装手册》把从 OS 环境检查到 gridSetup.sh、runInstaller、dbca 的整条链路拆成了 11 个步骤，命令和配置片段基本可以直接抄。
19c 之后集群形态有变化：12.2 起分 Standalone Cluster 和 Domain Services Cluster 两条路线，Standalone 支持 64 节点、各节点直连共享存储，而且 19c 的 Standalone 可以把 GIMR 做成可选项，OCR 和 voting disk 也能直接放共享文件系统。这些差异直接决定你要不要给 GIMR 预留那 1G 的 SGA、hugepages 该按几个实例算。手册面向的是要自己搭一套测试或准生产 RAC 的 DBA 和系统工程师，Linux 基础操作得熟，但 RAC 安装经验不一定要很深。
1.1 手册覆盖的配置链路
把这套手册的目录摊开看，它实际解决的是一条“装前基线 → 网络解析 → 图形化安装”的链路：OS 资源检查、THP 与 hugepages、软件包、内核参数、CVU 校验、网络与 GNS、时钟同步、IO Scheduler、SSH 超时、limits.conf、X11、Direct NFS、UDEV 绑 ASM 盘，最后落到 gridSetup.sh 与 dbca。这里面每一环单独看都不复杂，串起来才要命——前面某一环配错，CVU 会在最后一步给你一个语焉不详的报错，然后你只能从日志里往回倒推。
我一般把这条链路理解成三层：底层是内核与资源限制（THP、hugepages、sysctl、limits），中间是网络与命名解析（hosts、DNS、GNS、SCAN），上层才是 GI 和 DB 的图形化安装。下两层没扎稳，上层怎么点都是白搭。
1.2 两种集群模式，选型决定后面所有参数
Standalone Cluster 是最常见的形态：节点都直连共享存储，各自跑自己的 ASM 实例，本地管 GIMR（19c 可选不配），VIP 和 SCAN 可以手工配也可以交给 GNS。Domain Services Cluster 则是把网格基础架构管理存储库、TFA、ASM 存储管理服务、RHP 集中到一组节点上，再由一个或多个 Database Member Cluster 去消费这些服务。
选型影响很具体：走 DSC 就得给 GIMR 和 MGMTDB 留资源，hugepages 要把 GIMR 的 1G SGA 算进去；走 Standalone 且不配 GIMR，hugepages 只按数据库实例的 SGA 算就行。手册在说明章节把这两种模式讲清楚了，后面所有参数才有依据。先定模式，再算参数，最后才动系统，顺序反了就得返工。
2. 装前基线：OS 检查、THP 关闭与 Hugepages 落地
装 RAC 之前的系统基线，是整篇手册里最容易被跳过、也最容易在最后一步报复你的部分。这一章把 OS 资源检查、THP 禁用、hugepages 三件事拆开讲清楚，每一件都给出可执行的命令和判断标准，跑完这一章，你应该能回答“这台机器到底够不够装、内核有没有配干净”这两个问题。
2.1 资源与目录基线检查
手册列的第一张表就是硬指标：RAM 至少 8G、运行级别 3 或 5、内核版本有下限、/tmp 至少 1G、swap 按内存大小分档、/dev/shm 挂载类型要对、grid 至少 12G、Oracle 至少 10G 空间（建议直接给 100G 预留）。这些数字不是摆设，CVU 会逐条核对，任何一条不满足都会在 pre crsinst 阶段拦下来。
# 内存总量，单位 KB，除以 1024 换算成 MB 对照 8G 下限 grep MemTotal /proc/meminfo # 运行级别必须是 3 或 5，图形化安装需要 5 runlevel # 内核版本与发行版，确认在支持矩阵内 uname -mr cat /etc/redhat-release # /tmp 空间，至少 1G du -sh /tmp # swap 大小，注意启用 hugepages 后要扣掉那部分内存再比 grep SwapTotal /proc/meminfo # /dev/shm 的挂载类型与权限，必须是 tmpfs 且可读写 df -h /dev/shm # GI 和 Oracle 的安装目录空间 df -h /u01这段命令没有技巧，关键是每一项都要看输出而不是看命令有没有报错。swap 那一条最容易踩：手册明确写了，如果启用了 hugepages，计算 swap 需求时要把分配给 hugepages 的内存从 RAM 里减掉再对照档位，否则你会以为自己 swap 够，实际 CVU 判定不足。这也是后面避坑章节要展开的一个点。
空间规划上，grid 至少 12G、Oracle 至少 10G 是下限，不是建议值。19c 的 GI 家目录里带着 GIMR 的可执行文件、cv 目录、OPatch、各种 jar，实际占用会往上走；再加上 ADR 诊断目录默认也往 GI 基础目录下写，给 100G 预留是务实做法。如果你的 /u01 是独立 LVM，记得留扩容余量，后面打补丁、装 RU 都要用。
2.2 禁用 THP：改 GRUB 而不是只改运行时
透明大页（THP）对 Oracle 来说是个老问题：它按 2M 粒度做内存整理，khugepaged 内核线程会在后台合并页，带来的延迟抖动对数据库这种对响应敏感的业务不友好。手册的做法是从内核启动参数层面彻底关掉，而不是只写运行时开关。
先确认当前状态：
# enabled 里方括号落在哪一项，就代表当前生效的是哪一项 cat /sys/kernel/mm/transparent_hugepage/enabled # 输出形如 [always] madvise never 表示 THP 当前是开启的 # defrag 是碎片整理开关，同样要看方括号位置 cat /sys/kernel/mm/transparent_hugepage/defrag # 输出形如 [always] madvise never 说明后台整理也开着方括号套在always上就是要处理的状态。接着改 GRUB 启动参数：
# 编辑 GRUB 默认配置，在 GRUB_CMDLINE_LINUX 末尾追加参数 vi /etc/default/grub # 修改后形如： # GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap ... transparent_hugepage=never" # 改之前先备份，出问题能回滚 cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak # BIOS 引导的机器用这条重建 grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 引导的机器路径不同，别抄错 grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfgGRUB_CMDLINE_LINUX这一行是内核启动参数的来源，追加transparent_hugepage=never后必须重建 grub.cfg 才生效，直接改 grub.cfg 会在下次内核更新时被覆盖。BIOS 和 UEFI 的输出路径不一样，这是最常见的翻车点：在 UEFI 机器上跑了 BIOS 那条命令，命令不报错，但参数根本没写进真正的启动配置。
重建完重启，用下面两条验证：
# 看内核实际收到了什么参数 cat /proc/cmdline # 应该能看到 transparent_hugepage=never # 再看运行时状态，两项都应该是 never cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag/proc/cmdline是内核视角的“黑匣子”，它显示什么，内核就收到了什么。只看 sysfs 里变成 never 还不够——有可能是别人临时 echo 进去的，重启就没了。两条都过，才算真的关掉。
2.3 Hugepages 的算法与 memlock 同步
THP 关掉之后，Oracle 的 SGA 走的是显式 hugepages。这里要分清两个概念：THP 是内核自动合并、对应用透明；hugepages 是预留出来、只能被显式申请的 2M 页，vm.nr_hugepages就是预留的页数。数据库 SGA 用 hugepages 能减少页表项、降低 TLB miss，这是 RAC 节点上值得做的一步。
页数的算法：把要跑在这个节点上的所有实例的 SGA 加起来，除以 2M，再留 10% 左右余量向上取整。如果配了 GIMR（DSC 模式或 Standalone 主动开了 GIMR），别忘了 GIMR 自己还要占 1G 的 SGA，这部分也要算进去。举个具体例子：两个实例各 8G SGA，加上 GIMR 1G，合计 17G，除以 2M 得 8704 页，留余量取 9216 页。
# 写入 sysctl 配置，数值按上面的算法替换 vi /etc/sysctl.conf # 追加一行 vm.nr_hugepages = 9216 # 立即生效 sysctl -p # 验证：HugePages_Total 应等于设定值，HugePages_Free 在实例未启动时应等于 Total grep Huge /proc/meminfo内存锁限制必须同步放开，否则 Oracle 进程锁不住这么多页，GI 启动时会失败：
# 编辑 limits.conf，oracle 用户的软硬限制都要给足 vi /etc/security/limits.conf # 追加，数值按 SGA 字节数加余量，单位 KB # oracle soft memlock 17825792 # oracle hard memlock 17825792 # 切到 oracle 用户验证，注意 ulimit -l 单位是 KB su - oracle -c "ulimit -l"memlock的单位是 KB，而 SGA 一般按 GB 说，换算时容易少写一个数量级。软硬限制都要设，只设 soft 的话，hard 还是默认值，进程申请不到。另外 limits.conf 的生效依赖 PAM，su - oracle这种登录方式会走 PAM 所以能看到新值，如果直接在 root shell 里su oracle（不带横杠），可能读到旧值，验证方式本身就会误导你。
这三步做完，系统的内存基线就算扎稳了。剩下的软件包、内核参数、网络是下一层的事。
3. 预安装包与内核参数：Preinstall RPM 和手工 sysctl 两条路
内核参数和用户资源限制这一层，手册给了两条路：用 Oracle 官方的 preinstall RPM 一把梭，或者手工往 sysctl.d 里写参数。两条路各有适用场景，选错了不是装不上，而是后面排查问题时搞不清“这个值是谁改的”。这一章把两条路的差异、手工配置的完整参数表、以及 CVU 校验的用法讲清楚。
3.1 软件包清单与 preinstall RPM 的取舍
手册第 3 章列了一份 RHEL 7 的软件包清单，核心是这几类：编译与基础工具（bc、binutils、make、ksh、sysstat）、兼容库（compat-libcap1、compat-libstdc++）、开发库（glibc-devel、libaio-devel、libstdc++-devel、elfutils-libelf-devel）、图形库（libX11、libXau、libXi、libXtst、libXrender 及其 devel）、RAC 专用（net-tools、nfs-utils）、ACFS Remote 相关（python、python-configshell、python-rtslib、python-six、targetcli）、硬件监控（smartmontools）。这份清单的用处是：当 preinstall RPM 因为源不可用装不上时，你可以按它手工补包。
preinstall RPM 这条路的操作很直接：
# 配置 Oracle Linux 的 yum 源 cd /etc/yum.repos.d/ wget http://yum.oracle.com/public-yum-ol7.repo yum repolist # 安装 19c 的预安装包，它会自动建用户、建组、写 sysctl、写 limits yum install oracle-database-preinstall-19c这个 RPM 做的事在手册里写得很清楚：创建 oracle 用户、oraInventory（oinstall）组和 OSDBA（dba）组；写 sysctl.conf 调整内核参数；设置 hard/soft 用户资源限制；设置与内核版本相关的建议参数；以及设置numa=off。最后这条值得单独提——NUMA 关闭对 Oracle 是常规建议，preinstall 帮你做了，但如果你手工配，很容易漏。
我一般的判断是：能用 preinstall 就用 preinstall，但要清楚它改了什么。因为它写进去的值是“通用建议值”，你的机器内存特别大或者特别小的时候，kernel.shmmax这类参数可能需要微调。装完 preinstall 之后翻一遍/etc/sysctl.d/下的文件，心里有数，后面出问题才知道从哪查。
如果所在环境不能连外网源，就走手工路线，把清单里的包用本地 ISO 或内网源补齐，别指望装到一半再补——GI 安装器在检查阶段会因为缺包直接退出，而它给的提示往往只报第一个缺的包，补一个再跑一次，来回好几轮，血泪经验。
3.2 手工 sysctl 参数逐条解释
不用 preinstall 的话，手册给的是一份完整的手工配置。建议写在/etc/sysctl.d/97-oracledatabase-sysctl.conf这种独立文件里，而不是直接改/etc/sysctl.conf，好处是升级或排查时一眼能看出哪几行是 Oracle 相关。
# 独立配置文件，避免和系统默认值混在一起 vi /etc/sysctl.d/97-oracledatabase-sysctl.conf # 异步 IO 最大请求数，RAC 场景建议拉满 fs.aio-max-nr = 1048576 # 系统级文件句柄上限 fs.file-max = 6815744 # 共享内存总页数，单位是页（默认 4K） 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逐条说清楚每个参数管什么，比背数值有用。fs.aio-max-nr是异步 IO 的并发上限，ASM 和数据库都吃这个，配小了在压测时会看到ORA-27090之类的报错。kernel.shmall和kernel.shmmax是一对：shmmax 是单段上限，要大于最大的 SGA；shmall 是所有共享内存页的总和，按 shmmax 除以页大小再留余量算。kernel.sem四个数依次是 SEMMSL、SEMMNS、SEMOPM、SEMMNI，Oracle 的建议值就是手册这一组，一般不用动。
net.ipv4.ip_local_port_range起始值设成 9000，是为了把 1-8999 这段留给 Oracle 自己用（VIP、监听、SCAN 端口都在低位），避免和客户端临时端口撞车。收发缓冲区的四个值决定了网络吞吐的上限，RAC 的 Cache Fusion 走私有网络，这块配得太保守，节点间数据块传输会成为瓶颈。
写完文件后让内核重读：
# 加载全部 sysctl 配置 /sbin/sysctl --system # 逐项核对是否生效，重点看上面那几个参数 /sbin/sysctl -a | grep -E "aio-max-nr|file-max|shmmax|shmall|kernel.sem|rmem|wmem"sysctl --system会按目录顺序加载所有配置文件，后加载的覆盖先加载的。文件名用97-前缀就是为了让它排在系统默认配置之后。改完端口范围后如果还想立即生效，可以用echo 9000 65500 > /proc/sys/net/ipv4/ip_local_port_range直接写，但重启后就没了，正式配置还是以文件为准。手册里提到改完端口范围要重启网络服务，这一步在 RAC 节点上要谨慎，别把 SSH 会话一起断了。
3.3 CVU 校验：装之前先让工具挑毛病
CVU（Cluster Verification Utility）是这套流程里最值得用的一步，手册把它标成 optional，但我建议必做。它的作用是：在真正跑 gridSetup.sh 之前，把 OS 参数、用户、组、网络、存储这些前置条件全部检查一遍，把问题一次性列出来，而不是让你在图形界面里一个个撞。
安装 cvuqdisk 包的过程手册写得很细：
# 先看有没有旧版本 rpm -qi cvuqdisk # 有的话先卸掉 rpm -e cvuqdisk # 指定 cvuqdisk 属组，通常是 oinstall CVUQDISK_GRP=oinstall; export CVUQDISK_GRP # 从 GI 安装介质里找到这个包再装 rpm -iv cvuqdisk-1.0.10-1.rpm # 跑装前检查，-fixup 表示尝试自动修复能修的项目 ./runcluvfy.sh stage -pre crsinst -fixup -n node1,node2,node3-n后面跟节点列表，-fixup会让它顺带修一些能自动修的东西（比如部分 sysctl 值）。cvuqdisk 包的位置在Grid_home/cv/rpm目录下，每个节点都要装同一个版本，版本不一致会导致检查结果不可信。CVUQDISK_GRP这个环境变量不设的话，包会默认绑到 root 组，后面检查会报权限问题。
CVU 的输出要逐条看完，不能只看最后一行。它会把检查项分成“通过/失败/警告”三类，失败的必须处理，警告要判断是不是能接受。常见失败项包括：swap 不足、THP 没关、hugepages 配了但 memlock 不够、节点间时间不同步、/etc/hosts 解析不一致。这几项正好对应后面避坑章节要展开的内容。
提示：CVU 的检查结果和你跑它的用户有关。用 grid 用户跑和用 root 跑，能看到的检查项不完全一样。装前检查一般用 grid 用户跑，涉及系统层的项目它会提示你用 root 复核。
4. 网络层：固定 IP 与 GNS + BIND 的选型与配置
RAC 的网络配置是整个安装里最“讲究”的一块，因为它牵扯的不只是 IP 地址，还有命名解析和集群组件之间的约定。手册给了两种模式：纯固定配置（只把 SCAN 交给 DNS），以及 GNS + 固定配置的混合模式。选哪种，取决于你手上有没有可控的 DNS、要不要用 GNS 自动分配 VIP。
4.1 网络规划与 /etc/hosts 的写法
先把几个概念对齐。Public IP 是节点的对外地址，VIP 是节点故障时能漂走的地址，Private IP 走 Cache Fusion 和集群心跳，SCAN VIP 是客户端连进来的统一入口（19c 固定三个）。手册给的规则里，有几条是硬约束：
- 要么全 IPv4，要么全 IPv6，不能混。
- 从 18c 起 VIP 是可选的，但只能“全有或全无”，不能只给部分节点配 VIP。
- Private 最多配四个网卡做 HAIP，超过四个的部分自动降为冗余；private 不强制 bond，集群自己会做高可用。
- Public/VIP 名字只能用字母数字和
-，不能用下划线。 - Public、VIP、SCAN VIP 必须在同一子网。
- SCAN 需要三个固定 IP，其余组件可以交给 GNS。
/etc/hosts的写法手册给了模板，两个节点、public/private/vip/scan 四组：
# 节点一 public 192.168.204.11 pub19-node1.rac.demo # 节点二 public 192.168.204.12 pub19-node2.rac.demo # 私有网络，走独立网段 40.40.40.41 priv19-node1.rac.demo 40.40.40.42 priv19-node2.rac.demo # VIP，和 public 同网段 192.168.204.21 vip19-node1.rac.demo 192.168.204.22 vip19-node2.rac.demo # SCAN 三个地址，注释掉表示交给 DNS 解析而不是本地 hosts # 192.168.204.33 scan19-vip.rac.demo # 192.168.204.34 scan19-vip.rac.demo # 192.168.204.35 scan19-vip.rac.demo # GNS VIP 192.168.204.10 gns19-vip.rac.demo这里的关键判断是：SCAN 一定要走 DNS，不能写 hosts。因为 SCAN 是轮询的三个地址，写进 hosts 后集群没法做负载均衡，客户端会一直连第一个。手册把 SCAN 那三行注释掉，就是强制它去查 DNS。反过来，public/private/vip 写进 hosts 是为了节点间解析不依赖 DNS，减少单点。
Private 网段用 40.40.40.x 这种和 public 完全不相干的段，是常见做法：物理上走独立交换机或独立 VLAN，避免心跳流量和业务流量抢带宽。两个节点的 private 网卡要能互通，装之前先用 ping 和ip route确认路由没走错网卡。
4.2 BIND 正解与反解：SCAN 解析的地基
如果走“固定配置 + DNS 只解析 SCAN”这条最简单的路，你需要一台能解析 SCAN 三个地址的 DNS。手册给的是 BIND 的完整配置，分正解和反解两个 zone。
先装包、改主配置：
# 装 bind 和 chroot 包，chroot 让 named 跑在受限目录里 yum install -y bind chroot # 主配置文件 vi /etc/named.confnamed.conf的 options 段里，手册给了这样一组：
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; # 允许查询的来源，生产环境建议收窄到具体网段而不是 any allow-query { any; }; recursion yes; # 禁止区域传送，防止配置被外部拉走 allow-transfer { none; }; }; # 根提示 zone "." IN { type hint; file "named.ca"; }; # 正向解析域 zone "rac.demo" IN { type master; file "named.rac.demo"; }; # public 网段的反向解析 zone "204.168.192.in-addr.arpa" IN { type master; file "named.192.168.204"; }; # private 网段的反向解析 zone "40.40.40.in-addr.arpa" IN { type master; file "named.40.40.40"; };allow-query { any; }在测试环境够用，但生产环境要收窄成具体网段，否则你的 DNS 就成了一台开放解析器。allow-transfer { none; }是必须的，允许区域传送等于把整份解析记录公开。反向解析 zone 的名字是把网段倒过来写再加.in-addr.arpa，192.168.204 就写成204.168.192.in-addr.arpa，这一点写错的话正解能通、反解全挂。
正向解析文件：
vi /var/named/named.rac.demo$TTL 600 @ IN SOA rac.demo. admin.rac.demo. ( 0 ; serial，每次改完要加一 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum @ IN NS master master IN A 192.168.204.12 # SCAN 三个地址，客户端靠轮询这三个做负载均衡 scan19.vip.rac.demo. IN A 192.168.204.162 scan19.vip.rac.demo. IN A 192.168.204.163 scan19.vip.rac.demo. IN A 192.168.204.164 priv19-node1.rac.demo. IN A 40.40.40.41 priv19-node2.rac.demo. IN A 40.40.40.42 vip19-node1.rac.demo. IN A 192.168.204.21 vip19-node2.rac.demo. IN A 192.168.204.22 pub19-node1.rac.demo. IN A 192.168.204.11 pub19-node2.rac.demo. IN A 192.168.204.12 # 子域委托，GNS 的关键两行 vip.rac.demo. IN NS gns.rac.demo. gns.rac.demo. IN A 192.168.204.10最后两行是 GNS 的核心：它把vip.rac.demo这个子域的解析权委托给gns.rac.demo（地址 192.168.204.10）。没有这两行，GNS 就管不了这个子域，装的时候 SCAN 那一步会失败。serial 每次改完要加一，忘了加的话从库不会更新，主库自己测没问题，一上台就出问题。
反向解析文件同理，每个 IP 段一个文件，里面每个 IP 一条 PTR 记录，指回正向名字。
vi /var/named/named.192.168.204$TTL 600 @ IN SOA rac.demo. admin.rac.demo. ( 10 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum @ IN NS master.rac.demo. 12 IN PTR master.rac.demo. 33 IN PTR scan19.vip.rac.demo. 34 IN PTR scan19.vip.rac.demo. 35 IN PTR scan19.vip.rac.demo. 21 IN PTR vip19-node1.rac.demo. 22 IN PTR vip19-node2.rac.demo. 11 IN PTR pub19-node1.rac.demo.配完之后用named-checkconf和named-checkzone先做语法检查，再重启 named，然后用dig -x和nslookup双向验证。这一步别偷懒，正向通、反向不通的情况很常见，而 GI 安装器在配 SCAN 时会两边都查。
4.3 GNS 与 SCAN 子域委托：什么时候值得用
GNS（Grid Naming Service）的作用是让集群自己接管一部分命名解析：VIP、部分 Private IP、SCAN 都可以由它分配，配合 DHCP 还能做到 IP 全自动。手册给了两个前置条件：一是要么全 IPv4 要么全 IPv6，GNS 可以生成 IPv6 地址；二是 SCAN 的域名必须落在委托给 GNS 的子域里。
在 gridSetup.sh 的配置页面里，有三处要把手册里的规则对上：SCAN 的域名scan19.vip.rac.demo必须包含vip.rac.demo这个交给 GNS 的子域；GNS 的 IP 填 192.168.204.10；subdomain 填vip.rac.demo。这三处少对一处，装到配置 SCAN 那步就会报域名解析失败。
我的判断是：测试环境、需要频繁重建的环境，GNS 值得上；生产环境如果已经有成熟的 DNS 管理流程，纯固定配置更可控。GNS 的自动分配在重建时省事，但出问题时排查链路更长——解析失败时你要先确认是 BIND 的问题、GNS 的问题，还是子域委托写错了。纯固定配置就两步：hosts 写死，DNS 解析 SCAN，出问题查两个地方就够。
5. 常见问题排查：五个真实翻车点
前面几章讲的都是“应该怎么配”，这一章讲“配了但不对”的时候怎么查。RAC 安装的报错有个共同特点：报出来的错和真正的原因隔着一两层，比如 GI 起不来，报的是 CRS 错误，根因可能在 memlock。下面五条是这套流程里最常撞上的，每条按现象、原因、解决三段写。
5.1 THP 重启后又回到 always：GRUB 配置被覆盖
现象：装前检查时明明改过 GRUB、/proc/cmdline也能看到transparent_hugepage=never，但系统重启一次后cat /sys/kernel/mm/transparent_hugepage/enabled又显示[always]。
原因：改了grub.cfg但没改/etc/default/grub，或者在内核更新后 grub.cfg 被重新生成，手改的内容被覆盖。另一个常见原因是 UEFI 机器上跑了 BIOS 那条grub2-mkconfig命令，参数写进了一个不会被读取的文件。
解决：改的源头必须是/etc/default/grub里的GRUB_CMDLINE_LINUX，然后按引导方式选对输出路径重建。重建完cat /proc/cmdline和两个 sysfs 文件三处一起验证，只验一处不算过。内核更新频繁的环境，把这条参数写进配置管理，别靠手工记忆。
5.2 HugePages_Free 够了但 GI 起不来：memlock 没同步
现象：/proc/meminfo里HugePages_Total和HugePages_Free都对，但 GI 启动时报内存相关错误，或者数据库实例起不来，alert log 里有大页分配失败的记录。
原因：只改了vm.nr_hugepages，没改limits.conf里的memlock。预留的页在那儿，但 oracle 进程没有权限锁住这么多内存。另一个变体是改了 limits.conf 但验证方式不对——用su oracle而不是su - oracle，PAM 没走到，读到的还是旧限制。
解决：oracle soft memlock和oracle hard memlock都要设，数值按 SGA 字节数换算成 KB 再留余量。验证统一用su - oracle -c "ulimit -l"，带横杠才会走完整登录。改完最好重新登录一次再启 GI，别在同一个会话里直接重启服务。
5.3 SCAN 解析失败：子域委托少了一行 NS
现象：gridSetup.sh 配到 SCAN 那一步报域名解析错误，用nslookup scan19.vip.rac.demo查，有时能出结果有时不行，或者只能出一个地址。
原因：named.rac.demo里写了 SCAN 的 A 记录，但漏了把vip.rac.demo子域委托给 GNS 的那两行 NS 和 A。或者写了两行但顺序或域名拼错，比如把vip.rac.demo写成了vip.rac.demo.（多一个点）。还有一种情况是 serial 没加，从库没同步。
解决：正解文件里必须有vip.rac.demo. IN NS gns.rac.demo.和gns.rac.demo. IN A 192.168.204.10两行，且 gridSetup 里 SCAN 域名、GNS IP、subdomain 三处要互相对应。改完把 serial 加一，named-checkzone过一遍，然后从客户端机器（不是 DNS 本机）用dig验证，本机查有时走缓存，看不出问题。
5.4 ASM 盘符重启后漂移：UDEV 规则绑的是设备名
现象：装的时候 ASM 能识别到盘，重启一次后 ASM 起不来，lsblk一看盘符从/dev/sdb变成了/dev/sdc，或者两块盘顺序换了。
原因：UDEV 规则里用的是/dev/sdX这种设备名，而设备名由内核枚举顺序决定，加硬盘、换 HBA 卡、改 BIOS 顺序都会变。手册在第 6 章提到手工配置 ASM 磁盘用 UDEV，核心就是用 WWID 或 UUID 绑，不是用设备名。
解决：用scsi_id或udevadm info拿到每块盘的 WWID，规则里按 WWID 匹配，KERNEL 里用sd*通配，SYMLINK 指到固定的名字（比如/dev/asm-disk1）。规则文件放在/etc/udev/rules.d/下，文件名用99-前缀保证最后加载。写完udevadm control --reload-rules加udevadm trigger，然后拔插或重启验证，别只看当前状态。
5.5 CVU 报 swap 不足：hugepages 没从内存里扣
现象：机器 32G 内存、swap 配了 16G，按手册的档位（4G~16G 时 swap 等于 RAM）看着不够，但你觉得 16G 也不少了，CVU 还是报 swap 检查失败。
原因：CVU 计算 swap 需求时，用的是“可用内存”而不是物理内存总量。启用 hugepages 后，预留出去的那部分内存不算在可用内存里，所以实际参与计算的 RAM 变小了，对应的 swap 档位也变了。手册在 OS 检查那节特意写了这一点：启用 Huge Page 时，计算 SWAP 要减去分配给 HugePage 的内存。
解决：先算清楚 hugepages 占了多少（页数乘 2M），从物理内存里减掉，再对照档位表算 swap 需求。不够就加 swap 分区或 swap 文件。加 swap 文件的方式比重分区灵活，但要注意别放在性能差的盘上。改完swapon -s确认，再跑一次 CVU。
6. gridSetup.sh 之前的最后一遍检查与验证技巧
走到 gridSetup.sh 这一步，前面的坑基本都趟过了，但还有几件事值得在点“下一步”之前确认一遍。我的习惯是把它做成一张固定清单，逐项打勾，而不是凭记忆。这套手册的第 6 章列了一堆“其他配置”——操作系统杂项、时钟同步、NAS 附加配置、IO Scheduler、SSH 超时、用户组目录、图形界面、limits.conf、关闭 X11 Forward、Direct NFS、Oracle Member Cluster、UDEV 绑 ASM——这些看着零散，实际都是 GI 安装器会去查或者 GI 运行时会依赖的项目。
时钟同步要单独说。RAC 节点之间时间不同步，会导致集群心跳判定异常、OCR 写入冲突，装的时候 CVU 就会拦。常见做法是配 NTP 或 chrony 指向同一个内网时间源，chronyc sources看偏移量，控制在毫秒级。测试环境没有内网源的话，至少让两个节点互相同步，别让它们各走各的。
IO Scheduler 建议改成deadline或noop，对共享存储上的 ASM 盘，cfq的排队策略会引入不必要的延迟。改法是在 UDEV 规则里加ATTR{queue/scheduler}="deadline"，和绑定盘符的动作合并成一条规则，一次搞定。SSH 超时限制要放开，GI 安装过程中节点间要频繁跑 ssh 命令，默认的ClientAliveInterval太短会导致安装中途连接断开，表现为某一步卡住然后报通信失败。
X11 Forward 要关掉。这条容易被忽略：/etc/ssh/sshd_config里X11Forwarding yes开着的时候，gridSetup.sh 的图形界面在某些环境下会出奇怪的显示问题，关了反而稳。图形界面本身是通过 VNC 或 X11 转发到本地跑的，两回事。
最后是 gridSetup.sh 本身的参数和验证。图形化跑完之后，别急着跑 dbca，先做三件事：crsctl check cluster -all确认所有节点的 CRS 都起来了；crsctl stat res -t看各个资源的 target 和 state 是否都是 ONLINE；srvctl config scan和srvctl status scan_listener确认 SCAN 和监听正常。这三步过了再动数据库，顺序反了的话，数据库建到一半发现集群资源不正常，回退很麻烦。
# 集群整体状态，所有节点都应返回正常 crsctl check cluster -all # 资源明细，重点看 ora.asm、ora.gipcd、ora.mdnsd、ora.cvu 这些 crsctl stat res -t # SCAN 配置与监听状态 srvctl config scan srvctl status scan_listener # ASM 实例和磁盘组 srvctl status asm asmcmd lsdg这几条命令的输出要能对上：SCAN 的三个 VIP 都在、监听在两个节点上都注册了、ASM 磁盘组是 MOUNTED。asmcmd lsdg里如果磁盘组状态是DISMOUNTED或者MOUNTED但冗余度不对，说明 UDEV 那一步有问题，回到 5.4 去查。dbca 建库时最怕的就是 ASM 磁盘组状态不对，建到一半失败，清理起来比重装还费劲。
从那以后我每次跑 gridSetup.sh 之前，都会把这张清单从头过一遍，尤其是 THP、memlock、SCAN 解析、UDEV 这四项，宁可多花二十分钟验证，也不想在安装器跑到 80% 的时候重新来。希望帮到你。
本文还有配套的精品资源，点击获取
