级联备库日志转发需显式配置每跳的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 拼写与实际不一致——这种错不会报错，只会安静地不发日志。