级联备库不是主库直连替代方案，而是物理DG链路延伸：必须经由已存在的物理备库（Standby A）转发至下游备库（Standby B），主库不感知级联节点，且三端小版本与PSU必须完全一致，否则同步失败。
级联备库不是主库直连的替代方案，而是物理DG链路的延伸结构
Oracle 11g 不支持「主库 → 级联备库」这种跳过直接备库的同步路径。所谓级联（Cascade），必须基于一个已存在的物理备库（Standby A）作为中间节点，再向其下游挂载另一个物理备库（Standby B）。主库本身仍只与 Standby A 建立 LOG_ARCHIVE_DEST_n 关系，不感知 Standby B 的存在。
因此，想靠级联来“减轻主库压力”，本质是误解了数据流：主库压力来自归档日志生成和传输，而级联不会减少主库产生的 redo 量或归档任务数；它只是把 Standby A 变成一个“转发者”，由它承担向 Standby B 传输日志的责任——这对主库 CPU、I/O、LGWR 和 ARCH 进程无任何减负作用。
真正能缓解主库 LogMiner 解析压力的是 Active Data Guard + 备库直连同步工具
如果你的真实目标是让实时同步链路（比如 CloudCanal、OGG 或自研 LogMiner 工具）不再压主库，那关键不在级联，而在让同步工具连到可读写的备库上。这需要：
-
Active Data Guard许可（Enterprise Edition 高级选项，需单独购买） - 备库以
READ ONLY模式打开，同时运行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 确认
v$database.open_mode = 'READ ONLY WITH APPLY'，且v$managed_standby.process = 'MRP0'状态为APPLYING_LOG - 同步工具连接该备库，并确保其 LogMiner 会话使用本地归档日志（
DBMS_LOGMNR.ADD_LOGFILE指向备库本地LOG_ARCHIVE_DEST_1路径）
此时主库完全不参与 LogMiner 解析、字典构建、V$LOGMNR_CONTENTS 查询等操作，资源占用归零。
级联备库唯一适用场景：网络隔离或带宽受限的异地部署
只有当主库与最终备库之间存在严格网络策略（如不能直连、跨公网带宽极低），但主库 ↔ Standby A、Standby A ↔ Standby B 各自链路通畅时，才考虑级联。配置要点包括：
- 在 Standby A 上启用归档并开启
LOG_ARCHIVE_DEST_STATE_2 = ENABLE，指向 Standby B 的 TNS 别名 - Standby A 必须处于
MOUNT或READ ONLY状态（不能是READ WRITE），否则无法接收主库日志的同时又转发给下游 - Standby B 的
STANDBY_FILE_MANAGEMENT应设为AUTO，避免因 Standby A 转发日志中含文件操作导致同步中断 - 主库无需为级联额外配置；但 Standby A 的
LOG_ARCHIVE_CONFIG必须包含所有 DB_UNIQUE_NAME，例如'DG_CONFIG=(primary,standby_a,standby_b)'
注意：LOG_ARCHIVE_DEST_2 在 Standby A 上必须用 LGWR SYNC/ASYNC，不能用 ARCH，否则无法保证实时转发。
容易被忽略的兼容性硬约束：主库、级联节点、终端备库必须小版本+PSU完全一致
Oracle 11g 物理 DG 对版本极其敏感。哪怕主库是 11.2.0.4.0，Standby A 是 11.2.0.4.190115（打了最新 PSU），Standby B 是 11.2.0.4.0，整个链路就会在 MRP0 启动时崩溃，报 ORA-01092 或 control file version mismatch。
验证方式不是看 v$version，而是执行：
SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
以及检查：
$ORACLE_HOME/OPatch/opatch lsinventory -detail
三端输出的补丁集（尤其是 RDBMS 组件）必须逐字符相同。一旦不一致，重搭是唯一选择——没有参数或配置能绕过这个二进制级限制。
