5.2 数据保护与复制

5.2 数据保护与复制

本节摘要：Data Guard 用一份实时同步的物理副本，把"备份要到恢复时才知道行不行"变成"故障当场就有热替身"。本节讲清备库的同步原理、三种保护模式的定价逻辑，并给出一次完整的主备切换彩排步骤——切换是技能，切回也是。

从一次机房断电演练说起

5.1 的备份体系能保证数据不丢，但恢复要用小时计。业务方很快会问第二个问题：能不能不停？答案是搭一个"影子库"——Data Guard 让主库把归档（或重做）实时发给备库，备库持续应用，两边数据几乎零距离。主机宕了，备库几分钟内顶上；平时的备份、重报表也都可以甩给备库跑。这一节把这套体系从原理到彩排拆开。

一、备库在干什么：两种应用模式

物理备库与主库块对块一致，靠两个持续运转的动作活着。传输：主库的日志写进程（或专门的传送进程）把重做实时送到备库，备库先落成待用日志；应用：备库的应用进程把待用日志重演成数据变更。应用模式有两种脾气：已应用模式一边收一边重演，备库始终可查询（打开为只读），报表随便跑，但重演到一半的数据可能比主库慢几秒到几分钟；实时应用则是极限追赶，主备延迟以秒计。开放只读的备库叫活动 Data Guard，是"一份数据两份算力"的经典用法——但要记住备库上的负载本身也消耗重演能力，备库跑爆了主库切换过去就是接盘一个病库，备库负载也要做容量规划。

图 5-2：Data Guard 传输与应用链路

（主库日志流向备库的两级流水与保护模式的位置，见下方时序）

二、三种保护模式：给"不丢"定价

Data Guard 的三种保护模式回答同一个问题的三种报价：你能接受主库为保护备库付出多少性能代价？

• 最大性能（默认）：主库不等备库确认，异步发送。主库性能零损耗，代价是主库故障瞬间最后一段重做可能没送达——RPO 大于零（通常秒级，网络正常时接近零）。绝大多数业务的选择。
• 最大可用：正常时同步等确认（RPO 为零），备库断了就自动降级回异步，不拖死主库。"平时不丢、极端时认命"的折中。
• 最大保护：强制同步，备库确认前主库不提交。RPO 严格为零，代价是备库或网络一抖，主库直接停写。金融核心账务在双中心光纤冗余充足时才敢用。

选型的判断句式很朴素：先问业务"丢几秒数据赔多少钱"，再问网络"抖动概率多高"，两个答案对进表格里，档位自己浮出来。怕的是反着来——拿着模式找场景，把最大保护配在跨省网络上，主库三天两头停写。

三、切换彩排：一次完整的角色互换

切换（Switchover）是计划内的角色互换：主变备、备变主，用于演练、升级、机房维护。与故障转移（Failover，主库没了被迫扶正备库）不同，切换可逆、不丢数据。标准步骤如下：

-- 主库：确认无gap，切换为备库角色
SELECT * FROM v$archive_gap;                       -- 必须为空
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
-- 备库：检查收到末尾日志后，切换为主库
SELECT thread#, max(sequence#) FROM v$archived_log GROUP BY thread#;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;
-- 原主库侧：打开并启动实时应用，回归备库角色
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
-- 验证：两侧角色与序列号对齐
SELECT database_role, open_mode, switchover_status FROM v$database;
​

彩排的验收标准有三条：切换耗时（目标是分钟级，含应用重连）、切换后新主库的写入正常、切回同样顺利——只切不回的演练是半场演练。应用程序侧用连接串里的两个地址加故障转移参数（透明切换），或用 TAF/全局服务实现重连，这一环不练，数据库秒切完应用照样瘫在那重试。

四、案例：一场切换演练找出的三个问题

背景。 某物流平台首次正式 Data Guard 演练，预案上写的切换耗时 5 分钟。

操作与结果。 按上述步骤走，第一次切换耗时 41 分钟，切回失败。复盘揪出三个问题：其一，备库应用延迟在演练前已达 27 分钟——平时没人在意备库延迟，切换要先等它追平，预案里的 5 分钟是从"追平后"开始算的，属于指标定义骗人；其二，监听配置只登记了主库地址，切换后应用重连全靠改配置重启，人工环节吃掉 15 分钟；其三，切回时原主库有 3 个本地未传输的归档缺口，按流程修补又花 12 分钟。

解读。 三个问题的修复各归其位：备库延迟纳入日常监控告警（阈值 1 分钟）；连接串改造为双地址自动故障转移，人工环节清零；演练日历里加入"月度切换、半年切回"的完整循环。第二次演练实测 6 分 40 秒。变式。 若演练目标升级为"站点级容灾"（主站点整体不可达），流程换成 Failover 加可能的数据损失声明，预案里必须写清"谁有权下令接受数据丢失"——技术动作一样，决策链不同，这正是 5.4 要 formalize 的部分。

💡 关键直觉：Data Guard 的价值排序是——延迟监控比切换脚本重要，切换脚本比切换本身重要。看不见延迟的备库在演练日一定会给你惊喜；而没彩排过的切换，真到用时每一步都是即兴表演。

问题一：备库能做备份源吗？ 能，且是推荐用法：活动 Data Guard 的备库开放只读，RMAN 从备库做备份，主库彻底卸掉备份 I/O。前提是备份策略覆盖所有归档线程（主备的日志线程都要备到），并且演练时验证"从备库备份、在主库恢复"的完整链路——只配不练的备份源，切换日会给你补一课。

问题二：主备延迟到底该监控哪个数？ 看两个口径的差：传输延迟（主库生成与备库收到的序列差）与应用延迟（收到与应用完的差）。传输延迟指向网络与主库发送能力，应用延迟指向备库的重演能力（备库负载过重会拖慢应用）。分开告警，出问题才能一步定位是"送不过去"还是"追不上来"。

本节要点回顾

• 两级流水：传输（主库送重做）与应用（备库重演），备库开放只读就是活动 Data Guard。
• 模式即报价：最大性能零损耗可丢秒级、最大可用平时不丢极端认命、最大保护零丢失但主库可能停写。
• 切换可逆、转移单向：Switchover 用于计划内维护，Failover 用于灾难且需数据损失决策。
• 演练验全链：备库延迟、连接串转移、归档缺口修补——只切不回等于没练。

站点级容灾再往上一级，是"一台机器挂了业务没感觉"的双活架构。下一节拆 RAC。