MOUNT状态下备库可启动Redo Apply、激活切换为主库、查询v$database等实例视图、备份控制文件或归档日志；但不可执行SQL查询、访问数据字典、读写数据块。
备库 MOUNT 状态下能做什么
数据库处于 MOUNT 状态时，实例已启动，控制文件已加载，但数据文件和重做日志未打开，无法执行任何 SQL 查询（包括 SELECT），也不能访问数据字典视图（如 dba_tables）。此时仅支持有限的 DBA 操作：
-
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE启动 Redo Apply -
ALTER DATABASE ACTIVATE STANDBY DATABASE切换为主库（需先取消应用） - 查询
v$database、v$instance等实例级视图（不依赖数据文件） - 备份控制文件、归档日志，或执行 RMAN 的
BACKUP AS COPY（不读数据块）
关键限制：没有 buffer cache 加载，所有数据块访问被阻断；DBWR、LGWR 不写数据文件，ARCH 也不归档（除非主库传入）。
OPEN READ ONLY 状态的真实行为
备库以 OPEN READ ONLY 打开后，数据文件只读挂载，buffer cache 可缓存块，SQL 执行路径完整启用 —— 但有隐性代价：
- 每次
SELECT都会触发一致性读（CR）构造，需访问 undo 数据块（来自主库传输的归档/standby redo），若 undo 不足或延迟高，查询可能卡住或报ORA-01555 -
DBWR仍不写数据文件，但CKPT会更新数据文件头的checkpoint_change#（只读模式下该值冻结在 open 时刻） - 后台进程如
SMON、PMON正常运行，但不处理事务回滚（无写操作） - 连接数、游标、PGA 使用量与普通只读实例一致，内存压力真实存在
注意：OPEN READ ONLY 并不“轻量”，它只是关闭了写路径，读路径完全激活。
性能差异核心在 I/O 和内存模型
两者根本区别不在 CPU 或网络，而在数据访问层级：
-
MOUNT：零数据块 I/O，buffer cache 几乎空闲，SGA 中只有 shared pool 存放部分固定表定义（如x$ksuse） -
OPEN READ ONLY：全量 buffer cache 利用，频繁物理/逻辑读，undo 块加载，redo apply 进程（MRP）与前台查询竞争 I/O 资源（尤其当DB_FILE_MULTIBLOCK_READ_COUNT较大时） - 实测场景中，相同硬件下
OPEN READ ONLY的平均 IO wait time 是MOUNT状态下RECOVER模式的 3–5 倍
如果你只用备库做灾备切换准备，MOUNT 是最省资源的选择；一旦开启只读查询，就得按真实负载评估 I/O 和内存容量。
容易被忽略的兼容性陷阱
不是所有功能都能在 OPEN READ ONLY 下使用，而 MOUNT 下压根不涉及这些：
-
DBMS_STATS.GATHER_TABLE_STATS会失败（需要写sys.tab$），但MOUNT下连包都调不了 - 闪回查询（
AS OF TIMESTAMP）依赖 undo 完整性，在备库上极易因归档延迟失败 -
CREATE INDEX或ALTER TABLE ... MOVE在READ ONLY下直接报ORA-16000，但新手常误以为“只读”=“可建索引” - 某些监控脚本（如查
v$session_longops）在MOUNT下返回空，在READ ONLY下返回结果但可能过期
真正麻烦的是：应用层连接串里没显式指定 READ ONLY，却误连到只读备库，导致 DML 报错后重试风暴 —— 这种问题不会在 MOUNT 下发生，因为根本连不上。
