简介本资源是一份面向企业级Oracle数据库高可用架构师与DBA的「存储双活配置实战指南」聚焦跨数据中心RAC双活场景下突破传统RAC共享存储瓶颈与ADG仅容灾局限的核心难题。文档系统梳理了双活架构设计原理、Interconnect时延影响分析、6盘磁盘规划含AA/BB机房数据OCR盘及ZC仲裁盘、Grid Infrastructure安装、NORMAL冗余OCR/Data磁盘组创建含QUORUM故障组语法、OCR/votedisk迁移、ASM SPFILE迁移及asm_preferred_read_failure_groups参数调优等关键步骤并附Orion主机层IO性能测试方法与实测数据如64KB随机写达356MBps。资源为单个104KB的Word文档.docx内容结构清晰、命令完整、参数详实适合作为生产环境部署前的技术验证与实施蓝本。目前已有150人学习下载是少有的兼顾理论深度与落地细节的Oracle双活配置一手实践资料。1. Oracle 存储双活配置指南不是“开个镜像就完事”而是让 RAC 节点在存储层真正互为灾备的实操路径你手头有一套 Oracle RAC比如 19c两个节点分别连着两套独立 SAN 存储如 Dell EMC PowerMax、HPE Primera 或 Hitachi VSP但当前只是主库写 A 存储、备库同步 B 存储——这叫“主备”不叫“双活”。真正的 Oracle 存储双活是指两个 RAC 节点能同时、并发、无感知地读写同一套逻辑卷LUN集群且任意一套存储故障时数据库不中断、不切换、不丢事务。它不是靠 Oracle Data Guard 实现的也不是靠 ASM 冗余策略糊弄的它是底层存储阵列级的同步复制 主机多路径智能 failover Oracle ASM 的跨阵列 LUN 识别能力三者咬合的结果。适合正在规划同城双中心、要求 RTO0/RPO≈0 的金融、电信核心系统 DBA 和存储工程师。注意这不是给单实例 Oracle 做的“高可用”也不是给虚拟机挂共享盘的伪双活——它必须跑在真实物理 RAC 双控/双活存储阵列上且所有链路FC/iSCSI/HBA/多路径/ASM diskgroup都得按双活语义重新校准。网上大量所谓“Oracle 双活教程”只讲 DG 或 RACASM 冗余根本没碰存储层协同这个黑匣子照着做只会在线上翻车。2. 为什么必须绕过 ASM 冗余、直击存储阵列双活能力选型与架构对齐是成败前提Oracle 存储双活的本质是把“数据一致性保障”从数据库层如 Redo Apply、Log Shipping上移到存储硬件层。这意味着Oracle 不再负责跨站点的数据同步而是信任存储阵列已通过硬件级同步复制Synchronous Replication保证两个物理 LUN 的字节级一致。因此第一步不是改 Oracle 参数而是确认你的存储是否真支持“Active-Active 模式下的跨阵列 LUN 共享访问”。2.1 存储阵列双活能力验证别被“双活”宣传话术带偏很多厂商把“双活网关”或“异步复制手动切换”也包装成双活。真双活必须满足三点✅同步写入Write Synchronous主机发出一个 I/O必须等两个阵列都落盘成功才返回 ACK✅LUN 全局唯一标识WWN/ALUA Target Port Group两个阵列暴露的同一个 LUN其 SCSI Device ID如naa.600009700002345678901234567890ab完全一致且支持 ALUAAsymmetric Logical Unit Assignment自动路径优选✅阵列间心跳与仲裁机制当 FC 链路中断时能通过专用心跳线如 10GbE 第三方仲裁设备如 Dell EMC VPLEX Witness、HPE Quorum Witness防脑裂而非简单断连即降级。提示EMC VPLEX、HPE 3PAR Peer Persistence、Hitachi TrueCopy Sync、NetApp MetroCluster 是目前主流企业级方案。而所谓“EMC 存储 service mode”只是维护模式和双活无关——千万别在 service mode 下做双活配置会锁死 LUN 访问。2.2 Oracle RAC 架构适配RAC 必须运行在“共享存储双活”而非“本地存储集群”上常见错误是用两套独立存储每套挂给一个 RAC 节点再靠 DG 同步——这本质是主备非双活。正确拓扑是两套存储阵列A 和 B通过光纤交换机组成统一 SAN 网络每个 RAC 节点Node1/Node2各配 2 块 HBA 卡分别连 A 阵列的 Controller1/Controller2 和 B 阵列的 Controller1/Controller2存储侧将同一组 LUN如ORCL_DATA01,ORCL_FRA01同时映射给 Node1 和 Node2并启用 ALUA主机侧用多路径软件如 PowerPath、DM-Multipath聚合路径生成/dev/mapper/orcl_data01这类统一设备名ASM 使用这些 mapper 设备创建 diskgroup且compatible.asm 19.0或更高启用ASM_DISKSTRING /dev/mapper/*。这样当 A 阵列宕机多路径自动切到 B 阵列路径ASM 无感知继续服务——这才是存储双活的落地基座。2.3 为什么不能只靠 ASM 冗余Redundancy ≠ Dual-ActiveASM 的NORMAL或HIGH冗余是在同一套存储内部做镜像如 LUN1 和 LUN2 在同一阵列内 RAID1。一旦整套阵列掉电冗余失效。而双活要求的是跨阵列冗余LUN1 在 A 阵列有副本在 B 阵列也有实时副本。ASM 本身不参与跨阵列同步它只认/dev/mapper/orcl_data01这个设备——只要这个设备背后路径通ASM 就认为磁盘在线。所以双活的“活”90% 功夫在存储和主机多路径ASM 只是受益者不是驱动者。3. 从裸设备到 ASM Diskgroup五步完成双活存储链路贯通以下操作均在 Oracle 19c RAC 环境Linux x86_64下实测假设已部署好双活存储阵列并完成 LUN 映射。3.1 步骤一主机多路径配置以 DM-Multipath 为例目标让/dev/mapper/orcl_data01指向同一 LUN 的 4 条路径Node1-A-ctrl1, Node1-A-ctrl2, Node1-B-ctrl1, Node1-B-ctrl2并启用 ALUA 自动优选。# 编辑 /etc/multipath.conf关键段 defaults { user_friendly_names yes find_multipaths yes } devices { device { vendor DGC # EMC VNX/VMAX product LUNZ path_grouping_policy multibus getuid_callout /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/%n features 2 pg_init_retries 50 hardware_handler 1 alua prio alua failback immediate no_path_retry queue } }# 重载 multipath 并扫描 systemctl restart multipathd multipath -F multipath -v2 # 验证输出中应看到类似 # mpatha (36006016098a033001f9b4e5c8d7e9f0a) dm-2 DGC,RAID 10 # size1.0T features1 queue_if_no_path hwhandler1 alua wprw # -- policyservice-time 0 prio50 statusactive逻辑说明prio alua启用 ALUA 优先级策略存储阵列会通过 SCSI REPORT TARGET GROUP STATES 告知主机哪条路径是 Optimized首选哪条是 Non-optimized备用。failback immediate确保主路径恢复后立刻切回避免长期走次优路径拖慢 IO。参数prio50表示该路径当前为 Optimized 状态——这是双活链路健康的黄金指标。3.2 步骤二UDEV 规则固化设备名避免重启后 mapper 名变动ASM 依赖稳定设备名。若 multipath 重启后mpatha变成mpathbASM 无法识别磁盘。# 查 LUN WWID取自 multipath -ll 输出的 36006016... 字符串 # 编辑 /etc/udev/rules.d/99-oracle-asm.rules KERNELdm-*, SUBSYSTEMblock, PROGRAM/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device/dev/$name, SYMLINKoracleasm/disk1, MODE0660, OWNERgrid, GROUPasmadmin KERNELdm-*, SUBSYSTEMblock, PROGRAM/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device/dev/$name, SYMLINKoracleasm/disk2, MODE0660, OWNERgrid, GROUPasmadmin # 注意disk1/disk2 对应实际 LUN 顺序需按 multipath -ll 输出的 WWID 一一绑定# 重载 udev 并验证 udevadm control --reload-rules udevadm trigger --subsystem-matchblock ls -l /dev/oracleasm/ # 应看到 /dev/oracleasm/disk1 - /dev/mapper/mpatha参数说明SYMLINKoracleasm/disk1创建固定软链ASM 启动时通过ASM_DISKSTRING/dev/oracleasm/*扫描比直接扫/dev/mapper/*更可靠。MODE0660和OWNER/GROUP确保 grid 用户可读写这是 ASM 实例启动的前提。3.3 步骤三ASM 初始化与 Diskgroup 创建关键FORCE 选项与 COMPATIBLE 设置-- 以 grid 用户登录 ASM 实例 sqlplus / as sysasm -- 创建磁盘组必须指定 ATTRIBUTE compatible.asm19.0否则不支持跨阵列 LUN CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK /dev/oracleasm/disk1, /dev/oracleasm/disk2 ATTRIBUTE compatible.asm19.0, au_size4M; -- 验证磁盘状态重点看 HEADER_STATUS 和 MODE_STATUS SELECT name, header_status, mode_status, state, total_mb, free_mb FROM v$asm_disk WHERE group_number (SELECT group_number FROM v$asm_diskgroup WHERE nameDATA); -- 正常应全为 MEMBER 和 ONLINE逻辑说明EXTERNAL REDUNDANCY是必须的——因为冗余由存储阵列保证ASM 不做镜像。compatible.asm19.0是 Oracle 19c 双活支持的硬性要求低于此版本如 12.1的 ASM 无法正确处理 ALUA 路径切换事件。au_size4M是推荐值平衡元数据开销与大文件性能。3.4 步骤四RAC 数据库使用双活 Diskgroup含 OCR/Voting Disk 迁移OCR 和 Voting Disk 必须也放在双活 diskgroup 中否则集群无法跨存储故障存活。# root 用户执行在任一节点 # 迁移 OCR 到 DATA diskgroup ocrconfig -replace OCRVOTE -replacement DATA # 迁移 Voting Disk crsctl replace votedisk DATA # 验证 ocrcheck crsctl query css votedisk # 输出应显示 VOTE 盘在 DATA且状态 ONLINE-- 数据库创建表空间指向双活 diskgroup CREATE TABLESPACE users DATAFILE DATA SIZE 1G AUTOEXTEND ON NEXT 100M; -- 关键不要指定具体 ASM 文件名让 ASM 自动分配并利用双活路径注意迁移 OCR/Voting Disk 是高危操作务必在维护窗口执行并提前备份ocrconfig -export。迁移后crsctl check cluster必须返回所有节点 ONLINE且crsctl stat res -t中ora.asm和ora.cluster_vip状态正常。3.5 步骤五双活链路健康度持续监控不只是看 ASM 是否 MOUNT双活不是配置完就一劳永逸。需建立三层监控监控层级工具/命令关键指标异常含义存储层存储阵列 CLI如symcfg listfor VMAXState: Active-Active,Sync Rate: 100%同步延迟 5ms 或状态非 Active-Active说明链路或阵列异常主机层multipath -llstatusactive,prio50Optimized路径数 ≥2出现statusfail或prio10Non-optimized过多表示 ALUA 切换失败Oracle 层SELECT * FROM v$asm_operation;SELECT path, mode_status FROM v$asm_disk;v$asm_operation为空mode_status全为ONLINE若v$asm_disk.mode_statusMISSING说明某条路径彻底不可达需查 multipath4. 避坑五个让 DBA 加班到凌晨的真实翻车现场与血泪解法双活配置中最容易踩的坑往往藏在“看起来正常”的环节。以下是我在 3 家银行核心系统上线时亲历的典型问题按现象→原因→解法结构整理4.1 现象crsctl check cluster显示节点 ONLINE但sqlplus / as sysdba连接数据库超时原因OCR 迁移后DATAdiskgroup 虽 MOUNT但v$asm_disk中部分磁盘header_statusPROVISIONED未格式化导致 ASM 实例无法加载全部磁盘OCR 读取卡住。解法-- 以 sysasm 登录强制重写磁盘头 ALTER DISKGROUP DATA CHECK ALL REPAIR; -- 若仍失败用 kfed 修复慎用 kfed repair /dev/oracleasm/disk1 ausz41943044.2 现象存储阵列显示 Active-Active但multipath -ll中某节点只有 2 条路径而非预期 4 条原因HBA 卡 firmware 版本过低不支持 ALUA 的REPORT TARGET GROUP STATES命令导致多路径无法识别 Optimized 路径。解法升级 HBA firmware 至厂商推荐版本如 Emulex LPe31000 需 ≥11.2.265.23并重启服务器。4.3 现象A 阵列断电后数据库未中断但v$asm_disk.i/o统计显示 IO 延迟飙升至 200ms原因B 阵列未启用 Cache Write-Through 模式所有写请求必须等磁盘物理落盘才返回而 A 阵列断电后 B 阵列独扛双倍负载Cache 未及时刷新。解法登录 B 阵列管理界面将对应 LUN 的 Cache Policy 改为Write-Back需确保 B 阵列电池/超级电容健康并开启Cache Mirroring。4.4 现象asmcmd lsdg显示 DATA diskgroupfree_mb为负数原因compatible.asm版本低于 19.0ASM 无法正确计算跨阵列 LUN 的 AU 分配元数据溢出。解法-- 紧急扩容临时缓解 ALTER DISKGROUP DATA RESIZE ALL; -- 根本解决重建 diskgroup停业务窗口 DROP DISKGROUP DATA INCLUDING CONTENTS; CREATE DISKGROUP DATA EXTERNAL REDUNDANCY ... ATTRIBUTE compatible.asm19.0;4.5 现象crsctl stat res -t中ora.asm状态为INTERMEDIATE反复启停原因/etc/oracle/olr.loc中 OCR 位置仍指向旧 diskgroup如OCRVOTE而 CRS 启动时先读 OLR 再读 OCR路径冲突。解法# root 用户修正 OLR 位置 echo ocrconfig_locDATA /etc/oracle/olr.loc # 重启 CRS crsctl stop crs crsctl start crs5. 验证双活真实性的三把尺子压力测试、故障注入与日志溯源配置完成不等于双活可用。必须用生产级手段验证否则上线即事故。5.1 尺子一IO 压力下路径自动切换非模拟真断链用dd持续写入 iostat监控再物理拔掉 Node1 连接 A 阵列的一根光纤线缆# Node1 上执行后台运行 dd if/dev/zero of/u01/app/oracle/oradata/DATA/testfile bs1M count10000 oflagdirect # 同时监控 iostat -x 1 | grep mapper # 拔线瞬间观察 # - await 是否短暂冲高2s后回落至正常值10ms # - svctm 是否稳定证明路径切换未引入额外延迟 # - %util 是否从 50%双路径均分变为 100%单路径满载后又回落证明 B 阵列接管成功。注意必须用oflagdirect绕过 OS cache否则dd会缓存写入掩盖真实 IO 路径问题。svctm服务时间比await等待时间更能反映存储真实性能因await包含队列等待。5.2 尺子二RAC 节点级故障注入验证集群脑裂防护在双活仲裁正常时同时关闭 Node1 和 Node2 的 public 网络模拟同城网络中断观察集群行为# Node1 Node2 同时执行模拟网络分区 ip link set eth0 down # 观察 30 秒内 # - crsctl check cluster 是否仅剩一个节点 ONLINE仲裁胜出者 # - tail -f $GRID_HOME/log/ 下各节点 alert.log 是否出现 ORA-29770: instance termination due to network partition # - 未胜出节点是否自动 shutdown防脑裂。关键点仲裁设备Witness必须部署在第三地如云上 ECS且网络延迟 10ms。若仲裁与任一节点同机房网络分区时仲裁可能和该节点形成多数派导致误杀另一节点。5.3 尺子三Redo 日志与存储层日志交叉溯源确认 RPO≈0这是最硬核的验证——证明每个 COMMIT 都被双阵列同步落盘在数据库执行一个带时间戳的事务INSERT INTO test_log VALUES (SYSTIMESTAMP, BEFORE_FAIL); COMMIT;立即触发 A 阵列断电或拔光纤等待 5 秒执行INSERT INTO test_log VALUES (SYSTIMESTAMP, AFTER_FAIL); COMMIT;登录 B 阵列管理界面查该 LUN 的Write Log找到两条事务对应的时间戳区间对比数据库V$LOG_HISTORY中对应 SCN 的FIRST_TIME和NEXT_TIME若 B 阵列日志中AFTER_FAIL时间戳 ≤ 数据库NEXT_TIME则 RPO ≈ 0毫秒级。我的习惯每次上线前用这套三尺法测 3 轮每轮间隔 2 小时覆盖不同负载时段。曾发现某次测试中svctm在切换后持续 15ms追查发现是 B 阵列 Cache 未开启 Adaptive Read Caching补丁后降至 3ms。这种细节文档不会写但线上会要命。希望帮到你。本文还有配套的精品资源点击获取
