简介：面向需要在 Red Hat Enterprise Linux 7.6 上部署 Oracle 19c RAC 的数据库工程师与运维人员，这份安装手册聚焦 GNS 配置 SCAN 的完整落地路径，同时梳理 Flex ASM 机制及 12.2 之后 Standalone Cluster 与 Domain Service Cluster 两种集群模式的差异，适合具备一定 Linux 与 Oracle 基础、希望独立完成集群搭建的中高级读者。资源包共 1 个 docx 文档，约 160KB，内容按环境检查、关闭 THP 并开启 Hugepages、安装软件包、内核参数配置、网络配置（固定配置与 GNS 加固定配置）、时钟同步等章节组织，目录层次清晰，便于按步骤对照执行。文档还记录了配置过程中常见问题的解决思路与分析问题的方法，读者可据此理解报错定位逻辑，减少反复试错。目前已有 718 人学习下载，可作为 19c RAC 部署与排错的参考材料。
1. 两节点 19c RAC 装完起不来，问题多半出在装之前
上周帮一位同行看他那套两节点 19c RAC，gridSetup.sh跑到 root 脚本执行完，crsctl stat res -t里 ASM 实例一直 OFFLINE，日志翻到CLSU-00100才定位到是/dev/shm挂载权限和 HugePages 没对齐。这类问题在安装阶段几乎看不出来，装完才集中爆发。这份《Oracle 19c RAC on Linux 7.6 安装手册》把 OS 检查、THP 与 HugePages、内核参数、网络与 GNS、UDEV 绑盘、gridSetup 到 dbca 的整条链路按顺序拆开，适合第一次在 RedHat 7.6 上搭 19c RAC 的 DBA，也适合装过 11g、12c 想搞清楚 19c Standalone Cluster 与 Domain Services Cluster 差异的老手。它不教你 SQL，只解决一件事：让集群一次装通、装完能起。
2. 装之前先把 OS 底座压平：检查项、THP 与 HugePages
19c RAC 的安装失败，八成不是 Grid 本身的问题，而是 OS 底座没压平。手册把 OS 环境检查放在第一章是有道理的——内存、swap、/tmp、/dev/shm、运行级别、内核版本，任何一项不达标，后面 CVU 都会给你亮红灯。我一般会把这几个检查命令写成一个小脚本，在两台节点上各跑一遍，输出贴在一起对比，比装到一半再回头查省事得多。
2.1 环境检查的硬指标与命令对照
手册列出的检查项不是摆设，每一条都对应一个真实的失败场景。内存低于 8G，Grid 的 CSSD 进程可能起不来；swap 配小了，runcluvfy直接报错；/dev/shm权限不对，后面 ASM 和 GIMR 都会受影响。下面这张表是我按手册整理并补了判断标准的版本：
| 检查项 | 命令 | 合格标准 | 不达标后果 |
|---|---|---|---|
| 内存 | grep MemTotal /proc/meminfo | 至少 8G | CSSD 启动失败 |
| 运行级别 | runlevel | 3 或 5 | 图形安装器无法启动 |
| 内核版本 | uname -mr | 3.10.0-693.5.2.0.1.el7 及以上 | Grid 不兼容 |
/tmp空间 | du -h /tmp | 至少 1G | 安装器解压失败 |
| swap | grep SwapTotal /proc/meminfo | 4–16G 等于 RAM，超 16G 取 16G | CVU 预检查失败 |
/dev/shm | df -h /dev/shm | 挂载类型与权限正确 | ASM/GIMR 异常 |
| 软件空间 | df -h /u01 | grid 至少 12G，Oracle 至少 10G，建议 100G | 安装中途空间不足 |
这里有个容易忽略的点：如果启用了 HugePages，计算 swap 时要减去分配给 HugePage 的内存。手册特意提了这一句，因为很多人按物理内存算完 swap，开了大页之后实际可用内存对不上，CVU 就卡在这一项。
2.2 关 THP 与开 HugePages 的完整操作链
透明大页面（THP）是 19c RAC 的经典雷区。THP 的碎片整理会导致节点间心跳延迟抖动，表现出来就是集群偶尔 evict 一个节点，日志里看不出明显原因，属于典型的玄学故障。手册的做法是先确认状态，再改 GRUB 内核参数，最后重建 grub 配置并重启验证。
# 确认 THP 当前状态，方括号在 always 上说明是开启的 cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag # 把 transparent_hugepage=never 追加到内核启动参数 vi /etc/default/grub # GRUB_CMDLINE_LINUX="... transparent_hugepage=never" # 备份后重建 grub 配置，BIOS 和 UEFI 路径不同 cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器用：grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # 重启并验证 shutdown -r now cat /proc/cmdline这段操作的关键在最后一步验证：/proc/cmdline里必须能看到transparent_hugepage=never，否则说明 grub 重建没生效，常见原因是改错了 grub 文件路径或者机器是 UEFI 却用了 BIOS 的输出路径。重启前一定备份grub.cfg，这是后悔药。
THP 关掉之后要开 HugePages，否则 SGA 走普通页，内存管理效率会打折。手册给的配置是改sysctl.conf和limits.conf两处：
# 设置大页数量，具体值按 SGA 大小除以 2M 估算后留余量 vi /etc/sysctl.conf vm.nr_hugepages = 4096 sysctl -p # 放开 oracle 用户的内存锁定上限，否则大页分配会失败 vi /etc/security/limits.conf oracle soft memlock 8388608 oracle hard memlock 8388608vm.nr_hugepages的值不是拍脑袋定的，常见做法是按所有实例 SGA 总和除以 2M 再上浮 10% 左右。如果装的是 Domain Services Cluster 要配 GIMR，GIMR 的 SGA 会额外占用约 1G 大页，这部分必须算进去；Standalone Cluster 可以选择不配 GIMR，那就省掉这块。memlock的单位是 KB，设小了sysctl -p不报错，但实例启动时大页分配会失败，报错信息还不直观，这是血泪经验。
3. 内核参数与软件包：Preinstall RPM 还是手工配
OS 底座压平之后，下一步是内核参数和依赖包。这两块手册给了两条路：用 Oracle Preinstall RPM 一把梭，或者手工配sysctl加逐个装包。选哪条路取决于你的环境管控严格程度——生产环境很多公司不允许装第三方 repo 的包，那就只能手工来。
3.1 Preinstall RPM 做了什么，什么时候不该用它
oracle-database-preinstall-19c这个包会一次性完成这些事：创建 oracle 用户和 oinstall、dba 组，写sysctl.conf调内核参数，设limits.conf的资源限制，还会顺手把numa=off加上。对快速搭建测试环境来说，这是最省事的路径：
cd /etc/yum.repos.d/ wget http://yum.oracle.com/public-yum-ol7.repo yum repolist yum install -y oracle-database-preinstall-19c但要注意两点。第一，这个包会覆盖你已有的sysctl配置，如果机器上跑着别的服务，装之前先备份/etc/sysctl.conf。第二，它默认把numa=off写进内核参数，有些场景下你未必想要这个行为，装完记得检查/proc/cmdline。我一般会在测试环境用它快速起一套，生产环境则倾向手工配，因为每一项改了什么自己心里有数。
3.2 手工配内核参数的完整清单
不用 Preinstall RPM 的话，手册给了一份完整的内核参数清单，建议写到/etc/sysctl.d/97-oracledatabase-sysctl.conf而不是直接改sysctl.conf，这样升级和回滚都干净：
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 # 让配置生效并逐项核对 /sbin/sysctl --system /sbin/sysctl -a | grep -E "shmmax|shmall|sem|aio"参数含义上，kernel.shmmax是单个共享内存段的最大值，设成 4294967295 是 4G 减 1 字节，对大多数 SGA 够用；kernel.shmall是所有共享内存页的总量，单位是页，2097152 页乘以 4K 就是 8G；kernel.sem四个值分别是信号量集合数、每集合信号量数、单次操作数和系统级总数。这几个值改小了，实例启动会报ORA-27123之类的共享内存错误，改大了浪费资源但不致命。
网络端口范围net.ipv4.ip_local_port_range手册单独提了一句，改完要重启网络或者直接写/proc：
echo 9000 65500 > /proc/sys/net/ipv4/ip_local_port_range /etc/rc.d/init.d/network restart这个范围影响的是客户端连接时本地端口的分配，RAC 环境下监听和 SCAN 都要用，范围太窄高并发时会报端口耗尽。
3.3 软件包清单与 CVU 预检查
依赖包这块，手册列了 RHEL 7 的基础包和 ACFS 相关的附加包。基础包里compat-libcap1、compat-libstdc++、libaio、libaio-devel、libX11系列、libgcc、libstdc++、make、net-tools、nfs-utils、smartmontools、sysstat是必装的，少一个runcluvfy就会报缺包。ACFS 相关的python-configshell、python-rtslib、python-six、targetcli按需装，不用 ACFS 可以不装。
装完包之后，如果没用 Preinstall RPM，手册建议用 CVU 做预检查。cvuqdisk包在 Grid 安装介质的cv/rpm目录下，两台节点都要装：
# 先卸掉旧版本，再装新的 rpm -qi cvuqdisk rpm -e cvuqdisk export CVUQDISK_GRP=oinstall rpm -iv cvuqdisk-1.0.10-1.rpm # 跑预检查，-fixup 会自动修一部分可修项 ./runcluvfy.sh stage -pre crsinst -fixup -n node1,node2,node3-fixup这个参数很实用，它能自动修掉一部分权限和配置问题，但修完不会告诉你改了什么，所以跑完最好再不带-fixup跑一遍确认全绿。-n后面跟节点名，要和/etc/hosts里解析的一致，否则 CVU 连不上节点。
4. 网络与 GNS：SCAN、VIP、Private 的分配逻辑
网络配置是 19c RAC 里最容易配错的部分，因为 19c 引入了 GNS（Grid Naming Service）和 Flex Cluster 的概念，SCAN、VIP、Private IP 的分配方式比 11g 灵活，但也更容易踩坑。手册把网络配置单独成章，给了固定配置和 GNS 加固定配置两种方案。
4.1 固定配置与 GNS 的选型边界
固定配置就是所有 IP 手工指定，SCAN 只通过 DNS 解析。这种方式最直观，适合网络环境稳定、DNS 可控的场景。GNS 则是让 Grid 自己管理 VIP、Private IP 甚至 SCAN 的分配，配合 DHCP 可以做到节点加进来自动拿地址。
选型上我的建议是：如果集群规模固定、网络变更少，用固定配置，出问题好排查；如果节点会频繁增减、或者想统一管理子域解析，再上 GNS。手册里 GNS 的配置关键在 DNS 的 zone 文件——vip.rac.libai这个子域的 NS 记录要指向gns.rac.libai，而gns.rac.libai的 A 记录指向 GNS VIP 地址。这两行是 GNS 能工作的前提：
# 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 服务本身跑在 192.168.204.10 上。在gridSetup.sh里配 SCAN 时，SCAN 域名必须落在这个子域下，比如scan19.vip.rac.libai，否则 GNS 不接管。这一步配错，装完 SCAN VIP 起不来，srvctl status scan会一直显示 offline。
4.2 hosts 文件与 DNS 反解配置
不管用不用 GNS，/etc/hosts都要把 Public、Private、VIP 写清楚。手册给的示例结构是这样的：
# Public 192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai # Private 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai # VIP 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai # GNS VIP 192.168.204.10 gns19-vip.rac.libai几个硬性规则手册里写得很明确：Public、VIP、SCAN VIP 必须在同一子网段；Public 和 VIP 名称只能用字母数字和连字符，不能用下划线；Private 可以配最多四个 interface 做 HAIP，超过四个的部分自动作为冗余，不需要 bond 绑定。这些规则违反了，安装时不一定报错，但集群起来后 VIP 漂移或者 HAIP 选路会出问题。
DNS 反解域也要配，named.192.168.204和named.40.40.40两个文件分别对应 Public/VIP 网段和 Private 网段的反解。反解不配，runcluvfy的 DNS 检查项会报 warning，虽然不一定阻断安装，但后面 SCAN 的负载均衡可能不正常。
5. 避坑与排查：装完起不来时先看这几处
这一章是我自己踩过和帮别人排查过的记录，按「现象 → 原因 → 解决」整理。19c RAC 的报错信息经常指向错误的方向，知道往哪看比会看日志更重要。
5.1 ASM 磁盘权限漂移导致实例起不来
现象：gridSetup.sh跑完，crsctl stat res -t里 ASM 实例 OFFLINE，asmca看不到磁盘组。
原因：UDEV 规则没绑死，重启后/dev/sd*的属主变成 root，ASM 实例没有权限打开设备。手册里提到手工配置 ASM 磁盘用 UDEV，但规则文件的写法有讲究。
解决：用/usr/lib/udev/rules.d/下的规则文件按磁盘 WWID 绑定，而不是按/dev/sdX名字绑，因为设备名重启会变。绑完执行udevadm control --reload-rules && udevadm trigger，再用ls -l /dev/asm*确认属主是 grid:asmadmin、权限 660。
5.2 HugePages 数量不够导致实例启动报 ORA-27102
现象：数据库实例启动时报ORA-27102: out of memory，但free -g看内存还有富余。
原因：开了 HugePages 之后，SGA 只能从大页池里分配，vm.nr_hugepages设小了，普通内存再多也用不上。
解决：按grep HugePages /proc/meminfo看实际分配数和空闲数，把vm.nr_hugepages调到 SGA 总和除以 2M 再上浮 10%，sysctl -p后确认HugePages_Free有足够余量。注意调大页数需要连续物理内存，碎片多的时候可能调不上去，必要时重启。
5.3 SCAN VIP 起不来但 DNS 解析正常
现象：nslookup scan19.vip.rac.libai能解析出三个 IP，但srvctl status scan显示 SCAN VIP 全部 offline。
原因：GNS 子域配置和gridSetup.sh里填的 SCAN 域名不匹配，或者 SCAN 的三个 IP 不在 Public 同网段。
解决：检查named.conf里vip.rac.libai子域的 NS 记录是否指向 GNS，检查gridSetup.sh里 SCAN 域名是否以vip.rac.libai结尾，检查三个 SCAN IP 是否和 Public 同网段。三处任何一处不对，SCAN 都起不来。
5.4 root 脚本执行顺序错导致集群配置不完整
现象：gridSetup.sh提示在两个节点分别以 root 执行root.sh，执行完第二个节点后集群状态异常，部分资源无法启动。
原因：root.sh必须先在第一个节点执行完并确认成功，再在第二个节点执行。两个节点同时跑，或者第一个没跑完就跑第二个，会导致 OCR 写入冲突。
解决：严格按提示顺序，第一个节点root.sh输出Successfully configured之后再动第二个节点。如果已经跑乱了，用deinstall清干净重装，别试图手工修 OCR。
5.5/dev/shm权限不对导致 GIMR 异常
现象：Standalone Cluster 配了 GIMR，装完 MGMTDB 起不来，日志报共享内存相关错误。
原因：/dev/shm挂载权限或大小不对，GIMR 的 SGA 需要从/dev/shm分配。
解决：df -h /dev/shm确认大小至少和 GIMR SGA 匹配，mount | grep shm确认挂载参数没有noexec之类限制。19c Standalone 可以选择不配 GIMR，如果不需要就干脆别配，省掉这块风险。
6. 装完之后的验证与一个我必做的习惯
集群装完不等于装对，crsctl stat res -t全绿只是第一步。我一般会按顺序做三层验证：第一层看集群资源，crsctl check cluster -all确认所有节点 CSSD、CRS、EVM 都 online；第二层看网络，srvctl status scan和srvctl status vip -n node1确认 SCAN 和 VIP 都在正确的节点上；第三层看 ASM 和数据库，asmcmd lsdg确认磁盘组挂载正常，srvctl status database -d ORCL确认实例在各节点都 open。
这三层里最容易漏的是第二层。SCAN VIP 和节点 VIP 的状态在安装日志里不一定显眼，但它们是客户端连接的第一跳，VIP 漂移不对，应用连上来会随机失败。我习惯在装完后手动crsctl relocate vip -n node1把 VIP 在两个节点间来回切一次，确认漂移正常再交付。
还有一个习惯是装完立刻做一次基线快照：把crsctl stat res -t、srvctl config scan、asmcmd lsdg、/etc/sysctl.d/97-oracledatabase-sysctl.conf、UDEV 规则文件全部导出存一份。后面集群出任何异常，拿当前状态和基线一比，是配置漂移还是硬件问题一目了然。这个习惯帮我省过好几次排查时间——有一次节点莫名 evict，对比基线发现是有人改了limits.conf的 memlock，改回去就好了。
手册里 CVU 的-fixup参数也值得在装完后单独跑一次runcluvfy stage -post crsinst -n node1,node2，它会把装完后仍然不达标的项列出来，比人工逐项核对快。从那以后我每次装完 RAC，不管多急，都强制走一遍「三层验证 + 基线快照 + post CVU」这套流程，宁可多花二十分钟，也不留一个装完才爆的雷。希望帮到你。
本文还有配套的精品资源，点击获取
