级联DG中主库必须显式配置LOG_ARCHIVE_DEST_n指向中间备库并设置VALID_FOR和DB_UNIQUE_NAME，中间备库需启用LOG_ARCHIVE_CONFIG与FAL_SERVER，且所有节点DB_UNIQUE_NAME必须全局唯一。
Redo路由必须在主库设置LOG_ARCHIVE_DEST_n参数
级联备库不自动继承主库的归档路径，redo日志从主库发出后，要抵达级联备库，必须显式告诉主库“发一份到中间备库，再让它转发”。这一步全靠log_archive_dest_2（或更高编号）里的valid_for和db_unique_name控制。
常见错误是只在中间备库开LOG_ARCHIVE_DEST_STATE_n=ENABLE，却忘了在主库配发送目标。结果主库压根不发Redo过去，级联链路从源头就断了。
- 主库上至少需配置两个
LOG_ARCHIVE_DEST_n：一个指向直接备库（SYNC或ASYNC），另一个指向中间备库（必须带LOCATION=SERVICE+VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)） -
SERVICE值必须和中间备库tnsnames.ora里定义的服务名完全一致，大小写敏感 - 中间备库的
DB_UNIQUE_NAME必须出现在主库该LOG_ARCHIVE_DEST_n的DB_UNIQUE_NAME属性中，否则主库拒绝发送
中间备库必须启用LOG_ARCHIVE_CONFIG和FAL_SERVER
中间备库不是“被动接收者”，它得知道自己能被下游拉取、也得知道怎么反向请求缺的日志——这两件事分别由LOG_ARCHIVE_CONFIG和FAL_SERVER控制。漏掉任一，级联链路在第二跳就卡死。
典型现象是：主→中间正常，但中间→下游始终报ORA-16055: FAL request rejected或gap detected，下游一直APPLYING不动。
-
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,standby_mid,standby_down)'，三者DB_UNIQUE_NAME一个都不能少，顺序无关 -
FAL_SERVER设为下游备库的服务名（即下游tnsnames.ora里的服务别名），不是IP或主机名 -
FAL_CLIENT建议显式设为本库服务名，避免依赖默认解析，尤其当有多个监听端口时
级联备库的DB_UNIQUE_NAME不能重复且必须全局唯一
Oracle用DB_UNIQUE_NAME做DG内部路由标识，一旦重复，主库或中间备库会拒绝注册，甚至导致ALTER DATABASE RECOVER MANAGED STANDBY DATABASE失败并报ORA-16664: unable to receive the result from a database。
最容易踩的坑是复制数据库时没改DB_UNIQUE_NAME，或者测试环境和生产环境混用相同名称。
- 检查所有节点：
SELECT DB_UNIQUE_NAME FROM V$DATABASE;，确保无重复 - 修改方法：关闭库 → 启动到
MOUNT→ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;→ 修改DB_UNIQUE_NAME（需重建spfile或手动改pfile）→ 重启 - 修改后必须同步更新所有节点的
LOG_ARCHIVE_CONFIG、LOG_ARCHIVE_DEST_n中的DB_UNIQUE_NAME引用
验证Redo是否真正在级联链路上传递
光看ARCHIVED_THREAD#和APPLIED_THREAD#不够，因为中间备库可能已归档但尚未传输给下游。真正要看的是Redo是否离开中间备库的本地归档目录、是否被下游成功接收并应用。
常有人误以为V$ARCHIVED_LOG里DEST_ID=2有记录就代表级联成功，其实那只是中间备库自己归档完成，跟下游无关。
- 在中间备库查：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID IN (2,3);，确认下游目标状态是VALID且ERROR为空 - 在下游备库查：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES';，对比中间备库V$ARCHIVED_LOG中CREATED时间相近的SEQUENCE#，差值应≤2 - 抓包验证（紧急排查用）：
tcpdump -i any port 1521 and host，看是否有持续向外发包
级联架构里，任何一环的LOG_ARCHIVE_DEST_STATE_n被设成DEFER、网络ACL拦截1521端口、或tnsnames.ora里ADDRESS写错——都会让Redo在某一级静默消失，而错误日志往往藏在后台trace里，不主动查就看不到。
