备库关闭前必须先取消日志应用，否则直接 shutdown immediate 会因 mrp 进程阻塞而卡住或触发 ora-1092；正确步骤为：先执行 alter database recover managed standby database cancel，确认 v$managed_standby 中无 mrp0，再停监听、关实例，rac 环境需逐节点操作，并校验密码文件与 sysbackup 权限一致性。
备库关闭前必须先取消日志应用
直接 SHUTDOWN IMMEDIATE 会触发 ORA-1092（实例强制终止），因为 MRP 进程正在后台持续读取并应用归档日志。未显式取消恢复，数据库会卡在“等待日志应用完成”状态，shutdown 命令长时间无响应。
正确做法是先中断物理恢复流程：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;- 执行后立即查
V$MANAGED_STANDBY，确认所有PROCESS列为ARCH或NONE，无MRP0进程残留 - 若使用 DG Broker，还需运行
DGMGRL> DISABLE CONFIGURATION防止 Broker 自动重连触发恢复
RAC备库每个节点都要单独执行取消操作
RAC 备库不是单实例，ALTER DATABASE ... CANCEL 只影响当前连接的实例。如果只在一个节点上执行，其他节点的 MRP 进程仍在运行，后续 shutdown 仍会挂起。
必须逐节点登录并执行：
- 用
srvctl status database -d <db_name></db_name>确认哪些节点处于 OPEN 或 MOUNT 状态 - 对每个在线节点，用
sqlplus / as sysdba连接后运行 cancel 命令 - 特别注意：若备库启用了 Real-Time Apply（
USING CURRENT LOGFILE），cancel 后需额外检查V$DATAGUARD_PROCESS中无RBAL或RFS异常活跃
关闭顺序不能颠倒：先停监听再关实例
如果先 shutdown 实例，RFS 进程可能因监听器还在运行而尝试重连主库，导致告警日志刷屏 ORA-12514（TNS:listener does not currently know of service requested）。
标准动作链如下：
- 在每个备库节点上：先
lsnrctl stop（确保监听器完全退出） - 再
sqlplus / as sysdba→SHUTDOWN IMMEDIATE - 最后用
srvctl stop database -d <db_name></db_name>统一收口（尤其当使用 ASM 或 OCR 管理时）
漏掉监听器这步，重启时 RFS 可能抢在数据库 open 前就启动并失败，造成后续 STARTUP 卡在 MOUNT 状态。
密码文件和 SYSBACKUP 权限失效会导致静默失败
看似 shutdown 成功，但下次启动时 RFS 连不上主库，现象是 V$ARCHIVE_DEST_STATUS.STATUS 显示 ERROR，告警日志只写 ORA-01017——这其实是密码文件不同步或缺失 SYSBACKUP 权限的典型伪装。
关闭前建议快速验证：
- 在任一节点执行：
strings $ORACLE_HOME/dbs/orapw$ORACLE_SID | grep sysbackup，输出应含SYSBACKUP - 确认所有节点的密码文件 md5 值一致：
md5sum $ORACLE_HOME/dbs/orapw* - 若发现不一致，立刻用
orapwd重建并同步，否则 shutdown 后再 startup 就会暴露问题
这个点最容易被忽略：shutdown 过程本身不报错，但为下一次启动埋了雷。
