oracle 12c rac多租户环境下配置data guard白名单，须在$grid_home/network/admin/sqlnet.ora统一设置tcp.validnode_checking=yes及invited_nodes，并逐节点用srvctl重启监听器与scan监听器，确保dgmgrl服务和所有访问地址（scan/vip/备库ip）均被放行，否则导致ora-12154或ora-16664连接失败。
Oracle 12c 多租户（CDB/PDB）环境下配置 Data Guard 容灾白名单，本质是监听器层的网络访问控制，与 Data Guard 自身逻辑无关；但若白名单配置错误，会导致 DG Broker 连接失败、日志传输中断，直接表现为 ORA-12154 或 ORA-16664。
白名单必须在 GRID_HOME 的 sqlnet.ora 中统一配置（RAC 环境）
RAC 环境下，监听器由 GI 管理，sqlnet.ora 文件不在 $ORACLE_HOME/network/admin/，而是在 $GRID_HOME/network/admin/。所有节点都必须修改同一份文件，否则部分节点监听器拒绝连接，Broker 启动后无法联系全部实例。
- 编辑
$GRID_HOME/network/admin/sqlnet.ora，添加： TCP.VALIDNODE_CHECKING = yes-
TCP.INVITED_NODES = (primary-node1, primary-node2, standby-scan, far-sync-host)（填实际主机名或 IP，不能用通配符） - 修改后需逐节点执行：
srvctl stop listener -n node1→srvctl start listener -n node1，再操作 SCAN 监听：srvctl stop scan_listener→srvctl start scan_listener - 验证：在备库执行
tnsping rac_primary，并确认lsnrctl status listener_scan1输出中显示“Security: ON”且无拒绝日志
Data Guard Broker 连接失败时，先检查 GLOBAL_DBNAME 是否被白名单拦截
dgmgrl 连接主库时，依赖的是监听器注册的 GLOBAL_DBNAME = <db_unique_name>_DGMGRL.<domain></domain></db_unique_name> 服务，而非普通 SERVICE_NAME。如果白名单未放行该服务对应的目标地址，dgmgrl CONNECT sys/<pwd>@rac_primary</pwd> 就会报 ORA-12154，即使 sqlplus /@rac_primary 能连通。
- 确认监听器已静态注册 DGMGRL 服务：
lsnrctl status | grep -A5 DGMGRL - 检查
INVITED_NODES是否包含发起dgmgrl命令的客户端 IP（比如你在备库服务器上运行dgmgrl，那备库 IP 必须在白名单里） - 特别注意：RAC 主库各节点的监听器注册的是同一个
GLOBAL_DBNAME，但绑定的是各自本地 VIP 或 SCAN；白名单需覆盖所有可能被 Broker 访问到的地址（包括 SCAN VIP、各节点 VIP、以及远端备库地址）
多租户 CDB 级白名单不影响 PDB 级 Data Guard 行为
Data Guard 在 12c 中始终运行在 CDB 层级，PDB 不参与重做传输或角色切换。因此，sqlnet.ora 白名单只需保障 CDB 实例监听器可被 DG Broker 和归档进程访问，无需为每个 PDB 单独配置。
- 不需要在 PDB 内执行任何白名单相关命令（如
ALTER PLUGGABLE DATABASE ...） -
LOG_ARCHIVE_DEST_n中的SERVICE=...指向的是 CDB 的 TNS 服务名，白名单控制的是该服务名背后的监听器连接，与 PDB 名称无关 - 若后续启用 TDE 或审计日志远程写入，才需额外考虑对应组件的网络路径，但 Data Guard 本身不触发这些路径
最容易被忽略的一点：白名单配置后，srvctl stop/start listener 只重启监听器进程，不会自动重载 sqlnet.ora —— 必须用 lsnrctl reload 或完整重启监听器才能生效；而 RAC 环境下，lsnrctl reload 不被推荐，应坚持用 srvctl 全流程启停，否则会出现部分节点白名单生效、部分未生效的隐性不一致。
