简介面向跨数据中心 Oracle 数据库高可用场景这份指南系统讲解了存储双活方案的配置方法适合 DBA、运维工程师及架构师参考。内容从 RAC 依赖共享存储和 ADG 仅限数据级容灾的局限切入说明双活架构如何借助跨机房间共享存储与仲裁机制保持业务连续随后围绕 6 块磁盘规划、正常冗余 OCR 与 DATA 磁盘组创建、votedisk 迁移、ASM SPFILE 调整等关键步骤展开并特别说明 OCR 磁盘组需划分 AA/BB 两个故障组和 QUORUM 仲裁故障组DATA 磁盘组也按双故障组设计以应对单机房故障。全文同时强调跨机房网络时延与 IO 性能需严格测试并给出 Orion 读写测试流程与结果参考。全包只有 1 个 docx 文档压缩后约 104KB图文形式便于查阅包含可落地的命令示例与配置注意事项。通过阅读这份指南可掌握从磁盘规划、集群安装到性能验证的完整链路辅助规避跨机房部署常见的时延与切换风险。已有 150 人学习下载适合作为高可用方案评估和双活部署的参考。1. 存储双活配置指南先想清楚它是高可用方案还是容灾方案很多从业者第一次拿到存储双活配置指南都默认它是现成的高可用解决方案按文档把两套存储配对、把 Oracle RAC 数据文件放上去就算双活了。我拆过好几个这类项目真实情况是存储双活解决的是存储设备层面 RPO0、RTO 分钟级的问题不解决集群层面的脑裂与节点驱逐配置错一个仲裁参数双活就变成“双写”两端数据各写一半。这份指南适合 DBA、存储工程师以及做数据库高可用选型的人。它把存储双活与 Oracle RAC 叠加时的那层边界讲清楚哪些冗余由存储承担哪些必须由集群自己兜底。2. 双活架构选型同步复制、仲裁机制与 RAC 的配合关系2.1 同步复制才是真双活延迟预算怎么算双活这个词被用烂了。很多方案把异步复制也叫双活实际上异步复制下备站点数据落后主站点几十秒甚至几分钟连 RPO0 都保证不了严格说只能叫容灾不能叫双活。真正的存储双活写 IO 要同时落到两个站点的存储缓存里两个站点都确认以后这个 IO 才算完成这就是同步复制。同步复制的代价是延迟。一次写 IO 的完整延迟等于本地写缓存时间加网络往返时间加远端写缓存时间。光纤里的光速大约是二十万公里每秒站点间距离十公里时一个往返的传播延迟只有零点几毫秒加上两端的交换器转发延迟总往返在 0.3 到 0.5 毫秒这个量级对 Oracle 在线交易影响还能接受。但站点距离拉到一百公里往返延迟就到了三到五毫秒redo log 相关的 log file sync 等待会明显上涨。所以这份指南里第一步就是量距离、划延迟预算而不是直接开始配存储。我一般按这个公式评估业务提交峰值频率乘以每次提交的日志量再乘 1.3 的协议开销系数得出同步链路需要承载的每秒写字节数再对照实际链路带宽。如果业务峰值写带宽已经占到链路带宽的四成以上双活方案就得重新考虑否则峰值期链路排队会把整体延迟翻倍。这是双活项目里最常见的选型失误存储工程师只盯着容量和 IOPS没有看同步写延迟和带宽余量。异步与同步的适用边界可以简单压成一张表复制类型RPO适用距离典型场景同步复制0100 公里内视延迟而定双活、同城容灾异步复制秒到分钟级不限异地容灾、备份中心2.2 仲裁与脑裂防护没有第三方仲裁的双活是赌运气双活系统最怕的不是一台存储坏掉而是两站之间的链路断了。链路一断两个站点的存储都觉得自己还活着数据库节点也都活着两边同时接收写请求数据就开始分叉这就是脑裂。解决脑裂的办法只有一样东西仲裁。让其中一边立刻放弃写服务而不是两边都继续跑。仲裁的典型做法是第三地仲裁服务器或者仲裁盘。仲裁服务器不参与业务 IO只负责在链路断开时投票决定哪个站点继续服务。配置时要确认三个参数仲裁心跳超时、仲裁不可达时的失效策略、首选站点。失效策略一般有 fail to site A、fail to site B、保持现状三种。生产环境我很少推荐“保持现状”因为现状就是两边都写比停掉一个站点还要危险。有个容易忽略的坑仲裁服务器和站点 A 放在同一个机房。站点 A 断电时仲裁跟着断剩下站点 B 拿不到仲裁结果好一点的系统自动停服差的系统干脆拒绝切换。指南里对仲裁部署写得很明确仲裁节点必须与两个业务站点形成三边关系不能挂在任何一边。我见过为省一台机器把仲裁塞进主站点的案例后来机房检修停电整库停了四个小时这是典型的把后悔药提前吃掉。仲裁决策流我会在演练脚本里固化成检查清单先看仲裁进程再看双方网络心跳最后才允许动存储方向顺序乱了切换动作本身就会变成事故源。2.3 双活存储叠加 RAC两层冗余的分工边界存储双活给 Oracle RAC 提供的是“两个站点都能读到相同数据块”的底层视图。两个站点各有一组 RAC 节点共用同一套 LUN看起来所有节点都连在一个存储上。但这套组合里有个必须讲清楚的分工数据块的最新版本怎么同步靠的是 RAC 的缓存融合不是存储双活。节点 A 改了某个数据块节点 B 要读到最新版本是通过集群互联把这个块传过去这是 RAC 自己的机制。存储双活只保证磁盘上的数据两边一致管不到内存里的状态。所以双活存储永远替代不了 RAC 的私网心跳也不能因为有存储双活就砍掉集群互联链路的冗余。反过来RAC 缓存融合也替代不了存储双活节点迁移、ASM 扩展、存储设备整体故障最终还是落在磁盘层的数据一致性上。这两层冗余叠加时最需要决策的是冗余嵌套方式双层都做镜像还是只保留一层。常见做法是存储双活承担同步复制、ASM 用外部冗余避免写一次数据却付两倍 IO 的代价另一条路线是存储各自独立、ASM 用正常冗余但站点故障时另一站点根本没有可切换的数据视图只能靠数据库级复制兜底严格说已经不是双活。这两种选型会明显影响后面的磁盘组设计和性能表现我把它放在第 4 章展开。另外提醒一句双活存储的管理界面和 RAC 集群的告警是两套系统生产里必须把两边的时间轴关联起来看否则链路抖动时存储侧已经在切换、集群侧还在傻等问题会被掩盖到爆发那一刻。3. 存储侧配置落地多路径参数、一致性组与链路预算3.1 多路径配置multipath.conf 里的四个关键项双活存储的 LUN 在两个站点都有控制器路径服务器上看到的同一个 LUN 会带多组路径。多路径软件的任务是把这些路径合并成一个设备让 IO 在正常时分散、故障时快速切换。我在 /etc/multipath.conf 里先定四件事路径分组、路径选择策略、故障恢复策略、无路径时的行为。defaults { path_grouping_policy group_by_prio path_selector round-robin 0 failback immediate no_path_retry 5 rr_min_io 16 } multipaths { multipath { wwid 3600000abcd1234 alias oradatalun1 path_grouping_policy group_by_prio path_selector round-robin 0 failback immediate no_path_retry 5 } }group_by_prio 表示按存储返回的优先级把路径分组双活存储会给两个站点控制器设置不同的 priority多路径据此把路径分成两组优先走优先级高的那组。path_selector 用 round-robin让 IO 在组内轮询这个选择器在数据库这种均匀块大小场景下表现稳定。failback 设 immediate 指路径恢复后立刻回到优先级高的组但如果两个站点优先级设计得不合理failback 会引起路径频繁倒换我见过生产环境里改成 failback 120 来压住抖动的这里建议上线前实测再定。no_path_retry 是最需要想清楚的参数。设 queue 表示所有路径都掉时 IO 无限排队Oracle 侧表现为 IO 长时间挂起很快触发磁盘超时与节点驱逐设 5 表示重试五次后把错误返回上层数据库能快速感知路径故障并触发 ASM 的盘离线逻辑。两个值没有绝对好坏但如果 RAC 已经配了 disktimeout我建议不要设 queue让错误尽快上抛把决策权交还给集群层。另外多路径的路径探测轮询间隔默认偏长路径恢复后要等好几轮探测才被识别期间业务都压在其中一组路径上负载分布是歪的。我把 polling_interval 参数调小到 3 秒代价是 CPU 多一些换来的是故障切换路径的时间窗明显缩短。3.2 一致性组与故障域规划先画图再下手双活存储上不会只放一个 LUN一套数据库少则十几个数据文件 LUN多则几十个。这些 LUN 必须放进同一个一致性组存储层面才能保证跨 LUN 的写顺序一致。一致性组的作用是保证站点切换后数据库文件在某个时间点上是一致的不会出现数据文件是新版本、控制文件却是旧版本的局面。规划时我一般按这个顺序做第一步把所有数据库相关 LUN 按用途列出来但最终一定要放进同一个一致性组因为数据文件和在线日志是强关联的第二步每个站点定义一个故障域LUN 在两个站点各有一份视图第三步给一致性组绑定仲裁策略明确首选站点第四步给整个组挂独立的快照计划。关键项可以用下面的表一次性定下来规划项具体做法说明一致性组一套库的所有 LUN 放同一个组控制文件、数据文件、在线日志必须同组故障域每个站点一个故障域站点级故障时能整体切换仲裁归属一致性组绑定仲裁策略防止链路断后组内 LUN 各自为政快照策略每个一致性组挂独立快照双活失效时用于快速回退故障域这步最容易做错有人把同站点内的两块盘划成两个故障域站点故障时存储无法判断要切哪个域切换动作拖到超时。正确做法是故障域边界与站点边界对齐一个站点一个域。另外在线日志和归档日志必须与当前数据文件在同一一致性组否则 failover 后介质恢复到一半归档日志断了就只能做不完全恢复RPO 就不再是零。这个点我每次验收都专门查一遍因为它在存储管理界面里很隐蔽报错要等到切换那刻才出现。3.3 缓存策略与链路预算别只盯容量存储双活的写缓存默认镜像到对端缓存策略一般不用改需要改的是刷盘方式和延迟阈值。生产库建议写缓存优先性能好但要清楚缓存镜像期间任一端缓存损坏数据从镜像的另一端重建。如果存储管理界面能看到“同步写延迟”这个指标给它设告警阈值超过 3 毫秒开始关注持续超过 5 毫秒说明链路或对端控制器已经有压力。链路带宽预算我习惯这样粗算假设业务峰值每秒 12000 个写 IO平均块大小 8KB写比例 70%数据面写带宽大约是 12000 × 8KB × 70% ≈ 66MB/s加上多路径与协议头部开销乘 1.3 系数约 86MB/s。双活同步复制要在站点间再传一份同样大小的流量所以站点间链路至少按 170MB/s 以上规划同时必须是物理双链路。这里还没算 ASM 重平衡、备份恢复、批量作业这类突发流量生产里我再留 50% 余量。链路不够的典型症状是故障切换后恢复同步要花几小时业务写 IO 占满带宽同步队列越拉越长。提示同步延迟不是静态值。建议上线前跑一次峰值压测把全天写带宽曲线拉出来对照链路预算表看峰值点是否超过预留带宽的七成。4. Oracle 侧落地ASM 磁盘组、集群参数与切换顺序4.1 ASM 磁盘组冗余级别双活该配 external 还是 normal存储双活已经做了一层同步复制ASM 再配 normal redundancy 就是双层镜像。写一个数据块存储层写两端、ASM 层再写两份实际落盘四份写放大直接翻倍性能损失明显。所以双活存储加 RAC 的主流组合是 ASM 用 external redundancy把冗余职责完全交给存储层。CREATE DISKGROUP ORADATA EXTERNAL REDUNDANCY DISK /dev/mapper/oradatalun1 NAME ORADATA_1, /dev/mapper/oradatalun2 NAME ORADATA_2 ATTRIBUTE compatible.asm 19.0.0, compatible.rdbms 19.0.0;external redundancy 表示 ASM 不做镜像磁盘组里每块盘都是唯一副本。compatible.asm 和 compatible.rdbms 建议创建时一次定死后面升级数据库时不用再动。注意 external 冗余下任何一块盘离线ASM 会立刻把盘置为 offline 并可能触发强制 dismount所以多路径的 no_path_retry 必须和 ASM 磁盘超时行为对齐否则存储路径闪断会被 ASM 当成整盘丢失。创建磁盘组之前还要确认 asm_diskstring 指向的设备路径能同时发现两站点路径ASM 日志里常见的问题是只扫到一端路径磁盘组建起来了另一端却看不见盘。磁盘组创建完我习惯用 v$asm_disk 查一遍每块盘的状态确认两站点路径都能看到且 mode_status 是 ONLINE。如果某块盘在另一站点侧路径显示 OFFLINE多半是存储映射没放通趁业务还没进来提前排查。另一条路线是 ASM normal redundancy、存储各自独立这套方案性能好、不依赖站点间网络但站点故障时另一站点没有可切换的数据视图已经不是双活。所以这份指南的场景下我把 normal redundancy 列为不推荐选项。最后提醒一点ASM 重平衡会在双活存储上产生额外写流量在线加盘或 rebalance 要避开业务峰值提前确认链路带宽预算有富余。4.2 集群关键参数misscount、disktimeout 与互联心跳RAC 集群节点分布在两个机房时集群参数要和存储故障时间线对齐。misscount、disktimeout、diagwait 三个参数决定了从“存储路径抖动”到“节点被驱逐”的整段时间窗口默认值偏保守生产库建议按下表调整参数作用推荐值调整说明disktimeout磁盘 IO 挂起判定时间200 秒存储双活路径切换一般 10-30 秒留足余量misscountCSS 心跳丢失次数阈值60 秒跨站点网络抖动时避免误驱逐diagwait节点驱逐后诊断信息收集窗13 秒配合 misscount 调整避免诊断文件互相覆盖互联链路缓存融合专用网络独立冗余链路不能和业务 VLAN 混跑调整这些参数前要先做链路抖动测试。拔掉存储侧一条光纤再插回去记录多路径切换耗时再看集群日志里有没有 CSS 心跳告警最后才决定 misscount 要不要调大。经验是disktimeout 要大于多路径切换时间misscount 要大于存储切换时间两条时间轴不能错位否则会出现存储还没切完、数据库节点先被踢掉的局面。互联心跳这一项没有统一参数但有一条铁律缓存融合流量必须走独立冗余链路即使只有 10G 带宽也够用但必须与业务流量物理隔离。我处理过一个案例互联心跳和业务网共用一台交换机半夜业务高峰时交换机缓冲溢出两个节点同时丢心跳整库脑裂这个翻车点最不值得。每次验收我也优先查这个比查参数配置更优先。4.3 切换与回切脚本控制服务启动顺序切换演练是双活项目必修课。推荐的顺序是先把集群整体停掉再做存储方向切换最后在目标站点启动集群避免两头都在写的时候切换存储方向。# 在 A 站当前主站执行优雅停整个集群 crsctl stop cluster -all crsctl stat cluster -all # 确认集群完全停止后在存储侧执行双活方向切换 # 假设使用存储自带的双活管理 CLI切换方向到 B 站 # storagecli switchover --target-site B --consistency-group ORADATA # 在 B 站节点执行启动集群 crsctl start cluster -n bnode1,bnode2 crsctl stat res -tcrsctl stop cluster -all 会让节点先停资源再停 CSS正常情况不需要 -f。存储侧方向切换命令各家不一样我用注释形式代替实际执行前务必确认切的是整个一致性组而不是单个 LUN。启动集群后重点看三件事所有资源 online、VIP 飘到 B 站、ASM 磁盘组正常 mount。切换完成后我会按清单确认crsctl stat res -t 里 oracle 相关资源全部 ONLINEcrsctl stat cluster -all 显示节点数量正确v$asm_diskgroup 的 state 符合预期最后用 sqlplus 做一次 DML 冒烟再恢复业务流量。恢复业务后还要看存储侧同步延迟是否降回正常。回切流程刚好相反先在 B 站停集群把存储方向切回 A再启动 A 站。有个容易忽略的细节回切前要保证 B 站的在线日志已归档并且完整刷盘否则 A 站拿到的数据视图可能是 B 站断电瞬间的缓存状态。这个顺序我每次都写进演练脚本防止有人图省事直接热切。热切看着快实际是把两个站点同时置于可写状态风险最大。5. 常见问题与避坑五个让双活变单活的真实场景5.1 光纤抖动一次两个节点同时重启现象存储控制器升级时拔错一根光纤现场数据库两个节点几乎同时重启应用彻底停掉alert 日志里全是 CSS 心跳丢失与节点驱逐记录。原因光纤抖动引起存储路径瞬断多路径切换路径的几秒内产生 IO 延迟同时 RSS 网络心跳也受到干扰两个判断条件叠加CSS 判定节点失败。两个站点节点同时命中同一抖动源集群失去法定节点数只能重启。解决把存储设备变更纳入数据库变更管理变更窗口一次只动一个站点的链路。多路径层把路径轮询间隔调短让 IO 在一两秒内切到备用链路同时把 disktimeout 和 misscount 的时间轴对齐给存储切换留出余量。事后排查时我看三个时间线multipathd 的路径切换记录、cssd 日志的心跳丢失时刻、alert 日志的 IO 超时时刻一核对根因就清楚了。从那以后我在每个双活项目上线前都安排一次链路抖动演练不做这个测试不验收。5.2 仲裁配置错位链路断开后出现双写现象站点间一根核心光纤损坏两站点存储同时显示 active数据库两端同时接受写入恢复时两端数据对不上只能靠备份回退RPO 变成几小时。原因仲裁服务器部署在 A 站机房A 站断电路时仲裁下线B 站失去仲裁依据。链路恢复后 A 站带着陈旧数据重新加入同步系统没有自动做增量修复。双写比单点故障更麻烦的地方在于两边的 redo 序列都对不上哪边都不愿意让步谁恢复到最后都缺另一边那部分提交。解决仲裁必须部署在与两个站点平级的第三位置仲裁心跳超时设成比业务链路抖动容忍时间略长。每次演练都要做一次拉掉站点间链路的专项测试确认仲裁正确裁定胜负再恢复链路。仲裁日志保留切换后第一时间核对胜出站点与预期一致。我还要求存储管理界面的仲裁状态页在每次切换后截图留档出现分歧时这是最有说服力的证据。5.3 强行 force mount数据文件一致性校验不通过现象A 站存储故障后B 站 ASM 磁盘组 mount 失败DBA 用 alter diskgroup ... force mount 强挂随后 dbv 校验数据文件报大量一致性错误。原因force mount 跳过的只是 ASM 元数据检查不代表数据文件逻辑一致。A 站故障瞬间写缓存里可能还有未刷盘的已提交数据B 站存储视图虽然是同步完成的但数据库层面的数据文件与在线日志可能处于同一瞬间的不同状态需要介质恢复而不是直接强挂。解决切换后第一件事是用两端可用的 redo 判断能否做介质恢复而不是 force mount。正确顺序是确认双活存储状态为同步完成检查两端 LUN 序列号一致让 ASM 正常 mount实在不行从一致性组快照恢复快照没有再用备份。force mount 只在确认数据源干净时使用。这是我见过恢复事故里最冤的一种明明有完整的 redo 链结果一次 force mount 把恢复路径堵死了。5.4 两站点时间偏差SCN 跳变告警刷屏现象切换后 alert 日志大量出现与 SCN 校验相关的内部错误告警AWR 报告里 SCN 数值异常增大数据库性能明显下降。原因两个站点的 NTP 配置来源不一致或者其中一台服务器时间被手动调过站点间时钟偏差超过允许范围Oracle 的 SCN 推进机制被干扰。解决两站点的全部节点统一使用同一个 NTP 源配置 chrony 自动校时并开启闰秒处理策略。切换演练脚本加一步强制校时在停库窗口里用 date 对比两端节点时间差超过 1 秒先停下来校正。我还会在每次切换后检查各节点 NTP 偏移量顺便查 AWR 中 SCN 增长速率是否回到正常区间确认无误再放开应用访问。这个问题不出事则已一出事就是全库范围的性能劣化排查起来非常费劲。5.5 回切后复制状态卡在“同步中”下次切换失败现象一次切换演练结束后双活存储界面显示复制对状态一直是“同步中”持续几小时不变。第二次切换时存储直接报错无法切换方向。原因演练回切时业务流量已经全部回到 A 站B 站的复制对里还有增量数据没追平此时有人手动改了其中一个 LUN 的映射关系复制对的一致性被破坏存储无法自动重新同步。解决回切后必须检查每个一致性组的同步状态和延迟值确认掉队量为零再撤掉演练环境。LUN 映射关系变动必须走变更单复制对开启自动重建策略。我在演练清单里加了最后一项回切完成两小时后再次巡检同步状态用 multipath -ll 对比两端看到的 wwid确保映射没有串位防止演练完两三天才发现同步没追完的坑。这类问题平时静默只在下次真正需要切换的时候爆发属于最高危的隐患类型。6. 验证双活的最后一公里故障注入与数据一致性校验配置做完、能正常读写只能说明系统是通的说明不了双活真能扛住故障。最后一公里是故障注入。按从低到高的破坏度我给客户做验收时依次执行四个动作断开一条光纤路径观察多路径是否在数秒内切换强制一台存储控制器的缓存写错观察数据是否从另一站点缓存重建拉掉两站点间全部链路观察仲裁是否在预期时间内裁定胜负最后做一次完整站点断电从应用停止到数据库恢复可写全程记录恢复时间。每个动作结束都要做数据校验不能只看存储界面显示“同步正常”。数据库层面的校验我用两个动作一是用 dbv 对关键表空间做物理校验二是把两站点的归档日志完整对比一遍确认归档连续、无缺口。数据校验不能压缩成一句“应用正常”应用正常只代表能连上不代表数据一致。还有一个我认为最实用的验证技巧在验证窗口里对 ASM 磁盘组发起一次在线 rebalance人为制造大量写流量同时观察存储双活的同步延迟曲线。如果延迟稳定在 1 毫秒以内说明链路带宽余量充足如果延迟随 rebalance 飙升到 5 毫秒以上说明链路已经到瓶颈必须加带宽再测一次。这个办法等于给双活存储做一次压力测试不用额外工具靠数据库自身行为就能看出边界。双活系统真正的风险从来不在配置文档里而在每条路径故障后的实际行为。从那以后我在每个存储双活项目验收时都强制走一遍故障注入清单不再只看存储管理界面那四个字的“同步正常”。希望帮到你。本文还有配套的精品资源点击获取
