级联备库日志转发需显式配置每跳的log_archive_dest_n，确保中间节点（如Standby1）以MOUNTED状态运行、log_archive_dest_state_n=ENABLE、valid_for含(standby_logfile,standby_role)，且log_archive_config包含自身与下游db_unique_name。
确认级联路径中每一跳的 log_archive_dest_n 是否指向正确角色
级联备库（如 primary → standby1 → standby2）不是自动“转发”日志的，必须显式配置每台备库作为“中间节点”时，把归档发往下游。常见错误是 standby1 仍只配置了发给 primary 或自己，漏掉对 standby2 的 log_archive_dest_2（或更高编号）。
-
log_archive_dest_2必须同时满足两个条件：目标服务名可连通（tnsping能通）、valid_for包含(standby_logfile,standby_role) - 在 Standby1 上执行：
select dest_id, status, destination, valid_for from v$archive_dest where dest_id in (2,3);，确认其中一条明确指向 Standby2 的 TNS 别名，且status = VALID - 若使用
service=standby2_db，确保该别名在 Standby1 的$ORACLE_HOME/network/admin/tnsnames.ora中存在，且HOST、PORT、SERVICE_NAME全部正确——别依赖主库的 tnsnames.ora 复制过来就完事
检查中间备库是否真正处于 STANDBY 角色并启用了日志传输
即使数据库已启动，若未以 mount 状态打开、或未启用日志传输开关，它就不会主动发日志。级联链路上任一节点卡在 OPEN（尤其是只读打开）或 DISABLED 状态，下游就会断收。
- 在 Standby1 上运行：
select database_role, open_mode from v$database;，结果必须是PHYSICAL STANDBY+MOUNTED；若为READ ONLY，需先shutdown immediate，再startup mount - 确认日志传输已开启：
show parameter log_archive_dest_state_2，值应为ENABLE（不是DEFER或RESET） - 检查 LGWR/LNS 进程是否活跃：
select process, status, sequence# from v$managed_standby where process in ('LNS','RFS');，LNS行的status应为WRITING或OPEN，而非CLOSING或空
验证日志是否真被生成、归档、且未被跳过
终端备库收不到日志，不等于主库没发——可能在中间节点就被拦截、丢弃或归档路径写错导致“静默失败”。重点看 Standby1 的归档目录和告警日志。
- 查 Standby1 的归档目标是否写满或权限不足：
archive log list输出中的Archive destination路径，用ls -ld和df -h验证磁盘空间与属主 - 翻 Standby1 的
alert_.log，搜索关键词：ORA-00308（无法打开归档日志）、ORA-16055（归档拒绝）、gap detected；有这些说明日志根本没成功落地，更别说转发 - 对比 Standby1 和 Standby2 的当前应用序列号：
select max(sequence#) from v$archived_log where applied='YES';，若 Standby1 是 105，Standby2 停在 98，说明中间至少缺 7 个归档——不是网络问题，是转发逻辑没生效
绕过 TNS 解析直连测试，快速定位是配置还是网络层问题
ORA-12154（TNS 无法解析）和 ORA-12514（监听器拒绝连接）是最常卡住级联的第一道墙。与其反复改 tnsnames.ora，不如用易验证的直连串绕过解析环节。
- 在 Standby1 上临时修改
log_archive_dest_2：alter system set log_archive_dest_2='SERVICE="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standby2_ip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=standby2_svc)))" valid_for=(standby_logfile,standby_role) db_unique_name=standby2_db'; - 立刻切一次日志：
alter system switch logfile;，再查v$archived_log看新归档是否出现在 Standby2 的归档目录 - 如果直连成功，说明原 TNS 别名配置有误（比如大小写、括号缺失、多空格）；如果仍失败，问题在防火墙、监听器状态或 Standby2 的
log_archive_config未包含 Standby1 的db_unique_name
级联链路本质是“每台机器都当一次主库”，但默认不会自动承担这个责任。最容易被忽略的，是中间备库的 log_archive_config 没把自身和下游都列进去，或者 db_unique_name 拼写与实际不一致——这种错不会报错，只会安静地不发日志。
