简介：本资源是一份面向企业级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.1（Oracle 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/A） - Supported Oracle Versions: 明确列出
12.1.0.2+,19c - ASM Support: 标注
Yes，且注明ASM diskgroup creation and mount supported across Metro configuration
- Technology:
提示：若报告中仅写 “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 设备属性，确认 ALUA（Asymmetric 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 bs=4k count=1000 oflag=direct 2>&1 | 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*' scope=both; # 修改后重启 ASM 实例（注意：需停所有 RAC 实例）
参数说明：
/dev/mapper/mpath*是 multipath 生成的稳定设备名，不受底层 SCSI 设备名（sdX）变化影响。而/dev/sd*在双活路径切换时可能重映射（如原 sdg 变成 sdh），ASM 会认为磁盘丢失，触发灾难性重平衡。
3. ASM 磁盘组双活初始化：从 LUN 划分到磁盘组创建的六步闭环操作
双活存储的 LUN 必须由存储管理员在两个站点控制器上同时导出相同 WWN 的 LUN，并确保其在主机侧呈现为同一个 multipath 设备。任何一步偏差，都会导致 ASM 元数据分裂。
3.1 存储侧操作：LUN 导出必须满足“同 WWN、同容量、同属性”
以 Dell EMC PowerMax 为例（其他厂商逻辑一致）：
- 在 Unisphere 管理界面，进入
Storage > Block > Volumes - 创建新 Volume（LUN），设置：
- Capacity: 与目标 ASM 磁盘组需求一致（如 2TB）
- Volume Type:
Thin（推荐，避免空间浪费） - Host Group: 选择包含两个 RAC 节点的 Host Group（关键！不能只加一个节点）
- 在
Replication > Metro中，将该 Volume 加入 Metro Pair，并确认状态为Synchronized - 关键检查：在两个站点的 PowerMax 控制器上，执行
symcfg list -v，确认该 Volume 的WWN字段完全一致（16 进制字符串逐字相同）
注意：若两个控制器上 WWN 不同，主机 multipath 会识别为两个独立设备（如 mpatha 和 mpathb），ASM 将无法将其视为同一磁盘，后续创建磁盘组必失败。
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） KERNEL=="dm-*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="3600601609e0225001ecb4b6c1a2ae311", SYMLINK+="oracleasm/disk1" # 3. 重载 udev 并应用 sudo udevadm control --reload-rules sudo udevadm trigger --subsystem-match=block 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/*' SCOPE=BOTH; -- 再运行：SELECT path, header_status FROM v$asm_disk; -- 确保所有磁盘 header_status = 'CANDIDATE' 或 'MEMBER'参数说明：
EXTERNAL REDUNDANCY是双活前提——ASM 不做镜像，由存储阵列保障冗余；au_size=4M适配大块 I/O，提升双活跨站点吞吐；compatible.*必须与数据库版本严格匹配，否则 RAC 实例无法挂载。
4. RAC 实例挂载双活磁盘组：从 CRS 注册到服务高可用的完整链路
磁盘组创建成功 ≠ RAC 可用。必须确保 CRS（Cluster 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 必须启用 TAF（Transparent Application Failover）
即使 CRS 服务自动迁移，应用连接仍需主动重连。Oracle 官方要求应用层配置：
// JDBC 连接串示例（Oracle 19c JDBC Driver） String url = "jdbc:oracle:thin:@(DESCRIPTION=" + "(ADDRESS=(PROTOCOL=TCP)(HOST=scan-vip)(PORT=1521))" + "(CONNECT_DATA=(SERVICE_NAME=oltp_service)" + "(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180)(DELAY=5)))";关键点：
FAILOVER_MODE中TYPE=SELECT表示只对 SELECT 语句透明重试（INSERT/UPDATE 需应用层捕获 SQLException 重试）；RETRIES=180对应 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 bs=1024 count=100清除可能残留的旧 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-match=block； - 检查
/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_DEPENDENCIES=hard(ora.asm) weak(ora.net1.network)； - 若缺失，用
crsctl modify resource ora.storage -attr "START_DEPENDENCIES=hard(ora.asm)"修正。
5.5 现象：asmcmd lsdg显示磁盘组state=DISMOUNTED，但crsctl status显示资源 ONLINE
原因：ASM 实例内存中磁盘组状态与 CRS 记录不一致，常见于强制重启 ASM 后未清理 CRS 缓存。
解决：
- 手动
srvctl stop diskgroup -g DATA_DG； - 在所有节点执行
asmcmd umount DATA_DG（确保无进程占用）； srvctl start diskgroup -g DATA_DG；- 若仍失败，重启 CRS：
crsctl stop crs && crsctl start crs（需停整个集群）。
6. 验证双活真实有效性：用三类压力测试+日志分析，拒绝“界面显示正常”的玄学验收
配置完成不等于双活可用。必须用可量化的手段验证：I/O 连续性、故障切换时间、数据一致性。我一般会做这三件事，缺一不可。
6.1 持续 I/O 压力下模拟控制器故障：测 RTO（Recovery Time Objective）
在业务低峰期，用fio持续向 ASM 磁盘组写入：
# 在节点1执行（写入 DATA_DG 挂载点 /u01/oradata） fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=8k --size=1G \ --runtime=300 --time_based --group_reporting --filename=/u01/oradata/testfile- 同时，在存储管理界面，对当前主控制器执行
Graceful Shutdown（非断电）； - 用
iostat -x 1观察await：若峰值超过 100ms 且持续 >3 秒，RTO 超标； - 记录
fio日志中write: io=...的累计字节数，切换前后不应有丢包（fio默认sync=1，确保落盘）。
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.123+08:00: ASM: Disk group DATA_DG relocated to new storage path due to Metro failover # 2024-03-15T14:22:32.456+08: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 秒。双活不是买设备送的配置文档，它是需要你亲手拧紧每一颗螺丝的工程。希望帮到你。
本文还有配套的精品资源，点击获取
