主库必须显式配置LOG_ARCHIVE_DEST_n指向中间备库，如SERVICE=mid_std、VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)、DB_UNIQUE_NAME=mid_std_db；中间备库需设LOG_ARCHIVE_CONFIG、FAL_SERVER、FAL_CLIENT且DB_UNIQUE_NAME全局唯一。
主库必须显式配置 log_archive_dest_n 指向中间备库，否则级联链路从源头就断了。
主库上怎么配 LOG_ARCHIVE_DEST_n 才能让 Redo 发到中间备库
级联不是自动转发，主库得“主动发两份”：一份给直连备库（常规配置），另一份明确指定发给中间备库。关键在 VALID_FOR 和 DB_UNIQUE_NAME 的组合。
-
LOG_ARCHIVE_DEST_2（或更高编号）必须设为SERVICE=mid_std，其中mid_std是中间备库在tnsnames.ora里定义的服务名，大小写敏感 -
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)—— 这个不能写成(ALL_LOGFILES,PRIMARY_ROLE)，否则主库启动时会报 ORA-16057 -
DB_UNIQUE_NAME=mid_std_db必须和中间备库的V$DATABASE.DB_UNIQUE_NAME完全一致，否则主库直接跳过该归档路径 - 必须加
SYNC或ASYNC，不写默认是ASYNC；若要求强一致性，建议用SYNC NOAFFIRM避免网络抖动导致主库阻塞
中间备库为什么收得到 Redo 却转不出去
中间备库不是中继箱，它得同时扮演“接收者”和“发送者”两个角色，漏掉任一配置都会卡在第二跳。
-
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,mid_std_db,down_std_db)'—— 三者DB_UNIQUE_NAME缺一不可，顺序无关，但名称必须和所有节点实际值严格匹配 -
FAL_SERVER=down_std_db—— 值是下游备库的服务名（即其tnsnames.ora里的别名），不是 IP、主机名或DB_UNIQUE_NAME -
FAL_CLIENT=mid_std_db—— 强烈建议显式设置，避免监听端口多于一个时解析失败 - 中间备库也必须开启
FORCE LOGGING，否则下游拉取日志时可能报 ORA-16055（FAL request rejected）
DB_UNIQUE_NAME 重复会导致什么现象
Oracle 内部靠 DB_UNIQUE_NAME 路由 Redo，重复等于身份混淆，轻则同步失败，重则注册异常甚至 MRP 进程无法启动。
- 主库向中间备库发 Redo 时，发现目标
DB_UNIQUE_NAME已被另一节点注册，直接拒绝发送，ALTER SYSTEM ARCHIVE LOG CURRENT后查V$ARCHIVE_DEST_STATUS.ERROR会看到 “ORA-16664: unable to receive the result from a database” - 中间备库尝试向下游发起 FAL 请求时，因名称冲突被下游拒绝，MRP 日志持续报 “gap detected”，
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY中 FAL 进程状态为CONNECTED但无实际传输 - 检查命令统一用：
SELECT DB_UNIQUE_NAME FROM V$DATABASE;，所有节点执行一遍比对，不能只看参数文件或建库脚本
最常被忽略的是中间备库的 FAL_CLIENT 设置——它不参与 Redo 接收，只影响反向请求日志时的身份标识；一旦没设或设错，下游根本不知道该把缺的日志发给谁，整个级联链路就静默卡死，表面看一切正常，实则下游永远追不上。
