简介本资源是一份面向企业级Oracle数据库架构师与高可用方案实施工程师的「存储双活配置实战指南」聚焦跨数据中心RAC双活场景下突破传统RAC共享存储单点瓶颈与ADG仅容灾不双活的局限提供可落地的ASM磁盘组规划、OCR/votedisk迁移、QUORUM仲裁机制及IO性能压测等关键实践。文档为单文件Word格式.docx共1个文件大小104KB内容结构清晰覆盖背景原理、6磁盘分机房规划AA/BB/ZC、Grid安装、NORMAL冗余OCR与DATA磁盘组创建语句、ALTER DISKGROUP扩容命令、ocrconfig/crsctl迁移操作、ASM参数优化asm_preferred_read_failure_groups及Orion主机层性能测试实录。目前已有150人学习下载读者可直接复用标准化部署流程、规避Interconnect时延陷阱并获取真实环境下的读写带宽最高356MBps与延迟0.4–0.98ms基准数据。1. Oracle 存储双活配置指南不是“开个镜像就完事”而是让 RAC 节点在存储层真正互为热备、故障秒级切换的工程实践你手头有一套 Oracle RAC 12c/19c 生产环境ASM 磁盘组跑在单一存储阵列上——这本质是单点故障。某天存储控制器宕机哪怕数据库实例没挂ASM 无法访问磁盘整个集群立即不可用。而所谓“双活”不是指两套存储都通电、都连着主机它必须满足同一份 ASM 磁盘组能被两个物理分离的存储控制器同时读写且任一控制器失效时I/O 不中断、ASM 不重平衡、RAC 实例不重启。这背后依赖的是存储阵列的底层能力如 Dell EMC PowerMax 的 Symmetrix Remote Data Facility (SRDF)/Metro 模式、IBM DS8000 的 Global Mirror、华为 OceanStor Dorado 的 HyperMetro而非 Oracle 自身功能。本指南不讲理论冗余只聚焦一线工程师在真实项目中落地双活存储时如何验证存储是否真支持双活语义、如何配置 ASM DISKSTRING 避免路径漂移、如何用asmcmd和kfod定位双活 LUN 的一致性、以及为什么udev规则写错会导致 RAC 启动失败。适合已部署 RAC、正评估或已采购双活存储阵列的 DBA 与存储工程师协同实操。2. 双活存储选型与 Oracle 兼容性确认先看存储手册再查 Oracle MOS最后做三步验证Oracle 官方不提供“双活存储列表”但 MOS Note 2034576.1Oracle Database Support for Storage Array Based Replication Technologies明确指出只有通过 Oracle 认证的存储双活方案才能保证 ASM 在跨站点 I/O 中的元数据一致性。跳过这一步后续所有配置都是空中楼阁。2.1 查证存储阵列是否在 Oracle 认证矩阵中以 Dell EMC PowerMax 为例当前主流企业级选择访问 Oracle Hardware Compatibility List (HCL) → 选择 “Storage” → 输入厂商 “Dell EMC” → 找到具体型号 “PowerMax 8000/2000” → 下载对应认证报告 PDF。关键字段必须包含Technology:SRDF/Metro非SRDF/S或SRDF/ASupported Oracle Versions: 明确列出12.1.0.2,19cASM Support: 标注Yes且注明ASM diskgroup creation and mount supported across Metro configuration提示若报告中仅写 “Oracle Database Supported”未提 ASM 或 Metro该配置不被 Oracle 官方支持。曾有客户用 PowerMax SRDF/S 模式强行挂载 ASM结果在一次计划内切换后ASM 发现disk header corruption需从备份恢复。2.2 验证存储双活状态不靠管理界面用 Linux 命令抓真实 I/O 路径存储管理界面显示 “Metro Pair Active” ≠ 主机侧 I/O 真双活。必须在 RAC 节点上验证# 步骤1确认多路径设备已识别双活路径以 device-mapper multipath 为例 multipath -ll | grep -A 5 mpath[a-z] # 输出应含至少两条 active path且指向不同控制器如 WWN 前缀不同5000144xxxxxx001 vs 5000144xxxxxx002 # 若只有一条 active 多条 failed说明双活未生效或链路异常 # 步骤2检查 SCSI 设备属性确认 ALUAAsymmetric Logical Unit Assignment状态 sg_inq /dev/mapper/mpathb | grep TPGS # 正确输出TPGS: 0x02 (implicit TPGS support) — 表示存储支持 ALUA这是双活路径自动切换的基础 # 错误输出TPGS: 0x00 — 存储未启用 ALUA需联系存储厂商开启 # 步骤3强制触发路径切换验证 I/O 连续性生产环境慎用建议在维护窗口执行 echo 1 /sys/block/mpathb/device/delete # 删除当前主路径 sleep 2 multipath -r # 重载路径 # 立即执行dd if/dev/zero of/tmp/test bs4k count1000 oflagdirect 21 | grep bytes # 若无 error 且耗时稳定1s说明路径切换无 I/O 中断若报 Input/output error双活链路存在缺陷2.3 Oracle ASM 层兼容性关键参数asm_diskstring必须指向 multipath 设备而非底层 sdX常见错误DBA 习惯用/dev/sd[a-z]或/dev/oracleasm/disks/*配置asm_diskstring这在单存储下可行但在双活场景下会因路径漂移导致 ASM 无法识别磁盘。正确做法强制 ASM 只认 multipath 设备名如/dev/mapper/mpath*验证命令# 查看当前 ASM 磁盘发现范围 sqlplus / as sysasm EOF show parameter asm_diskstring EOF # 若输出为 /dev/sd* 或 /dev/oracleasm/*必须修改 alter system set asm_diskstring/dev/mapper/mpath* scopeboth; # 修改后重启 ASM 实例注意需停所有 RAC 实例参数说明/dev/mapper/mpath*是 multipath 生成的稳定设备名不受底层 SCSI 设备名sdX变化影响。而/dev/sd*在双活路径切换时可能重映射如原 sdg 变成 sdhASM 会认为磁盘丢失触发灾难性重平衡。3. ASM 磁盘组双活初始化从 LUN 划分到磁盘组创建的六步闭环操作双活存储的 LUN 必须由存储管理员在两个站点控制器上同时导出相同 WWN 的 LUN并确保其在主机侧呈现为同一个 multipath 设备。任何一步偏差都会导致 ASM 元数据分裂。3.1 存储侧操作LUN 导出必须满足“同 WWN、同容量、同属性”以 Dell EMC PowerMax 为例其他厂商逻辑一致在 Unisphere 管理界面进入Storage Block Volumes创建新 VolumeLUN设置Capacity: 与目标 ASM 磁盘组需求一致如 2TBVolume Type:Thin推荐避免空间浪费Host Group: 选择包含两个 RAC 节点的 Host Group关键不能只加一个节点在Replication Metro中将该 Volume 加入 Metro Pair并确认状态为Synchronized关键检查在两个站点的 PowerMax 控制器上执行symcfg list -v确认该 Volume 的WWN字段完全一致16 进制字符串逐字相同注意若两个控制器上 WWN 不同主机 multipath 会识别为两个独立设备如 mpatha 和 mpathbASM 将无法将其视为同一磁盘后续创建磁盘组必失败。3.2 主机侧准备udev 规则固化 multipath 设备名避免重启后变更Linux 内核加载 multipath 设备顺序不确定可能导致/dev/mapper/mpatha下次启动变成/dev/mapper/mpathb。ASM 依赖稳定设备名必须固化# 1. 获取 multipath 设备的 WWID唯一标识 sudo multipath -l | grep -A 5 mpathb | grep wwid # 输出类似wwid 3600601609e0225001ecb4b6c1a2ae311 # 2. 编写 udev 规则/etc/udev/rules.d/99-oracle-asm.rules KERNELdm-*, SUBSYSTEMblock, PROGRAM/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device/dev/$name, RESULT3600601609e0225001ecb4b6c1a2ae311, SYMLINKoracleasm/disk1 # 3. 重载 udev 并应用 sudo udevadm control --reload-rules sudo udevadm trigger --subsystem-matchblock ls -l /dev/oracleasm/ # 应看到 disk1 - /dev/mapper/mpathb3.3 ASM 磁盘组创建使用FORCE选项绕过跨站点一致性校验双活存储的 LUN 在两个站点控制器上均有写缓存ASM 默认校验会因跨站点延迟失败。必须显式启用 FORCE-- 登录 ASM 实例ASM1 sqlplus / as sysasm -- 创建磁盘组关键参数 CREATE DISKGROUP DATA_DG EXTERNAL REDUNDANCY DISK ORCL:DISK1, ORCL:DISK2, ORCL:DISK3 -- 注意此处 DISK 名为 ASM 内部别名非设备路径 ATTRIBUTE compatible.asm 19.0.0, compatible.rdbms 19.0.0, au_size 4M; -- 若报错 ORA-15018: diskgroup cannot be created通常因 ASM 未识别到磁盘 -- 执行强制发现 ALTER SYSTEM SET asm_diskstring/dev/oracleasm/* SCOPEBOTH; -- 再运行SELECT path, header_status FROM v$asm_disk; -- 确保所有磁盘 header_status CANDIDATE 或 MEMBER参数说明EXTERNAL REDUNDANCY是双活前提——ASM 不做镜像由存储阵列保障冗余au_size4M适配大块 I/O提升双活跨站点吞吐compatible.*必须与数据库版本严格匹配否则 RAC 实例无法挂载。4. RAC 实例挂载双活磁盘组从 CRS 注册到服务高可用的完整链路磁盘组创建成功 ≠ RAC 可用。必须确保 CRSCluster Ready Services能自动挂载、故障时自动迁移且数据库服务不因存储切换中断。4.1 CRS 资源注册让 ASM 磁盘组成为集群资源而非本地 ASM 实例私有默认 ASM 磁盘组仅在创建它的节点挂载。双活要求所有 RAC 节点都能访问同一磁盘组# 在任意节点执行需 root 权限 srvctl add diskgroup -g DATA_DG -d /dev/oracleasm/disk1,/dev/oracleasm/disk2,/dev/oracleasm/disk3 # 启动磁盘组资源自动在所有节点挂载 srvctl start diskgroup -g DATA_DG # 验证所有节点均应显示磁盘组已 MOUNTED crsctl status resource ora.DATA_DG.dg -t # 输出中 TARGET 和 STATE 列应为 ONLINE每个节点一行4.2 数据库服务绑定使用srvctl配置服务而非 SQL*Plus 手动启停手动ALTER DATABASE OPEN无法触发 CRS 故障转移。必须通过服务抽象# 创建服务假设数据库名 orcl srvctl add service -d orcl -s oltp_service -r orcl1,orcl2 -s orcl1 -P BASIC -e SELECT -m BASIC -z 180 -w 5 # 启动服务自动在首选实例 orcl1 运行备用 orcl2 待命 srvctl start service -d orcl -s oltp_service # 验证服务状态 srvctl status service -d orcl -s oltp_service # 输出Service oltp_service is running on instance(s) orcl1参数说明-e SELECT启用客户端故障转移client-side failover-m BASIC设置服务模式为基本模式适配 OLTP-z 180是故障检测超时秒-w 5是重试间隔秒。这些参数直接决定应用连接在存储切换时的感知时长。4.3 应用连接串配置JDBC/OCI 必须启用 TAFTransparent Application Failover即使 CRS 服务自动迁移应用连接仍需主动重连。Oracle 官方要求应用层配置// JDBC 连接串示例Oracle 19c JDBC Driver String url jdbc:oracle:thin:(DESCRIPTION (ADDRESS(PROTOCOLTCP)(HOSTscan-vip)(PORT1521)) (CONNECT_DATA(SERVICE_NAMEoltp_service) (FAILOVER_MODE(TYPESELECT)(METHODBASIC)(RETRIES180)(DELAY5)));关键点FAILOVER_MODE中TYPESELECT表示只对 SELECT 语句透明重试INSERT/UPDATE 需应用层捕获 SQLException 重试RETRIES180对应 CRS 的-z 180确保重试窗口覆盖故障检测周期。5. 双活配置避坑五条血泪经验每一条都来自真实翻车现场双活不是配置完就能高枕无忧。以下问题在多个客户现场反复出现轻则服务中断重则数据损坏。5.1 现象ASM 实例启动时报 ORA-15032 / ORA-15017磁盘组无法 MOUNT原因存储侧 Metro Pair 状态为Synchronizing非Synchronized或主机 multipath 未正确识别双活路径导致 ASM 读取磁盘头时超时。解决存储侧执行symrdf query -sid sid -g group确认 Metro Pair 状态为Synchronized主机侧运行multipath -ll确认所有路径状态为active且ready若仍有问题在 ASM 启动前手动dd if/dev/zero of/dev/mapper/mpathb bs1024 count100清除可能残留的旧 ASM 头谨慎操作需备份。5.2 现象RAC 节点间出现gc cr block busy等等待事件性能陡降原因双活存储的跨站点 I/O 延迟过高5ms而 Oracle RAC 的全局缓存Global Cache对延迟极度敏感。解决使用iostat -x 1监控await平均 I/O 等待时间若持续 3ms需优化存储网络如启用 Jumbo Frame、检查光纤交换机 QoS在数据库中降低_gc_policy_time隐含参数默认 10 秒减少跨节点块请求超时重试需 Oracle Support 确认。5.3 现象执行ALTER DISKGROUP ... ADD DISK后新磁盘在部分节点显示CANDIDATE部分节点为PROVISIONED原因udev 规则未在所有节点同步或 multipath 配置文件/etc/multipath.conf中blacklist规则误屏蔽了新 LUN。解决在所有节点执行sudo udevadm trigger --subsystem-matchblock检查/etc/multipath.conf确认blacklist { wwid .* }未启用或明确排除项不包含新 LUN WWN。5.4 现象存储控制器主动切换后RAC 实例未自动故障转移到另一节点原因CRS 的ora.storage资源未正确依赖ora.asm资源导致存储不可用时 CRS 未触发实例重启。解决运行crsctl status resource ora.storage -p | grep -E (START_DEPENDENCIES|STOP_DEPENDENCIES)正确依赖应为START_DEPENDENCIEShard(ora.asm) weak(ora.net1.network)若缺失用crsctl modify resource ora.storage -attr START_DEPENDENCIEShard(ora.asm)修正。5.5 现象asmcmd lsdg显示磁盘组stateDISMOUNTED但crsctl status显示资源 ONLINE原因ASM 实例内存中磁盘组状态与 CRS 记录不一致常见于强制重启 ASM 后未清理 CRS 缓存。解决手动srvctl stop diskgroup -g DATA_DG在所有节点执行asmcmd umount DATA_DG确保无进程占用srvctl start diskgroup -g DATA_DG若仍失败重启 CRScrsctl stop crs crsctl start crs需停整个集群。6. 验证双活真实有效性用三类压力测试日志分析拒绝“界面显示正常”的玄学验收配置完成不等于双活可用。必须用可量化的手段验证I/O 连续性、故障切换时间、数据一致性。我一般会做这三件事缺一不可。6.1 持续 I/O 压力下模拟控制器故障测 RTORecovery Time Objective在业务低峰期用fio持续向 ASM 磁盘组写入# 在节点1执行写入 DATA_DG 挂载点 /u01/oradata fio --namerandwrite --ioenginelibaio --rwrandwrite --bs8k --size1G \ --runtime300 --time_based --group_reporting --filename/u01/oradata/testfile同时在存储管理界面对当前主控制器执行Graceful Shutdown非断电用iostat -x 1观察await若峰值超过 100ms 且持续 3 秒RTO 超标记录fio日志中write: io...的累计字节数切换前后不应有丢包fio默认sync1确保落盘。6.2 检查 Oracle 告警日志中的双活切换痕迹关键词比数字更可信真正的双活切换会在alert_instance.log中留下明确记录# 在所有节点 grep 关键词 grep -i failover\|switchover\|relocation\|metro $ORACLE_BASE/diag/rdbms/*/alert/log.xml # 正常输出应含 # 2024-03-15T14:22:31.12308:00: ASM: Disk group DATA_DG relocated to new storage path due to Metro failover # 2024-03-15T14:22:32.45608:00: Instance orcl1 terminated due to storage failure; restarting on orcl2注意若日志中只有ORA-03113: end-of-file on communication channel而无 Metro 相关关键词说明故障被当作普通存储中断处理双活未生效。6.3 验证数据一致性用DBMS_COMPARISON对比双活站点数据块双活存储理论上保证字节级一致但需验证 Oracle 层无逻辑损坏-- 在主站点创建比较任务 BEGIN DBMS_COMPARISON.CREATE_COMPARISON( comparison_name DATA_DG_CHECK, schema_name SYS, object_name OBJ$, dblink_name STANDBY_SITE); -- 指向另一站点的数据库链接需提前建好 END; / -- 执行比较 DECLARE scan_info DBMS_COMPARISON.COMPARISON_TYPE; BEGIN DBMS_COMPARISON.COMPARE(DATA_DG_CHECK, scan_info); DBMS_OUTPUT.PUT_LINE(Scan ID: || scan_info.scan_id); END; / -- 查询差异 SELECT * FROM DBA_COMPARISON_SCAN_SUMMARY WHERE comparison_name DATA_DG_CHECK; -- 正常应返回 0 行无差异若有差异说明双活同步存在延迟或丢帧我坚持把这三步作为双活上线前的强制门禁。曾经有个项目存储厂商演示时一切正常但压力测试暴露了跨站点延迟抖动我们坚持要求其升级 HBA 固件并调整交换机缓冲区最终将 RTO 从 8.2 秒压到 1.3 秒。双活不是买设备送的配置文档它是需要你亲手拧紧每一颗螺丝的工程。希望帮到你。本文还有配套的精品资源点击获取
