rac环境data guard无损切换需主备库状态干净、redo无延迟、节点收敛至单实例；主库须剩一活动实例且switchover_status为to standby或sessions active（后者需确认无用户会话）；切换后主库变physical standby，备库切主需取消mrp、执行switchover并open所有pdb；新备库须手动启mrp并验证transport lag与apply lag均为+00 00:00:00。
能无损切换，前提是主备库状态干净、Redo传输与应用无延迟，且RAC节点已收敛到单实例操作——跳过任一检查，ORA-16129 或角色卡在 NOT ALLOWED 就是大概率结果。
确认 RAC 主库只剩一个活动实例并查 switchover_status
RAC 环境下 ALTER DATABASE COMMIT TO SWITCHOVER 只能在单实例上执行。必须先停掉非目标节点的实例（比如关掉 racdb2），再在剩余节点（如 racdb1）上验证：
-
SELECT database_role, switchover_status FROM v$database;—— 主库必须返回TO STANDBY或SESSIONS ACTIVE - 若为
SESSIONS ACTIVE，需确认残留会话是否全是后台进程（查v$session过滤type='BACKGROUND'），否则加WITH SESSION SHUTDOWN - 常见陷阱：误在所有节点都查到
TO STANDBY就直接切——那是 DG Broker 自动同步的状态显示，不代表本地 Redo 已清空；必须以当前连接实例的v$database为准
主库执行切换并手动 STARTUP MOUNT
执行后主库立即关闭，不能靠 SHUTDOWN IMMEDIATE 补救：
- Oracle 19c：直接
STARTUP MOUNT即可；若仍报ORA-01507，说明有残留共享内存段，用ipcs -mt+ipcrm清理 - 执行完立刻查：
SELECT database_role FROM v$database;必须是PHYSICAL STANDBY（注意不是STANDBY） - 别急着启 MRP——此时新备库还没开始接收日志，先确保
v$archive_dest_status中dest_id=2的status是VALID，error为空
备库（RAC 或单机）切主并打开 PDB
必须等主库已成功转为 PHYSICAL STANDBY 后，再在备库操作：
- 先取消日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 再执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;（即使switchover_status显示TO PRIMARY，也建议加WITH SESSION SHUTDOWN防卡住） - 切完立刻
ALTER PLUGGABLE DATABASE ALL OPEN;—— 19c 默认 PDB 不自动 open，漏这步会导致应用连不上 - 验证：
SELECT database_role, open_mode FROM v$database;应为PRIMARY和READ WRITE
启动新备库 MRP 并验证零延迟
旧主库（现为备库）必须主动拉起日志应用，且不能只信 transport lag = 0：
- 启动命令：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 立刻查：
SELECT process, status, sequence# FROM v$managed_standby WHERE process IN ('MRP0', 'RFS');——MRP0状态必须是APPLYING_LOG - 双指标必须同时为零：
SELECT name, value FROM v$dataguard_stats WHERE name IN ('transport lag', 'apply lag');返回值应为+00 00:00:00，单位是时间差，不是字节数 - 最容易被忽略的一点：RAC 备库切主后，
log_archive_dest_2中的DB_UNIQUE_NAME指向仍是原主库名，但实际归档已发往新主库——此时不用改参数，只要v$archive_dest_status显示 VALID 就算生效
