企业官网建设流程全解析

简介：面向数据库工程师与运维人员的Oracle RAC部署实战教程，完整讲解在VMware虚拟化环境下安装CentOS 7.5操作系统，并在此基础上部署GRID软件与Oracle 19c RAC集群，涵盖ASM自动存储管理、LVM磁盘管理与Linux常用命令操作。内容按实际部署流程递进展开：虚拟机兼容性设置与ISO镜像加载、网络与IP地址规划（公共IP、私有IP、VIP、SAN IP）、存储空间规划（根目录、/u01、数据文件、备份与归档目录）、数据库参数配置、监听器创建及客户端连接，并延伸至生产环境中的性能监控、定期备份与故障恢复操作。教程同时解析多节点实例通信与数据同步机制，附有IP规划表和空间分配表，便于按图实施。资料为PDF格式，全文111页，单文件共5.24MB，已有418人学习，适合数据库工程师、软件工程师及希望系统掌握Linux高可用数据库集群实施方法的技术人员参考。

1. 为什么是 CentOS 7.5、Oracle 19c 和 RAC：这套组合到底在解决什么问题

CentOS 7.5、Oracle 19c 和 RAC 这三个词放在一起，很多人会直接把它理解成“一份安装手册”。但更准确地说，这是一个实施 RAC 集群的完整技术决策组合：CentOS 7.5 是底层操作系统的基线版本，Oracle 19c 是数据库长期支持版本，RAC 则是把两台服务器变成一台逻辑数据库的关键形态。它解决的核心问题，是业务系统在不停机的前提下完成数据库实例漂移、负载均衡和单点故障转移。对 DBA 和运维工程师来说，这套组合比单机 Oracle 多了网络、ASM 磁盘、集群时钟三条完整链路；比云上托管数据库多了一层可控的自主运维边界。适合读下去的人，不只是会敲命令的安装工，而是需要在一周内把双节点 RAC 交付出来，并且对后续故障负责的从业者。

2. 装前必做：把节点、网络、共享盘和内核参数一次钉死

2.1 节点规划：两台机器最少要几块网卡、几块共享磁盘

很多 RAC 安装翻车，不是在 Oracle 软件层面，而是在还没动手装之前，物理资源就已经分错了。RAC 的核心是共享存储和私有网络，前者用来放 OCR、投票盘、数据文件和归档，后者用来让两个节点之间同步心跳信息。所以我先不急着解压安装包，而是按下面这张表把每个节点的资源画出来，再决定共享磁盘怎么从存储端映射。

共享磁盘这块尤其容易埋坑。Oracle 19c 的 Grid Infrastructure 要求 OCR、投票盘和数据文件所在磁盘必须由共享存储提供，不能是本地盘，也不能是云盘挂载后模拟的共享目录，否则两个节点同时写会有严重的一致性风险。常见做法是在存储端把 LUN 映射给两个节点，然后通过 udev 或 multipath 绑定成固定设备名，比如 /dev/asm-disk1 到 /dev/asm-disk5。我一般会让 udev 规则同时固定设备的属主和权限，owner 设为 grid，group 设为 asmadmin，mode 设为 0660，这样后面装 Grid 时就不用反复改权限。

2.2 公网、私网和 SCAN 地址：先写对 /etc/hosts，再谈安装

RAC 最怕 DNS 解析不干净，因为集群组件之间对主机名的解析极其敏感。家庭实验室或内网环境没有正经 DNS 时，最简单可靠的方式就是静态 hosts 文件，而且是两个节点完全一致。下面是我常用的写法：

# 公网地址：对外服务和 VIP 所在网段 192.168.10.11 rac1.example.com rac1 192.168.10.12 rac2.example.com rac2 192.168.10.13 scan-cluster.example.com scan-cluster # 私网地址：心跳和 Cache Fusion 10.10.1.11 rac1-priv 10.10.1.12 rac2-priv

这里有两个容易忽略的参数：第一，SCAN 地址不能和任何节点主机名重合，它是一组独立 IP，由集群软件在两台机器间漂移；第二，私网地址不要出现在客户端连接串里，它只服务集群内部流量。hosts 文件配置完成后，一定要在每台机器上执行ping rac1、ping rac2、ping scan-cluster确认都能通，并且hostname不带多余域名后缀，再继续往下走。

2.3 内核参数、透明大页和用户资源限制：少了这几个值，预检会卡死

Oracle 19c 对内核参数的要求比 11g 时代更严格，但很多安装文档停留在经验值上。我的习惯是先改 /etc/sysctl.conf，再统一执行sysctl -p，而不是在安装过程中临时用命令行改。下面是一套以 64GB 内存、双节点 RAC 为基准的配置：

# 共享内存：shmmax 建议大于 SGA_MAX_SIZE，通常取物理内存的 60% kernel.shmmax = 41231686041 kernel.shmall = 10066329 kernel.shmmni = 4096 # 信号量：四个值分别是 semmsl semmns semopm semmni kernel.sem = 250 32000 100 128 # 文件句柄和端口范围 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500 # 网络缓冲，RAC 节点间通信吃的是这个 net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_max = 1048576

参数说明：shmmax 决定一个共享内存段最大能多大，SGA 分配时需要它能包住整个 SGA 大小，所以不能给得太小；shmall 给出共享内存页总数，一般等于 shmmax 除以页大小 4096。信号量里的 32000 是 semmns，也就是系统最大信号量数，太小会导致数据库进程在并发高时直接报ORA-27154。端口范围设置为 9000 到 65500，是为了给集群组件之间大量的非固定连接留出足够空间。

除此之外，还要关闭透明大页 THP。RAC 对内存分配非常敏感，THP 会引发延迟抖动，经典的整治方式是在 /etc/default/grub 的内核引导参数里加transparent_hugepage=never，然后重启后检查：

cat /sys/kernel/mm/transparent_hugepage/enabled # 期望输出：always madvise [never]

还要用 limits.conf 锁住 oracle 和 grid 用户的资源限制。我见过有人只在命令行执行ulimit -n 65536，看起来生效了，但重启后失效，数据库进程在高峰期文件句柄耗尽，报ORA-12547或系统级Too many open files。正确的做法是写入 /etc/security/limits.conf，并确保/etc/pam.d/login和 sshd 会话都加载了 pam_limits 模块。

# /etc/security/limits.conf grid soft nofile 65536 grid hard nofile 65536 grid soft nproc 16384 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 oracle soft nofile 65536 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768

这里 nproc 必须同时设置 soft 和 hard，否则 grid 用户在运行crsctl start时可能因为进程数限制直接被系统杀掉。stack 10240 是 Oracle 19c 的最低建议，不要因为某些定制内核改得更小。

3. 安装 Grid Infrastructure：从 CVU 预检到 root.sh 的正确时序

3.1 软件解包和响应文件：19c 不像旧版本那样直接 runInstaller

Oracle 19c 的 Grid Infrastructure 软件包解压后，目录里不再是旧的./runInstaller，而是gridSetup.sh。所以拿到 LINUX.X64_193000_grid_home.zip 后，我一般会先把它解压到目标目录，比如 /u01/app/19c/grid，再确认 owner 是 grid、目录权限是 775。解压命令本身不复杂，复杂的是要决定用交互式还是静默安装。生产环境里图形界面不一定能弹出，所以更可靠的做法是先把响应文件写好，用静默方式安装。

mkdir -p /u01/app/19c/grid chown grid:oinstall /u01/app/19c/grid unzip -q /opt/soft/LINUX.X64_193000_grid_home.zip -d /tmp/grid_unzip cp -rf /tmp/grid_unzip/* /u01/app/19c/grid/

为什么要先解压到临时目录再复制？因为 Oracle 19c 的 grid home 要求安装介质内容必须落在最终位置，直接解压到 /tmp 再复制，能避免某些包管理器把软链接打断。更关键的是，这一步之后 grid 用户要用ls -l检查所有二进制是否有执行权，补上权限缺失会导致后续gridSetup.sh一启动就报PRVG-1001。

3.2 跑 CVU 预检：只需要盯住 Check Passed 和 Check Failed 两列

CVU 是 Oracle 提供的前置环境校验工具，全称 Cluster Verification Utility。它会把内核参数、用户组、依赖包、通信协议挨个检查一遍。很多人碰到这个环节只是机械地跑命令，看到一大段 WARNING 就慌。我的判断标准很简单：只要有Check failed，就暂停安装，先把失败项填掉；如果只是WARNING，结合文字判断是不是版本差异导致的误报。

cd /u01/app/19c/grid/bin ./cluvfy stage -pre crsinst -n rac1,rac2 -fixup -fixupdir /tmp/cluvfy_fix

-fixup会让工具自动生成修复脚本，但不要无脑执行。它生成的脚本会改内核参数、增加系统用户组，甚至可能修改你已经调好的 sysctl 配置。我一般先让它在 /tmp/cluvfy_fix 下生成脚本，然后用diff对比现有配置，逐条确认后再执行。CVU 输出的关键内容包括三大部分：系统包检查、用户组检查、节点互信检查。节点互信这一项尤其重要，它要求 grid 用户在 rac1 和 rac2 之间可以免密 SSH，否则后续 root.sh 阶段会在第二节点卡在ORA-28000或CLSRSC-100。

3.3 root.sh 的时序：第二节点抢跑，是整个安装翻车的重灾区

Grid 安装过程中，gridSetup.sh正常结束后会提示你分别在两个节点执行root.sh。这里有一个非常反直觉的规则：必须在第一个节点 root.sh 完全跑完后，再在第二个节点执行 root.sh。原因是第一个节点的 root.sh 会初始化 OCR、启动 CSS、写入集群配置，这些完成后，第二个节点才能注册进去。

# 节点 1：root 执行 /u01/app/19c/grid/root.sh # 节点 2：必须等节点 1 执行成功，日志里出现成功标志后再跑 /u01/app/19c/grid/root.sh

root.sh 执行时间通常持续 5 到 15 分钟，中间会调用crsctl启动集群资源。等得久不代表失败，但如果卡在Adding daemon to inittab、timestamp这类位置超过 20 分钟，就需要立刻查看 $ORACLE_HOME/crs/install/crsconfig_params 和对应日志。另一个常见问题是两个节点使用不同主机名大小写，或者 hosts 文件里有重复解析，导致 root.sh 在初始化 GNS 时找不到匹配的公网地址，最终报CRS-5018。遇到这种情况，不要急着重装，先把 hosts 统一、SSH 互信重建、跑一遍 CVU 再执行 root.sh。

4. 用 ASM 引导存储并把数据库集群立起来：磁盘组设计与 dbca

4.1 ASM 磁盘组怎么划分：OCR、DATA、FRA 各自的冗余策略

数据库集群装好 Grid 之后，ASM 就是所有数据库文件的存放层。磁盘组的设计直接决定 RAC 的故障容忍能力，而不是单纯看磁盘总容量。下面是三个磁盘组的使用划分建议。

OCR 磁盘组我用 3 块 20GB 共享盘，理由是 NORMAL 冗余下任何一块盘损坏都不影响集群读取 OCR 内容。DATA 磁盘组如果存储本身是 RAID10，外接的 LUN 已经具备冗余，我通常直接用 EXTERNAL，省下镜像空间；如果存储是直通盘没有冗余，就改成 NORMAL。FRA 的容量我习惯按“每天归档量 × 保留 3 天 + 一次全量备份大小”估算，宁可多给 20% 空间，也不要出现归档写满导致数据库挂起的现象。

4.2 dbca 静默建库命令：RAC 数据库不是装完 Grid 就自动出现

Grid Infrastructure 负责集群资源，数据库本身还要单独创建。常见做法是用 dbca 的 silent 模式，这样可以在没有图形界面的终端里把整个建库流程完整跑完。下面是一条实际可用的命令，执行用户是 oracle，而不是 grid。

dbca -createDatabase -silent \ -gdbName ORCL \ -sid ORCL \ -systemType RAC \ -templateName General_Purpose.dbc \ -sysPassword Oracle#123 \ -systemPassword Oracle#123 \ -datafileDestination '+DATA' \ -storageType ASM \ -characterSet AL32UTF8 \ -memoryPercentage 30 \ -nodeList rac1,rac2 \ -ignorePreReqs

参数说明：-gdbName是全局库名，-sid是实例名前缀，RAC 场景两个实例会自动变成 ORCL1 和 ORCL2；-systemType RAC告诉 dbca 要创建集群数据库而不是单实例；-datafileDestination指向 ASM 磁盘组 DATA；-memoryPercentage 30表示把机器物理内存的 30% 分给数据库实例，具体数值要结合环境调整，但第一次建库不要给太高。实际生产环境我不建议把密码直接放在命令行里，因为这样 shell history 会留下明文记录，更规范的做法是把这批参数写成响应文件，然后用dbca -silent -createDatabase -responseFile /u01/soft/dbca.rsp执行。

4.3 建库后三分钟检查清单：实例、监听、磁盘状态

dbca 执行结束后，终端会显示 “Database creation complete”，但这一步只是说明建库动作结束，集群资源是否全部在线还要手动确认。我习惯按以下顺序做三分钟检查。

# 1. 查看集群所有资源 crsctl stat res -t # 2. 查看监听资源 srvctl status listener # 3. 查看数据库状态 srvctl status database -d ORCL

执行后期望看到监听在 rac1 和 rac2 在线运行，数据库 ORCL 的两个实例都是 ONLINE。如果某个实例显示 OFFLINE，先不要急着人工启动，先查$ORACLE_BASE/diag/rdbms/orcl下的 alert 日志，很多实例起不来是因为 ASM 磁盘没找到，而不是 SQL 层面问题。然后登录数据库确认集群参数确实生效：

sqlplus / as sysdba show parameter cluster_database; -- 希望看到值为 true select inst_id, instance_name, status from gv$instance;

gv$instance如果能返回两行，说明 RAC 真正跑起来了。这一步是判断集群库有没有“只有一个实例在干活、另一个实际没注册”的黄金标准，因为仅靠crsctl看到 ONLINE 还不够，SQL 层面的双实例视图才是最终结论。

5. 避坑指南：RAC 实施现场最容易让人翻车的五个问题

5.1 两节点时间偏差超过 30 秒，root.sh 后集群起不来

现象：两个节点按同一份文档执行后，节点 1 的 root.sh 显示成功，节点 2 却一直没有反应，查看日志看到CRS-5018，提示集群无法从 Oracle Cluster Registry 中读取配置。此时执行cluvfy stage -post crsinst会发现时钟同步检查失败。

原因：RAC 的很多组件依赖节点间时间一致性，尤其是 CSS、OCR 和 Lock Manager。时间差过大会导致集群心跳无法正确对齐，节点之间互相以为对方失联，最终形成脑裂或无法启动。

解决：修正两节点时间，并确认 NTP 或 chrony 配置一致，然后重新执行crsctl stop crs和crsctl start crs。如果集群状态还是乱，不要急着重新安装，找到$ORACLE_HOME/crs/install/crsconfig_params检查 SCAN、GNS 配置是否正确，再重跑 root.sh。

5.2 共享磁盘权限漂移，重启后 ASM 找不到盘

现象：安装完成时一切正常，重启机器后lsblk能看到 /dev/asm-disk1 到 /dev/asm-disk5，但ls -l /dev/asm*显示屬组变成了 disk 而不是 asmadmin，数据库实例起不来，alert 日志报无法打开 ASM 磁盘。

原因：udev 规则的触发条件不严谨，设备名或磁盘序列号匹配失败后，内核默认归属磁盘属主，导致 ASM 访问权限丢失。

解决：检查 /etc/udev/rules.d/ 下的规则文件，重新触发规则：

udevadm control --reload-rules udevadm trigger --type=subsystems --action=change

随后用ll /dev/asm*确认属主是否恢复为 grid:asmadmin，再启动集群。

5.3 SCAN 地址解析时通时不通，客户端连接不稳定

现象：应用通过 SCAN 连接数据库，有时候秒连，有时候等很久才报ORA-12545，甚至连接失败。而用节点 VIP 连接却一直正常。

原因：SCAN 地址在 hosts 和 DNS 中存在重复解析，或者不同节点看到的 SCAN IP 不一致。SCAN 要求由同一个解析来源提供统一结果，客户端一旦走到错误 IP，连接就超时。

解决：先固定 /etc/hosts 中 SCAN 映射，注意 IP 必须和公网同一网段，再执行nslookup scan-cluster.example.com和getent hosts scan-cluster.example.com，确认两节点结果一致。如果曾经配过 DNS，优先清理 DNS 记录，避免 hosts 和 DNS 同时生效造成解析矛盾。

5.4 dbca 建库报磁盘路径不存在，但 asmcmd 能看到盘

现象：dbca 执行到 10% 时报ORA-15020，说磁盘组 DATA 不能访问，但用asmcmd lsdg可以正常列出 DATA 磁盘组。

原因：dbca 是以 oracle 用户执行的，oracle 用户属于 asmdba 组，具备管理权限；但某些环境下 ASM 的访问控制被设置成仅允许 grid 用户操作，oracle 用户的会话被过滤。

解决：确认 grid 用户和 oracle 用户都被加入应有的用户组，并重启监听和数据库实例让权限配置生效。排查方法是在 oracle 用户下执行：

id groups # 确认包含 asmdba

如果没有 asmdba，用 root 执行usermod -aG asmdba oracle，再重试 dbca。

5.5 重装 RAC 时旧集群信息残留，新集群反复报 CRS-4000

现象：由于安装失败重装，但第二次跑gridSetup.sh或 root.sh 时出现CRS-4000，提示集群已经存在或 OCR 内容无法覆盖。

原因：上一轮安装未彻底清理，OCR 磁盘里的旧 cluster name、votedisk 还在，新安装程序无法识别。

解决：清理阶段除了删除 /u01/app 下的安装目录，还要用dd覆盖 OCR 磁盘头部区域，清除 ASM 磁盘上的旧标记。清除后重新分区或绑定 udev，再做全新安装。这个步骤非常考验耐心，我的经验是宁可多花十分钟覆盖全部共享磁盘，也不要只删目录和系统文件，因为 OCR 内容对格式化并不敏感。

6. 把 failover 验证和性能基线做成一组固定动作

安装完成只是开始，真正决定 RAC 能不能投产的是故障切换测试。我会先手工做一次最干净的验证：在 oracle 用户下执行srvctl stop instance -d ORCL -i ORCL1，让第一节点实例正常停止，而不是直接拔电源。正常停止后，会话会自动漂到第二节点吗？并不会完全自动，但集群会重新调度 VIP 和监听。随后执行select inst_id, instance_name, status from gv$instance;，如果只能查到一条记录，说明 RAC 偏斜或者数据库没把服务切干净，需要看监听状态和服务注册。

更接近生产环境的测试是直接执行srvctl stop database -d ORCL再启动，验证整个集群能否完成冷启动。此时我会配合crsctl stat res -t观察每个资源的 ONLINE/OFFLINE 流转时间。生产经验的教训是：只测一次 failover 不能证明集群稳定。我养成的习惯是把测试标准化，每隔一段时间跑一次同样的验证，并记录时间、资源状态、alert 日志里的错误片段，当作 RAC 的健康基线。等真正到了要割接的夜晚，你才发现心跳抖动、ASM 盘权限漂移或者 SCAN 解析问题，那时候已经来不及补救了。希望这篇笔记帮你把 CentOS 7.5、Oracle 19c 和 RAC 的每一步都踩在实路上。

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