级联Redo传输必须显式配置LOG_ARCHIVE_DEST_n的CASCADE属性，主库需在指向一级备库的参数中添加CASCADE，一级备库自身还需单独配置LOG_ARCHIVE_DEST_n指向二级备库，并确保三端DB_UNIQUE_NAME、tnsnames.ora及log_archive_config完全一致。
级联Redo传输必须启用LOG_ARCHIVE_DEST_n的CASCADE属性
Oracle 19c中，级联（Cascade）不是自动开启的模式，而是由主库显式配置某个LOG_ARCHIVE_DEST_n参数的CASCADE属性触发。不加这个关键字，哪怕网络连通、监听正常，一级备库也只会接收日志，不会主动转发——它默认把自己当成终端备库。
常见错误现象是：主库归档日志已成功传到一级备库，但二级备库的V$ARCHIVED_LOG始终为空，SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID IN (2,3)显示二级目标STATUS为INACTIVE或ERROR，而错误信息通常是ORA-16057: DGID not set for destination——本质就是没告诉一级备库“你得转发”。
- 主库上配置一级备库目标时，必须加上
CASCADE，例如：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=std1 SYNC AFFIRM DB_UNIQUE_NAME=std1 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) REOPEN=60 CASCADE';
-
CASCADE只能用于LOG_ARCHIVE_DEST_n中指向**物理备库**的目标，不能用于LOG_ARCHIVE_DEST_STATE_n=DEFER或指向远端同步实例（Far Sync）的配置 - 一级备库自身不需要额外设置
LOG_ARCHIVE_CONFIG来“声明自己支持级联”，它只认主库传来的CASCADE指令；但它的DB_UNIQUE_NAME必须与主库LOG_ARCHIVE_DEST_n中指定的一致，否则会拒绝接收
一级备库必须开启LOG_ARCHIVE_DEST_n并指向二级备库
级联不是“主库→一级备库→二级备库”的单向链式推导，而是一个两级独立配置：主库告诉一级备库“你收着，并转发”；一级备库自己再配一条LOG_ARCHIVE_DEST_n，明确指向二级备库。一级备库此时角色是“转发者”，不是“只读终端”，所以它必须像主库一样具备归档发送能力。
容易踩的坑是以为只要主库配了CASCADE，一级备库就会自动转发——实际它根本不会启动ARCn进程去连二级备库，除非你手动在一级备库上执行：
- 确认一级备库已启用归档：
archive log list输出必须为“数据库日志模式 存档模式” - 在一级备库上配置转发目标，例如：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=std2 ASYNC DB_UNIQUE_NAME=std2 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) REOPEN=30';
-
VALID_FOR必须设为(STANDBY_LOGFILES,STANDBY_ROLE)，不能沿用主库的(ONLINE_LOGFILES,PRIMARY_ROLE)，否则一级备库处于STANDBY_ROLE时该目标被忽略 - 一级备库的
log_archive_config需包含所有参与节点：ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(prim,std1,std2)'，否则无法识别std2的DB_UNIQUE_NAME
DB_UNIQUE_NAME和tnsnames.ora必须三端严格一致
级联失败里超过60%的案例源于DB_UNIQUE_NAME拼写或大小写不一致，或者tnsnames.ora中服务别名解析错位。Oracle在Redo传输阶段对DB_UNIQUE_NAME做精确字符串匹配，不忽略空格、下划线甚至大小写。
典型错误现象：一级备库ALERT.log反复报ORA-16057: DGID not set for destination 'std2'，但tnsping std2能通——说明网络层OK，问题出在逻辑层未识别目标身份。
- 三台机器的
/etc/hosts必须互相解析对方主机名，且与DB_UNIQUE_NAME完全对应（如主库DB_UNIQUE_NAME=prim，则/etc/hosts中必须有xxx.xxx.xxx.xxx prim） - 每个节点的
$ORACLE_HOME/network/admin/tnsnames.ora中，服务名（如std1、std2）对应的HOST值必须是对方机器可解析的主机名，不能写IP（除非/etc/hosts已绑定），也不能写localhost - 检查命令：
SELECT DB_UNIQUE_NAME, DATABASE_ROLE FROM V$DATABASE;和lsnrctl status | grep -A 5 "Services"，确保服务名出现在监听器注册列表中
级联链路中任意节点故障都会中断下游传输
级联Redo传输是线性依赖：主库→一级备库→二级备库。一级备库宕机或归档进程卡住，二级备库立刻停止接收；同样，一级备库能连通二级备库，但二级备库监听未启动或密码文件缺失，一级备库的ARCn进程会在REOPEN间隔后不断重试，日志里持续刷ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。
这不是配置缺陷，而是架构特性。如果你需要高可用级联，必须在一级备库侧部署本地归档（LOG_ARCHIVE_DEST_1）+ 定期备份，或改用Far Sync实例替代一级物理备库——但Far Sync本身不存数据，只做中继，不能提供容灾能力。
真正容易被忽略的是：级联环境下，LOG_ARCHIVE_DEST_STATE_n的状态必须人工维护。比如一级备库临时切换为主库，其LOG_ARCHIVE_DEST_3（指向二级备库）会自动失效（因VALID_FOR限定STANDBY_ROLE），切回备库后必须手动执行ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE，否则转发不恢复。
