当前位置： 首页 > news >正文

Oracle RAC 26ai双节点部署实战：从环境准备到高可用验证

news 2026/7/23 6:58:05

如果你曾经在凌晨三点被数据库单点故障的告警电话叫醒，或者经历过因为硬件维护导致业务停摆的尴尬时刻，那么 Oracle RAC（Real Application Clusters）对你来说可能不仅仅是一个技术方案，而是保障业务连续性的生命线。

但很多人在初次接触 RAC 时容易陷入一个误区：认为只要把两个节点装上 Oracle 软件、连上共享存储，就能自动获得高可用性。实际上，RAC 部署中最容易出问题的往往不是软件安装本身，而是前期环境准备和后期运维细节——特别是网络规划、共享存储配置和集群状态监控这三个关键环节。

今天我们就以 Oracle 26ai 版本在 Linux 环境下的双节点 RAC 部署为例，从实战角度拆解每个步骤背后的原理和注意事项。这不是一个简单的操作手册，而是一个让你真正理解 RAC 工作机制的完整指南。

1. 为什么 RAC 部署的关键在环境准备，而不是软件安装

很多人一拿到 RAC 安装包就急着运行安装程序，结果在中间步骤频繁报错。实际上，Oracle RAC 对底层环境的要求极为严格，90% 的安装失败都源于环境配置不当。

1.1 网络规划：RAC 的神经系统

RAC 集群依赖三套独立的网络体系，每套网络都有不可替代的作用：

Public Network（公网）负责客户端连接和日常管理通信。在实际部署中，建议使用绑定（bonding）模式提高可靠性。比如使用 mode=1（active-backup）确保单网卡故障时自动切换：

# 查看网卡绑定状态 cat /proc/net/bonding/bond0

Private Network（私网）是节点间的心跳网络，负责缓存融合（Cache Fusion）数据同步。这是 RAC 性能的关键所在，必须满足两个硬性要求：

  • 网络延迟必须低于 1 毫秒
  • 必须使用专用交换机或 VLAN，绝对禁止与公网混用

你可以用以下命令测试私网质量：

# 测试延迟和丢包率 ping -c 100 -s 1472 192.168.10.11 # 使用更专业的网络测试工具 yum install -y iperf3 # 在节点2启动服务端 iperf3 -s # 在节点1测试带宽和抖动 iperf3 -c 192.168.10.11 -t 60 -J

Storage Network（存储网络）如果使用 iSCSI 或 NFS 等基于 IP 的存储方案，需要独立的网络通道。在企业环境中，通常采用光纤通道（FC）或 NVMe over Fabrics 获得更低延迟。

1.2 共享存储：RAC 的心脏

RAC 的核心思想是多个节点共享同一份数据。这意味着所有节点必须能够同时读写相同的磁盘设备。Oracle 官方推荐的方案是 ASM（Automatic Storage Management），它本质上是一个专门为 Oracle 数据库设计的卷管理器。

ASM 的优势不仅在于自动条带化和镜像，更重要的是它与 Oracle 数据库内核深度集成，能够感知数据块的热度并智能分布 I/O 负载。在规划 ASM 磁盘时，要注意以下几点：

  • 每个 ASM 磁盘应该来自不同的物理磁盘或 RAID 组，避免单点故障
  • 建议使用 4MB 的分配单元（AU_SIZE）平衡大表扫描和小事务的性能
  • 为不同的用途创建独立的磁盘组：DATA（数据文件）、FRA（恢复文件）、OCR（集群注册信息）

1.3 操作系统一致性：避免隐性问题

RAC 要求所有节点的操作系统版本、内核版本、软件包版本完全一致。一个常见的坑是：两个节点看似配置相同，但细微的时区设置或语言环境差异可能导致集群软件行为异常。

# 检查系统一致性 # 节点1执行后，将命令输出保存为文件 cat /etc/os-release uname -r rpm -qa | sort > node1_rpms.list # 节点2执行相同操作后对比差异 diff node1_rpms.list node2_rpms.list

如果发现不一致的软件包，需要先统一环境再继续安装。这一步虽然繁琐，但能避免后续很多难以排查的问题。

2. 分步实操：从零构建双节点 RAC 集群

环境准备就绪后，我们进入具体的安装流程。Oracle RAC 安装分为两个主要阶段：先安装 Grid Infrastructure（集群基础架构），再安装 Database 软件并创建数据库。

2.1 第一阶段：Grid Infrastructure 部署

Grid Infrastructure 是 RAC 的基石，包含集群管理、存储管理和高可用服务。安装前需要确认以下关键点：

用户和权限配置：创建专用的操作系统用户和组。注意权限分离原则：

# 创建必要的用户组 groupadd -g 54321 oinstall groupadd -g 54322 dba groupadd -g 54323 oper groupadd -g 54324 asmdba groupadd -g 54325 asmoper groupadd -g 54326 asmadmin # 创建 Grid Infrastructure 用户 useradd -u 54321 -g oinstall -G asmadmin,asmdba,asmoper,dba,oper grid # 创建 Database 用户（稍后使用） useradd -u 54322 -g oinstall -G dba,oper,asmdba oracle

共享存储初始化：配置 ASM 磁盘。这里演示使用 Oracle ASMLib 的方式：

# 安装 ASMLib 工具包 yum install -y oracleasm-support oracleasmlib oracleasm-`uname -r` # 配置 ASMLib oracleasm configure -i # 按照提示设置默认用户和组 # 扫描磁盘设备 oracleasm scandisks oracleasm listdisks # 创建 ASM 磁盘 oracleasm createdisk DATA_DISK01 /dev/sdb1 oracleasm createdisk DATA_DISK02 /dev/sdc1 oracleasm createdisk FRA_DISK01 /dev/sdd1

安装 Grid Infrastructure：使用静默安装方式更适合生产环境。准备响应文件是关键：

# 解压安装包 unzip linuxx64_26ai_grid_home.zip -d /u01/app/26ai/grid # 创建响应文件模板 ./grid/runInstaller -generateResponseFile -destinationFile /home/grid/grid.rsp # 编辑响应文件，重点配置以下参数： # oracle.install.option=HA_CONFIG # ORACLE_HOSTNAME=node1 # ORACLE_BASE=/u01/app/grid # INVENTORY_LOCATION=/u01/app/oraInventory # SELECTED_LANGUAGES=en,zh_CN # oracle.install.asm.OSDBA=asmdba # oracle.install.asm.OSOPER=asmoper # oracle.install.asm.OSASM=asmadmin # oracle.install.crs.config.gpnp.scanName=rac-scan.example.com # oracle.install.crs.config.gpnp.scanPort=1521 # 执行静默安装 ./grid/runInstaller -silent -responseFile /home/grid/grid.rsp -ignorePrereqFailure

安装完成后，以 root 身份在两个节点依次执行配置脚本：

# 在节点1执行 /u01/app/oraInventory/orainstRoot.sh /u01/app/26ai/grid/root.sh # 在节点2执行 /u01/app/26ai/grid/root.sh

2.2 第二阶段：Database 软件安装和数据库创建

Grid Infrastructure 就绪后，开始安装 Database 软件。这里有个重要决策点：是使用 Oracle Universal Installer 图形界面还是静默安装？

对于生产环境，我强烈推荐静默安装。不仅因为效率高，更重要的是可以版本化控制安装参数，便于后续重复部署和自动化管理。

Database 软件安装：

# 解压安装包 unzip linuxx64_26ai_database.zip -d /u01/app/oracle/software # 准备响应文件 ./database/runInstaller -generateResponseFile -destinationFile /home/oracle/db.rsp # 关键配置参数： # oracle.install.option=INSTALL_DB_SWONLY # UNIX_GROUP_NAME=oinstall # ORACLE_HOME=/u01/app/oracle/product/26ai/dbhome_1 # ORACLE_BASE=/u01/app/oracle # oracle.install.db.InstallEdition=EE # oracle.install.db.OSDBA=dba # oracle.install.db.OSOPER=oper # oracle.install.db.OSBACKUP=dba # 静默安装 ./database/runInstaller -silent -responseFile /home/oracle/db.rsp

使用 DBCA 创建 RAC 数据库：这是最关键的步骤，很多配置一旦设定就很难修改。

# 启动 DBCA 静默模式 dbca -silent \ -createDatabase \ -templateName General_Purpose.dbc \ -gdbName racdb.example.com \ -sid racdb \ -characterSet AL32UTF8 \ -createAsContainerDatabase true \ -numberOfPDBs 1 \ -pdbName pdb1 \ -useLocalUndoForPDBs true \ -sid racdb \ -sysPassword "YourSysPass123!" \ -systemPassword "YourSystemPass123!" \ -emConfiguration NONE \ -storageType ASM \ -diskGroupName DATA \ -recoveryGroupName FRA \ -sampleSchema true \ -databaseConfigType RAC \ -nodelist node1,node2 \ -totalMemory 4096

创建完成后，立即验证集群状态：

-- 检查实例状态 SELECT instance_name, host_name, status, database_status FROM gv$instance; -- 验证缓存融合功能 SELECT inst_id, name, value FROM gv$sysstat WHERE name LIKE '%gc%' AND value > 0; -- 检查 ASM 磁盘组使用情况 SELECT name, total_mb, free_mb, usable_file_mb FROM v$asm_diskgroup;

3. 安装后的关键验证：确保高可用真正生效

数据库创建成功只是第一步，真正的考验是验证高可用功能是否按预期工作。很多团队在安装后只是简单测试连接就认为大功告成，结果真正发生故障时才发现配置有问题。

3.1 基础功能验证

连接负载均衡测试：RAC 应该能够将新连接均匀分布到各个节点。

# 使用 SCAN 地址连接，观察连接分配到哪个节点 sqlplus system/YourSystemPass123!@rac-scan.example.com:1521/racdb # 在数据库内查看当前连接的实例 SELECT instance_name FROM v$instance;

透明应用故障切换（TAF）测试：模拟节点故障，验证会话是否自动迁移。

-- 在节点1上创建一个测试会话 INSERT INTO test_taf VALUES (1, '测试数据', SYSDATE); COMMIT; -- 突然关闭节点1的数据库实例 ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE; -- 在原来的会话中继续操作，应该自动切换到节点2 SELECT * FROM test_taf;

3.2 性能基准测试

RAC 环境下的性能特征与单实例有很大不同，需要特别关注缓存融合的开销。

-- 测试跨节点数据访问性能 -- 在节点1上创建测试表 CREATE TABLE perf_test AS SELECT * FROM dba_objects; -- 在节点2上频繁访问该表 DECLARE v_count NUMBER; BEGIN FOR i IN 1..1000 LOOP SELECT COUNT(*) INTO v_count FROM perf_test; END LOOP; END; / -- 监控全局缓存效率 SELECT inst_id, name, value FROM gv$sysstat WHERE name IN ('global cache blocks received', 'global cache blocks served');

理想的缓存命中率应该在 90% 以上。如果发现过多的跨节点数据块传输，可能需要调整数据分布或应用设计。

3.3 故障恢复演练

定期进行有计划的故障演练是保证 RAC 可靠性的关键。以下是一个标准的演练清单：

  1. 网络故障演练：临时断开私网连接，观察集群如何反应
  2. 存储故障演练：模拟一块 ASM 磁盘故障，验证镜像保护机制
  3. 节点故障演练：正常关闭一个节点，验证服务自动切换
  4. 脑裂场景演练：模拟网络分区，验证投票磁盘机制

每次演练后都要详细记录恢复时间和数据一致性状态，不断完善应急预案。

4. 生产环境运维要点：从能用走向好用

RAC 安装成功只是开始，长期稳定运行需要建立完善的运维体系。以下是容易被忽视但至关重要的实践要点。

4.1 监控体系构建

基础的集群状态监控是必要的，但还不够。一个完整的 RAC 监控体系应该包括：

集群层监控：

# 定期检查集群状态 crsctl status resource -t # 监控节点间网络延迟 cluvfy comp health -n all -verbose

数据库层监控：

-- 监控全局队列性能 SELECT * FROM v$cr_block_server; -- 监控实例间锁竞争 SELECT * FROM v$dlm_stats;

应用层监控：通过业务视角验证集群健康度，比如关键事务的响应时间分布。

4.2 备份恢复策略

RAC 环境的备份恢复比单实例更复杂，需要特别注意：

  • 使用 RMAN 备份时，确保连接到正确的实例
  • 定期验证备份的可用性，特别是归档日志的连续性
  • 制定详细的灾难恢复流程，明确各种故障场景下的恢复步骤
# RAC 环境下的 RMAN 备份示例 rman target sys/YourSysPass123!@racdb1 RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'sys/YourSysPass123!@racdb1'; ALLOCATE CHANNEL ch2 DEVICE TYPE DISK CONNECT 'sys/YourSysPass123!@racdb2'; BACKUP DATABASE PLUS ARCHIVELOG; RELEASE CHANNEL ch1; RELEASE CHANNEL ch2; }

4.3 性能优化持续进行

RAC 性能优化是一个持续的过程，重点关注以下几个方面：

应用设计优化：尽量减少跨实例的数据访问，通过数据分区将相关数据放在同一实例上。

数据库参数调优：特别注意与集群相关的参数，如cluster_database_instances、cluster_interconnects等。

系统资源规划：定期评估硬件资源使用情况，提前规划扩容方案。

5. 常见问题深度排查：从现象到根因

即使按照最佳实践部署，RAC 环境中仍然可能出现各种问题。关键在于建立系统化的排查思路。

5.1 节点驱逐问题排查

节点被意外驱逐是 RAC 环境中最严重的问题之一。排查思路如下：

  1. 检查集群日志：首先查看$GRID_HOME/log/<hostname>/alert<hostname>.log
  2. 分析时间线：确定驱逐发生的确切时间，关联系统日志和网络监控数据
  3. 网络质量分析：检查私网在故障时间点的延迟和丢包率
  4. 资源竞争分析：检查当时是否有资源瓶颈导致心跳超时

5.2 性能问题排查

RAC 性能问题往往比单实例更复杂，需要多维度分析：

-- 快速定位性能瓶颈的查询 SELECT inst_id, event, total_waits, time_waited_micro FROM gv$system_event WHERE wait_class <> 'Idle' ORDER BY time_waited_micro DESC; -- 检查跨实例等待事件 SELECT * FROM v$waitclassmetric WHERE wait_class_name = 'Cluster';

5.3 连接管理问题

连接池配置不当是 RAC 环境常见的问题源：

  • 确保连接字符串正确使用 SCAN 地址
  • 验证负载均衡配置是否生效
  • 检查连接超时和故障切换设置
  • 监控连接分布是否均衡

Oracle RAC 的部署和运维确实比单实例数据库复杂得多，但这种复杂性换来的是业务连续性的质的提升。真正的价值不在于安装成功的那一刻，而在于当硬件故障、网络中断或其他意外情况发生时，业务能够几乎无感知地继续运行。

最重要的是，要把 RAC 看作一个完整的体系而不仅仅是软件组合。从前期规划、中期部署到后期运维，每个环节都需要严谨的态度和系统化的方法。只有这样，RAC 才能真正成为支撑关键业务的可靠基石。

http://www.jsqmd.com/news/1246212/

相关文章：

  • 从PLC到工业物联网：数字化工厂转型与技能升级
  • # MatrixOne Git4Data 技术详解（八）·AI 训练实践篇：从数据进入到模型迭代——Git4Data 能力如何贯穿机器学习全流程
  • 我用这两个skill，把小红书带货图文流水线彻底跑通了
  • WordPress网站CDN加速优化与常见问题解析
  • 2026年直线模组厂家选型避坑：靠谱半封闭皮带模组性价比实测指南
  • 2026年广东检测仪器回收机构推荐，阻抗分析仪回收/信号分析仪器回收/扫频仪回收，检测仪器回收公司选哪家 - 品牌推荐师
  • Claude Code限额提升50%：AI编程助手使用策略与开发效率优化
  • 嵌入式开发为何需要计算机体系结构：从CS61C到实战优化
  • 计算机毕业设计之基于SpringBoot的社区医疗中心预约挂号平台的设计与实现
  • 腾讯混元大模型Hy3限免实战：API集成与代码生成最佳实践
  • 登报挂失公章怎么办？一文带你搞定公章登报全流程！速看！
  • 大语言模型思维链语言偏好分析：从Kimi K3英文推理现象到实践应对
  • 48V锂电池PACK知名企业怎么选？钜大锂电提供专业甄选标准
  • Android模拟器Frida逆向环境搭建：版本与架构匹配全攻略
  • Claude提示词优化：少即是多的AI交互核心原则
  • 程序员转型安卓开发：核心技术栈与高效学习路径
  • C++面向对象进阶：构造函数、静态成员、友元与对象关系详解
  • 家用纯电SUV技术解析：640km续航与智能驾驶
  • Maven项目中JUnit依赖配置与@AfterEach注解实战指南
  • DaVinci DM644x UART引导与闪存编程：从原理到工程实践
  • Grok for Excel：AI如何革新金融建模与数据分析工作流
  • 2026 年新消息：哈密诚信的耐磨衬板铸件厂家电话定做厂家竞争格局,揭秘：顶级耐磨衬板铸件的秘密供应商电话曝光！ - 行业甄选官
  • 2026年7月最新真力时泉州鲤城万达广场维修保养服务电话 - 亨得利钟表维修中心
  • Kimi K3模型技术解析：缩小中美AI差距的国产大模型实践
  • 剪映专业版教程：制作文字环绕人物滚动效果
  • Unity项目CI/CD自动化构建实战：基于Jenkins的流水线搭建指南
  • 从零实现C++字符串类：深入理解内存管理、SSO优化与现代C++实践
  • EasyGoAdmin 敏捷开发框架 v3.1.1 更新：修复问题，多版本助力高效开发！
  • C++视觉算法实战：从OpenCV环境搭建到性能优化与项目部署
  • Linux安装失败与Docker镜像源优化实战