必须按thread执行，因rac各实例独立生成重做日志流；漏配某thread的standby logfile会导致其日志无法写入srl，传输静默挂起、transport lag持续上涨且status仍显示valid，极难排查。
能配，但必须按RAC集群维度统一配置，不能把每个节点当单实例处理；漏掉THREAD级Standby Logfile、VALID_FOR错配、密码文件不同步，三者占现场故障的80%以上。
为什么ALTER DATABASE ADD STANDBY LOGFILE必须按THREAD执行
RAC主库每个实例（即每个THREAD）独立生成重做日志流。如果只给THREAD 1加Standby Logfile，THREAD 2产生的日志到达备库后，RFS进程无法写入Standby Redo Log，传输会静默挂起——V$ARCHIVE_DEST_STATUS里STATUS仍显示VALID，但V$DATAGUARD_STATS中transport lag持续上涨，极难排查。
- 先查主库所有THREAD：SELECT THREAD#, INSTANCE FROM GV$INSTANCE
- 在备库每个节点上，为每个THREAD单独执行：
ALTER DATABASE ADD STANDBY LOGFILE THREAD N SIZE 200M（N替换为实际线程号） - 每THREAD至少配3组Standby Logfile，建议组数 ≥ 主库该THREAD在线日志组数 + 2，避免日志切换竞争
LOG_ARCHIVE_DEST_n的VALID_FOR和DB_UNIQUE_NAME怎么写才不触发ORA-16789
VALID_FOR不是可选参数，而是DG Broker启用传输服务的硬性校验点。写成(ALL_LOGFILES,PRIMARY_ROLE)或漏写，Broker直接拒绝启动LNS进程，报ORA-16789: standby redo logs not configured，但错误指向的是“没配SRL”，实际是VALID_FOR不匹配导致Broker跳过检查。
- 主库SPFILE中必须用
SID='*'全局生效，例如：LOG_ARCHIVE_DEST_2='SERVICE=sbcdb ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=sbcdb' -
SERVICE=sbcdb必须与备库tnsnames.ora中定义的服务名完全一致，且该服务必须指向备库SCAN地址，不能写单节点VIP或IP - 备库端也必须配
LOG_ARCHIVE_DEST_2指回主库，否则Switchover后无法反向传输，报ORA-16664
密码文件同步和SYSBACKUP权限为什么必须手工验证
RAC各节点的密码文件内容不一致，或缺少SYSBACKUP权限，会导致备库RFS进程连接主库时认证失败。现象是SELECT STATUS FROM V$ARCHIVE_DEST WHERE DEST_ID = 2返回ERROR，但告警日志只写ORA-01017: invalid username/password，掩盖了真实问题。
- 在主库任一节点执行：
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID dbuniquename=cdb format=12.2，并带上sysbackup=y - 用
scp把生成的orapw*文件复制到所有主库节点的$ORACLE_HOME/dbs/下，覆盖原文件 - 验证命令：
strings $ORACLE_HOME/dbs/orapw* | grep -i sysbackup，输出应含SYSBACKUP
最易被忽略的是：DG Broker启动前，必须确保备库所有节点的listener.ora里已声明GLOBAL_DBNAME = sbcdb_DGMGRL，否则Broker无法通过SCAN识别整个RAC集群，后续DGMGRL SHOW CONFIGURATION会卡在“WARNING: ORA-12545”——这个配置不在数据库参数里，而是在操作系统级监听配置中，查不到日志，也进不了视图。
