企业官网建设流程全解析

1. 别急着点安装包：19c RAC的架构决定成败

先说结论：Oracle 19c RAC不是“装一个数据库”，而是“在共享存储上搭一套集群，再把数据库跑进去”。很多第一次接触RAC的人上来就下载Oracle Database 19c的安装包，结果装到一半发现缺GI（Grid Infrastructure）、缺ASM、缺共享磁盘，整个流程直接卡死。我见过太多连“RAC到底需要几台机器”都没搞清楚的同行，所以我决定把这篇博客的重点放在“怎么装”之前——“怎么想清楚再装”。

RAC（Real Application Clusters）的核心价值，用一句话说就是在多台服务器上运行同一个数据库实例，这些实例通过共享存储访问同一份数据文件，当一个节点宕机，另一个节点能继续提供服务，业务几乎无感知。而支撑这个架构的底座，就是Oracle 19c时代的标准集群软件——Grid Infrastructure（GI），它包含了Clusterware（节点通信、资源管理）、ASM（自动存储管理）、ACFS（集群文件系统）等一系列核心组件。先装GI、再装数据库软件、最后用DBCA建库，这个顺序不能乱。

这篇文章主要写给两类人：一类是第一次在Linux上搭19c RAC的DBA，希望少走弯路；另一类是平时只玩单机Oracle，突然要接手RAC环境的运维。我会从环境规划开始，一路讲到GI安装、数据库建库和常见问题排查，全程用我自己实际操作的细节来铺开，没有一句是官方网站文档的翻译腔。

动手之前，先盘一盘整个安装过程中最容易被低估的三件事：服务器配置、共享存储和网络规划。这三件事没想明白，后面每一步都在给自己挖坑。

1.1 19c RAC的架构到底“大”在哪里

很多人以为RAC就是把Oracle装两遍，其实不是。RAC里有两层核心代码：第一层叫Clusterware，负责管理节点成员关系、锁、心跳、资源调度；第二层叫ASM，负责管理磁盘，你在Linux上看到的裸设备、分区、多路径盘，最终都要被ASM接管。GI这一层装好后，系统里会多出一堆进程，比如crsd.bin、ocssd.bin、evmd.bin、cssdagent，它们分别负责集群资源、节点心跳、事件通知，任何一个挂掉，集群都可能出问题。

所以在规划阶段，你就要清楚：这台服务器不是简单地装上Oracle 19c就完事，它至少要跑两套“操作系统级的守护进程体系”——一个是Linux自己的systemd，另一个是Oracle GI的crs体系。这两个体系还会互相影响，比如Linux防火墙没关、SELinux没关、NTP没配好，都会导致GI起不来或者节点被踢出集群。

架构上的另一个关键点是SCAN（Single Client Access Name）。RAC时代的客户端连接方式和单机完全不一样，单机连一个IP，RAC则建议配一个SCAN域名，由DNS解析出三个VIP，客户端只需要连SCAN，集群内部自动分发到具体节点。如果你没配DNS，也可以用hosts文件硬解析，但要提前规划好IP。这里面的坑我后面会详细讲，第一次弄RAC的人最容易在IP规划上翻车。

1.2 安装之前必须想清楚的选型问题

版本选型这件事，很多人的做法是“去官网下载最新的19c”，但19c也分小版本，而且有时候补丁版本太新反而和Linux内核存在兼容性问题。我在生产环境用的组合是：Oracle Linux 7.9（或RHEL 7.9）+ 19.3.0.0基础版 + 最新的RU（Release Update）补丁。19.3是19c的初始版本，必须至少要打到19.10以上才建议上生产，因为早期的19.3存在不少已知Bug，比如ASM磁盘组兼容性、Clusterware滚动补丁失败等问题。

如果你是测试环境，装个19.3直接用也行，但生产环境一定要规划补丁。另外一个容易忽略的点是/etc/hosts里的主机名解析顺序，RAC要求节点名、VIP名、SCAN名、GNS名（如果你用GNS）都能被正确解析。很多安装失败的案例，最后查来查去都是hosts文件写错了。

还有一个选型问题是“用不用DNS”。说实话，我建议测试环境直接用hosts文件，生产环境用DNS + 固定IP + SCAN。GNS（Grid Naming Service）虽然能自动分配VIP和SCAN，但依赖DNS动态更新，很多企业内部DNS团队配合度不高，反而给自己找麻烦。所以我在生产环境几乎不用GNS，全部固定IP，SCAN域名也手动写在DNS里。

1.3 一次失败装机的预算清单

我自己第一次装19c RAC的时候，整整折腾了一个多星期，最后才发现问题是共享磁盘的udev权限没配对——两个节点的ASM盘属主和权限不一致，导致第二个节点挂载磁盘组失败。那次经历让我养成一个习惯：在装GI之前，把所有的环境检查项列成一个清单，逐项打勾，缺一项就停下来先解决。

这个清单包括：

• 两台服务器的主机名、公网IP、私有IP、VIP、SCAN IP是否规划完毕
• 系统版本、内核参数、依赖包是否全部准备好
• 共享存储是否已从存储侧映射到两台服务器，LUN是否一致
• ASM盘是否已用multipath或udev绑定，属主是否为grid:asmadmin、权限是否为660
• SSH互信是否配置成功
• Linux防火墙、SELinux是否关闭，NTP时间同步是否生效
• /etc/hosts解析是否正常，两个节点的hostname是否不重复

这些检查项每一个背后都有一段“血泪史”。接下来我按实操顺序，从最底层的Linux系统配置开始，一直到建库完成，逐项展开。你可以直接把这篇文章当一份checklist用，装到哪一步就翻到哪一节。

2. 从裸服务器到可安装环境：Linux基础配置

很多初学者以为RAC的安装难点在Oracle软件本身，其实前期的Linux系统配置才是决定成败的关键。这里没有巧劲，只有细节——你配置错了任何一个系统参数，后面GI安装检测的那一步就会直接告诉你不通过，然后你只能一层一层往回找原因。

2.1 基础环境：一台“配得恰到好处”的Linux

先说系统版本。我推荐的操作系统是Oracle Linux 7.9或RHEL 7.9，内核版本3.10。19c官方要求的最低内核版本是3.10.0-327.el7，但新一点的补丁版本对内核也有要求，所以建议装系统时直接选7.9，避免以后打补丁还要升级内核惹麻烦。

系统装好之后，第一件事不是安装Oracle，而是做几项“纪律性”配置：

• 关闭防火墙：systemctl stop firewalld && systemctl disable firewalld
• 关闭SELinux：修改/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled
• 配置hosts文件：把节点名、VIP、SCAN全部写进去
• 配置时间同步：用chrony或NTP，保证两个节点时间差不能超过阈值（默认是30秒，但建议相差不超过1秒）

为什么关防火墙？因为RAC集群内部通信需要大量端口，比如1521、1522、5500等，如果防火墙策略没放行，节点之间通信异常，集群就会出现“脑裂”甚至节点被驱逐。测试环境直接关掉最省心，生产环境则要按端口清单逐一放行。SELinux同理，Oracle官方虽然给过SELinux的布尔值设置方法，但绝大多数情况下你很难精确匹配所有进程的上下文，关掉是最稳的选择。

hosts文件的写法是个技术活。假设我有两个节点，主机名分别是rac1和rac2，它们的公网IP是192.168.1.101/102，私有IP是10.0.0.101/102，VIP是192.168.1.111/112，SCAN IP是192.168.1.121。那么/etc/hosts应该这样写：

192.168.1.101 rac1.localdomain rac1 192.168.1.102 rac2.localdomain rac2 10.0.0.101 rac1-priv.localdomain rac1-priv 10.0.0.102 rac2-priv.localdomain rac2-priv 192.168.1.111 rac1-vip.localdomain rac1-vip 192.168.1.112 rac2-vip.localdomain rac2-vip 192.168.1.121 rac-scan.localdomain rac-scan

注意这里是三个IP段：公网IP用于业务流量，私有IP用于集群内部的cache fusion和心跳，VIP是节点漂移地址。很多新手只用两个IP，把私有IP省略了，结果安装时crsctl检查直接报错，连crsctl start crs都起不来。私有IP网络在RAC里是“生命线”，cache fusion的块传输都走这个网卡，如果延迟太高或丢包，整个集群的性能都会崩。

时间同步这一项，我用的是chrony，因为RHEL 7内置chrony比NTP更好用。重点是：永远不要把两个节点互相当成时间源，必须指向同一个外部时钟源。我第一次装的时候把节点1设为节点2的时间源，结果发现两台机器时间一直有偏差，后来改成都指向公司内部的NTP服务器才稳定。

2.2 共享存储与ASM磁盘组规划

接下来是重头戏：共享存储。RAC要求所有节点都能访问同一份数据文件，所以你必须有一台共享存储设备（比如SAN存储、磁盘阵列、或者测试环境用iSCSI）。在测试环境里，最常见的共享存储方案是Openfiler、FreeNAS或者直接用VMware的共享虚拟磁盘，但在生产环境，用的都是企业级存储 + 光纤通道 + multipath多路径。

我在测试环境里用的方案是iSCSI + Linux multipath：存储侧把LUN映射给两个节点，然后在Linux上用multipath -ll确认多路径盘符。一个关键点：两个节点上看到的多路径设备名必须一致，比如都叫/dev/mapper/data01，否则ASM磁盘组在另一个节点上无法识别。

共享磁盘规划的核心指标是磁盘大小和磁盘数量。ASM磁盘组可以有三种冗余级别：

• External Redundancy（外部冗余）：不冗余，依赖存储自身RAID。适合测试环境。
• Normal Redundancy（正常冗余）：一份数据存两份，至少需要两个failure group，磁盘数量要够。
• High Redundancy（高冗余）：一份数据存三份，至少需要三个failure group。

我建议生产环境用Normal，ASM磁盘组至少配置两个failgroup，每个failgroup至少2块盘，这样任意一块盘坏掉都不会导致数据丢失。测试环境可以先External，少占空间，但生产千万别这么做。另外，磁盘组的命名建议用简短的英文别名，比如DATA、FRA，不要用系统自动生成的+DATA_0000这种名字去手动管理磁盘，那样太乱。

磁盘大小的计算可以按这个思路来：假设数据库的数据文件是500GB，归档日志放在FRA里，FRA一般建议是数据文件大小的2倍，也就是1TB。那么测试环境至少需要500GB的DATA磁盘组和1TB的FRA磁盘组，Normal冗余下总量就要翻倍。先把这些数字定下来，再去存储侧划LUN，省得到时候折腾半天发现磁盘不够。

设备绑定这块，我强烈建议用udev而不是ASMLIB。ASMLIB早就被Oracle放弃支持了，在Oracle Linux 7上去装ASMLIB纯属给自己添堵。udev的配置方法是写一个/etc/udev/rules.d/96-oracle.rules文件，把每个ASM盘的/dev/mapper/xxx固定映射成/dev/asm-disk1这种名称，并设置属主和权限。举个例子：

KERNEL=="dm-*", PROGRAM=="/sbin/scsi_id -g -u -d /dev/$name", RESULT=="3600c0ff000d1234567890abcdef", SYMLINK+="asm-disk1", OWNER="grid", GROUP="asmadmin", MODE="0660"

写完规则后，执行udevadm control --reload && udevadm trigger，然后确认/dev/asm-disk1出现并且属主是grid:asmadmin。这一步是最容易被忽略也是最容易出问题的环节，两个节点的设备名不一致、权限不一致、UUID写错，都会导致GI安装时ASM磁盘发现失败。

2.3 用户、组和目录规划

在Linux上安装Oracle，需要创建两个专用用户：grid用户（用于安装GI和ASM）和oracle用户（用于安装数据库软件）。同时需要创建以下Linux用户组：

• oinstall：Oracle软件所有者组
• dba：数据库管理员组
• oper：数据库操作员组（可选）
• asmadmin：ASM管理员组，把grid用户加入该组
• asmdba：ASM和数据库管理员组，把oracle用户和grid用户都加入该组
• asmoper：ASM操作员组（可选）

我的习惯是：

groupadd oinstall groupadd dba groupadd oper groupadd asmadmin groupadd asmdba groupadd asmoper useradd -g oinstall -G dba,asmadmin,asmdba,asmoper grid useradd -g oinstall -G dba,asmdba,oper oracle

然后创建Oracle安装目录，并设置属主：

mkdir -p /u01/app/19c/grid mkdir -p /u01/app/oracle mkdir -p /u01/app/oraInventory chown -R grid:oinstall /u01/app/19c chown -R oracle:oinstall /u01/app/oracle chown -R grid:oinstall /u01/app/oraInventory chmod -R 775 /u01/app

目录结构的使用方式特别需要注意：oraInventory在GI安装时必须和数据库软件的安装目录分开，否则后面会遇到“inventory指针指向错误”的问题。很多老手在这个环节都有过惨痛教训：因为图省事，把所有目录全给了oracle用户，结果GI安装时orainstRoot.sh脚本执行权限不对，导致整个安装失败。

环境变量的配置也是必须做在前面的事。grid用户的环境变量和生产数据库的oracle用户环境变量不同，我的配置方式是用一个独立的grid.env文件，方便切换。比如grid用户：

export ORACLE_BASE=/u01/app/grid export ORACLE_HOME=/u01/app/19c/grid export ORACLE_SID=+ASM1 export PATH=$ORACLE_HOME/bin:$PATH

注意ORACLE_SID在GI安装前不要设置得和后面安装完一样，否则可能导致一些命令连接进错误的ASM实例。我通常先把注释掉，装完GI后再补上，避免灰头土脸找半天原因。

2.4 系统内核参数与依赖包

内核参数配置是一个容易让人选择困难的地方。好在Oracle官方提供了一键配置工具——oracle-database-preinstall包，安装后会自动配置所有内核参数、依赖包甚至一些辅助工具。但有些环境里装不了这个包，这就得手动设置。

最关键的几个内核参数：

• kernel.shmall：共享内存页数，建议设为物理内存的75%除以页大小
• kernel.shmmax：单个共享内存段的最大大小，建议设成物理内存的一半（但不要超过15GB）
• kernel.shmmni：共享内存段数量，4096足够
• vm.swappiness：建议设为10，避免Linux过多使用swap导致性能下降
• fs.aio-max-nr：建议设成1048576，保证异步I/O够用
• fs.file-max：建议设成6815744

这些参数都写在/etc/sysctl.conf里，然后执行sysctl -p生效。除了内核参数，还有一系列依赖包：binutils、compat-libcap1、gcc、gcc-c++、glibc、glibc-devel、ksh、libaio、libaio-devel、libgcc、libstdc++、libstdc++-devel、libXext、libXtst、libX11、libXau、libXi、make、sysstat、unixODBC、unixODBC-devel等。你当然可以一个个手动yum，但更省事的是先装oracle-database-preinstall这个RPM包，能省掉一大堆排查依赖的时间。

在Oracle Linux 7上，执行：

yum install -y oracle-database-preinstall-19c

这个包会自动把上面的依赖包全部装好，还会创建oracle用户和组。如果你用的不是Oracle Linux而是RHEL 7，可能没有这个RPM包，那就只能用本地光盘或yum仓库手工安装了。

3. 安装GI：最容易被“卡脖子”的一步

GI安装是整个19c RAC流程中最容易出错、也最考验耐心的环节。很多人卡在这一步好几天，不是因为在安装界面里选错了选项，而是因为前期Linux环境、共享磁盘权限、以及系统依赖包没搞干净。如果你前面的基础环境配置全部检查通过了，到这一步应该会顺利很多，但仍然有些细节值得单独拎出来讲。

3.1 安装前的cvuqdisk和依赖包检查

GI安装包解压之后，在/u01/app/19c/grid下会有很多RPM包和脚本。安装之前需要先手动安装cvuqdisk，它的作用是让Oracle的集群验证工具（CVU）能识别到你的共享磁盘。这个包在安装介质里的GridSetup的rpm目录下，文件名叫cvuqdisk-1.0.10-1.rpm或类似。

执行安装：

cd /u01/app/19c/grid/rpm rpm -ivh cvuqdisk-1.0.10-1.rpm

如果在安装时提示libcap.so.1: cannot open shared object file这种错误，说明缺compat-libcap1包，装一下gcc相关依赖就行。解决依赖问题后，还要设置一个环境变量让CVU能找到磁盘：

export CVUQDISK_GRP=oinstall

如果你忘了装cvuqdisk就直接安装GI，会在“Run as root”这个环节被srvctl或root.sh卡住，所以别跳过这一步。

3.2 安装介质与gridSetup.sh

把GI的安装包下载解压后，在/u01/app/19c/grid目录下以grid用户执行：

cd /u01/app/19c/grid ./gridSetup.sh

启动后是图形界面。如果你在远程服务器上没有图形界面，需要先配置X11转发或者使用VNC。但我觉得大多数生产环境根本不会开图形界面，所以更推荐用命令行模式安装，虽然交互步骤多一点，但更可控。实际生产我更喜欢“图形+静默”结合：先把配置写在响应文件里，再用./gridSetup.sh -silent -responseFile /path/to/grid.rsp这种方式。不过对于第一次尝试的人，图形向导反而更直观，能帮你理解每一步是干什么的。

图形向导里的关键选项是：

• 选择“Configure Oracle Grid Infrastructure for a New Cluster”
• 填写Cluster Name（集群名），比如rac-cluster
• 选择“Configure a Standard Cluster”
• 添加两个节点的主机名和VIP地址

SCAN和GNS部分，我前面提过生产环境推荐用DNS做SCAN解析。在这个界面里，选“Use DNS for SCAN”并填写SCAN名称（比如rac-scan.example.com）。如果你没DNS，选“Use GNS”则需要在DNS里配置GNS区域，口味比较重，测试环境可以直接选“Configure SCAN using a manually configured SCAN listener”这种变通方案，把SCAN IP写在hosts里也可以。

接下来会进入SSH互信配置的步骤。这一步会检测两个节点之间的SSH连通性，你需要先手动配置好grid用户的SSH公钥互信。具体操作是分别在两个节点上执行ssh-keygen生成密钥，然后把~/.ssh/id_rsa.pub追加到对方的~/.ssh/authorized_keys里。配置完后用ssh rac1 date、ssh rac2 date测试一下，确保不输密码能连通。界面里点的“Test”按钮本质上就是测试这个互信。

3.3 OCR与Voting Disk的存放位置

GI安装需要两个关键元数据：OCR（Oracle Cluster Registry）和Voting Disk，它们都必须存放在共享存储上，RAC才能保证集群状态的一致性。在安装向导中，ASM磁盘组部分会要求你选择用于存放OCR和Voting Disk的磁盘组。

我的习惯是单独建一个小的ASM磁盘组，比如叫+SYSTEM，大小20GB即可，专门用来放OCR和Voting Disk。这个磁盘组我设置Normal冗余，两块盘各10GB；如果测试环境，可以直接External，一块盘20GB。注意：千万不要把OCR/Voting Disk和数据库文件放到同一个磁盘组里，否则查询性能和数据安全边界都会受影响。

接下来ASM磁盘组配置有一个选择：是否启用“ASM Filter Driver”。这个技术其实就是用一个内核模块直接过滤IO请求，避免某些节点错误地写入磁盘组。默认推荐启用，但我建议测试环境可以先不启用，因为启用后需要额外配置内核模块和系统启动项，对新手不友好。生产环境建议启用，详见Oracle官方文档。

配置完磁盘组之后，安装程序会跑一个“Run as root”的脚本步骤，要求你在两个节点上分别执行orainstRoot.sh（在/u01/app/oraInventory目录下）和root.sh（在$GRID_HOME目录下）。这一步一定要按顺序来：先在节点1执行orainstRoot.sh，再在节点2执行；然后节点1执行root.sh，节点2执行root.sh。root.sh执行过程中会向hosts文件和OCR写入关键配置，如果在两个节点同时执行，会造成锁等待，甚至导致OCR写入失败。

3.4 root.sh的“通病”与ASMCA验证

root.sh执行中经常遇到的坑，我举一个最常见的例子：执行到一半报错说“The number of votes needed for a quorum is equal to the number of votes in the configuration”。这个报错一般是因为Voting Disk磁盘的发现权限或者ASM磁盘组权限有问题，尤其常见于udev配置错误的情况。解决方法是先检查ll /dev/asm-disk*，确认属主都是grid:asmadmin、权限是660，两个节点一致；然后再重新执行一次root.sh。

另一个很常见的问题是DNS解析。root.sh在执行时，会尝试用SCAN名字解析VIP，如果你没有配置DNS，仅靠hosts文件，那么一定要确保/etc/hosts里的SCAN域名不是注释状态。有些安装文档建议在生产环境使用DNS，但如果你因为测试环境跳过DNS，务必确认SCAN解析出的IP是三个固定的VIP或者一个固定的虚拟IP，不要解析到节点自身的公网IP，否则会导致SCAN监听器注册失败。

GI装完以后，用crsctl stat res -t检查一下集群资源状态，你会看到一排资源都是ONLINE状态，其中ora.asm、ora.cssd、ora.crsd必须是ONLINE。然后执行asmca打开ASM配置助手，确认ASM实例运行正常，并且+SYSTEM、+DATA、+FRA这些磁盘组都是MOUNTED状态。另外，还能用asmcmd lsdg查看磁盘组的使用情况，顺便验证一下两个节点的ASM实例是否都正常。

4. 数据库软件安装与DBCA建库

GI安装完毕后，集群的底层已经具备跑RAC的条件了，接下来安装数据库软件和创建数据库就相对顺畅很多。但这里的“顺畅”是相对的——如果GI环节没整利索，数据库软件安装时依然会提示各种问题。这一节我接着讲数据库软件安装的过程，然后到DBCA建库为止。

4.1 数据库软件安装：oracle用户的“主场”

数据库软件安装必须以oracle用户执行，中间会用到oracle用户和oracle组。解压数据库安装包到/u01/app/oracle/product/19c/dbhome_1目录（或者任何你规划的ORACLE_HOME），然后执行：

cd /u01/app/oracle/product/19c/dbhome_1 ./runInstaller

安装类型选择“Set Up Software Only”，这一步我是推荐选择“software only”而不是直接“Create and configure a database”，因为RAC环境下用DBCA建库会更灵活。后面建库时再通过DBCA把数据库注册到集群里，方便指定字符集、内存分配、磁盘组等参数。

在“Cluster Installation”界面，要勾选“Cluster Installation”并加入两个节点，这样数据库软件才会被安装到两个节点上。如果你这里漏选了，只在当前节点装了数据库软件，后面DBCA建库时另一个节点会找不到ORACLE_HOME，报错“ORA-12547: TNS lost contact”。

软件安装完成后，会要求你在两个节点以root执行root.sh脚本。这个脚本会在两个节点上完成数据库软件目录权限设置、环境变量注入、网络配置等。执行顺序同样是节点1先、节点2后，确保不会出现文件竞争。

4.2 DBCA建库：关键参数与注意事项

执行dbca图形(命令行)创建数据库。其中比较关键的几个参数：

• Global Database Name（全局数据库名）：比如orcl.example.com
• SID前缀：orcl
• 存储类型：选择“Oracle Automatic Storage Management (ASM)”
• 磁盘组：选择+DATA作为数据文件存放位置，+FRA作为快速恢复区
• 字符集：生产环境推荐AL32UTF8，除非业务有历史兼容性限制，否则别用ZHS16GBK了，跨字符集的问题迟早会找上你
• 内存管理：选择“自动内存管理（AMM）”，测试环境给2GB即可，生产环境按物理内存的40%~50%分配
• 数据库选项：建议全部取消勾选“Oracle Text”“OLAP”等不用的组件，减少后续维护成本

DBCA在RAC环境下会通过srvctl把数据库注册到集群，创建完成后可以用crsctl stat res -t看到ora.orcl.db资源已ONLINE，两个实例orcl1、orcl2分别在两个节点上运行。你还可以用srvctl status database -d orcl来查看两个实例的运行状态。

建库过程中有一个细节很多人忽略：redo日志组的大小和数量。默认的redo日志组会比较小（200MB左右），在高并发写入场景下会导致频繁日志切换。建议直接把redo调成2GB一组、每个节点至少2组，或者3组。另一个是UNDO表空间，RAC的每个实例要有独立的UNDO表空间，DBCA默认会为实例1和实例2各创建一个UNDO表空间，这个保持默认即可，不要手动把两个实例的UNDO指到同一个表空间。

数据库创建完成后，lsnrctl status检查一下监听是否正常。在RAC环境里，监听器的管理应该用srvctl而不是直接lsnrctl start，因为srvctl会把监听器作为集群资源来管理，节点重启后能自动拉起来。如果你只用lsnrctl start，则监听器不会随集群自动启动，以后会出现“数据库在线但客户端连不上”的情况。

5. 避坑指南：常见问题与排查记录

这部分我拿自己的实战经验当例子，列一下19c RAC安装过程中最高频的问题，以及我对应的排查思路和解决方案。这些问题有一半以上会在你第一次安装时遇到，所以建议收藏。

5.1 常见问题速查表

5.2 踩过的坑：一次由“多路径盘符混乱”导致的装机会话

这里分享一个我印象特别深的排障过程。有一次在测试环境部署19c RAC，一切配置都正常，gridSetup.sh也已经顺利执行到root.sh，结果在节点2执行root.sh时报错：ORA-15032: not all alterations performed，后来跟着是ORA-15063: ASM discovered an insufficient number of disks for disk group DATA。我当时第一反应是ASM磁盘组在节点2上未能发现。

检查了一遍nil发现节点1的/dev/mapper/data01在节点2上变成了/dev/mapper/data02——原来存储侧LUN映射给两个节点时，scsi_id的优先级顺序不同，导致multipath生成的设备名在不同节点上不一致。这样ASM通过磁盘名去识别盘就完全对不上号。解决方法是改用udev绑定固定的设备名，不依赖multipath生成的自动名称。也就是我前面讲的，在96-oracle.rules里用RESULT匹配scsi_id得到的UUID，再强制生成/dev/asm-disk1这个符号链接。这样无论multipath怎么映射，始终以asm-disk1作为ASM盘的唯一入口，问题就解决了。

类似的还有一次，两个节点的/dev/asm-disk*设备名一致了，但权限一个是oracle:dba，另一个是grid:asmadmin，安装时也报权限错误。后来又回头专门统一了udev规则，才把问题彻底根治。所以这里再强调一遍：ASM盘的属主、权限、设备名，在各自节点上必须完全一致。这是GI安装和RAC运行最基础也最容易出错的条件，没有之一。

5.3 关于“异机安装”与“无图形化安装”的经验

生产环境很多时候没有图形界面可用，或者远程服务器网络延迟太高，X11转发卡得让人崩溃。这时候第一个选项就是静默安装，也就是用响应文件。把gridSetup.sh -silent -responseFile执行成功之后，还需要在高阶配置里指定GIMR（Grid Infrastructure Management Repository）的磁盘组，一般建议单独一个20GB的磁盘组存放。这部分在响应文件里对应oracle.install.crs.gimrDGName参数，如果没配，安装程序会去自动创建，可能占用你预留的DATA空间。

响应文件里另一个容易踩坑的地方是集群节点列表的写法——节点名和VIP必须和hosts文件里完全对应，一个字母差都会导致集群验证失败。我建议每次用响应文件安装之前，先跑一遍cluvfy stage -pre crsinst -n rac1,rac2，把预检查结果看完再继续。CVU工具的好处就是能在你真正安装前把所有潜在问题暴露出来，省去后面反复重启GI的麻烦。

无图形化安装的另一个选择是开一个VNC会话，但VNC需要额外安装桌面环境，占用资源不说，配置也比较繁琐。我个人的经验是：会玩响应文件之后，基本上不再需要图形界面了。对于重复部署，响应文件复用的效率也更高——改改主机名、IP，然后跑一遍就可以。

5.4 RAC安装完成后，匹配运维习惯的一些必要操作

要说装完RAC就算完事，其实还太早。装完之后还要做一些日常运维的习惯性配套动作，才能让这套集群真正“好用、好管、好排查”。

首先，把oracle用户和grid用户的基础环境变量里加上umask 022，确保日志和trace文件的权限不会因为默认umask不对导致其他节点无法读取。其次，配置oracle用户的tnsnames.ora，把orcl的负载均衡和故障转移都设置好，让客户端能体验到真正的RAC优势。例如：

ORCL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) )

同时启用SQLNET.ORA里的SQLNET.OUTBOUND_CONNECT_TIMEOUT=10和SQLNET.INBOUND_CONNECT_TIMEOUT=10，防止连接卡死。接着，打开归档模式（生产环境必须），执行：

srvctl stop database -d orcl sqlplus / as sysdba ALTER SYSTEM SET db_recovery_file_dest_size=1T; ALTER SYSTEM SET db_recovery_file_dest='+FRA'; SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; srvctl start database -d orcl

这里注意，RAC环境不建议直接shutdown，而是用srvctl stop database -d orcl来停掉整个数据库，因为srvctl会同时处理两个实例和集群资源的状态，比你一个一个实例去操作要安全得多。

最后建议安装完成后把crsctl config scan、crsctl config vip和crsctl status resource -t的输出保存到部署文档中备份，后续做变更或扩容时用得上。

6. 后记：关于19c RAC部署，我最想跟你说的三句话

第一句话：不要试图跳过“环境准备”。所有RAC安装失败的案例，几乎都是因为Linux基础配置、共享存储权限、网络规划这三个环节里有一个没做扎实。你把环境准备好了，后面的Oracle安装反而像走流程一样顺畅。

第二句话：共享磁盘的“一致性”比磁盘本身的性能更致命。两个节点上的设备名、属主、权限、UUID必须一模一样，否则ASM会认为磁盘组缺盘，进而导致集群无法启动。我见过太多生产环境因为多路径设备名不统一而引发的灾难，这句话怎么强调都不为过。

第三句话：认真理解每个脚本和每个资源的作用，而不是盲目复制命令。比如root.sh执行时做了什么？crsctl和srvctl到底是什么关系？asmca和asmcmd有什么区别？这些问题你花几天时间彻底搞明白，后面运维RAC时会比别人轻松十倍。

我在实际安装19c RAC的过程中，最喜欢做的一件事就是把每步报错信息、crsctl stat res -t的输出、asmcmd lsdg的结果源源不断记录下来，整理成一个故障排查笔记。下次再有人遇到“Voting Disk找不到”“OCR自动备份失败”“节点被驱逐”之类的问题，直接翻笔记就能给出答案，不用从头开始排除。

最后再分享一个小技巧：安装完成后立刻做一次重启测试——重启节点1，确认集群、数据库、监听自动拉起；再重启节点2，确认两个实例都恢复ONLINE。这个测试虽然简单，但能帮你提前暴露出很多“安装时没暴露、运行一阵子才暴露”的问题，尤其是那些没有正确启用srvctl自动启动的资源。趁热打铁做一遍，比等上线之后半夜接电话强得多。