企业官网建设流程全解析

简介：这份Oracle 19c RAC on Linux 7.6安装手册面向Linux运维工程师与DBA，重点解决RedHat 7.6环境从零搭建19c RAC的流程问题。内容覆盖GNS配置SCAN、Flex ASM机制介绍、12.2之后Standalone Cluster与Domain Service Cluster两种集群模式差异，并给出配置中典型报错的原因分析与排错思路。文档为单个docx文件，压缩包约160KB，按清晰目录组织章节，从OS环境检查、关闭THP与开启Hugepages、依赖软件包安装、内核参数配置，到固定IP/GNS网络方案及时钟同步逐项展开，便于对照实施。已有716人学习下载，适合需要理解GNS域名解析与SCAN工作机制、并希望获得实用问题排查方法的初中级DBA参考。

1. Oracle 19c RAC on Linux 7.6：为什么值得照着这份手册装一遍

数据库凌晨两点自动重启，就因为一台物理机的内存报警——这是没上 RAC 之前最常见的夜班剧情。Oracle 19c RAC（Real Application Clusters）把两个节点的算力和内存放进同一个集群，数据放在共享存储上由 ASM 统一管理，一个节点故障，业务连接自动漂移到另一个节点，应用几乎无感知。Linux 7.6 是跑 19c RAC 非常稳妥的底包，这份安装手册的落地路径就是：准备系统、规划网络与共享盘、装 Grid Infrastructure、装数据库软件、建 RAC 库。适合正在做高可用改造的 DBA、准备从单机往集群迁移的运维，以及第一次独立装 RAC 就要面对生产环境的人。它不是概念科普，是我按生产环境标准反复走过的一整套可复现流程。

2. 安装前的准备：把 Linux 7.6 调成能跑 RAC 的状态

2.1 硬件与版本核对：先确认机器配不配

RAC 对硬件的要求不高，但对一致性要求很高。最怕两节点配置不对称，比如一个节点 8 核 16GB，另一个 4 核 8GB，平时没事，故障切换时慢节点拖垮整个集群。我一般先做一轮最小配置核对：CPU 至少 2 核（生产建议 8 核以上）、内存至少 8GB（生产建议 16GB 起步）、/u01 目录预留 100GB 以上、/tmp 至少 2GB。两节点的主机名、内核版本、架构必须一致，操作系统补丁级别也要对齐。

uname -r free -g df -h /u01 /tmp lscpu | grep "Model name"

这段命令看四件事：内核版本是否一致、内存是否达标、/u01 和 /tmp 是否够用、CPU 型号是否统一。RAC 里有个隐藏的坑：如果两节点 /etc/hosts 里写的主机名不同，后续 Grid Infrastructure 安装时 gpnp 配置文件会生成两套不同的节点身份，root.sh 阶段大概率翻车。所以第一件事是把主机名固定下来，安装全程不要改。

我还会顺手检查时间同步。19c 集群对节点间时钟偏差很敏感，偏差超过一定阈值，crsd 会主动踢节点。Linux 7.6 自带 chronyd，安装前把时间源配好，确认 chronyc sources 能看到同步源，比装完再折腾省事得多。

systemctl enable chronyd --now chronyc sources -v timedatectl status

2.2 内核参数与系统限制：一批 sysctl 搞定

Oracle 官方对 Linux 7.6 跑 19c 有明确的 sysctl 建议，但网上流传的版本五花八门。我习惯把这组参数直接写进 /etc/sysctl.conf，前两节点内容保持一致，执行 sysctl -p 生效。下面这组是经过生产验证的，重点是信号量和网络缓冲区。

cat >> /etc/sysctl.conf <<'EOF' fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 4194304 net.ipv4.conf.all.rp_filter = 2 net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 vm.swappiness = 10 vm.dirty_ratio = 30 vm.dirty_background_ratio = 3 vm.min_free_kbytes = 524288 EOF sysctl -p

参数说明：kernel.sem 四个值分别是信号量数组最大长度、系统内最大信号量数、每次操作最大信号量数、最大信号量集合数，RAC 的集群进程和 ASM 后台进程对信号量消耗很大，这四个值不能省。net.core.rmem_max 和 wmem_max 决定集群节点间通信（私有网络）的缓冲区上限，19c 的 HAIP 和缓存融合都依赖它。vm.min_free_kbytes 设置为 524288（约 512MB）是为了防止内存压力过大时节点 hang 住，这在 Linux 7.6 的内核上尤其重要。rp_filter 设置为 2 是严格反向路径过滤，防止私有网卡收到异常源地址的包导致集群脑裂。

2.3 用户、组与环境变量：把运行权限对齐

RAC 安装需要两个操作系统用户：grid 和 oracle，分别对应 Grid Infrastructure 和数据库软件。组的划分有讲究，最少要建 oinstall、dba、asmadmin、asmdba、asmoper 五个组，grid 用户的主组用 oinstall，附加组加上 dba、asmadmin、asmdba、asmoper；oracle 用户主组用 oinstall，附加组加 dba、asmdba。这样设计的目的是让 ASM 实例归 grid 管，数据库实例归 oracle 管，权限互不越界。

groupadd oinstall groupadd dba groupadd asmadmin groupadd asmdba groupadd asmoper useradd -g oinstall -G dba,asmdba,asmadmin,asmoper grid useradd -g oinstall -G dba,asmdba oracle mkdir -p /u01/app/19.0.0/grid mkdir -p /u01/app/oracle chown -R grid:oinstall /u01/app/19.0.0/grid chown -R oracle:oinstall /u01/app/oracle

19c 的 Grid Infrastructure 安装目录默认是 /u01/app/19.0.0/grid，和 oracle 用户的 ORACLE_HOME 分开。目录权限错了，安装界面会在目录检查步骤报错，提前把属主设对能省一次重跑。两个用户在 /etc/security/limits.conf 里还需要放开文件描述符和进程数限制，否则 RAC 跑起来后监听和后台进程可能报 "too many open files"。

cat >> /etc/security/limits.conf <<'EOF' grid soft nofile 1024 grid hard nofile 65536 grid soft nproc 2047 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768 EOF

环境变量我一般写在每个用户家目录的 .bash_profile 里，而不是 /etc/profile。ORACLE_BASE、ORACLE_HOME、PATH 这些变量指向清晰，后面跑安装脚本和 sqlplus 都不用手动 export。注意 grid 用户和 oracle 用户的 ORACLE_HOME 不一样，混着写容易在 DBCA 建库时报出奇怪的路径错误。

2.4 RPM 依赖核查：少一个包，安装界面就停在预检查

Linux 7.6 最小化安装后缺不少软件包，Oracle 的安装向导在预检查阶段会列出来，但那时再回头装就慢了。我习惯提前把依赖一次性装好。19c 在 Linux 7.6 上必须要 compat-openssl10，这是最容易漏的包，少了它 OUI 预检查直接报错。

yum install -y bc binutils compat-libcap1 compat-libstdc++-33 \ compat-openssl10 elfutils-libelf elfutils-libelf-devel \ gcc gcc-c++ glibc glibc-devel ksh libaio libaio-devel \ libX11 libXau libXi libXtst libXrender libXext make \ net-tools nfs-utils smartmontools sysstat libnsl rpm -qa | grep -E "compat-openssl10|libnsl|sysstat"

最后一条 rpm 查询是确认关键包已经装上。libnsl 在 Linux 7.6 里默认不装，而 19c 的客户端工具在解析主机名时需要它，没装会在运行 dbca 时碰上诡异的段错误。sysstat 提供 sar 命令，后面排查性能问题要用它看历史负载，一次装齐不后悔。如果公司内部有统一的 yum 源，建议在安装前就把这些依赖固化到主机初始化脚本里，每个新节点跑一遍即可。

3. 网络与共享存储：RAC 的血管和仓库

3.1 网卡与 IP 规划：public/private/VIP/SCAN 一张图画清

RAC 网络是整个集群最容易出问题的部分，规划阶段画一张清晰的 IP 分配表比任何配置都重要。每个节点至少需要两块物理网卡：public 网卡承载业务连接、VIP 和 SCAN 监听；private 网卡承载节点间心跳、缓存融合和集群消息。private 网络绝对不能用 public 网段，否则一旦 public 网络抖动，集群通信和业务流量互相干扰，容易引发节点驱逐。

VIP 由 Grid Infrastructure 自动绑定到 public 网卡上，不需要手工配 IP，安装向导里把 public 网卡选对就行。SCAN IP 在 19c 里建议配 3 个，客户端通过 SCAN 名称连接时，会在多个 IP 之间做负载均衡。如果没有 DNS 环境，也可以把 SCAN 写在 /etc/hosts 里，但必须保证集群内所有节点和客户端机器上的解析结果一致。

3.2 hosts 文件与 SSH 互信：装到一半才配就晚了

hosts 文件是 RAC 安装里最基础也最容易被忽视的文件。两个节点必须包含完整的条目：节点名、随后是 VIP 名、private 名、SCAN 名。有一类典型故障是 private 主机名写进了公网 hosts，导致集群在解析内部主机名时走了错误网段，私网心跳时断时续。

cat >> /etc/hosts <<'EOF' 192.168.10.11 node1.example.com node1 192.168.10.12 node2.example.com node2 192.168.10.21 node1-vip.example.com node1-vip 192.168.10.22 node2-vip.example.com node2-vip 10.0.0.11 node1-priv.example.com node1-priv 10.0.0.12 node2-priv.example.com node2-priv 192.168.10.31 rac-scan.example.com rac-scan EOF

配置完成后，用 getent hosts 验证每个名字解析出的 IP 是否正确。private 主机名尽量用 -priv 后缀区分，不要和 public 名称混用。SSH 互信是安装向导自动配置的，但提前手动配好更稳妥，两个用户的公钥都要互相分发，否则 OUI 检查 SSH 连通性那一步会卡住。

ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa ssh-copy-id -i ~/.ssh/id_rsa.pub node1 ssh-copy-id -i ~/.ssh/id_rsa.pub node2 ssh node1 date; ssh node2 date

最后一条命令同时验证了 SSH 免密和时间一致性。注意 grid 用户和 oracle 用户都要各配一次，别只配了 oracle 用户的，安装 Grid Infrastructure 时用 grid 用户执行脚本会报权限错误。

3.3 共享存储与 ASM 磁盘：udev 绑定避免漂移

RAC 的数据库文件必须放在共享存储上。常见做法是两台机器通过光纤或 iSCSI 连接到同一套存储，划分出若干 LUN 作为 ASM 磁盘。安装前在两台机器上都执行 lsblk，确认看到的 LUN 数量、大小一致。这里有个关键的玄学问题：Linux 对 SCSI 盘的设备名分配不保证稳定，重启后 /dev/sdb 可能变成 /dev/sdc，直接裸用设备名做 ASM 盘，重启后磁盘权限和路径全乱。解决办法是用 udev 规则按磁盘的 WWID 绑定固定设备名。

ls /dev/sd* udevadm info --query=property --name=/dev/sdb | grep ID_SERIAL

cat > /etc/udev/rules.d/99-oracle-asm.rules <<'EOF' KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", RESULT=="3600a0b00000abc123", OWNER="grid", GROUP="asmadmin", MODE="0660" EOF udevadm control --reload udevadm trigger ls -l /dev/sd?1

RESULT 后面跟的是通过 scsi_id 查到的 LUN 唯一标识。生产环境的 LUN 数量多，我习惯把规则文件按 WWID 一条条写清楚，每个磁盘对应一个固定名称，避免靠设备名猜。写在 99- 开头的规则文件里，确保不会被其他规则覆盖。权限必须是 grid:asmadmin，MODE 660，如果属主不对，ASM 实例在 OUI 里会发现磁盘但标红不可用。

4. 装 Grid Infrastructure：RAC 的骨架和第一道坎

4.1 用 runcluvfy.sh 做安装前体检：预检查就是后悔药

Grid Infrastructure 是整个 RAC 的骨架，装它之前先跑一遍 Oracle 自带的集群验证工具。这个工具会检查硬件、内核参数、依赖包、网络连通性、SSH 互信等所有前置条件，比人工逐项核对快得多。命令在安装介质解压后的目录下执行。

cd /u01/grid_setup ./runcluvfy.sh stage -pre crsinst -n node1,node2

执行完看输出里的 Check passed 和 Check failed。遇到 failed 项目，按它提示的路径去修，比如某个包没装、某个 sysctl 参数不匹配。有个小技巧：先看 Summary 段，不要盯着几百行滚动输出从头看。如果这台机器以前装过其他 Oracle 软件，cvu 会提示环境变量残留在 /etc/profile 里，顺手清掉再跑，否则后面 OUI 会被旧配置干扰。

4.2 gridSetup.sh 的关键选择：磁盘组、ASM、管理网络

图形安装界面用 grid 用户启动，执行安装介质里的 ./gridSetup.sh。整个安装过程里最需要想清楚的是几个关键点：集群类型选 Oracle Standalone Cluster；网络配置界面会显示检测到的网卡，把 public 网卡对勾选上，private 网卡标为专用，SCAN 名称填 rac-scan 对应的解析名。19c 相比 11g 多了一个管理网络选项，如果没有单独的管理网卡，选择使用 public 网络即可，别勾选独立的 management 接口，否则安装后网卡资源会处于错乱状态。

ASM 磁盘组是另一个关键。磁盘组名称常用 DATA，冗余级别选 EXTERNAL（外部冗余）表示没有镜像，生产环境一般用 NORMAL 冗余，但前提是存储底层的 LUN 数量足够。我见过不少人在测试环境选 NORMAL 冗余，却发现只有一块候选盘，安装界面直接灰掉。测试环境老老实实选 EXTERNAL，一块盘也能建磁盘组。ASM 的 SYS 密码要记好，后面 DBCA 建库和日常维护都要用。

安装向导会列出 OS 组的映射：OSASM 组选 asmadmin，OSDBA 选 dba，OSOPER 选 asmoper。这步如果选错，装完后 asmcmd 和 sqlplus 的权限会很拧巴，重装 Grid Infrastructure 才能解决。全部确认后，向导进入最后的执行阶段，在进度条跑到 100% 附近，会弹出一个提示框，要求分别在两个节点用 root 用户执行 root.sh。

4.3 root.sh 的执行顺序与日志：两个节点各跑一次

root.sh 是 RAC 安装里最容易卡住的一步，也是排错经验最集中的一步。执行顺序有硬性要求：先在第一个节点完整跑完，确认没有报错，再在第二个节点执行。两个节点同时跑可能导致集群配置信息互相覆盖。

# 节点1 [root@node1 ~]# /u01/app/19.0.0/grid/root.sh # 节点2，等节点1 跑完再执行 [root@node2 ~]# /u01/app/19.0.0/grid/root.sh

root.sh 输出里看到 "The command completed successfully" 才算真正完成。它的日志写在 $ORACLE_BASE/crsdata/ 下，具体位置是 /u01/app/grid/crsdata/node1/crs/trace/，如果执行过程卡住，先看这个目录下 ohasd.log 和 cssd.log 的尾部。root.sh 卡住最常见的三个原因：/etc/oracle 目录权限不对、DNS 反向解析失败、私网路由异常。前两个可以通过 chown -R root:oinstall /etc/oracle 和修正 hosts 解决；私网路由异常要检查 /etc/sysconfig/network-scripts/ifcfg-eth1 是否配置了 GATEWAY，私网网卡绝不能配默认网关。

4.4 安装后验证集群状态：crsctl 查看在线状态

root.sh 全部执行完后，用 grid 用户验证集群层面是否健康。crsctl stat res -t 是核心命令，它会列出所有集群资源的当前状态和目标状态。重点关注以下几项：ora.cssd、ora.crsd、ora.evmd、ora.asm、ora.cluster_interconnect.haip 必须 ONLINE，扫描监听 ora.scan1.listener 和节点监听 ora.node1.vip 也要 ONLINE。

crsctl stat res -t asmcmd lsdg crsctl check cluster -all

asmcmd lsdg 看到 DATA 磁盘组的 State 为 MOUNTED，说明 ASM 实例已经正常起来。crsctl check cluster -all 输出两个节点的状态，全绿才算集群层面健康。这一步做完，Grid Infrastructure 的骨架算是立住了，接下来可以进入数据库软件安装。

5. RAC 安装避坑：我在 Linux 7.6 上踩过的五个坑

5.1 现象：root.sh 卡在 ohasd 启动失败

装某套测试环境时，root.sh 执行到 "Adding daemon to inittab" 就停住，等十几分钟也没有后续输出，单独进程里 ohasd 根本不存在。原因是这台机器的 /etc/oracle 目录属主在之前卸载旧环境时变成了 root:root，root.sh 写入 scls_scr 文件时权限校验失败，又不会直接报错退出，而是反复重试。

解决方式：先检查 /etc/oracle/scls_scr 下文件的属主，改成 root:oinstall，然后把 root.sh 进程中断，清理半成品状态后重新执行。清理命令用 $GRID_HOME/crs/install/rootcrs.pl -deconfig -force，这会把已生成的集群配置清掉，再次执行 root.sh 时是干净环境。这个坑的教训是：接手别人装过半截的机器时，先看 /etc/oracle 目录的属主再动手。

5.2 现象：重启后 ASM 盘权限漂移成 root:disk

两节点装完 RAC 后一切正常，某次机房计划性重启，起来后执行 asmcmd lsdsk 发现所有磁盘的路径还在，但权限变成了 root:disk，ASM 实例无法读取磁盘组。原因是 udev 规则虽然写了，但规则触发的条件依赖 scsi_id 命令的返回值，这台机器的 multipath 服务抢先占用了设备节点，udev 规则没有匹配到。

解决方式：确认 /etc/multipath.conf 是否存在，存在则把 ASM 磁盘加入 blacklist，让 multipath 不要接管这些 LUN；然后重新执行 udevadm control --reload 和 udevadm trigger，再检查 /dev/sd?1 的属主是否恢复成 grid:asmadmin。这类问题在混合了多路径和本地盘的存储环境里很容易出现，装完最好做一次带重启的完整验证，别等生产切换时才暴露。

5.3 现象：SCAN IP 解析导致客户端连接报错

集群本身 ONLINE，应用侧 JDBC 连接串用的是 SCAN 名称，但连库时报出 ORA-12545，提示连接目标不可达。排查看监听状态正常、VIP 正常，问题是客户端所在的机器 hosts 文件里只写了 SCAN 名称对应一个 IP，而集群实际监听的是另外两个 SCAN IP。SCAN 在 hosts 解析下不会自动同步，客户端必须能解析到集群配置里全部 SCAN IP。

解决方式：把客户端机器的 hosts 补齐三个 SCAN IP，或者在 DNS 里配置 SCAN 的轮询解析。另一个做法是修改应用连接串，直接用某个节点的 VIP 做测试，但生产环境不值得为省 DNS 配置牺牲 SCAN 的负载均衡能力。这个坑在纯内网环境最典型，网络组和 DBA 各管一段，SCAN 的解析链路上没有人整体兜底。

5.4 现象：crsctl stat res -t 显示 OFFline，手动 start 又报错

某节点资源整体处于 OFFLINE，用 crsctl start resource 单独拉起时报出与节点通信异常的错误。最直接原因是两节点时钟偏差过大，节点间的心跳校验不通过，集群拒绝把资源调度到该节点。检查 chronyc sources 发现时间源失联，节点时间已经慢了两分钟。

解决方式：用 chronyc makestep 强制同步本节点时间，等两个节点时间差小于 1 秒后，在任意节点执行 crsctl stop cluster -all 和 crsctl start cluster -all，让整个集群重新拉起。RAC 对时钟的要求不是玄学，是硬性约束，建议在每台机器上配好 chronyd 的 fallback 时间源，并加监控盯时间偏移量。

5.5 现象：DBCA 建库报 ORA-15095，磁盘组成员读不到

建库到 80% 突然报 ORA-15095，提示 ASM 磁盘无法访问。检查 asmcmd lsdsk 能看到磁盘名称，但 ls -l 发现 /dev/sdb1 的属组是 oinstall 而不是 asmadmin。原因是 udev 规则在最后一次系统更新后被覆盖掉了，磁盘权限回归默认值，而 ASM 实例是在权限正常时启动的，运行中突然失去权限，磁盘组直接进入不可用状态。

解决方式：修正 udev 规则并重新 trigger，然后用 asmcmd 确认磁盘可读；如果磁盘属于某个磁盘组的成员且无法正常 mount，优先在 ASM 实例里执行 alter diskgroup DATA mount，必要时把 offline 的磁盘 online 回来。这个坑告诉我们，udev 规则文件要纳入配置管理，系统更新后主动检查规则是否还在，而不是等 ASM 报错才想起它。

6. 装完怎么验：从 crsctl 到 sqlplus 的十分钟体检

集群装完不是看到 ONLINE 就结束了，我习惯按一张固定清单验收，十分钟跑完，每一项都过一遍才敢交给业务方。下面这个表格就是日常用的体检项目。

crsctl check cluster -all crsctl stat res -t srvctl status database -d orcl srvctl status scan

最后一环，也是我最看重的验证：故障切换实测。找一个维护窗口，在 node1 上执行 shutdown -rf 模拟主机掉电，观察 node2 上的实例是否自动接管，业务连接是否能在数据库 session 层面恢复。切换完成后用 srvctl status database -d orcl 确认集群把 node1 的资源重新拉起，两个实例恢复到 OPEN。这套验证做完，RAC 才算真正交付。

这是我装 RAC 几年养成的习惯：每完成一套环境，就把体检命令存成 shell 脚本，命名 check_rac.sh，放进 /home/grid 下，后续巡检直接跑。安装手册写再多，都不如这套体检脚本可靠。希望帮到你。

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