ORA-16475报错表明备库日志应用未完成，不可升主；须先查V$MANAGED_STANDBY确认MRP0是否APPLYING_LOG，再查V$ARCHIVE_GAP和物理归档文件完整性，且RAC环境下必须确保所有节点归档已传全、DG Broker已ENABLE并正确配置，否则手动ALTER DATABASE切换必失败。
ORA-16475 报错时，别急着重试，先查 MRPS 进程状态
ORA-16475 是 RAC + ADG 切换卡死最典型的信号，意思是“备库尚未完成所有日志应用，无法升主”。它不是配置错误，而是数据同步还没收尾。很多人看到这个错就反复执行 ALTER DATABASE COMMIT TO SWITCHOVER，结果越试越乱——原主库可能已降为备库，但新主库仍卡在 MOUNT 状态，MRP 进程没跑完。
实操建议：
- 在备库上立刻执行
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY;，重点看MRP0（或MRP1）是否为APPLYING_LOG；若显示WAIT_FOR_LOG或IDLE，说明归档没传全或路径不对 - 检查
SELECT * FROM V$ARCHIVE_GAP;，确认是否有归档断号；RAC 环境下必须每个实例都传完，漏一个节点的归档，MRP 就停摆 - 用
ls -lt $ORACLE_BASE/fast_recovery_area/<db_unique_name>/archivelog/直接看物理归档文件是否齐全，别只信数据字典——RAC 节点间归档路径不一致、NFS 挂载延迟、ASM diskgroup 权限问题都会导致文件“存在但不可见”
Data Guard Broker 未 ENABLE 就执行 switchover，等于直接跳崖
RAC 环境下，ALTER DATABASE 手动切主是无效操作，Broker 不启动，DMON 进程就不调度，LGWR 归档根本不会统一发往备库。你在一个节点改了 LOG_ARCHIVE_DEST_2，其他节点照样往旧地址发，结果就是备库只收到部分日志，switchover 必然失败并报 ORA-16789。
实操建议：
- 切换前必须确认
dgmgrl已连上主库：运行dgmgrl sys/<pwd>@rac_primary，再执行SHOW CONFIGURATION；若提示 ORA-12154，不是 tnsnames.ora 问题，而是监听器没静态注册GLOBAL_DBNAME = rac_primary_DGMGRL.example.com -
ENABLE CONFIGURATION命令必须成功返回 “Succeeded”，且SHOW DATABASE VERBOSE rac_primary中Role显示PRIMARY、Intended State为TRANSPORT-ON - 切勿在
dgmgrl里用SWITCHOVER TO rac_standby之前，手动在 SQL*Plus 里执行任何ALTER SYSTEM SET LOG_ARCHIVE_DEST_n——Broker 会覆盖掉，且留下不一致状态
Switchover 后部分节点仍 MOUNT，大概率是 CRS 资源依赖没对齐
RAC 主库切换后，新主库所有节点必须自动 OPEN，否则业务连接会报 ORA-01033。但常出现一个节点 OPEN 成功、另一个卡在 MOUNT，根源不在数据库层，而在 Clusterware 层：Oracle Restart 或 GI 的资源定义里，ora.<db_name>.db 资源的 START_DEPENDENCIES 缺失对 ora.<db_name>.vip 或 ora.<db_name>.lsnr 的强依赖，导致节点启动顺序错乱。
实操建议：
- 在任意节点执行
crsctl stat res -t | grep db，确认ora.<db_name>.db状态是否全为ONLINE；若某节点显示INTERMEDIATE，说明资源启动被阻塞 - 运行
srvctl config database -d <db_name>，检查输出中Database is enabled和Server pools: <pool_name>是否一致；不同 pool 会导致节点被调度到不同资源组 - 切勿直接
srvctl start instance -i <inst_name> -d <db_name>单启实例——这绕过 CRS 调度，后续srvctl stop database会失败，残留进程难清理
切换后监听连不上，先盯住 GLOBAL_DBNAME 和 SERVICE_NAME 区别
Switchover 完成，新主库 OPEN 了，但应用连不上，tnsping 通、sqlplus / as sysdba 也通，唯独业务报 ORA-12154。这不是网络问题，而是 Broker 切换后，监听注册的服务名变了：它用的是 GLOBAL_DBNAME（如 rac_primary_DGMGRL.example.com），而不是你 tnsnames.ora 里写的 SERVICE_NAME=rac_primary。
实操建议：
- 在新主库上执行
lsnrctl services，查看输出里Service "rac_primary_DGMGRL.example.com"是否有status READY；没有就说明静态注册没生效 - 编辑
$ORACLE_HOME/network/admin/listener.ora，确保 SID_LIST 下包含：SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = rac_primary_DGMGRL.example.com) (ORACLE_HOME = /u01/app/oracle/product/21c/dbhome_1) (SID_NAME = rac1) ) ) - 不要改
tnsnames.ora去适配 DGMGRL 服务名——业务连接串应继续用SERVICE_NAME=rac_primary，靠监听的动态注册转发；DGMGRL 服务名只供 Broker 内部使用
真正卡住的地方，往往不是命令敲错了，而是 RAC 多节点之间、数据库与 Clusterware 之间、Broker 与监听器之间，那几条隐式依赖链没对齐。一个节点的归档没传完，一个资源的启动顺序错了，一个监听的服务名没注册上——三者任一出问题，switchover 就会静默失败，日志里还不报明显错误。
