简介面向需要搭建跨数据中心高可用Oracle环境的DBA和架构师系统讲解存储双活配置方案弥补传统RAC共享存储单点故障和ADG仅容灾的不足。压缩包内为单个docx文件大小约104KB目前已有149人学习。内容涵盖双活架构背景、前提条件与磁盘规划明确至少6块盘按AA/BB机房及仲裁ZC机房划分OCR和数据故障组并包含Grid Infrastructure安装、OCR磁盘组与DATA磁盘组创建、临时OCR迁移、votedisk替换、ASM SPFILE迁移等完整操作步骤同时给出后续磁盘扩容、平衡与日常维护要点。文档还提供关键SQL和命令行示例如CREATE DISKGROUP、ocrconfig、crsctl replace votedisk、asm_preferred_read_failure_groups设置以及Orion性能测试方法可帮助读者评估跨机房IO与Interconnect延迟影响并用于生产部署前的验证与调优。整体是一份可直接参考落地的解决方案指南。 凌晨1点47分电话把我从梦里拽出来。值班同事声音都在抖库起不来了存储控制器卡死所有LUN全部丢失。Oracle实例一个接一个夯住告警刷屏了。我边穿外套边问容灾呢不是有一套ADG吗他沉默了几秒日志断层了备库追不上。那天晚上我对着监控面板脑子里反复翻来覆去只有一个念头如果当初给这套核心库上了存储双活这个夜班根本不用过成这样。事后复盘我花了整整两个月把方案补上又花了三个月让它在各种故障场景里真正抗造。这篇东西就是给所有正在评估或准备落地Oracle存储双活的DBA、存储工程师和架构师看的从原理到步骤到坑一次讲透。1. 为什么Oracle要上存储双活一场RTO0的修行数据库最怕的不是性能瓶颈而是底层存储悄悄死掉。单存储架构下控制器故障、背板损坏、光纤交换机端口失效、固件bug导致LUN不响应任意一个发生数据库要么直接宕机要么进入半死不活的卡顿状态。传统做法是RMAN备份加ADG但备份恢复的时间单位是小时ADG虽然能把RTO压到分钟级却受制于网络延迟和日志传输的完整性极端情况下仍然可能丢数据。存储双活的思路完全不同。它的核心是让两台存储阵列同时对外提供读写服务数据在两端做实时同步复制任何一端故障另一端的LUN继续可见、可写主机上的Oracle几乎感知不到底层路径变化。只要配置得当RTO可以压缩到秒级甚至趋近于零RPO严格为零。对核心交易库、订单库、支付库来说这是普通容灾方案给不了的保障。Oracle对存储双活的要求比普通业务系统苛刻得多原因在于它的数据文件、控制文件、在线日志、归档日志必须处于一致的状态。如果复制是异步的故障瞬间必然丢IO数据库轻则需要实例恢复重则出现不可修复的逻辑损坏。所以Oracle场景下的存储双活必须走同步复制模式也就是每个写IO要同时落入两台存储的磁盘并返回成功主机才认为这个IO完成。做配置前第一件事就是在存储设备上确认复制模式是Sync而不是Async这个前提错了后面全白搭。维度存储双活ADG备份恢复RTO秒级业务几乎无感分钟级需激活备库小时级需恢复并前滚RPO零日志传输延迟内可能有少量丢失取决于备份策略通常小时级故障范围存储、交换机、主机路径数据库节点故障存储单点仍存在任何故障都能兜底但最慢人工介入很少自动切换需要手动激活或配置failover需要较长恢复流程投入成本高需要两套存储中一套备库存储低备份介质即可2. 开工之前的架构评估别把双活做成双挂2.1 三种主流双活形态选型对比存储双活不是只有一种实现方式市面上常见的能叫双活的架构大体分三类。第一类是存储网关双活比如在两套存储上层架设一个虚拟化网关把后端异构存储统一成一套逻辑卷再在网关层做镜像。好处是对底层存储品牌不挑剔能兼容老设备坏处是网关本身成了新的单点而且IO路径多一跳性能损耗不可忽视。第二类是存储原生双活现在主流厂商的中高端存储基本都内置了这种能力两台同品牌存储直接配对通过专用复制链路做同步镜像性能和稳定性最好配置也最直观。第三类是主机层镜像不依赖任何存储功能靠主机逻辑卷管理或数据库自身的扩展能力做镜像比如ASM的故障组设计但这种方案IO路径复杂、管理成本高在Oracle场景下一般只作为特殊需求的补充。我给大多数生产系统推荐的是存储原生双活 Oracle RAC ASM的组合。理由很简单路径短、延迟低、切换逻辑由存储和集群两层协同完成故障感知和IO接管都足够成熟。选型时要注意两台存储必须是同一品牌同一系列固件版本和微码版本要一致或兼容否则双活功能可能无法启用。双活形态优点缺点适用场景存储网关双活异构存储可接入保护旧投资网关单点风险性能有损耗跨越多个品牌存储的整合场景存储原生双活性能好切换成熟管理简单需同品牌同系列两套存储生产核心库首选方案主机层镜像不依赖存储功能管理复杂IO路径多运维成本高无法采购双活存储时的替代方案2.2 仲裁设计双活能不能在事故中活下来双活最怕的不是存储坏掉而是脑裂。想象一下两台存储之间的复制链路突然断了但双方都还活着于是各自认为对方已经故障同时接管同一个LUN的读写。如果此时主机同时向两端写数据数据立刻分叉等链路恢复后两边内容各不相同这场事故就没法收场了。为了避免脑裂双活架构必须引入仲裁机制。常见做法是部署一个独立的第三方仲裁节点两台存储通过心跳定时向仲裁上报状态。当一台存储联系不到对端时它不会立刻认为自己应该接管全部IO而是要先去问仲裁我是该成为主节点还是降级仲裁只能把唯一的主导权授予其中一方从而保证整个双活域只有一个数据出口。我在实际项目里吃过大亏。早期为了省事把仲裁节点放在了两台存储中的某一台上结果那台存储宕机时仲裁跟着一起没了剩下的存储因为拿不到仲裁结果直接进入保护模式拒绝所有写IO业务反而比单存储故障更早瘫痪。所以仲裁节点一定要放在独立的第三方位置可以是一台小型服务器、一个独立的管理存储或者是异地的轻量节点但绝不能复用生产存储节点。2.3 网络和主机环境底线存储双活对链路质量十分敏感因为每个写IO都要经过主机到存储A、存储A到存储B、存储B返回确认这条完整链路。往返时延必须控制得很低业界通常建议同步复制场景下端到端延迟小于1毫秒。超过这个值数据库的每次提交都会变慢用户能直观感受到系统卡顿。距离上同城双活一般控制在几十公里以内而且要采用专用的光纤或DWDM链路承载复制流量不要跟业务网络混跑。主机端的基础环境也要提前规范。每台数据库服务器至少要配两块独立的HBA卡分别连接到两台冗余的FC交换机再由两台交换机分别连接到两台存储。这样从主机到存储的每一段都有冗余路径任意一条链路断了多路径软件都能自动切换到其他路径不会中断数据库的IO。多路径软件的选择建议和存储品牌配套通常在存储驱动包里自带如果环境复杂也可以用操作系统自带的Device Mapper但配置时要特别注意路径优先级和failover策略否则切换时抖动时间会很长。3. 存储层配置从创建双活域到同步完成3.1 在存储管理台上创建双活域不同厂商的存储管理界面叫法不一样但配置流程大方向一致。首先要做的是把两台存储互相配对组成一个双活域。登录存储A的管理台找到双活或MetroCluster、Peer Persistence这类功能模块输入存储B的管理IP和管理凭据发起配对请求。存储B响应之后两台设备会建立管理通道并确认双方的设备型号、软件版本、License是否满足双活要求有一项不满足配对就会失败。配对成功后需要设置存储间心跳链路。这个心跳链路建议使用独立的物理链路不要和复制数据链路复用。复制链路用来同步IO数据要求带宽充足心跳链路只传状态信息带宽要求不高但必须稳定。有些存储支持一组心跳加两组复制链路的组合方案目的就是避免单一链路故障导致误判。心跳配置完成后把仲裁节点的地址填入系统存储会自动建立与仲裁节点的心跳整个双活域才算基本成型。从这个阶段开始所有操作都要在存储端的变更窗口内进行而且我建议每一步都在两台存储上分别截图留档。双活配置不像普通LUN创建改错了影响面是整个数据库系统出了问题想回退没有完整的操作记录会非常被动。3.2 一致性组Oracle恢复的救命稻草Oracle的数据文件、控制文件、在线日志通常分布在多个LUN上如果这些LUN各自独立做复制就可能出现存储A已经写入了日志文件、但数据文件还没复制完的情况。切换过去之后数据库启动时会发现日志比数据文件新必须做实例恢复更糟的可能是恢复过程中缺少某个关键IO直接导致数据不一致。一致性组就是解决这个问题的。它把一组LUN纳入同一份复制一致性快照中保证跨LUN的IO在执行切换时处于同一个时间点。配置双活时一定要把所有Oracle相关LUN全部塞进同一个一致性组数据文件卷、控制文件卷、在线日志卷、归档日志卷、OCR和Voting File所在的卷一个都不能漏。创建一致性组的操作大致如下以某主流存储的命令行风格为例品牌不同命令有差异# 在双活域内创建一个一致性组 create metro_consistency_group -name ORACLE_CG # 把双活LUN加入一致性组 add metro_lun -cg ORACLE_CG -lun lun_data_01 add metro_lun -cg ORACLE_CG -lun lun_data_02 add metro_lun -cg ORACLE_CG -lun lun_redo_01 add metro_lun -cg ORACLE_CG -lun lun_redo_02 add metro_lun -cg ORACLE_CG -lun lun_control_01 add metro_lun -cg ORACLE_CG -lun lun_arch_01 add metro_lun -cg ORACLE_CG -lun lun_crs_01 # 启用一致性组的同步复制 enable metro_sync -cg ORACLE_CG这里要特别提醒如果漏掉了归档日志卷虽然数据库平时不会出问题但一旦执行某些需要归档日志的恢复流程或者要启用备库就会因为归档不连续而失败。漏掉OCR和Voting File所在的卷则会让整个RAC集群在存储切换时陷入群龙无首的状态。3.3 全量同步与后续检查一致性组启用后存储会把原来两台存储上的LUN数据进行全量同步。这个过程中主端LUN的数据会整个复制到对端对于几TB的大库来说耗时会很长。全量同步期间业务照常运行但要注意对端存储的容量规划不能在同一时间并发太多其他任务否则会拖慢复制速度。同步状态可以在管理台上查看一般会有一个同步完成或一致的标志只有状态变为正常才说明双活配置真正生效。一个小技巧是全量同步跑完以后先不要急着上业务验证先把两端存储上LUN的序列号、WWID、容量全部比对一遍确认主机看到的设备在两端都一致。很多配置问题都藏在看起来一样、实际差一个字段的细节里。4. 主机侧接入让Oracle在双活LUN上稳稳跑起来4.1 多路径配置的要点主机通过两张HBA卡、两个FC交换机、两台存储一条LUN在主机上会呈现出多条路径。如果不做多路径聚合操作系统会把这些路径当成多个不同的磁盘Oracle根本没法稳定使用。多路径软件的作用就是把这些路径合并成一个逻辑设备并在路径故障时自动切换。以Linux自带的Device Mapper为例需要在/etc/multipath.conf里配置wwid和别名尽量让设备名稳定固定下来。一个典型的配置片段如下multipaths { multipath { wwid 3600508b1001c123456789abcdef alias oracle_data01 path_grouping_policy group_by_prio path_checker tur failback immediate path_selector round-robin 0 } }path_grouping_policy设置成group_by_prio是根据存储返回的路径优先级自动分组双活存储通常会返回两组路径一组优先一组备用这样可以做到主动优先路径路径故障时才切到备用。failback设置为immediate表示优先路径恢复后立刻回切避免长期跑在备用路径上性能不佳。很多生产事故出在配置完多路径后没有主动测试路径切换。我建议在窗口期内直接拔掉一条光纤观察multipath -ll的输出确认路径组是否正确failover然后插回光纤看能否自动failback。这个测试看起来粗暴但能把80%的配置问题在业务上线前暴露出来。4.2 设备权限绑定udev规则与ASM磁盘组设备名固定下来之后还要解决权限问题。ASM实例通常以grid用户运行磁盘设备必须保证grid用户可读写。重启服务器后/dev下的设备名可能会变所以推荐用udev规则按wwid绑定设备并设置权限和所有者。# /etc/udev/rules.d/99-oracle-asm.rules KERNELdm-*, PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT3600508b1001c123456789abcdef, \ OWNERgrid, GROUPasmadmin, MODE0660, SYMLINKoracleasm/oradata01这段规则的意思是匹配指定wwid的dm设备把它软链成oracleasm/oradata01并设置所有者和权限。配置完成后用udevadm trigger --typedevices --actionchange重新加载规则然后确认/dev/oracleasm/下面的软链是否出现。在双活环境下ASM磁盘组的冗余策略建议设置为external redundancy。因为双活本身已经在两块存储上做了镜像如果ASM再设置normal或high冗余相当于把数据复制了三份甚至更多白白浪费存储空间也会让写性能进一步下降。除非你真的需要同时忍受两台存储都故障的超低级容错否则external足够。4.3 Oracle数据库层的IO优化参数如果数据文件放在文件系统上比如OCFS2或Ext4数据库层的IO参数会影响双活的性能表现。强烈建议设置filesystemio_optionssetall这个参数允许Oracle跳过文件系统缓存使用异步IO直接读写设备能减少CPU开销和IO延迟。同时确认disk_asynch_iotrue这是异步IO的总开关很多场景下默认就是true但AIX和Solaris上偶尔会被隐式关闭需要检查。如果数据文件放在ASM里重点检查ASM实例的disk_repair_time参数。双活切换过程中路径抖动可能导致某个磁盘在短时间内被标记为offline如果disk_repair_time过短磁盘会在路径恢复前被强制dropASM磁盘组开始重新平衡整个集群性能瞬间跌落。我一般建议设置成8.5小时这样在存储切换和路径闪断时ASM有足够时间容忍磁盘短暂离线。5. 切换演练真金不怕火炼双活得用故障验证5.1 单存储故障的自动切换过程配置完成不等于万事大吉双活方案是否可靠只有通过实际断存储测试才能验证。上线后的第一个维护窗口我会组织一次完整的切换演练模拟A存储控制器故障让A存储整体无法对外提供服务。预想中的流程是这样的主机上的多路径软件最先感知到A存储路径全部失效IO自动切换到B存储路径双活存储检测到对端失去心跳通过仲裁确认自己是否接管数据库层面由于IO仍在持续、只是路径变了几乎无感。实际操作中数据库可能只会有一次极短的IO抖动体现在AWR里可能是一条log file sync等待的尖峰但业务不会中断。演练时要盯住几类日志数据库的alert日志、ASM的alert日志、/var/log/messages、以及存储端的事件告警。我遇到过案例存储切换本身很顺利但主机多路径软件因为之前的path_checker配置不对把本来是健康状态的B存储路径也误判失效导致IO中断了几分钟。这种问题只有通过实测才能暴露。5.2 故障恢复后的回切细节A存储修好之后不要急着把流量切回去。先让存储系统对A存储做增量反向同步也就是把A故障期间B存储上新写入的数据同步给A。这个过程同样要走一致性组保证两端数据完全一致。在同步状态达到最新的同步完成之前强行回切等于把数据回退到故障点必然丢数据。回切操作本身也要分步走。先把数据库的一个节点切换成优先访问A存储观察一段时间确认没有报错、性能正常再切换其他节点。我见过有人图省事一次性把双活域整体回切结果某条路径的优先级设置有误所有节点同时对A存储发起大量IO反而把刚修好的存储打挂了。谨慎一点按节点分批回切出问题有回退空间。5.3 脑裂场景模拟仲裁失效会怎样比单存储故障更极端的场景是两台存储之间的复制链路和心跳同时中断也就是完全断联。此时如果没有仲裁系统会进入自我保护模式某端存储自动停止对外提供写服务防止两边数据分叉。从业务角度看这表现为数据库写入超时或直接hang住直到管理员介入。模拟脑裂的正确姿势是同时断开两台存储间的复制链路和心跳链路但不拔掉主机到存储的路径然后观察存储会做出什么裁决。符合预期的情况下只有一方能继续提供服务另一方进入Secondary状态并拒绝读写。这个时候再恢复链路系统应该自动退出保护模式两端重新建立同步不需要人工去抢主导权。如果模拟结果不是这样说明仲裁配置有问题需要立刻排查。6. 踩坑记录与实战提醒6.1 控制文件跨双活LUN后重启数据库ORA-00214一次双活切演练结束后数据库重启时直接报ORA-00214控制文件与控制文件不一致。排查下来发现我把三个控制文件分别放在了不同的双活LUN上而这些LUN虽然都在同一个一致性组里但切换瞬间两个控制文件的更新进度出现了微小的差异。正常情况下这个差异几乎可以忽略但那次正好赶上切换和日志切换重叠控制文件头部的checkpoint信息出现了错位。解决方法是把控制文件收敛到一个双活卷内利用文件系统或ASM提供的多路径镜像来替代跨LUN的分散布局或者确保所有控制文件所在的LUN属于同一个一致性组并且同步模式设置为严格一致。说到底Oracle要求同一个数据库的所有控制文件必须完全一致双活并不能消除这个约束只是把故障概率缩小但代码逻辑层面该遵守的还是要遵守。6.2 ASM磁盘组在双活下的SCSI-3 PR锁问题RAC场景下的ASM磁盘组会使用SCSI-3 Persistent Reservation也就是持久锁来防止多个节点同时写入同一块磁盘。存储双活如果对SCSI-3 PR支持不完整或者仲裁切换过程中锁信息没有正确传递可能导致某个节点被强制驱逐出集群严重的时候整个集群都起不来。这个问题最容易出现在老版本存储的双活功能上。我遇到过一次节点A在存储切换后报ORA-15078或ASM error检查/var/log/messages才发现是PR锁被另一端的存储接管后没有释放。排障链路是先把ASM的磁盘扫描延时时长调大减少路径抖动对锁刷新造成的影响然后联系存储厂商确认该型号双活版本是否完整支持SCSI-3 PR。如果存储能力有限另一个思路是在ASM层让Voting File使用独立的、不参与双活的仲裁盘但这算是绕路方案能选存储原生支持PR的版本最好。6.3 双活不是备份必须保留的兜底手段存储双活解决的是存储硬件单点故障它解决不了误删表、恶意update少写where条件、逻辑损坏、勒索病毒、或者DBA手滑drop了分区这类问题。双活同步的是损坏后的数据一旦误操作发生损坏会以光速复制到两端连找回的机会都很少。所以双活上线之后原来的备份策略不但不能减反而要做加强。RMAN备份继续保留并且建议把部分归档日志单独通过远程复制通道传到异地作为逻辑错误的兜底。还可以在数据库层面开启闪回数据库或者闪回查询误操作时可以快速回退到过去某个时间点。监控上要盯住双活域的健康状态复制延迟、心跳状态、仲裁状态、链路误码率、两端存储的告警事件都应该进入统一的监控看板任何指标异常都能第一时间感知。我在实际维护中每个月会做一次双活状态的巡检统计复制延迟的峰值、检查两端存储空间余量、核对归档日志是否在该同步的卷上正常归档。半年做一次完整的切换演练每次演练后都记录新的问题。这套双活方案跑了快两年真正派上用场的是一个深夜的控制器升级事故——业务零中断告警只弹了一条多路径路径切换的通知。那时我才觉得当初熬的那几个月值了。本文还有配套的精品资源点击获取 Oracle存储双活实战：同步复制、一致性组与故障切换
简介面向需要搭建跨数据中心高可用Oracle环境的DBA和架构师系统讲解存储双活配置方案弥补传统RAC共享存储单点故障和ADG仅容灾的不足。压缩包内为单个docx文件大小约104KB目前已有149人学习。内容涵盖双活架构背景、前提条件与磁盘规划明确至少6块盘按AA/BB机房及仲裁ZC机房划分OCR和数据故障组并包含Grid Infrastructure安装、OCR磁盘组与DATA磁盘组创建、临时OCR迁移、votedisk替换、ASM SPFILE迁移等完整操作步骤同时给出后续磁盘扩容、平衡与日常维护要点。文档还提供关键SQL和命令行示例如CREATE DISKGROUP、ocrconfig、crsctl replace votedisk、asm_preferred_read_failure_groups设置以及Orion性能测试方法可帮助读者评估跨机房IO与Interconnect延迟影响并用于生产部署前的验证与调优。整体是一份可直接参考落地的解决方案指南。 凌晨1点47分电话把我从梦里拽出来。值班同事声音都在抖库起不来了存储控制器卡死所有LUN全部丢失。Oracle实例一个接一个夯住告警刷屏了。我边穿外套边问容灾呢不是有一套ADG吗他沉默了几秒日志断层了备库追不上。那天晚上我对着监控面板脑子里反复翻来覆去只有一个念头如果当初给这套核心库上了存储双活这个夜班根本不用过成这样。事后复盘我花了整整两个月把方案补上又花了三个月让它在各种故障场景里真正抗造。这篇东西就是给所有正在评估或准备落地Oracle存储双活的DBA、存储工程师和架构师看的从原理到步骤到坑一次讲透。1. 为什么Oracle要上存储双活一场RTO0的修行数据库最怕的不是性能瓶颈而是底层存储悄悄死掉。单存储架构下控制器故障、背板损坏、光纤交换机端口失效、固件bug导致LUN不响应任意一个发生数据库要么直接宕机要么进入半死不活的卡顿状态。传统做法是RMAN备份加ADG但备份恢复的时间单位是小时ADG虽然能把RTO压到分钟级却受制于网络延迟和日志传输的完整性极端情况下仍然可能丢数据。存储双活的思路完全不同。它的核心是让两台存储阵列同时对外提供读写服务数据在两端做实时同步复制任何一端故障另一端的LUN继续可见、可写主机上的Oracle几乎感知不到底层路径变化。只要配置得当RTO可以压缩到秒级甚至趋近于零RPO严格为零。对核心交易库、订单库、支付库来说这是普通容灾方案给不了的保障。Oracle对存储双活的要求比普通业务系统苛刻得多原因在于它的数据文件、控制文件、在线日志、归档日志必须处于一致的状态。如果复制是异步的故障瞬间必然丢IO数据库轻则需要实例恢复重则出现不可修复的逻辑损坏。所以Oracle场景下的存储双活必须走同步复制模式也就是每个写IO要同时落入两台存储的磁盘并返回成功主机才认为这个IO完成。做配置前第一件事就是在存储设备上确认复制模式是Sync而不是Async这个前提错了后面全白搭。维度存储双活ADG备份恢复RTO秒级业务几乎无感分钟级需激活备库小时级需恢复并前滚RPO零日志传输延迟内可能有少量丢失取决于备份策略通常小时级故障范围存储、交换机、主机路径数据库节点故障存储单点仍存在任何故障都能兜底但最慢人工介入很少自动切换需要手动激活或配置failover需要较长恢复流程投入成本高需要两套存储中一套备库存储低备份介质即可2. 开工之前的架构评估别把双活做成双挂2.1 三种主流双活形态选型对比存储双活不是只有一种实现方式市面上常见的能叫双活的架构大体分三类。第一类是存储网关双活比如在两套存储上层架设一个虚拟化网关把后端异构存储统一成一套逻辑卷再在网关层做镜像。好处是对底层存储品牌不挑剔能兼容老设备坏处是网关本身成了新的单点而且IO路径多一跳性能损耗不可忽视。第二类是存储原生双活现在主流厂商的中高端存储基本都内置了这种能力两台同品牌存储直接配对通过专用复制链路做同步镜像性能和稳定性最好配置也最直观。第三类是主机层镜像不依赖任何存储功能靠主机逻辑卷管理或数据库自身的扩展能力做镜像比如ASM的故障组设计但这种方案IO路径复杂、管理成本高在Oracle场景下一般只作为特殊需求的补充。我给大多数生产系统推荐的是存储原生双活 Oracle RAC ASM的组合。理由很简单路径短、延迟低、切换逻辑由存储和集群两层协同完成故障感知和IO接管都足够成熟。选型时要注意两台存储必须是同一品牌同一系列固件版本和微码版本要一致或兼容否则双活功能可能无法启用。双活形态优点缺点适用场景存储网关双活异构存储可接入保护旧投资网关单点风险性能有损耗跨越多个品牌存储的整合场景存储原生双活性能好切换成熟管理简单需同品牌同系列两套存储生产核心库首选方案主机层镜像不依赖存储功能管理复杂IO路径多运维成本高无法采购双活存储时的替代方案2.2 仲裁设计双活能不能在事故中活下来双活最怕的不是存储坏掉而是脑裂。想象一下两台存储之间的复制链路突然断了但双方都还活着于是各自认为对方已经故障同时接管同一个LUN的读写。如果此时主机同时向两端写数据数据立刻分叉等链路恢复后两边内容各不相同这场事故就没法收场了。为了避免脑裂双活架构必须引入仲裁机制。常见做法是部署一个独立的第三方仲裁节点两台存储通过心跳定时向仲裁上报状态。当一台存储联系不到对端时它不会立刻认为自己应该接管全部IO而是要先去问仲裁我是该成为主节点还是降级仲裁只能把唯一的主导权授予其中一方从而保证整个双活域只有一个数据出口。我在实际项目里吃过大亏。早期为了省事把仲裁节点放在了两台存储中的某一台上结果那台存储宕机时仲裁跟着一起没了剩下的存储因为拿不到仲裁结果直接进入保护模式拒绝所有写IO业务反而比单存储故障更早瘫痪。所以仲裁节点一定要放在独立的第三方位置可以是一台小型服务器、一个独立的管理存储或者是异地的轻量节点但绝不能复用生产存储节点。2.3 网络和主机环境底线存储双活对链路质量十分敏感因为每个写IO都要经过主机到存储A、存储A到存储B、存储B返回确认这条完整链路。往返时延必须控制得很低业界通常建议同步复制场景下端到端延迟小于1毫秒。超过这个值数据库的每次提交都会变慢用户能直观感受到系统卡顿。距离上同城双活一般控制在几十公里以内而且要采用专用的光纤或DWDM链路承载复制流量不要跟业务网络混跑。主机端的基础环境也要提前规范。每台数据库服务器至少要配两块独立的HBA卡分别连接到两台冗余的FC交换机再由两台交换机分别连接到两台存储。这样从主机到存储的每一段都有冗余路径任意一条链路断了多路径软件都能自动切换到其他路径不会中断数据库的IO。多路径软件的选择建议和存储品牌配套通常在存储驱动包里自带如果环境复杂也可以用操作系统自带的Device Mapper但配置时要特别注意路径优先级和failover策略否则切换时抖动时间会很长。3. 存储层配置从创建双活域到同步完成3.1 在存储管理台上创建双活域不同厂商的存储管理界面叫法不一样但配置流程大方向一致。首先要做的是把两台存储互相配对组成一个双活域。登录存储A的管理台找到双活或MetroCluster、Peer Persistence这类功能模块输入存储B的管理IP和管理凭据发起配对请求。存储B响应之后两台设备会建立管理通道并确认双方的设备型号、软件版本、License是否满足双活要求有一项不满足配对就会失败。配对成功后需要设置存储间心跳链路。这个心跳链路建议使用独立的物理链路不要和复制数据链路复用。复制链路用来同步IO数据要求带宽充足心跳链路只传状态信息带宽要求不高但必须稳定。有些存储支持一组心跳加两组复制链路的组合方案目的就是避免单一链路故障导致误判。心跳配置完成后把仲裁节点的地址填入系统存储会自动建立与仲裁节点的心跳整个双活域才算基本成型。从这个阶段开始所有操作都要在存储端的变更窗口内进行而且我建议每一步都在两台存储上分别截图留档。双活配置不像普通LUN创建改错了影响面是整个数据库系统出了问题想回退没有完整的操作记录会非常被动。3.2 一致性组Oracle恢复的救命稻草Oracle的数据文件、控制文件、在线日志通常分布在多个LUN上如果这些LUN各自独立做复制就可能出现存储A已经写入了日志文件、但数据文件还没复制完的情况。切换过去之后数据库启动时会发现日志比数据文件新必须做实例恢复更糟的可能是恢复过程中缺少某个关键IO直接导致数据不一致。一致性组就是解决这个问题的。它把一组LUN纳入同一份复制一致性快照中保证跨LUN的IO在执行切换时处于同一个时间点。配置双活时一定要把所有Oracle相关LUN全部塞进同一个一致性组数据文件卷、控制文件卷、在线日志卷、归档日志卷、OCR和Voting File所在的卷一个都不能漏。创建一致性组的操作大致如下以某主流存储的命令行风格为例品牌不同命令有差异# 在双活域内创建一个一致性组 create metro_consistency_group -name ORACLE_CG # 把双活LUN加入一致性组 add metro_lun -cg ORACLE_CG -lun lun_data_01 add metro_lun -cg ORACLE_CG -lun lun_data_02 add metro_lun -cg ORACLE_CG -lun lun_redo_01 add metro_lun -cg ORACLE_CG -lun lun_redo_02 add metro_lun -cg ORACLE_CG -lun lun_control_01 add metro_lun -cg ORACLE_CG -lun lun_arch_01 add metro_lun -cg ORACLE_CG -lun lun_crs_01 # 启用一致性组的同步复制 enable metro_sync -cg ORACLE_CG这里要特别提醒如果漏掉了归档日志卷虽然数据库平时不会出问题但一旦执行某些需要归档日志的恢复流程或者要启用备库就会因为归档不连续而失败。漏掉OCR和Voting File所在的卷则会让整个RAC集群在存储切换时陷入群龙无首的状态。3.3 全量同步与后续检查一致性组启用后存储会把原来两台存储上的LUN数据进行全量同步。这个过程中主端LUN的数据会整个复制到对端对于几TB的大库来说耗时会很长。全量同步期间业务照常运行但要注意对端存储的容量规划不能在同一时间并发太多其他任务否则会拖慢复制速度。同步状态可以在管理台上查看一般会有一个同步完成或一致的标志只有状态变为正常才说明双活配置真正生效。一个小技巧是全量同步跑完以后先不要急着上业务验证先把两端存储上LUN的序列号、WWID、容量全部比对一遍确认主机看到的设备在两端都一致。很多配置问题都藏在看起来一样、实际差一个字段的细节里。4. 主机侧接入让Oracle在双活LUN上稳稳跑起来4.1 多路径配置的要点主机通过两张HBA卡、两个FC交换机、两台存储一条LUN在主机上会呈现出多条路径。如果不做多路径聚合操作系统会把这些路径当成多个不同的磁盘Oracle根本没法稳定使用。多路径软件的作用就是把这些路径合并成一个逻辑设备并在路径故障时自动切换。以Linux自带的Device Mapper为例需要在/etc/multipath.conf里配置wwid和别名尽量让设备名稳定固定下来。一个典型的配置片段如下multipaths { multipath { wwid 3600508b1001c123456789abcdef alias oracle_data01 path_grouping_policy group_by_prio path_checker tur failback immediate path_selector round-robin 0 } }path_grouping_policy设置成group_by_prio是根据存储返回的路径优先级自动分组双活存储通常会返回两组路径一组优先一组备用这样可以做到主动优先路径路径故障时才切到备用。failback设置为immediate表示优先路径恢复后立刻回切避免长期跑在备用路径上性能不佳。很多生产事故出在配置完多路径后没有主动测试路径切换。我建议在窗口期内直接拔掉一条光纤观察multipath -ll的输出确认路径组是否正确failover然后插回光纤看能否自动failback。这个测试看起来粗暴但能把80%的配置问题在业务上线前暴露出来。4.2 设备权限绑定udev规则与ASM磁盘组设备名固定下来之后还要解决权限问题。ASM实例通常以grid用户运行磁盘设备必须保证grid用户可读写。重启服务器后/dev下的设备名可能会变所以推荐用udev规则按wwid绑定设备并设置权限和所有者。# /etc/udev/rules.d/99-oracle-asm.rules KERNELdm-*, PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT3600508b1001c123456789abcdef, \ OWNERgrid, GROUPasmadmin, MODE0660, SYMLINKoracleasm/oradata01这段规则的意思是匹配指定wwid的dm设备把它软链成oracleasm/oradata01并设置所有者和权限。配置完成后用udevadm trigger --typedevices --actionchange重新加载规则然后确认/dev/oracleasm/下面的软链是否出现。在双活环境下ASM磁盘组的冗余策略建议设置为external redundancy。因为双活本身已经在两块存储上做了镜像如果ASM再设置normal或high冗余相当于把数据复制了三份甚至更多白白浪费存储空间也会让写性能进一步下降。除非你真的需要同时忍受两台存储都故障的超低级容错否则external足够。4.3 Oracle数据库层的IO优化参数如果数据文件放在文件系统上比如OCFS2或Ext4数据库层的IO参数会影响双活的性能表现。强烈建议设置filesystemio_optionssetall这个参数允许Oracle跳过文件系统缓存使用异步IO直接读写设备能减少CPU开销和IO延迟。同时确认disk_asynch_iotrue这是异步IO的总开关很多场景下默认就是true但AIX和Solaris上偶尔会被隐式关闭需要检查。如果数据文件放在ASM里重点检查ASM实例的disk_repair_time参数。双活切换过程中路径抖动可能导致某个磁盘在短时间内被标记为offline如果disk_repair_time过短磁盘会在路径恢复前被强制dropASM磁盘组开始重新平衡整个集群性能瞬间跌落。我一般建议设置成8.5小时这样在存储切换和路径闪断时ASM有足够时间容忍磁盘短暂离线。5. 切换演练真金不怕火炼双活得用故障验证5.1 单存储故障的自动切换过程配置完成不等于万事大吉双活方案是否可靠只有通过实际断存储测试才能验证。上线后的第一个维护窗口我会组织一次完整的切换演练模拟A存储控制器故障让A存储整体无法对外提供服务。预想中的流程是这样的主机上的多路径软件最先感知到A存储路径全部失效IO自动切换到B存储路径双活存储检测到对端失去心跳通过仲裁确认自己是否接管数据库层面由于IO仍在持续、只是路径变了几乎无感。实际操作中数据库可能只会有一次极短的IO抖动体现在AWR里可能是一条log file sync等待的尖峰但业务不会中断。演练时要盯住几类日志数据库的alert日志、ASM的alert日志、/var/log/messages、以及存储端的事件告警。我遇到过案例存储切换本身很顺利但主机多路径软件因为之前的path_checker配置不对把本来是健康状态的B存储路径也误判失效导致IO中断了几分钟。这种问题只有通过实测才能暴露。5.2 故障恢复后的回切细节A存储修好之后不要急着把流量切回去。先让存储系统对A存储做增量反向同步也就是把A故障期间B存储上新写入的数据同步给A。这个过程同样要走一致性组保证两端数据完全一致。在同步状态达到最新的同步完成之前强行回切等于把数据回退到故障点必然丢数据。回切操作本身也要分步走。先把数据库的一个节点切换成优先访问A存储观察一段时间确认没有报错、性能正常再切换其他节点。我见过有人图省事一次性把双活域整体回切结果某条路径的优先级设置有误所有节点同时对A存储发起大量IO反而把刚修好的存储打挂了。谨慎一点按节点分批回切出问题有回退空间。5.3 脑裂场景模拟仲裁失效会怎样比单存储故障更极端的场景是两台存储之间的复制链路和心跳同时中断也就是完全断联。此时如果没有仲裁系统会进入自我保护模式某端存储自动停止对外提供写服务防止两边数据分叉。从业务角度看这表现为数据库写入超时或直接hang住直到管理员介入。模拟脑裂的正确姿势是同时断开两台存储间的复制链路和心跳链路但不拔掉主机到存储的路径然后观察存储会做出什么裁决。符合预期的情况下只有一方能继续提供服务另一方进入Secondary状态并拒绝读写。这个时候再恢复链路系统应该自动退出保护模式两端重新建立同步不需要人工去抢主导权。如果模拟结果不是这样说明仲裁配置有问题需要立刻排查。6. 踩坑记录与实战提醒6.1 控制文件跨双活LUN后重启数据库ORA-00214一次双活切演练结束后数据库重启时直接报ORA-00214控制文件与控制文件不一致。排查下来发现我把三个控制文件分别放在了不同的双活LUN上而这些LUN虽然都在同一个一致性组里但切换瞬间两个控制文件的更新进度出现了微小的差异。正常情况下这个差异几乎可以忽略但那次正好赶上切换和日志切换重叠控制文件头部的checkpoint信息出现了错位。解决方法是把控制文件收敛到一个双活卷内利用文件系统或ASM提供的多路径镜像来替代跨LUN的分散布局或者确保所有控制文件所在的LUN属于同一个一致性组并且同步模式设置为严格一致。说到底Oracle要求同一个数据库的所有控制文件必须完全一致双活并不能消除这个约束只是把故障概率缩小但代码逻辑层面该遵守的还是要遵守。6.2 ASM磁盘组在双活下的SCSI-3 PR锁问题RAC场景下的ASM磁盘组会使用SCSI-3 Persistent Reservation也就是持久锁来防止多个节点同时写入同一块磁盘。存储双活如果对SCSI-3 PR支持不完整或者仲裁切换过程中锁信息没有正确传递可能导致某个节点被强制驱逐出集群严重的时候整个集群都起不来。这个问题最容易出现在老版本存储的双活功能上。我遇到过一次节点A在存储切换后报ORA-15078或ASM error检查/var/log/messages才发现是PR锁被另一端的存储接管后没有释放。排障链路是先把ASM的磁盘扫描延时时长调大减少路径抖动对锁刷新造成的影响然后联系存储厂商确认该型号双活版本是否完整支持SCSI-3 PR。如果存储能力有限另一个思路是在ASM层让Voting File使用独立的、不参与双活的仲裁盘但这算是绕路方案能选存储原生支持PR的版本最好。6.3 双活不是备份必须保留的兜底手段存储双活解决的是存储硬件单点故障它解决不了误删表、恶意update少写where条件、逻辑损坏、勒索病毒、或者DBA手滑drop了分区这类问题。双活同步的是损坏后的数据一旦误操作发生损坏会以光速复制到两端连找回的机会都很少。所以双活上线之后原来的备份策略不但不能减反而要做加强。RMAN备份继续保留并且建议把部分归档日志单独通过远程复制通道传到异地作为逻辑错误的兜底。还可以在数据库层面开启闪回数据库或者闪回查询误操作时可以快速回退到过去某个时间点。监控上要盯住双活域的健康状态复制延迟、心跳状态、仲裁状态、链路误码率、两端存储的告警事件都应该进入统一的监控看板任何指标异常都能第一时间感知。我在实际维护中每个月会做一次双活状态的巡检统计复制延迟的峰值、检查两端存储空间余量、核对归档日志是否在该同步的卷上正常归档。半年做一次完整的切换演练每次演练后都记录新的问题。这套双活方案跑了快两年真正派上用场的是一个深夜的控制器升级事故——业务零中断告警只弹了一条多路径路径切换的通知。那时我才觉得当初熬的那几个月值了。本文还有配套的精品资源点击获取