Oracle Data Guard 日常运维与故障场景 (19c / 23ai)

已部署的 Data Guard (physical standby) 配置的日常运维与故障恢复 runbook；初始搭建请使用 Data Guard 安装指南。如果不确定该做什么，请从“状态与延迟检查”开始：只读诊断会把您引导到正确的场景（计划内 switchover、failover、reinstate 旧 primary、归档间隙、用 RECOVER … FROM SERVICE 前滚、重建 standby、snapshot standby、apply/read-only、保护模式/FSFO/observer、数据文件和 redo log 操作、从 standby 做 RMAN 备份）。每个场景都按 诊断 → 安全网 → 执行 → 验证 → 后续 的顺序进行；同时给出使用 broker (DGMGRL) 和不使用 broker (SQL) 的路径，并说明单实例 / Oracle Restart / RAC 的差异。

架构: Primary（单实例 / Oracle Restart / RAC）+ physical standby（单实例 / Oracle Restart / RAC）+ 可选 observer

场景

• 状态与延迟检查（一切正常吗？） — 只读：配置、transport/apply lag、归档间隙、进程和 alert log；不做任何更改。如果不确定该做什么，请从这里开始：最后一步会根据输出告诉您应选择的场景。
• 计划内 switchover（互换角色） — Primary 和 standby 都正常，您希望有计划地互换角色（维护、DR 演练、切回原角色）；不会丢失数据，应用中断几分钟。只要还能访问 primary，角色转换就始终选择此项。
• Primary 丢失：failover 到 standby — Primary 无法访问且不会恢复（服务器、存储或站点丢失）；standby 成为 primary。不可逆：在 MaxPerformance 下最后几秒的数据可能丢失，旧 primary 之后需要 reinstate 或重建。如果仍能访问 primary，请选择 switchover。
• Failover 后将旧 primary 恢复为 standby (reinstate) — 已执行 failover，旧 primary 服务器已恢复；如果 Flashback Database 已启用，无需重建即可将其转换为新 primary 的 standby。新 primary 保持打开。如果 flashback 未启用或闪回窗口不够，诊断步骤会引导您去重建。
• 归档间隙 (gap)：standby 在等待缺失的归档日志 — v$archive_gap 返回行，或 alert log 中有 FAL/gap 消息；apply 卡在某个 sequence。数据库保持打开。如果缺失的归档日志在任何地方都不存在，可在表单中选择转到前滚路径。
• Standby 严重落后或归档已丢失：前滚 (RECOVER FROM SERVICE) — 间隙中的归档日志在任何地方都不存在、NOLOGGING 操作损坏了 standby，或 standby 已落后数天；无需重建 standby，即可从 primary 增量同步 (18c+)。
• 从头重建 standby — 无法 reinstate（没有 flashback），也无法前滚，或者 standby 的文件/控制文件已丢失；删除 standby 并用 DUPLICATE 重新创建。Primary 保持打开，但在重建完成前不受保护（除非还有其他 standby）。
• 转换为 snapshot standby / 转换回来（用于测试的可写副本） — 您希望临时以读写方式打开 standby 进行测试，然后丢弃更改并恢复为 physical standby；primary 不受影响，redo 继续接收，但作为 snapshot standby 期间，该 standby 无法用于 failover。
• 停止 / 启动 Redo Apply，更换 apply 实例，以 read-only 打开 — 您希望为维护而停止或重启 MRP、在 RAC standby 上将 apply 移到另一个实例，或打开 standby 用于报表（Active Data Guard 许可警告）。
• 保护模式、Fast-Start Failover 与 observer — 您希望在 MaxPerformance / MaxAvailability / MaxProtection 之间切换、启用或禁用 FSFO，或管理 observer。
• 添加数据文件、redo log 和 standby redo log / UNNAMED 文件 — 要在 primary 上添加数据文件或 redo log，standby 上出现了 UNNAMED 文件 (ORA-01111/ORA-01274)，或缺少 standby redo log。
• 从 standby 做 RMAN 备份 — 您希望在 standby 上运行 RMAN 备份以减轻 primary 的备份负载，并相应地设置归档日志删除策略。

开始之前

• 所有服务器上 oracle 用户的 profile 中已设置 ORACLE_HOME=…、ORACLE_SID（…RAC 上按节点为 …1、…2 …………）和 PATH；sqlplus、rman…、dgmgrl… 可以运行。配置是用 Data Guard 安装指南 或等效方式搭建的（TNS 别名 …、…，静态 _DGMGRL listener 条目，相同的密码文件）。
• 已验证角色与输入一致：当前 … 是 primary，… 是 physical standby。否则（例如之前做过 switchover）请在输入中互换名称。
• 已知 SYS 密码（角色转换、重启远端实例以及 RMAN FROM SERVICE 都需要密码认证的连接）。密码中不含 @、/、" 和空格。
• 许可：Data Guard 包含在 Enterprise Edition 中。在 apply 运行期间打开 standby 使用、在 standby 上启用 block change tracking 以及 Far Sync 需要 Active Data Guard 许可。Snapshot standby 以及在 apply 停止时以 read-only 打开不需要许可。
• 变更处于已批准的维护窗口内；应用和监控团队已知悉…（连接会中断几分钟）…。
• Failover 决定由授权人员做出；已确保旧 primary 不会再被打开 (split-brain)：服务器已关闭、已从网络隔离，或实例保持在 MOUNT 状态。

指南阶段

• 状态：配置、延迟和进程（只读） — 显示 broker 配置和角色转换就绪情况 · 用 SQL 检查 primary 端 · 用 SQL 检查 standby 端 · 扫描 alert log 中的 Data Guard 错误 · 解读结果并选择正确的场景
• 1. 诊断：是否已准备好 switchover？ — 验证就绪情况 (VALIDATE) · 验证就绪情况 (SWITCHOVER … VERIFY) · 检查 standby 延迟
• 2. 安全网 — 保存当前配置 (primary) · 保存当前配置 (standby)
• 3. 执行：switchover — Switchover：将 … 变为 primary (broker) · 启动 switchover (primary → standby) · 打开新 primary (…) · 更新 Clusterware 角色（新 primary） · 打开另一个实例（新 primary 节点 …：…） · 将旧 primary 作为 standby 以 MOUNT 打开 (…) …
• 4. 验证 — 验证新角色和配置 · 检查新 standby 上的 apply 和延迟
• 5. 后续 — 应用、作业和监控检查
• 1. 诊断：真的需要 failover 吗？ — 最后一次尝试访问 primary（从 standby） · 评估 standby 状态和可能的数据丢失 · 显示 broker 看到的状态（从 standby）
• 2. 安全网与剩余 redo — 保存 standby 的当前设置 · 以 MOUNT 打开旧 primary 并发送剩余 redo (FLUSH REDO) · 手工复制缺失的归档日志（无 broker，如可能）
• 3. 执行：failover — Failover：将 … 变为 primary (broker) · 停止 Redo Apply 并执行 failover (SQL) · 打开新 primary (SQL) · 更新 Clusterware 角色（新 primary） · 打开另一个实例（新 primary 节点 …：…）
• 4. 验证 — 验证新 primary
• 5. 后续 — 对新 primary 做全备 · 旧 primary 恢复时：不要打开
• 应用服务（基于角色） — 在 … 端定义并启动服务 (Clusterware) · 在 … 端定义服务 (Clusterware) · 定义服务和角色触发器（无 Grid） · 用两个地址配置客户端连接描述符
• 1. 诊断：能否 reinstate？ — 检查新 primary 和角色转换 SCN · 显示 broker 状态（新 primary） · 以 MOUNT 打开旧 primary 并检查闪回窗口
• 2. 安全网 — 保存旧 primary 的控制文件和参数
• 3. 执行：reinstate — Reinstate 旧 primary (broker) · 启动其他实例（旧 primary，RAC） · 闪回并转换为 physical standby (SQL) · 在新 primary 上启用 … 目标 (SQL) · 启动 Redo Apply 并越过角色转换记录 (SQL)
• 4. 验证 — 验证配置 · 在旧 primary（新 standby）上验证 apply
• 5. 后续 — 恢复原角色（可选）并处理根本原因
• 1. 诊断：间隙在哪里，归档日志是否存在？ — 显示 standby 上的间隙和进程 · 检查 FAL 连接和 alert log (standby) · 缺失的归档日志还在 primary 上吗？ · 缺失的归档日志在 RMAN 备份中吗？
• 2. 安全网 — 确认 standby FRA 中有空间
• 3. 执行：获取并注册缺失的归档日志 — 如果归档日志只在备份中：在 primary 上还原 · 将缺失的归档日志复制到文件系统并发送到 standby (primary) · 在 standby 上注册归档日志 · 重启 Redo Apply (standby)
• 4. 验证 — 观察间隙消除 (standby)
• 5. 后续 — 删除临时副本 · 处理根本原因
• 1. 诊断：standby 落后多少？ — 显示 standby 的 SCN 和状态 · 检查 primary 上的 NOLOGGING 操作和 COMPATIBLE 值
• 2. 安全网 — 备份 standby 控制文件和 spfile
• 3. 执行：前滚 standby — 停止 Redo Apply (standby) · 将 standby 置于 MOUNT…（仅实例 1）… · 从 primary 前滚 standby (RECOVER STANDBY DATABASE FROM SERVICE) · 启动其他 standby 实例 · 检查 standby redo log 和 flashback 状态 · 启动 Redo Apply (standby)
• 4. 验证 — 验证延迟已追平
• 5. 后续 — 处理根本原因
• 1. 诊断：真的需要重建吗？ — 显示配置和 primary 的状态
• 2. 安全网 — 保留 standby 的配置文件
• 3. 执行：删除并重建 — 从 broker 配置中移除 standby · 在 primary 上暂停 standby 目标 (DEFER) · 删除旧的 standby 数据库 · 清理残留的 broker、init 和密码文件 · 移开旧的 init 文件（standby 节点 …：…） · 用安装指南重新创建 standby …