级联备库本身不减轻主库压力，关键需主库禁用直连级联备库（设LOG_ARCHIVE_DEST_n=LOCATION=NONE）、由一级备库通过VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)转发日志，方可真正卸载主库归档传输负载。
直接上结论：级联备库（Cascade Standby）本身不减轻主库压力，但配合LOG_ARCHIVE_DEST_n的LOCATION=NONE + VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)配置，能让主库只向一级备库传日志，由一级备库中转日志给级联备库——这才是真正卸载主库归档传输负载的关键。
为什么级联备库不能“自动”减压主库
Oracle 12c 的级联备库本质是“转发节点”，不是主库的直连下游。但默认配置下，如果主库的LOG_ARCHIVE_DEST_2指向一级备库、LOG_ARCHIVE_DEST_3又指向级联备库，主库会**同时向两个目标发起归档传输**，反而增加LGWR进程负担和网络开销。
- 主库不会识别“级联”语义，它只按
LOG_ARCHIVE_DEST_n参数逐条执行传输任务 -
DB_UNIQUE_NAME在级联链路中必须全局唯一，但主库无法感知二级备库的存在 - 若未显式禁用主库对级联备库的直连传输，
V$ARCHIVE_DEST中对应条目状态可能为ERROR或DEFERRED，但归档进程仍会周期性重试
必须关闭主库对级联备库的直连归档
主库的LOG_ARCHIVE_DEST_3（假设指向级联备库）必须设为无效转发态，否则主库持续尝试连接：
- 执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='LOCATION=NONE' SCOPE=BOTH; - 确认：
SELECT DEST_ID, STATUS, TARGET, VALID_FOR FROM V$ARCHIVE_DEST WHERE DEST_ID = 3;——STATUS应为INACTIVE，VALID_FOR应含STANDBY_ROLE - 严禁写成
LOCATION=''或''，空字符串会导致ORA-16019错误 - 该参数在主库处于
PRIMARY角色时完全不生效，但能防止误配后主库发起无意义连接
一级备库需启用归档转发并配置SERVICE别名
级联能力实际由一级备库承担，它必须以STANDBY角色运行，并主动将收到的归档日志转发给下级：
- 一级备库启动到
MOUNT状态后，执行：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_cascade ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=cascade_db' SCOPE=BOTH; -
standby_cascade是tnsnames.ora中定义的服务名，指向级联备库监听地址 - 确保一级备库的
LOG_ARCHIVE_CONFIG包含全部DB_UNIQUE_NAME：'DG_CONFIG=(primary_db,standby_db,cascade_db)' - 级联备库自身无需额外配置转发，它只接收一级备库发来的归档，不做二次转发
验证级联链路是否真正卸载主库
重点看主库是否还跟级联备库发生网络交互：
- 在主库执行：
SELECT DEST_ID, DESTINATION, TRANSMIT_MODE, AFFIRM, BIND FROM V$ARCHIVE_DEST WHERE DEST_ID IN (2,3);——DESTINATION为NULL或NOT APPLICABLE才安全 - 抓包验证：
tcpdump -i any port 1521 and host <cascade_ip>，主库节点不应出现与级联备库IP的SYN握手 - 检查主库告警日志：
tail -f $ORACLE_BASE/diag/rdbms/primary_db/primary/trace/alert_*.log，不应有TNS-12541或ORA-16057指向级联备库 - 级联备库的
ARCHIVE_LAG_TARGET参数无效——它只对主库直连的备库起作用
最容易被忽略的是：级联备库的DB_UNIQUE_NAME必须出现在主库和一级备库双方的LOG_ARCHIVE_CONFIG中，缺一则VALID_FOR校验失败，导致一级备库拒绝转发。这个参数不像其他初始化参数能动态生效，修改后需重启实例才加载。
