srvctl stop database前必须确认switchover_status为to standby，否则强制关闭将导致备库无法接管；若为sessions active需加with session shutdown，not allowed则须先解决归档gap。
srvctl stop database 之前必须确认 switchover_status 是 TO STANDBY
主库执行 srvctl stop database 前，如果没完成角色切换，会直接强制关闭实例，导致备库无法接管——这不是停DG，是炸库。必须先查 switchover_status：
- 返回
TO STANDBY：可直接执行alter database commit to switchover to physical standby - 返回
SESSIONS ACTIVE：先查v$session确认是否真有业务会话；若全是后台进程（如LGWR、DBW0），可用with session shutdown强制切 - 返回
NOT ALLOWED或RECOVERY NEEDED：说明日志传输或应用存在 GAP，得先跑select * from v$archive_gap和v$managed_standby定位卡点
crsctl stop cluster -all 不能在主备混启的节点上乱用
RAC + DG 环境里，主库和备库通常部署在不同物理集群（比如主库在 rac01/rac02，备库在 racdg01/racdg02）。如果在主库集群节点上误执行 crsctl stop cluster -all，会连带停掉本节点的 ASM、监听、VIP，但备库集群不受影响——这没问题；但如果误在备库节点上执行该命令，而该节点又同时运行着 Broker 的 dmon 进程或静态监听器（用于 DGMGRL 连接），就会导致后续 switchover 命令失败，报错 DGM-16954: Failed to connect to database。
安全做法是：
- 主库侧停集群：只在主库节点执行
crsctl stop cluster -all，且确保已先切为 standby - 备库侧停集群：只在备库节点执行，且必须确认
dgmgrl已退出、broker_config_file不被锁定 - 绝对避免跨集群执行，尤其不要在主库节点上对备库
db_unique_name做任何srvctl操作
监听器必须静态注册 _dgmgrl 全局名才能支撑自动启动实例
DG 切换后，新主库需要能被 Broker 自动拉起。如果监听器没静态注册 GLOBAL_DBNAME = <db_unique_name>_DGMGRL</db_unique_name>，Broker 尝试连接时会收到 ORA-12514: TNS:listener does not currently know of service requested in connect descriptor，然后卡住不动。
每个节点的 $ORACLE_HOME/network/admin/listener.ora 必须含类似配置：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = p19c0_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/19.3.0/db_1)
(SID_NAME = p19c01)
)
)
注意三点：
-
GLOBAL_DBNAME必须是<db_unique_name>_DGMGRL</db_unique_name>，不是<db_name></db_name>，也不是<service_name></service_name> -
SID_NAME必须与本节点实际运行的实例名一致（如p19c01），不能写成p19c02 - 改完要
lsnrctl reload，不能只stop/start，否则旧配置仍缓存
启动顺序错一步，ASM 就可能挂不上磁盘组
重启集群时，如果先启数据库再等 ASM 就绪，srvctl start database 会报 ORA-01078: failure in processing system parameters 或 ORA-00204: error in reading (block 1, # blocks 1) of control file——本质是控制文件所在的 ASM 磁盘组（如 +OCR、+DATA）还没 online。
正确顺序只能是：
- 所有节点：用 root 执行
crsctl start cluster -all（它会按依赖链自动启 CSSD → CRSD → ASM → DB） - 不手动启 ASM 实例：RAC 集群服务已托管 ASM 启动逻辑，单独
sqlplus / as sysasm启startup可能破坏 OCR 状态 - 检查
crsctl status res -t | grep -E "(ASM|diskgroup)"，确认ora.DATA.dg等状态为ONLINE后，再验证数据库
最容易被忽略的是：备库节点上的 ASM 实例，必须加载和主库相同的磁盘组别名（比如都叫 +DATA），否则 srvctl start database 会找不到控制文件路径。
