必须先取消备库MRP再shutdown——直接shutdown immediate主库会中断日志传输，备库不cancel MRP0则挂起；RAC需逐节点cancel，监听器须早于实例启动，DG Broker建议disable配置。
不能直接 shutdown immediate 主库或备库——主库强关会中断日志传输，备库不 cancel MRP 就关不掉，大概率触发 ORA-1092 或卡死。
备库必须先取消日志应用再 shutdown
物理备库的 MRP0 进程（Managed Recovery Process）持续读取并应用归档日志。只要它还在运行，SHUTDOWN IMMEDIATE 就会挂起，等“应用完成”，而这个“完成”永远不会来。
- 执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;后，立刻查V$MANAGED_STANDBY，确认PROCESS列无MRP0，只有ARCH、RFS或NONE - 若启用 Real-Time Apply（即带
USING CURRENT LOGFILE），cancel 后还要检查V$DATAGUARD_PROCESS，确保没有异常活跃的RBAL或RFS - RAC 环境下，
CANCEL命令只作用于当前连接节点，必须逐节点登录执行；用srvctl status database -d先确认哪些节点在线 - 使用 DG Broker 时，
CANCEL后建议在DGMGRL中运行DISABLE CONFIGURATION，防止 Broker 自动重连重启恢复
主库和备库关闭/启动顺序不能颠倒
关机顺序错会导致归档断链；开机顺序错则可能让主库发日志时备库监听未就绪，刷屏 ORA-12514。
-
关机：先主库
SHUTDOWN IMMEDIATE，再备库CANCEL + SHUTDOWN IMMEDIATE -
开机：先备库
STARTUP（自动 OPEN，无需额外ALTER DATABASE OPEN），再主库STARTUP - 备库启动后，需立即执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;拉起 MRP；这条命令前台不返回，但后台已运行，别误以为卡住 - 监听器必须早于实例启动：先
lsnrctl start，再STARTUP；若先关实例再停监听，RFS 可能反复尝试连主库，触发大量ORA-12514
RAC 备库重启要额外注意权限与文件一致性
RAC 节点间不是共享内存式协同，每个节点都独立持有密码文件、本地监听配置和 SYSBACKUP 权限状态。
- 所有节点的 Oracle 密码文件（
$ORACLE_HOME/dbs/orapw）必须完全一致，否则某节点sqlplus / as sysdba会失败 - SYSBACKUP 权限需在每个节点上单独验证：
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'SYSBACKUP'; - 若用 srvctl 管理，重启前确认资源状态：
srvctl status database -d和srvctl config database -d，避免因 OCR 配置漂移导致某节点起不来 - 监听器配置中，
SID_LIST_LISTENER必须包含_DGMGRL条目（如GLOBAL_DBNAME=slavea_DGMGRL），否则 DG Broker 无法连接该节点
最易被忽略的是 RAC 备库的“单点 cancel”陷阱——只在一个节点执行 CANCEL，其他节点 MRP 仍在跑，后续 shutdown 仍会卡住；还有就是监听器启停时机，晚启或早停都会让 RFS 进程陷入重连循环，日志里塞满错误却看不出根本原因。
