switchover_status持续显示session active是rac后台进程（如racgimon、j000）残留所致，需先查并停一个实例，再执行alter database commit to switchover to physical standby with session shutdown强制切换。
挂起无响应不是 Broker 卡死，而是底层状态不满足切换前提，必须从会话、实例、日志三处逐层排查。
switchover_status 一直显示 SESSION ACTIVE 怎么办
这不是配置错误，是 RAC 环境下后台进程残留导致的典型假死现象。v$database.switchover_status 不更新，本质是 racgimon、J000 等集群监控进程仍在运行，数据库误判“有活跃会话”。
- 先查真实会话：
SELECT SID, SERIAL#, PROGRAM, STATUS FROM v$session WHERE PROGRAM LIKE '%racgimon%' OR PROGRAM LIKE '%J00%' - RAC 必须停一个实例：
srvctl stop instance -d <db_unique_name> -n <node_name></node_name></db_unique_name>，不能只 shutdown abort - 停完再查状态，若仍为 SESSION ACTIVE，直接执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN——它会跳过检查并强制终止所有会话 - 切忌用
ALTER SYSTEM KILL SESSION手动杀 racgimon：它是 OCR 健康探针，杀掉可能触发集群异常
执行 ALTER DATABASE SWITCHOVER TO STANDBY 后卡住不动
卡在 SQL 层面，说明主库未发出 End of Redo 标记，或备库没收到/没应用完。根本原因常是实例状态冲突或 SRL 缺失。
- 确认主库仅一实例 OPEN：
SELECT INST_ID, STATUS, DATABASE_ROLE FROM gv$instance，其余必须是 NOT MOUNTED - 确认备库为 MOUNTED 且无 OPEN 实例，
SELECT OPEN_MODE, DATABASE_ROLE FROM v$database必须返回MOUNTED+PHYSICAL STANDBY - 检查 standby redo log：
SELECT GROUP#, THREAD#, BYTES/1024/1024 MB, STATUS FROM v$standby_log，缺失或全为UNASSIGNED会导致 MRP 无法启动，进而阻塞切换 - ORA-01105 / ORA-1093 报错？说明多实例同时 MOUNT，立刻用
crsctl stat res -t | grep <db_unique_name></db_unique_name>确认 CRS 资源真正 offline，别只信状态显示
Broker 切换命令（DGMGRL）无反应或报 ORA-16525
DGMGRL 不是独立服务，它依赖后台 dmon 进程连接各库。无响应往往源于连接链路中断或配置文件不可访问，而非命令本身问题。
- 确认
dg_broker_start在所有实例均为 TRUE 且 SCOPE 是 BOTH：SELECT INST_ID, VALUE FROM GV$PARAMETER WHERE NAME = 'dg_broker_start' - 检查配置文件路径：
SHOW PARAMETER DG_BROKER_CONFIG_FILE1，路径必须存在、目录已创建、属主为 oracle、权限 644 - 验证监听器静态注册：备库
listener.ora中GLOBAL_DBNAME必须等于其DB_UNIQUE_NAME，且lsnrctl status显示该服务状态为 READY - 关键线索在 dmon 日志：
$ORACLE_HOME/rdbms/log/drc<db_unique_name>.trc</db_unique_name>，ORA-16501、ORA-16706 类错误必须看它才能定位真实失败点
最易被忽略的是：RAC 环境中每个节点的 ASM 磁盘组状态必须单独验证，v$asm_diskgroup 全 DISMOUNTED 时，哪怕 CRS 显示资源 ONLINE，数据库也根本启不动——切换命令自然无响应。
