企业官网建设流程全解析

简介：这是一份面向数据库工程师、软件工程师及数据库学习者的完整实操教程，以VMware虚拟化平台为基础，系统讲解CentOS 7.5环境下部署Oracle 19c RAC集群的全流程，涵盖GRID软件安装、ASM磁盘配置、RAC数据库实例创建、IP与存储空间规划，以及后续的数据库和ASM运维操作，适合希望从零搭建高可用数据库环境的读者。资源包共1个PDF文件，大小5.24MB，内容共111页，按章节组织，从文档说明、安装规划、VMware创建虚拟机到GRID与RAC安装步骤层层递进，并配有空间规划、IP规划等关键参数表，便于对照实施。目前已有418人学习，值得作为生产环境部署Oracle RAC的案头参考与操作手册。

1. 为什么要看这份 CentOS7.5+Oracle 19c+RAC 的 PDF

很多 DBA 和运维手里攒着一堆安装文档，但 CentOS 7.5 配 Oracle 19c RAC 的这一类，往往是群里转来转去、页脚都卷边了的那份。原因很简单：CentOS 7.5 不是 Red Hat 官方认证的 RHEL 版本，Oracle 19c 又是一代大幅改动过的版本，RAC 的安装链路比单实例长得多——光是 Grid Infrastructure（GI）的 root.sh 就能卡掉一半的人。这份 PDF 的价值不是把官方文档翻译一遍，而是它把三个版本组合之间的兼容性、内核参数、cvuqdisk 缺失这类软性坑全部提前踩平了。

这份文档能解决的具体问题包括：在 CentOS 7.5 上让 19c RAC 的安装前检查（cvecheck）一次通过、正确配置共享存储和 ASM 磁盘组、处理 GI 和数据库软件两个 Oracle Home 的安装顺序，以及集群起不来的时候的排查路径。适合三类人：一是刚接手 RAC 环境的新人 DBA，需要一份能照着敲的部署手册；二是做企业私有化交付的工程师，需要在无外网环境下快速出一套高可用数据库；三是准备把旧版 11g/12c RAC 升级到 19c 的运维，需要先理解 19c 在架构和命令层面的变化。

需要先说明，标题指向的是一份 PDF 文档，我这里不会逐页复述它的原文，而是沿着「CentOS 7.5 + Oracle 19c + RAC」这条技术主线，把每步的选型理由、关键参数和最容易翻车的地方讲清楚。你能在这个方向里拿到可复现的步骤，也能看到我做这套环境时踩过的坑。

2. 装 RAC 前先把账算清：硬件、网络和存储的三个硬约束

2.1 为什么 CentOS 7.5 不是 Red Hat 却常被拿来跑 Oracle 19c

Oracle 19c 的官方认证列表里写的是 Red Hat Enterprise Linux 7 系列，但 CentOS 和 RHEL 在二进制兼容性上几乎一致，内核版本、glibc、systemd 的行为都对齐，所以社区和大量企业内部环境都默认 CentOS 7.x 可以跑。关键点是内核版本要和 19c 的 GI 要求的 min kernel 对得上。19c 在 x86_64 上要求内核不低于 3.10.0-957，CentOS 7.5 的内核是 3.10.0-862，这就出现了一个真实存在的落差。

如果你的 CentOS 7.5 内核停留在 862，直接装 GI 18c 以上的版本，root.sh 阶段可能报关于oracle-validated包或内核参数的错。实操里两条路：一条是yum update kernel把内核升到 957 以上再装，另一条是依然用 7.5 但手动补齐所有参数和包。我一般倾向第一条，省心。换句话说，CentOS 7.5 + Oracle 19c RAC 这套组合能成立的前提，是系统内核先对齐到 19c 的认证线。

2.2 两台节点的最低配置和共享存储划分

RAC 至少需要两台节点，每台内存最低按 16G 规划，8G 不是不能跑，但 GI + DB 两个 Home 加上 ASM 实例和集群进程，内存会非常紧张。我自己在虚拟机里做过一次 8G 的测试环境，swap 用得飞起，crsd 进程被 OOM 的概率很大，后来老老实实回到 16G。

存储上，Oracle 19c RAC 支持 ASM 直接管盘，也可以走 NFS，但生产环境绝大多数还是 ASM。需要准备一块共享盘放 OCR 和 Vote File，至少三块小盘做冗余，盘的大小不用太讲究，1G 到 5G 都行。另一组盘放数据文件和 FRA，空间按数据量估。这里注意一个容易忽略的点：OCR 和 Vote File 在 19c 里默认放同一个磁盘组，而且这个磁盘组的冗余度决定了集群的可用性。如果你只有一块共享盘，ASM 的 external 冗余也能建，但任一节点掉盘集群就废了，测试无所谓，生产别这么干。

2.3 网络规划：public、private 和 VIP 的地址分配逻辑

RAC 需要至少两张网卡，一张跑 public 网络（含 VIP），一张跑 private 的集群内部心跳。19c 的 GI 安装时要求你提供 public hostname、node VIP hostname 和 private hostname。常见的坑是 private 网卡用了和 public 同一网段，这在安装检查时会直接报错。标准做法是 private 网络用独立的网段，比如 192.168.56.x 这类不要路由到外部的地址段。

DNS 配置方面，每个节点的/etc/hosts必须写全所有节点的 public、VIP、private 三条记录，缺 VIP 记录或写反 private 地址是安装检查里非常高频的报错来源。下面是我的一份 hosts 模板：

# /etc/hosts 模板，节点一 192.168.10.11 db1.localdomain db1 192.168.10.12 db2.localdomain db2 192.168.10.111 db1-vip.localdomain db1-vip 192.168.10.112 db2-vip.localdomain db2-vip 192.168.56.11 db1-priv.localdomain db1-priv 192.168.56.12 db2-priv.localdomain db2-priv

参数说明：public 和 VIP 在同一网段，VIP 不能配在网卡上，由 GI 的 oracle-rs 脚本统一管理。private 地址必须和 public 分开网段，而且两个节点间的 private 网段要能互通，用ping -c 3 db2-priv验证。特别注意，hostname 里的短名要和/etc/sysconfig/network里配置的 HOSTNAME 一致，否则 GI 的配置工具会识别为两个不同的节点。

3. GI 安装链路：从 yum 依赖到 root.sh 跑通的完整脚本

3.1 用 yum 一次性补齐系统依赖包

CentOS 7.5 装 19c GI 前需要装一堆依赖包，官方文档列得七零八落，实际用 yum 一条命令更省事。前提是你的 yum 源可用，如果机器在隔离内网，需要提前把 RPM 包装到本地。以下是我常用的安装命令：

# 安装基础依赖和 Oracle 需要的包，CentOS 7 用 Oracle Linux 7 的包名兼容 yum install -y binutils \ compat-libcap1 \ compat-libstdc++-33 \ glibc \ glibc-devel \ ksh \ libaio \ libaio-devel \ libgcc \ libstdc++ \ libstdc++-devel \ libXext \ libXtst \ libX11 \ libXau \ libXi \ make \ sysstat \ unixODBC \ unixODBC-devel \ gcc \ gcc-c++ \ elfutils-libelf-devel \ fontconfig-devel \ libXrender-devel \ libXpm-devel \ libXp-devel 2>/dev/null || true # 2>/dev/null 是防止个别包名在 CentOS 7.5 里不存在时直接中断

命令逻辑就是一次性把编译链接、图形界面库、ODBC 驱动全收齐。compat-libstdc++-33这个包在 CentOS 7 的默认源里未必有，需要先启用 EPEL 源或用 Oracle Linux 的包替换，否则会失败。判断依赖是否全部可用的快捷办法是直接启动runInstaller，GI 的安装前检查会报告缺失项，那时再补也不迟。

3.2 用户、内核参数和 limits.conf 的一组统一配置

Oracle 用户和用户组是 RAC 的根，grid 用户和 oracle 用户的属组必须规划一致。常见做法是创建两个用户，oinstall 是所有用户的主组，dba 给 oracle 用户做系统组，asmdba、asmadmin 给 grid 用户做 ASM 的管理组。下面是创建用户和目录的脚本：

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

参数说明：grid 用户必须加 asmadmin 和 asmdba 组，这是 19c 里 ASM 实例归属的硬性要求。oracle 用户不加 asmadmin，只有 asmdba，因为数据库实例只需要访问 ASM 的权限，不需要管理权限。这个分配如果错了，装完 GI 后 oracle 用户执行asmcmd会报权限错误。

内核参数的配置直接影响数据库性能，也能让安装前检查直接绿掉。19c 在 7.5 上的参数比 11g 时代多了不少，我贴一份实际用到的最小集：

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.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 vm.swappiness = 10 EOF sysctl -p

逻辑说明：kernel.shmmax我按物理内存的 50% 以上配置，测试环境 32G 时设成 4T 的上限，目的是让 SGA 在分配时不至于触碰共享内存上限。net.ipv4.ip_local_port_range从 9000 开始是因为 RAC 内部通信会大量占用高端口，范围太窄会导致连接池耗尽。vm.swappiness设 10 是让 Redis、Oracle 这类内存型应用尽量少进入 swap，这个值在 CentOS 7 上对 Linux 内核有效，Oracle 官方文档也推荐了。

最后是 limits.conf。19c 的安装检查对 nofile、nproc、stack 的要求很高，以下配置可以直接覆盖默认：

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

3.3 用 cluvfy 做安装前检查，cvuqdisk 缺失的修复

19c GI 安装包里自带cluvfy工具，做安装前多节点检查是这套流程里最值得花时间的一步。命令路径通常是$GRID_HOME/bin/cluvfy，但在还没有安装 GI 之前，需要通过解压后的安装介质来调用：

# 解压 GI 安装包到 cluster 目录后执行 cd /u01/grid19c export CVUQDISK_PKG=/u01/grid19c/gridSetup.rsp ./runcluvfy.sh stage -pre crsinst -n db1,db2 -fixup -method root

cvuqdisk是全套检查里最容易报错的一项，报错信息通常是缺少cvuqdiskRPM 包。这个包在 GI 安装介质的rpm目录下能找到，名字形如cvuqdisk-1.0.10-1.rpm。安装方式要注意，必须用 root 装到每个节点上：

rpm -ivh cvuqdisk-1.0.10-1.rpm

说明一下：cvuqdisk 是 Oracle 用来探测共享磁盘的一个驱动包，不装的话cluvfy检查共享存储会直接失败，而且后面asmca创建磁盘组时也识别不到盘。这个包虽然小，但因为它藏在 GI 安装介质的 rpm 目录里，很多第一次装 19c RAC 的人会卡在这一步。

3.4 响应文件静默安装 GI，root.sh 的等待与验证

GUI 跑runInstaller在单一节点上没问题，但多节点环境里更容易复现、更适合写成脚本的是响应文件静默安装。19c 的 GI 安装响应文件与其他版本差异不小，最常见的方式是先用图形界面生成一份 rsp，然后拿它做静默安装。但如果没有图形环境，可以直接手写一个最小响应文件：

# grid19c.rsp 的片段 oracle.install.responseFileVersion=/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0 INVENTORY_LOCATION=/u01/app/oraInventory oracle.install.option=CRS_CONFIG ORACLE_BASE=/u01/app/grid ORACLE_HOME=/u01/app/19.0.0/grid oracle.install.asm.OSDBA=asmdba oracle.install.asm.OSOPER=asmoper oracle.install.asm.OSASM=asmadmin oracle.install.asm.SYSASMPassword=YourPassw0rd oracle.install.asm.diskGroup.name=DATA oracle.install.asm.diskGroup.redundancy=EXTERNAL oracle.install.asm.diskGroup.AUSize=4 oracle.install.asm.diskGroup.disks=/dev/sdb1;/dev/sdc1 oracle.install.crs.config.scanName=scan-cluster.example.com oracle.install.crs.config.gpnp.enableGpnp=true

说明关键参数：INVENTORY_LOCATION是 oraInventory 的位置，必须所有节点一致；oracle.install.asm.diskGroup.disks用分号分隔多块 ASM 盘；oracle.install.asm.SYSASMPassword会用于 ASM 实例的 SYS 用户，后续 dbca 建库时还要用到。SCAN 名称需要提前在 DNS 里配好，如果没有 DNS，可以在/etc/hosts里把 SCAN 解析到其中一个节点的 public IP 上，测试环境这样做没问题，生产环境建议还是上 DNS。

启动静默安装后，安装脚本会在两个节点上依次执行 root.sh。这个阶段最容易出现的问题有两个：一是 root.sh 在第二个节点上跑的时候因为 ssh 互信没配对而失败；二是 root.sh 执行期间发生了ohasd启动失败，常见原因是/etc/oracle目录权限或has服务被 systemd 的默认配置干扰。验证 GI 是否装好，用下面这组命令：

# 以 grid 用户执行 crsctl check cluster -all crsctl status resource -t

正常能看到 ora.cssd、ora.diskmon、ora.evmd 等资源在两边节点都是 ONLINE。如果只有一边 ONLINE，先看$ORACLE_HOME/log/下的 alert 日志，再检查 private 网络互通。

4. 从 ASM 磁盘组到 19c 数据库实例：dbca 建库的完整参数链路

4.1 先理解 19c RAC 的两个 Home：Grid Home 和 DB Home

19c 的软件布局沿用了 18c 的拆分方式——GI 的 Oracle Home 只负责集群和 ASM，数据库软件的 Home 单独一套。这意味着你在系统里会看到两个 ORACLE_HOME：一个属于 grid 用户，通常是/u01/app/19.0.0/grid；另一个属于 oracle 用户，通常是/u01/app/oracle/product/19.0.0/dbhome_1。

这一拆分带来的直接影响是环境变量的设置必须严格区分。很多人在两个 Home 切换时把 ORACLE_HOME 指错，然后在sqlplus里连接的时候报ORA-12547或者直接找不到libclntsh.so。我的习惯是给每个用户单独写一个.bash_profile，grid 用户只指向 GI 的 Home，oracle 用户只指向 DB 的 Home，避免交叉。

4.2 用 asmca 创建 DATA 和 FRA 磁盘组

GI 装完后，ASM 实例已经在跑了，但还没有可用的磁盘组。使用 asmca 的图形界面能比较直观地建磁盘组，但同样可以通过命令行的asmca -silent完成。下面的命令建立一个外部冗余的 DATA 磁盘组和一个外部冗余的 FRA 磁盘组：

# 以 grid 用户执行，-silent 参数避免图形界面 asmca -silent \ -createDiskGroup -diskGroupName DATA \ -diskList /dev/sdb1,/dev/sdc1,/dev/sdd1 \ -redundancy EXTERNAL \ -auSize 4 \ -sysAsmPassword 'YourPassw0rd' \ -asmsnmpPassword 'YourPassw0rd' asmca -silent \ -createDiskGroup -diskGroupName FRA \ -diskList /dev/sde1,/dev/sdf1 \ -redundancy EXTERNAL \ -auSize 4 \ -sysAsmPassword 'YourPassw0rd' \ -asmsnmpPassword 'YourPassw0rd'

参数说明：-auSize 4表示 ASM 分配单元大小是 4MB，19c 默认就是 4MB，这个是针对 OLTP 类随机 IO 的推荐值，如果你要跑数仓类的顺序大文件，auSize 可以改成 8 或 16。-redundancy EXTERNAL意味着这块磁盘组里任何一块盘挂了数据就真没了，生产中至少要用 NORMAL（需要至少三块盘）。FRA 磁盘组是专门给归档日志和闪回用的，大小建议为数据总量的两倍，理论上越大越灵活。

4.3 dbca 静默建 RAC 数据库：参数选型和实测要点

数据库实例的创建在 19c 里依然可以用 dbca 的图形向导，但静默方式更适合脚本化交付。常见做法是写一个 dbca.rsp 响应文件，然后执行：

dbca -silent \ -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -numberOfPDBs 1 \ -pdbName orclpdb \ -systemPassword 'YourPassw0rd' \ -sysPassword 'YourPassw0rd' \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaDiskGroup FRA \ -recoveryAreaSize 200G \ -totalMemory 8G \ -characterset AL32UTF8 \ -nationalCharacterSet UTF8 \ -sampleSchema false \ -databaseType OLTP \ -nodeList db1,db2

各参数的含义和修改逻辑：-numberOfPDBs 1会在容器数据库里自动创建一个可插拔库，19c 是默认多租户架构，单实例也可以选择非 CDB 模式，但 RAC 建议直接上 CDB 方便后续运维。-totalMemory 8G是给数据库实例的 SGA+PGA 的合计上限，如果节点本身只有 16G 内存，这个值超过 10G 就可能跟 GI 抢内存。-recoveryAreaSize 200G要匹配 FRA 磁盘组的实际容量，设大了 dbca 会报警，设小了归档日志容易被撑满。

建库完成后验证数据库实例在两个节点上都能打开：

# 以 oracle 用户执行 srvctl status database -d orcl srvctl start database -d orcl

4.4 19c 的新特性在 RAC 安装里的实际影响

19c 在 RAC 安装链路上有几个地方和老版本有明显差异。一个是前面说的 Oracle Home 分离，另一个是安装介质的解压结构变化——19c 的 DB 和 GI 安装包下载下来是 zip 文件，解压后结构完全不同，GI 的解压目录直接就是安装程序所在目录，而 DB 的解压目录下要再分Database子目录才找得到安装程序。

还有一个对运维影响大的点是 19c 的srvctl命令支持了更多的资源属性。例如管理 PDB 时，直接用srvctl add service -db orcl -pdb orclpdb就能注册一个服务指向特定 PDB，这在 12c 时代还要手工改服务名。另外，19c 里crsctl status resource的输出比 11g 长很多，你会在其中看到许多名字里带.pxp、.gns的资源——这是 GI 自带的 GNS 和 PX 协议组件，如果没配置 DNS，这些资源的状态会是 OFFLINE，但通常不影响集群整体功能。

5. RAC 部署避坑实录：常见问题的现象、原因与解法

5.1 安装前检查时 cluvfy 报共享存储不可见

现象：runcluvfy.sh stage -pre crsinst执行到共享存储检查步骤时报错，提示找不到候选磁盘，或者盘在节点一能看到、节点二看不到。

原因：这类问题多数不是磁盘真没接好，而是多路径软件没有配或者 ASM 使用的磁盘设备名不一致。比如节点一上 ASM 盘是/dev/sdb1，节点二上同一个 LUN 却变成了/dev/sdc1。也可能是没有安装cvuqdisk，导致 GI 无法通过驱动枚举共享盘。

解决：先统一两节点的设备名，最好的办法是用/dev/mapper/下的设备名或<data的盘符ID>绑定。检查两节点/dev/mapper下是否有相同名称的映射；如果没有，用multipath -ll确认多路径是否生效。临时做法是把 ASM 盘的 owner 改成 grid:asmadmin 并把权限设为 660，再用asmcmd lsdsk确认。

5.2 root.sh 在第二个节点执行失败，提示 CSS 无法启动

现象：GI 安装过程中，第一个节点的 root.sh 正常结束，但第二个节点执行 root.sh 时提示CRS-5010或ohasd failed to start，之后crsctl check cluster显示只有一个节点的组件是 ONLINE。

原因：最常见的是两个节点之间的 SSH 互信没有完全建立，导致第二个节点向第一个节点请求集群配置时被拒绝。另一个高频原因是第二个节点的主机名解析到了错误的 IP 或/etc/hosts里写了多余条目，导致 GI 无法识别这是同一套集群的第二个成员。

解决：重新用ssh-keygen和ssh-copy-id重建两个节点 grid 和 oracle 用户的互信。然后逐行检查/etc/hosts，确保只有一套主机名映射。最后在第二个节点以 grid 用户执行crsctl start crs看具体报错，配合$ORACLE_HOME/log/db1/agent/下的ohasd日志定位根因。

5.3 ASM 磁盘组磁盘头损坏或 ASM 实例起不来

现象：机器重启后crsctl status resource -t里ora.asm是 OFFLINE，通过crsctl start resource ora.asm启动时报从磁盘组读取失败或磁盘头无效错误。

原因：ASM 磁盘头损坏通常不是硬件问题，而是磁盘组里某块盘被操作系统重新分区或格式化导致 disk header 被覆盖，也可能是/dev/sdX设备名刷新后 ASM 无法通过设备名定位到盘。

解决：先用kfed read /dev/sdb1查看磁盘头内容，确认 AU size、磁盘组名以及盘在组内的编号。如果确实是磁盘头被抹掉，可以用kfed repair恢复，但前提是你手里有另一块同组盘的完好头部信息作参考。更稳的做法是在恢复前先用dd备份坏盘的前 100MB，再尝试修复，这样即便kfed repair失败也有后悔药。

5.4 数据库实例能起，但只有单个节点注册了服务

现象：srvctl status service -d orcl显示服务只在 db1 上运行，db2 上的实例启动了但服务没有注册。

原因：这通常不是故障，而是服务的 TAF 策略配置问题。默认策略下服务只在一个实例上运行，另一个节点作为备用。DBA 误以为 RAC 的服务必须在所有节点都启动。

解决：确认业务需要的模式。如果是负载均衡型，可以用srvctl modify service -d orcl -s orcl_service -availpolicy balance -preferred db1,db2改配置。如果是 failover 型，保持当前配置即可。这个坑之所以常见，是因为很多 DBA 从单实例切到 RAC 后，对服务管理模型没有切换过来。

5.5 SCAN IP 解析失败导致 JDBC 连接报 ORA-12545

现象：应用通过 SCAN 连接数据库报ORA-12545: Connect failed because target host or object does not exist，但直接连节点 IP 可以正常连接。

原因：SCAN 的解析可能落在了只有一个节点 IP 的 hosts 文件上，或者 SCAN VIP 在 DNS 中没有正确注册。19c 里如果使用 GNS，SCAN 由 GNS 自动管理；如果没有 GNS，你必须手动维护 DNS 或 hosts 内的 SCAN 解析。

解决：测试环境最简单的方式是确保 SCAN 的三个 IP 都写进/etc/hosts，并且每个节点看到的解析一致。生产环境建议把 SCAN 三个 IP 和对应主机名配到 DNS 的 round-robin 记录里；排查时用nslookup scan-cluster.example.com和ping scan-cluster.example.com验证解析结果。还要检查 listener 是否正确注册了 SCAN listener，用lsnrctl status LISTENER_SCAN1查看。

6. 留给维护期的一个技巧：用 asmcmd 和 crsctl 快速确认集群健康度

进入维护期后，你最有用的工具不是 GUI 控制台，而是命令行。我日常巡检 RAC 的第一件事是执行crsctl status resource -t，但这条输出太长了，我不会每条细看，直接拉关键项：

crsctl status resource -t | grep -E "ora.(asm|cssd|evmd|diskmon|scan)" | \ grep -E "ONLINE|OFFLINE" | sort | uniq -c

这个命令的意图是把所有集群核心资源的在线状态汇总成一个统计输出。ora.asm表示 ASM 实例资源，ora.cssd是 Cluster Synchronization Service，ora.evmd是事件管理守护进程，ora.scan是 SCAN listener。如果某个资源在两节点上只有一个 ONLINE，说明集群有隐患。

ASM 磁盘组的状态是另一个巡检重点。用asmcmd能一目了然地看到磁盘组的挂载状态和可用空间：

asmcmd -p lsdg

输出里关注 USABLE_FILE_MB 如果持续低于 10%，就该考虑扩容或清理归档。注意asmcmd默认要用 grid 用户执行，而且环境变量 ORACLE_SID 要设为+ASM1（节点一）或+ASM2（节点二）。如果你的 oracle 用户也能执行，那多半是之前提到的属组配置有问题。

最后分享一个我在维护 RAC 时的习惯：每次装完 19c RAC，都会把响应文件、/etc/hosts备份、cvuqdisk的 RPM 包放到一个独立目录里，并且在两台节点上再各存一份。这个习惯救过我不少次——有次因为存储整列损坏要重搭集群，我没有重新解压安装包，直接用备份的响应文件和命令脚本在半小时内恢复了 GI。把整套安装过程整理成可重复执行的脚本，而不是依赖点鼠标的记忆，是 RAC 运维里最值得投入的一件事。希望这些经验帮到你。

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