Oracle - DG - 主从切换注意点：切换前后日志角色变化
要彻底厘清 “多次主备切换的操作流程” 与 “日志角色变化”，需结合 Oracle Data Guard 角色适配规则 和 最佳实践（新建备用日志的必要性）—— 你提到的 “切换后新主库需新建 STANDBY REDO LOG” 并非 Oracle 强制要求，但属于 生产环境最佳实践（否则下次切换时新从库将无法接收 redo，导致 Data Guard 中断）。以下将整合 初始状态、第一次切换、第二次切换 的完整操作步骤，以及每次切换前后 ONLINE log/STANDBY log 的角色变化，同时明确 “新建备用日志” 的时机与原因。

前提：初始环境配置（搭建完成后未切换）

假设初始主库为 A，初始从库为 B，两者日志配置与你查询结果一致（以 GROUP# 区分类型）：
数据库角色日志配置（TYPE+GROUP#）日志当前作用
A（主） 主库 ONLINE log（GROUP#1-10） 核心：记录 A 自身事务 redo（如 INSERT/UPDATE），LGWR 进程实时写入。
    STANDBY log（GROUP#11-21） 闲置：仅当 A 作为 “级联主库” 时才用，常规主库无需备用日志，暂待命。
B（从） 从库 ONLINE log（GROUP#1-10） 闲置：从库不产生事务，ONLINE log 无进程使用，STATUS 为 UNUSED。
    STANDBY log（GROUP#11-21） 核心（实时模式）：RFS 接收主库 A 的 redo 写入，MRP 从这里读取并实时应用，部分组为 ACTIVE。

1. 第一次主备切换（A→新从库，B→新主库）

1.1. 切换前准备操作（避免切换失败）

  1. 检查主库 A 状态：确保主库无未归档日志（SELECT ARCHIVED, STATUS FROM V$LOG; 所有日志均为 ARCHIVED）。
  2. 检查从库 B 状态：确保 MRP 进程正常运行（SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; MRP 为 APPLYING_LOG），且无应用延迟（V$DATAGUARD_STATS 中 APPLY LAG 为 0）。
  3. 记录主从库日志序列号：避免切换后日志同步中断（SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;）。

1.2. 执行切换操作（关键 SQL）

（1）主库 A 切换为 “备库”（先操作原主库）

-- 1. 原主库 A 切换为备库（需 SYSDBA 权限）
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
-- 2. 关闭并重启 A，激活备库角色
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
-- 3. 启动 MRP 进程，开始接收新主库 B 的 redo（实时应用）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
 

（2）从库 B 切换为 “主库”（再操作原从库）

-- 1. 原从库 B 切换为主库（需 SYSDBA 权限）
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
-- 2. 关闭并重启 B，激活主库角色（允许读写）
SHUTDOWN IMMEDIATE;
STARTUP;
 

1.3. 切换后：新主库（B）与新从库（A）的日志角色变化

（1）新主库（原从库 B）：必须补充 “新建 STANDBY log”（最佳实践）

日志类型切换前角色（B 为从库）切换后角色（B 为主库）关键操作与原因
ONLINE log GROUP#1-10（闲置，UNUSED） 仍闲置：B 作为主库时，Oracle 不启用原从库的 ONLINE log（无有效 redo 记录），STATUS 保持 UNUSED。 无需处理，后续可删除或保留（建议删除，避免混淆）。
STANDBY log GROUP#11-21（活跃，接收 A 的 redo） 自动转换为 ONLINE log（TYPE 从 STANDBY 变为 ONLINE），立即用于记录 B 作为主库的事务 redo，LGWR 实时写入。 转换后，B 的 ONLINE log 实际是原备用日志组（如 GROUP#11 变为 CURRENT 状态）。
新增操作 - 必须新建一组 STANDBY log（如 GROUP#22-32），路径建议与原备用日志一致（如 /data/oradata/rkhy/slog_new*.rdo）。 原因：下次切换时，B 将变回从库，需要备用日志接收新主库（A）的 redo；若不新建，下次切换后 Data Guard 会因无备用日志而中断。
新建备用日志的 SQL 示例（新主库 B 执行）：
-- 新建 3 组备用日志（每组 1 个成员，大小与 ONLINE log 一致，如 500M）
ALTER DATABASE ADD STANDBY LOGFILE GROUP 22 ('/data/oradata/rkhy/slog_new1.rdo') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 23 ('/data/oradata/rkhy/slog_new2.rdo') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 24 ('/data/oradata/rkhy/slog_new3.rdo') SIZE 500M;
 

（2）新从库（原主库 A）：原 ONLINE log 转为备用日志（自动 + 手动辅助）

日志类型切换前角色（A 为主库）切换后角色（A 为从库）关键说明
ONLINE log GROUP#1-10（活跃，记录 A 的 redo） 自动清空 redo 内容，标记为 UNUSED，并可手动转换为备用日志（TYPE 从 ONLINE 变为 STANDBY）。 Oracle 不会自动修改 TYPE 字段，但会清空日志内容（避免旧 redo 干扰）；手动转换是最佳实践（避免闲置资源浪费）。
STANDBY log GROUP#11-21（闲置，待命） 立即激活为 备用日志，由 RFS 接收新主库 B 的 redo 写入，MRP 从这里读取并应用，部分组为 ACTIVE。 无需新建，直接复用原备用日志组，减少操作成本。
手动转换原 ONLINE log 为备用日志的 SQL（新从库 A 执行，可选但推荐）：
-- 1. 删除原 ONLINE log（需先确保日志已归档且状态为 UNUSED）
ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 2;
-- 2. 以备用日志类型重建（路径复用原 ONLINE log 路径，避免空间浪费）
ALTER DATABASE ADD STANDBY LOGFILE GROUP 1 ('/data/oradata/rkhy/redo01.log') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 2 ('/data/oradata/rkhy/redo02.log') SIZE 500M;
 

2. 第二次主备切换（恢复原始角色：A→主库，B→从库）

2.1. 切换前准备操作

  1. 检查新主库 B 状态：确保所有日志已归档，无未同步 redo。
  2. 检查新从库 A 状态：MRP 正常运行，APPLY LAG 为 0。
  3. 记录新主库 B 的备用日志信息（避免切换后新从库无法接收 redo）。

2.2. 执行切换操作（关键 SQL）

（1）新主库 B 切换为 “备库”

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
-- 启动 MRP，接收新主库 A 的 redo
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

（2）新从库 A 切换为 “主库”

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP;

2.3. 切换后：恢复原始角色的日志变化

（1）恢复为主库的 A：复用原 ONLINE log，备用日志待命

日志类型切换前角色（A 为从库）切换后角色（A 为主库）关键说明
ONLINE log 原 ONLINE log（已转为备用日志，GROUP#1-2） 自动转换为 ONLINE log（TYPE 从 STANDBY 变为 ONLINE），LGWR 重新写入 A 的事务 redo。 复用之前转换的日志，无需新建，节省操作时间。
STANDBY log GROUP#11-21（活跃，接收 B 的 redo） 恢复为 闲置待命：A 为主库后无需接收 redo，备用日志仅在下次切换或级联 Data Guard 时使用。 无需处理，保持现有配置即可。

（2）恢复为从库的 B：复用第一次切换时新建的备用日志

日志类型切换前角色（B 为主库）切换后角色（B 为从库）关键说明
ONLINE log 原备用日志（GROUP#11-21，记录 B 的 redo） 自动清空，标记为 UNUSED，可手动转为备用日志（可选）。 避免旧 redo 干扰，手动转换后可复用为备用日志，减少空间浪费。
STANDBY log 第一次切换时新建的 GROUP#22-24 立即激活为 备用日志，RFS 接收主库 A 的 redo 写入，MRP 读取应用，部分组为 ACTIVE。 复用第一次新建的备用日志，无需重复新建，符合最佳实践。

3. 不同 Oracle 版本主从切换后「Standby Redo Log（备用日志）」创建方式对比表

3.1 创建方式对比表

数据库版本是否需要手动新建 Standby Log关键特性 / 自动创建条件操作说明与最佳实践
11g 是（完全手动，无自动能力） 1. 无原生自动创建功能；
 
2. 切换后新主库若缺失 Standby Log，无任何提示或补偿机制。		 1. 切换后必须手动执行ALTER DATABASE ADD STANDBY LOGFILE创建；
 
2. 建议按「在线日志组数 + 1」配置（如在线日志 10 组，备用日志 11 组），大小与在线日志一致；
 
3. 不创建会导致下次切换后新从库无法接收 redo，Data Guard 中断（报错ORA-16072: a minimum of one standby redo log group is required）。
12c 是（手动为主，工具辅助有限） 1. 原生仍无自动创建功能；
 
2. 仅 Oracle Enterprise Manager（OEM）图形化工具可提供「自动创建向导」，但需手动触发；
 
3. 多租户（CDB/PDB）环境下，需在 CDB 根容器手动创建（PDB 继承使用）。		 1. 常规场景：切换后手动在新主库创建 Standby Log（语法同 11g）；
 
2. 多租户场景：需在 CDB 级创建，避免 PDB 单独配置导致不一致；
 
3. 建议创建后通过V$STANDBY_LOG验证状态（确保STATUS为UNUSED或ACTIVE）。
18c 是（手动为主，Broker 简化配置） 1. 无原生自动创建功能；
 
2. Data Guard Broker（DG Broker）支持「预配置模板」：可提前在 Broker 配置中定义 Standby Log 参数（如组数、大小、路径），切换后手动触发模板创建；
 
3. 支持在线创建（无需关闭数据库），简化操作流程。		 1. 推荐使用 DG Broker：切换前在 Broker 中通过EDIT DATABASE ... SET PROPERTY StandbyLogFileSize=500M;预配置，切换后执行ALTER DATABASE ADD STANDBY LOGFILE调用模板；
 
2. 无 Broker 场景：仍需手动执行 SQL 创建，操作逻辑与 12c 一致；
 
3. 可通过DGMGRL命令SHOW DATABASE ... STANDBYLOG验证配置。
21c 否（支持原生自动创建，需满足条件） 1. 新增「Auto-Create Standby Redo Logs」原生特性；
 
2. 自动创建触发条件：
 
- 切换后新主库检测到无 Standby Log；
 
- 启用 Data Guard Broker（dg_broker_start=TRUE）；
 
- 初始化参数LOG_ARCHIVE_AUTO_CREATE_STANDBY_LOGS=TRUE（默认FALSE，需显式开启）；
 
3. 自动创建规则：按「在线日志组数 + 1」生成，大小、路径与在线日志保持一致。		 1. 自动场景配置：
 
- 切换前确保dg_broker_start=TRUE且LOG_ARCHIVE_AUTO_CREATE_STANDBY_LOGS=TRUE；
 
- 切换后新主库会自动检测并创建 Standby Log，无需手动干预；
 
2. 手动兜底：若自动创建失败（如路径权限不足），仍需手动执行ALTER DATABASE ADD STANDBY LOGFILE补建；
 
3. 验证：通过SELECT GROUP#, STATUS FROM V$STANDBY_LOG;确认自动创建结果。
23ai 否（自动创建增强，条件更宽松） 1. 继承 21c 自动创建特性，且取消部分限制；
 
2. 自动创建触发条件简化：
 
- 切换后新主库检测到无 Standby Log 即可触发（无需强制启用 DG Broker，原生 SQL 切换也支持）；
 
- LOG_ARCHIVE_AUTO_CREATE_STANDBY_LOGS默认改为TRUE；
 
3. 增强特性：跨云场景下自动适配云存储路径（如 OCI 对象存储），避免路径错误。		 1. 默认自动场景：
 
- 无需额外配置，切换后新主库自动检测并创建 Standby Log；
 
- 云环境下自动使用CLOUD_STORAGE参数指定的路径（如/oci/data/standby_logs/）；
 
2. 手动干预：若需自定义组数 / 大小，可在切换后手动执行ALTER DATABASE ADD STANDBY LOGFILE覆盖自动配置；
 
3. 监控：通过V$DIAG_INFO查看自动创建日志（路径：Diag Trace目录下的alert.log）。

3.2. 核心总结：版本演进规律与实践建议

  1. 演进趋势：从「完全手动」（11g/12c）→「工具辅助简化」（18c）→「原生自动」（21c/23ai），Oracle 逐步降低 Standby Log 配置门槛，核心目标是减少切换后的人工干预。
  2. 自动创建前提：21c/23ai 的自动功能需依赖特定参数（21c 需显式开启LOG_ARCHIVE_AUTO_CREATE_STANDBY_LOGS，23ai 默认开启），且需确保路径权限充足（避免自动创建失败）。
  3. 生产环境建议：
    • 11g/12c/18c：提前在「切换前」创建 Standby Log（而非切换后），避免切换后中断；
    • 21c/23ai：优先依赖自动创建，但需在切换后通过V$STANDBY_LOG验证结果，防止因环境异常（如磁盘满）导致自动创建失败；
    • 统一规则：Standby Log 组数建议为「在线日志组数 + 1」，大小与在线日志一致（如在线日志 500M，备用日志也设为 500M），避免日志切换频率异常。

4. 核心总结：多次切换的日志角色规律与操作要点

4.1. 日志角色的核心原则

  • 角色决定功能：无论日志初始类型是 ONLINE 还是 STANDBY，主库只使用 ONLINE log 记录自身 redo，从库只使用 STANDBY log 接收主库 redo—— 角色反转时，日志功能自动 / 手动适配新角色。
  • 备用日志的必要性：任何主库都必须配置 STANDBY log（即使当前无备库），否则下次切换为从库时，无法接收新主库的 redo，导致 Data Guard 中断（这是你提到 “新建备用日志” 的本质原因）。

4.2. 每次切换的必做操作（生产环境）

切换阶段必做操作目的
切换前 检查主库归档状态、从库 MRP 状态、日志同步延迟。 避免切换失败或数据不一致。
切换后（新主库） 1. 确认原备用日志已转为 ONLINE log；2. 新建一组 STANDBY log（若不存在）。 为下次切换做准备，确保新从库有备用日志接收 redo。
切换后（新从库） 1. 启动 MRP 进程；2. 可选：将原 ONLINE log 转为备用日志（复用资源）。 确保从库能实时接收并应用 redo，避免闲置资源浪费。

4.3. 两次切换后的最终状态（恢复原始角色）

数据库角色ONLINE log 来源STANDBY log 来源状态
A（主） 主库 原 ONLINE log（切换后转回） 原 STANDBY log（闲置待命） LGWR 写入 ONLINE log，备用日志为下次切换准备。
B（从） 从库 原备用日志（切换后转为 UNUSED） 第一次切换时新建的 STANDBY log RFS 写入备用日志，MRP 实时应用，Data Guard 正常运行。
通过以上流程，可确保多次主备切换后 Data Guard 始终稳定，日志资源高效复用，避免因配置缺失导致的切换失败或同步中断。
 posted on 2025-09-23 21:03  xibuhaohao  阅读(8)  评论(0)    收藏  举报