简介Oracle 19c RAC on Linux 7.6安装手册是一份面向数据库运维与实施人员的实操文档覆盖RedHat 7.6环境下从系统准备到集群上线的完整流程。手册重点讲解GNS配置SCAN、Flex ASM特性以及自12.2起Standalone Cluster与Domain Service Cluster两种集群模式的差异正文按OS环境检查、关闭THP并开启Hugepages、软件包安装、内核参数设置Preinstall RPM/手工两种方式、网络配置固定与GNS两种模式等模块展开既适合刚接触RAC的读者按步骤操作也适合中高级DBA对照排错。内容还整理了常见配置问题的解决思路与分析方法帮助读者在遇到类似故障时快速定位。资源仅含1个docx文档约160KB目录结构清晰可分段查阅。目前已有714人学习使用对正在规划或实施19c RAC项目的人员具有直接参考价值。1. Oracle 19c RAC on Linux 7.6为什么这套组合是生产环境的主流选择在数据库这条路上Oracle 19c RAC on Linux 7.6 是一个躲不开的组合。19c 是 Oracle 长期支持版本里生命周期最长的一代Linux 7.6 又是过去几年企业服务器预装最多的操作系统两个版本碰在一起既是企业级高可用架构的事实标准也顺带成了面试和运维考核的常客。很多人以为装 RAC 最难的是数据库创建真实情况恰恰相反——我第一次独立部署这套环境时在 Grid Infrastructure 阶段就折腾了整整两天而真正跑 dbca 反而只花了半个小时。这篇笔记就是把那两天的血泪经验压缩成一条可复现的路径。你不需要有 RAC 实战基础但至少要装过单机 Oracle知道监听、实例、pfile 这些词。跟着章节一步步走从架构原理、资源规划、GI 安装、建库到避坑验证最后你会得到一套能撑住生产压力的 19c RAC 集群。2. 装前必读RAC 架构与 Linux 7.6 的资源规划2.1 Oracle RAC 集群的核心部件OCR、Voting Disk 与 ASM 磁盘组RAC 的原理可以压缩成一句话多台服务器跑同一个数据库通过共享存储和高速网络实现实例级高可用。听起来不复杂但落地时要管好三样东西——OCR、Voting Disk 和 ASM 磁盘组这三者是整个集群的命根子。OCROracle Cluster Registry保存集群和数据库的配置信息节点加入、资源启停都要读它Voting Disk 负责脑裂仲裁节点间心跳异常时靠它投票决定谁活谁死ASM 磁盘组则承担数据文件、控制文件、日志文件的存储。三者的关系用大白话说OCR 和 Voting Disk 是集群的“大脑”和“表决器”ASM 是数据库文件的“仓库”。装 Grid Infrastructure简称 GI时会顺带把 OCR 和 Voting Disk 放进第一个 ASM 磁盘组也就是 19c 里默认创建的 DATA 和 GIMR 之外的第三个组件。这里有一个新手常混淆的点OCR 和 Voting Disk 不是独立分区而是存放在 ASM 磁盘组里的文件。这意味着磁盘组的冗余策略直接决定集群能否在坏一块盘后继续运行。生产环境我一般用 NORMAL 冗余也就是至少三块盘允许坏一块测试环境用 EXTERNAL省盘但没有任何保护。与这个标题直接相关的热搜词是“oracle rac集群原理”大多数人看原理觉得清晰一进安装界面就乱。原因在于原理说的是概念安装界面问的是具体参数——比如磁盘组冗余选哪个、OCR 放哪个目录、SCAN 监听解析到哪。我的建议是先把本节说的三样东西记牢再往后走后面的每一步都绕着这三样展开。2.2 Linux 7.6 上的资源基线内存、共享盘、网络与内核参数Linux 7.6 是 CentOS/RHEL 7.6 的通称装 Oracle 19c RAC 前要把资源基线定好。先说硬性门槛物理内存建议不低于 16GB因为 GI 和数据库实例共享这台机器19c 对共享内存段也有最低要求交换分区按内存的 1.5 倍规划但如果内存超过 32GB交换分区反而可以只给 8GB——大内存机器上交换分区过大只会拖慢性能。共享存储是 RAC 和单机最大的区别。每节点至少要看到同一批磁盘而且必须是真实共享不是把一台机器上的盘 NFS 出去给另一台用——ASM 对 NFS 的支持极差我曾经在测试环境这么干过结果两个节点抢着写盘差点把磁盘头搞坏。生产上常见的是 SAN LUN、iSCSI 或者云平台的多挂载云盘。大小方面OCR/Voting Disk 所在磁盘组给 40GB 左右即可数据磁盘组按实际数据量翻倍再留 50% 余量。网络方面19c RAC 最少需要两张网卡一张公有网卡跑业务流量一张私有网卡跑心跳和 ASM 网络通信。私有网卡不能用 DHCP必须配静态 IP并且两个节点的私有 IP 要在同一网段。心跳网卡的流量不大但延迟很敏感建议单独走交换机不要和业务流量混在一起。内核参数在 7.6 上有几个必须改的项kernel.sem控制信号量kernel.shmall和kernel.shmmax控制共享内存fs.aio-max-nr控制异步 IO 上限。下面是我在生产环境用的参数模板cat /etc/sysctl.conf EOF 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 vm.swappiness 10 EOF sysctl -pkernel.shmmax设成 4GB 左右适合大多数场景如果你的数据库 SGA 规划超过 8GB把它改成物理内存的一半。kernel.sem的前三个值对应信号量数组上限、系统范围最大值和每个信号量集的最大值Oracle 官方文档给的基线就是这组数直接沿用即可。vm.swappiness10是防止 Linux 把空闲内存拿去换页数据库服务器上这个值越低越好但不能设成 0否则 OOM 时内核可能直接杀 oracle 进程。2.3 用户、组与依赖包清单含 19c 特有RAC 安装需要两类操作系统用户grid用户跑 GIoracle用户跑数据库软件。这两个用户必须属于同一个主组否则 ASM 磁盘的权限校验会出问题。下面是生产环境常用的创建命令groupadd -g 54321 oinstall groupadd -g 54322 dba groupadd -g 54323 oper groupadd -g 54324 backupdba groupadd -g 54325 asmdba groupadd -g 54326 asmoper groupadd -g 54327 asmadmin useradd -u 11001 -g oinstall -G dba,oper,backupdba,asmdba grid useradd -u 11002 -g oinstall -G dba,oper,backupdba,asmdba oracle usermod -g oinstall -G asmadmin,asmdba,asmoper gridgrid用户必须属于asmadmin因为 ASM 实例的管理权限归 grid 所有oracle用户必须有asmdba因为数据库实例要读写 ASM 文件。这个权限矩阵是 RAC 安装里最容易错的地方错了会在root.sh阶段报权限不足后面避坑章节会细说。依赖包在 Linux 7.6 上用 yum 一次装齐注意 19c 比 11g/12c 多几个包比如libnsl和libnss_nis。缺了libnsl的典型现象是crsctl start crs报找不到共享库很隐蔽。命令如下yum install -y bc binutils compat-libcap1 compat-libstdc-33 \ gcc gcc-c elfutils-libelf-devel glibc glibc-devel ksh \ libaio libaio-devel libgcc libstdc libstdc-devel libxcb \ libX11 libXau libXi libXrender libXtst libXext \ make net-tools nfs-utils python python3 python3-devel \ smartmontools sysstat unzip which xorg-x11-utils \ libnsl libnss_nis libnss3装完包后用rpm -q逐个确认版本不要跳过。尤其ksh这个包Oracle 的很多脚本默认用 ksh 执行缺了会出现莫名其妙的“脚本运行一半就退出”问题。另外/etc/hosts的配置在 7.6 上要特别注意主机名解析顺序是先 hosts 后 DNSSCAN IP 和私有 IP 必须写在 hosts 里这个细节直接影响后面 GI 安装的 DNS 检查项。3. 安装 Grid Infrastructure一次跑通 19c RAC 的地基3.1 共享磁盘的 udev 绑定与权限验证含示例共享磁盘是 RAC 的物理基础Linux 7.6 上推荐用 udev 规则把 ASM 磁盘的属主和权限固定下来避免每次重启后/dev/sdb这种设备名漂移导致 ASM 找不到盘。先看磁盘的 WWID再写规则/usr/lib/udev/scsi_id -g -u /dev/sdb拿到类似36000c29a4b0c1a2d3e4f5a6b7c8d9e0f的串后创建规则文件cat /etc/udev/rules.d/99-oracle-asm.rules EOF KERNELsd*, SUBSYSTEMblock, ENV{DEVTYPE}disk, \ ATTR{wwid}36000c29a4b0c1a2d3e4f5a6b7c8d9e0f, \ OWNERgrid, GROUPasmadmin, MODE0660 EOF udevadm control --reload-rules udevadm trigger ls -l /dev/sdb规则里OWNERgrid和GROUPasmadmin是 RAC 的关键grid 用户要能读写这些盘asmadmin 组成员负责管理 ASM 磁盘。MODE0660保证 owner 和 group 可读写其他用户无权访问。如果ATTR{wwid}匹配不到盘可以用ENV{ID_SERIAL}或自定义SYMLINK方式绑定但生产上我更倾向 wwid因为它稳定且不依赖总线顺序。验证规则是否生效不能只看ls -l还要在两台节点上分别执行dd if/dev/sdb of/dev/null count1确认两边都能读。这个验证看似多余实际能提前发现很多共享存储链路问题——比如某台节点的光纤卡没识别到 LUN。3.2 用 cvu 预检查捕捉环境问题常用命令与输出判读Grid Infrastructure 安装包自带的 CVUCluster Verification Utility是装 RAC 前最值得花时间的工具。它的核心价值在于把安装过程中的硬性要求自动化检查一遍包括内核参数、依赖包、网络、用户组、磁盘权限、主机名解析等。官方推荐在运行安装程序前先跑一次 cvu我习惯在打完补丁、改完参数后各跑一次每次能提前抓出两三个问题。用grid用户执行cd /u01/app/19c/grid ./runcluvfy.sh stage -pre crsinst -n rac1,rac2 \ -r 19c -verbose-n指定集群节点名-r 19c指定版本-verbose输出详细日志。跑完后重点看两类输出一类是Check Failed这类是硬伤必须解决另一类是Check Warning比如 NTP 未同步、包版本略旧这类可以视情况放行但建议还是处理掉。CVU 输出里最容易忽略的是时间同步检查。19c RAC 要求节点间时钟偏差不超过 1 秒很多生产环境装了 NTP 但没启用开机自启CVU 报 warning安装时没问题运行一段时间后集群节点被踢。在 Linux 7.6 上我推荐用 chrony 而不是 ntpd配置更简单同步精度也能满足要求。3.3 安装 grid 软件与 root.sh 执行要点含响应文件有了干净的预检查结果就可以正式安装 GI 软件了。19c 支持图形界面和静默安装两种方式生产环境我强烈建议用响应文件方式理由很简单可重复、可审计、不用为 X11 转发折腾半天。先把安装包解压再用响应文件启动 installerunzip /data/linuxx64_19c_grid_home.zip -d /u01/app/19c/grid cd /u01/app/19c/grid ./runInstaller -silent -responseFile /data/19c_grid.rsp \ -ignorePrereq响应文件的关键参数如下oracle.install.optionCRS_CONFIG ORACLE_BASE/u01/app/grid ORACLE_HOME/u01/app/19c/grid INVENTORY_LOCATION/u01/app/oraInventory oracle.install.asm.OSDBAasmdba oracle.install.asm.OSOPERasmoper oracle.install.asm.OSASMasmadmin oracle.install.crs.configureGIMRDataDGfalse oracle.install.asm.diskGroup.nameDATA oracle.install.asm.diskGroup.redundancyNORMAL oracle.install.asm.diskGroup.disks/dev/sdb,/dev/sdc,/dev/sdd oracle.install.asm.diskGroup.diskDiscoveryString/dev/sd*configureGIMRDataDGfalse是 19c 特有的选项GIMRGrid Infrastructure Management Repository默认会创建一个独立磁盘组存放集群健康监控数据但很多生产环境并不需要这个功能关掉可以省一块盘也少一个出问题的点。如果你开着它磁盘组至少要多准备 20GB。安装程序执行完后会在两个节点分别生成root.sh脚本这是整个 GI 安装的高危环节。执行顺序必须是第一个节点先跑完、成功退出后再在第二个节点执行/u01/app/19c/grid/root.shroot.sh 会把oracle和grid的二进制属主改掉启动ohasd和cssd配置 OCR 和 Voting Disk。脚本输出里看到CRS-2672和CRS-2673表示资源启动成功如果看到CRS-2673后卡住别急着重跑先用crsctl stat res -t看资源状态常见原因是/etc/hosts里节点名和ipc通信配置不一致。3.4 用 asmca 建磁盘组参数与常见误区GI 装完但磁盘组只有 DATA 一个如果当初没建 GIMR此时还需要用asmca手动补充其他磁盘组标准做法是新建一个 FRA快速恢复区磁盘组。用 grid 用户执行asmca打开图形界面或者在命令行模式建sqlplus / as sysasm CREATE DISKGROUP FRA EXTERNAL REDUNDANCY DISK /dev/sde, /dev/sdf, /dev/sdg ATTRIBUTE COMPATIBLE.ASM19.0;这里有一个常见误区EXTERNAL REDUNDANCY表示不冗余只适合有存储层 RAID 保护的场景。如果你的共享存储本身是 RAID10用 EXTERNAL 没问题如果是裸盘直接映射必须用 NORMAL 冗余。ATTRIBUTE COMPATIBLE.ASM要和 GI 版本匹配写成19.0不要写成19.0.0.0后一种格式在某些 19c RU补丁更新版本上会校验失败。建完磁盘组后用asmcmd lsdg确认状态asmcmd lsdg输出里的STATEMOUNTED表示磁盘组已挂载。如果显示DISMOUNTED多半是磁盘权限或diskDiscoveryString配置问题回到 3.1 节检查。4. 部署 Oracle 19c RAC 数据库从 dbca 到连接串4.1 用 dbca 创建 RAC 库选型与参数GI 就绪后创建 RAC 库反而是体力活。用dbca静默模式创建适用于两个节点的经典 RAC 配置dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -sid orcl \ -gdbName orcl \ -racOption RAC \ -nodeList rac1,rac2 \ -sysPassword SysPass1 \ -systemPassword SystemPass1 \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaName FRA \ -recoveryAreaSize 200 \ -characterSet AL32UTF8 \ -sampleSchema false \ -memoryMgmtType AUTO_SGA \ -totalMemory 4000-racOption RAC告诉 dbca 这是集群数据库-nodeList明确参与实例的节点。-storageType ASM指定数据放 ASM-diskGroupName DATA必须在 GI 阶段建好-recoveryAreaName FRA对应恢复区磁盘组。-totalMemory 4000表示总内存 4GB由两个实例平分各 2GB。创建完成后检查实例状态srvctl status database -d orcl输出类似Database is running且列出两个实例说明 RAC 库已正常。这里有个关键参数容易被忽略-sampleSchema false测试库加示例 schema 会多占一倍的磁盘和内存生产环境没人用示例数据别选 true。4.2 SCAN 与监听配置客户端连接背后的解析链RAC 客户端连接的“门面”是 SCANSingle Client Access Name。客户端只需要知道 SCAN 域名Oracle 会帮它把连接请求分发到实际节点。19c 安装时 SCAN 配置常见两种方式DNS 解析或/etc/hosts静态映射。DNS 方式的正确做法是给 SCAN 名配三个 A 记录指向三个不同 IPscan-cluster.example.com. A 192.168.1.101 scan-cluster.example.com. A 192.168.1.102 scan-cluster.example.com. A 192.168.1.103如果公司没有 DNS 条件可以在客户端和服务器/etc/hosts里写同一组映射。注意 SCAN 解析的三个 IP 必须和 GI 安装时定义的 SCAN IP 一一对应不能随意改。监听检查lsnrctl status正常输出会显示两个节点的监听都注册到 SCAN 上。容易出现的一个问题监听注册到了本地 IP 而不是 SCAN IP客户端连接时提示 ORA-12514。排查思路是看tnsnames.ora里HOST填的是 SCAN 名还是物理 IP生产环境一律写 SCAN 名。4.3 验证集群与数据库状态的常规命令建库后必须做一套成体系的验证不能只盯着数据库看。先看集群层crsctl stat res -t crsctl check cluster -all再看数据库层sqlplus / as sysdba select inst_id, instance_name, status from gv$instance; select name, open_mode from v$database;最后做一次实例间通信测试确认 RAC 的 Cache Fusion 正常select * from v$resource_limit where resource_namegcs_server_processes;如果看到两个实例都在跑数据库OPEN_MODE为READ WRITEGCS 进程数符合预期这套 19c RAC 就基本可以交付了。还有一个常用的验证点crsctl stat res -t里ora.orcl.db的状态必须是ONLINE两个实例的 target 和 state 都要显示ONLINE on rac1、ONLINE on rac2。5. 安装避坑我在 19c RAC 上踩过的 5 个典型问题5.1 root.sh 执行后集群资源启动失败现象第一个节点 root.sh 跑完crsctl stat res -t里ora.asm、ora.cssd都是OFFLINE日志报CRS-0184: Cannot communicate with the CRS daemon。原因最常见的不是配置错误而是/etc/hosts里节点名解析到了::1或127.0.0.1CSSCluster Synchronization Service通信走 loopback导致节点间握手失败。解决把 hosts 里节点名指向真实内网 IP同时注释掉localhost之外的 IPv6 映射sed -i s/^::1.*// /etc/hosts hostname /etc/hostname改完执行reboot或重启ohasdsystemctl restart ohasd crsctl stat res -t5.2 两个节点抢锁同一块 ASM 磁盘现象第二个节点跑root.sh或asmca时报ORA-15085: ASM disk name has a collision两个节点的asm_diskstring都指向同一批sd*设备但磁盘头信息不一致。原因磁盘没有做绑定每个节点看到的设备名相同但实际对应不同的 LUNASM 会误认为磁盘冲突。常见陷阱是/dev/sdb在 rac1 上是 LUN1在 rac2 上却是 LUN2被 udev 规则错误绑定。解决放弃设备名用 WWID 重新生成 udev 规则参考 3.1 节并保证两节点规则一致。验证方式是两节点分别执行asmcmd lsdsk -k输出里磁盘LABEL和PATH必须完全对应。5.3 chrony 与 NTP 时间同步冲突现象集群运行三到五天crsctl stat res -t显示某个节点被踢出集群alert日志报Cluster Ready Services was unable to connect to other cluster nodes。原因安装时选择了 NTP但系统同时启用了 chrony两个时间同步服务都在跑互相覆盖时钟偏差超过 30 秒触发 CSS 驱逐。解决停掉一个统一用 chronysystemctl stop ntpd systemctl disable ntpd systemctl enable chronyd chronyc makestep改完在两节点执行clockdiff确认偏差在 1 秒内。5.4 GIMR 磁盘组创建失败现象GI 安装时没有关 GIMR响应文件又没指定GIMRDataDG的磁盘安装进行到 70% 时失败日志提示找不到MGMT磁盘组。原因19c 默认要求创建 GIMR 存储集群健康监控数据若不想用却没有在响应文件里关闭程序会尝试自动创建但磁盘不足。解决如果不需要 GIMR 功能重新生成响应文件并加一行oracle.install.crs.configureGIMRDataDGfalse如果磁盘足够且想保留 GIMR准备 20GB 以上的单独磁盘组命名MGMT并在响应文件里指定oracle.install.asm.diskGroup.name.MGMT。5.5 建库后客户端连接提示 ORA-12545现象数据库状态正常但客户端连接报ORA-12545: Connect failed because target host or object does not exist。原因tnsnames.ora 里写的是物理节点 IP而不是 SCAN 名客户端只能连接其中一个节点节点故障后连接失败或者 SCAN IP 没有正确注册到监听。解决把连接串改成 SCAN 名并确认监听上能解析sqlplus systemhostscan-cluster.example.com:1521/serviceorcl如果仍失败用lsnrctl services查看监听注册的服务名确认orcl的对外服务名和tnsnames.ora一致。6. 安装完成后的验证方法从 crsctl 到 srvctl 的日常排障技巧安装不是终点交付后的第一周才是问题集中爆发的时间段。我的习惯是在装完后的 72 小时内做一轮高密度验证而不是直接让业务方接手。先把集群完整性测一遍crsctl check cluster -all crsctl check database -d orcl -a再故意踢掉一个节点的 ASM 实例观察集群能否在两分钟内自动拉起资源这比任何配置检查都更能说明问题。日常运维里最实用的命令是srvctl它的价值在于把“数据库服务”抽象成可启停的整体srvctl config database -d orcl srvctl start database -d orcl srvctl stop instance -d orcl -n rac1stop instance这种操作在生产切换场景很常用比如服务器要打补丁可以把某节点实例优雅停止而不影响其他节点继续服务。注意 stop instance 使用的是srvctl stop instance而不是sqlplus shutdown后者不会更新集群资源状态容易让 CRS 误判实例故障。还有一类验证容易被忽略ASM 磁盘组的写日志能力。用asmcmd随机往 FRA 磁盘组写一小段数据再删掉验证权限链是否真的通畅。这个动作看似多余但能提前暴露存储层面的隐性故障比如光纤卡驱动老化导致写入超时。我遇到过两次一次是磁盘权限看着没问题但 grid 用户无法写 ASM 日志另一次是存储端 dedupe 配置导致 ASM 写 I/O 延迟高到触发实例驱逐——都是跑这类小测试才发现的。最后留一个我个人的教训无论安装多顺利永远别删掉服务器上最初的/etc/hosts备份和 cvu 预检查日志。RAC 排障时第一件事就是对“安装前的基线”和“故障时的现状”做对比这份文件就是我排查大半问题的后悔药。这套 19c RAC 踩坑路径我已经走过了希望帮到你少走两趟。本文还有配套的精品资源点击获取