ORA-16057 根源是RAC各实例未统一启用DG配置：需在每个节点执行LOG_ARCHIVE_CONFIG设置，并确保V$DATABASE.DATABASE_ROLE均为PRIMARY、V$DATAGUARD_CONFIG完整，DB_UNIQUE_NAME全局唯一且大小写敏感。
ORA-16057: Data Guard configuration not enabled on this instance
这是 rac 环境下 dg 启动日志传输时最常卡住的第一步——主库节点没真正“认”自己是 dg 主库。不是配了 log_archive_dest_2 就算数，rac 每个实例都得单独确认 dg 角色状态。
实操要点：
-
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,standby_db)' SCOPE=BOTH;必须在每个 RAC 实例上执行，不能只在一个节点跑 - 检查
V$DATABASE.DATABASE_ROLE和V$DATAGUARD_CONFIG，两个节点都要返回PRIMARY和完整配置，缺一不可 - RAC 中
DB_UNIQUE_NAME必须全局唯一，且和LOG_ARCHIVE_DEST_n里写的完全一致（大小写敏感），常见坑是备库 RAC 的两个节点用了同一个DB_UNIQUE_NAME - 如果用 ASM 存储，
LOG_ARCHIVE_DEST_1的本地归档路径必须指向共享 ASM 磁盘组（如+FRA），不能指向本地文件系统
主库 RAC 到备库 RAC 的 LGWR ASYNC 传输不生效
看着参数都设了 LGWR ASYNC，但 V$ARCHIVE_DEST_STATUS.STATUS 一直显示 DEFERRED 或 ERROR，根本没发出去。本质是网络层 + Oracle 网络服务没对齐。
实操要点：
- 主库每个实例的
LOG_ARCHIVE_DEST_2必须指向备库的 SCAN 名（如standby-scan.example.com），不是单个 VIP 或节点名；否则只有一半连接能通 - 检查
tnsnames.ora：备库端的CONNECT_DATA.SERVICE_NAME必须是 DG 专用服务名（如standby_DGB），不能直接用默认standby，否则 RAC listener 不会把连接路由到所有实例 - 在主库任意节点执行
tnsping standby-scan，必须返回多个地址（至少两个 VIP），否则 TNS 解析失败，日志传输静默失败 - 启用
LOG_ARCHIVE_TRACE=8后查trace文件，重点看有没有TNS-12545或ORA-12170，这类错误基本都出在网络配置或防火墙
备库 RAC 节点间 SRL（Standby Redo Log）不同步导致 GAP
主库切日志很快，但备库只有一台节点在应用，另一台始终 APPLYING_LOG 状态为 NO，V$ARCHIVE_GAP 频繁报 gap。问题不在传输链路，而在 SRL 分布策略。
实操要点：
- SRL 必须在每个备库节点的本地 ASM 磁盘组上创建（如
+DATA_STBY/node1、+DATA_STBY/node2），不能共用同一组别名；否则只有一个实例能成功 allocate SRL - 检查
V$STANDBY_LOG：每个节点的INST_ID对应的 SRL 组数要一致，且STATUS不能全是UNASSIGNED - 启动备库时，确保两节点都以
MOUNT状态启动，并执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;—— 缺少USING CURRENT LOGFILE会导致仅一个节点进入实时应用 - RAC 备库不支持
ADG下的跨节点并行应用，SRL 必须按节点隔离，别指望自动负载均衡
Switchover 后原主库 RAC 启动失败：ORA-01102: cannot mount database in EXCLUSIVE mode
切换完成后，原主库 RAC 两个节点都起不来，报错直指 EXCLUSIVE 模式冲突。这不是 DG 配置问题，而是 RAC 实例启动时没正确识别自身新角色。
实操要点：
- Switchover 前，确保主库 RAC 所有节点已停止应用（
RECOVER MANAGED STANDBY DATABASE CANCEL），否则残留的 MRP 进程会锁住控制文件 - Switchover 完成后，在新备库（原主库）任一节点执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;——WITH SESSION SHUTDOWN是关键，否则后台进程残留 - 重启前，检查
$ORACLE_HOME/dbs/lk<SID>锁文件是否残留，RAC 下这个文件可能被另一个节点持有，需手动清理 - 启动时用
srvctl start database -d <db_name>，别用sqlplus / as sysdba单节点启，否则 CRS 不感知状态，后续资源管理全乱
最麻烦的其实是 RAC 和 DG 交界处的状态同步：DG 认的是数据库级角色，RAC 管的是实例级生命周期，两边不主动对齐，就靠 DBA 手动掐准时机做动作。参数写对只是起点，什么时候停、在哪节点停、停完清什么、再启走哪条路径——这些顺序错了，日志就断在看不见的地方。
