主库必须显式配置log_archive_dest_n指向中间备库，且需严格匹配valid_for、db_unique_name及service参数；中间备库须同时配置接收与转发功能，并启用active data guard许可和force logging。
主库必须显式配置 log_archive_dest_n 指向中间备库，否则级联链路从源头就断了——这不是“多加一个 dest 就完事”，而是角色、时机、参数三者严格匹配的结果。
主库怎么配 LOG_ARCHIVE_DEST_n 才能让 Redo 发到中间备库
级联不是自动转发，主库得“主动发两份”：一份给直连备库（常规配置），另一份明确指定发给中间备库。关键在 VALID_FOR 和 DB_UNIQUE_NAME 的组合。
-
LOG_ARCHIVE_DEST_2（或更高编号）必须设为SERVICE=mid_std，其中mid_std是中间备库在tnsnames.ora里定义的服务名，大小写敏感 -
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)—— 这个不能写成(ALL_LOGFILES,PRIMARY_ROLE)，否则主库启动时会报ORA-16057 -
DB_UNIQUE_NAME=mid_std_db必须和中间备库的V$DATABASE.DB_UNIQUE_NAME完全一致，否则主库直接跳过该归档路径 - 必须加
SYNC或ASYNC，不写默认是ASYNC；若要求强一致性，建议用SYNC NOAFFIRM避免网络抖动导致主库阻塞
中间备库为什么收得到 Redo 却转不出去
中间备库不是中继箱，它得同时扮演“接收者”和“发送者”两个角色，漏掉任一配置都会卡在第二跳。
-
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,mid_std_db,down_std_db)'—— 三者DB_UNIQUE_NAME缺一不可，顺序无关，但名称必须和所有节点实际值严格匹配 -
FAL_SERVER=down_std_db—— 值是下游备库的服务名（即其tnsnames.ora里的别名），不是 IP、主机名或DB_UNIQUE_NAME -
FAL_CLIENT=mid_std_db—— 强烈建议显式设置，避免监听端口多于一个时解析失败 - 中间备库也必须开启
FORCE LOGGING，否则下游拉取日志时可能报ORA-16055（FAL request rejected）
级联链路对物理备库和许可的硬性依赖
只有物理备库能当级联源，且实时转发能力受 Active Data Guard 许可锁死。
- 级联库必须是
PHYSICAL STANDBY，逻辑备库、快照备库、Far Sync 实例都不行；Far Sync 没有数据文件、不应用日志、不参与角色转换，本质是日志中转桩，不能当级联源用 -
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT必须在中间备库上启用实时应用，否则无法实时转发 - 检查许可状态：
SELECT * FROM V$OPTION WHERE PARAMETER = 'Active Data Guard'；返回TRUE才可用 real-time 级联 - 没许可时，
LOG_ARCHIVE_DEST_n的SYNC/ASYNC设置会被忽略，系统自动降级为归档后转发；延迟通常增加 1~3 分钟，且受ARCHIVE_LAG_TARGET影响 - real-time 级联下，
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)是必须项，写成(ONLINE_LOGFILES,)会静默失效
最容易被忽略的是 DB_UNIQUE_NAME 全局唯一性——Oracle 内部靠它路由 Redo，重复等于身份混淆，轻则同步失败，重则 MRP 进程无法启动；主库发 Redo 时发现目标名已被注册，直接拒绝，查 V$ARCHIVE_DEST_STATUS.ERROR 会看到 ORA-16664；中间备库发起 FAL 请求时被下游拒绝，MRP 日志持续报 “gap detected”。
