根本原因是OPEN READ ONLY WITH APPLY强制MRP串行化、STANDBY_FILE_MANAGEMENT=AUTO引发字典争用、I/O路径竞争及_disable_ksq_lock未启用导致锁升级。
Oracle 19c DG备库开启实时查询（OPEN READ ONLY WITH APPLY）时，日志应用速度明显变慢，根本原因不是“只读”本身，而是它强制启用了MRP进程的串行应用模式，并与底层I/O、内存和SQL执行层产生隐性冲突。
为什么OPEN READ ONLY WITH APPLY会禁用并行MRP
在19c中，只要备库处于READ ONLY状态（哪怕只是临时ALTER DATABASE OPEN READ ONLY再切回MOUNT），数据库内部会自动将MRP进程降级为单线程协调模式。此时即使你显式设置了PARALLEL_MAX_SERVERS或_log_parallelism_max，也不会生效。
-
MRP不再启动多个PR00~PR99应用进程，所有redo解析和SQL apply都压在一个线程里 -
V$MANAGED_STANDBY中PROCESS列只显示一个MRP0，且STATUS长期为APPLYING_LOG而非WAIT_FOR_LOG - 该行为是19c硬编码逻辑，不受
COMPATIBLE参数影响，也和是否启用ADG无关
STANDBY_FILE_MANAGEMENT=AUTO在实时查询下放大开销
当备库处于READ ONLY状态并持续应用日志时，STANDBY_FILE_MANAGEMENT=AUTO会频繁触发数据字典访问，而这些访问在只读模式下必须走本地缓存+一致性读路径，极易引发争用。
- 每次应用含
CREATE/ALTER TABLESPACE或ADD DATAFILE的日志，都会触发OBJ$、TS$等基表的一致性读 - 这些读操作无法利用
DB_CACHE_SIZE中的脏块，全部落到SHARED_POOL和LIBRARY_CACHE上 - 实测中，关闭该参数（
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL）后，MRP0的CPU占用下降约40%，apply lag收敛速度提升2–3倍
实时查询导致I/O路径竞争的真实表现
表面看备库I/O吞吐正常（dd测试可达数百MB/s），但MRP实际写入的是standby redo log和datafile，这两类I/O在只读状态下共享同一套DB_WRITER调度队列，且无法被IO_SLAVES卸载。
-
select * from v$iostat_file where filetype_name in ('Standby Redo Log','Data File')显示SMALL_READ_REQS和SMALL_WRITE_REQS比值严重失衡（如 1:8） - 操作系统层
iostat -x 1可见%util不高，但await持续高于20ms，说明随机小写阻塞了顺序大写 - 解决方案不是换磁盘，而是把
DB_RECOVERY_FILE_DEST和DB_CREATE_FILE_DEST指向不同物理盘（哪怕只是不同LUN），避免ARCH和MRP共用同一I/O栈
最容易被忽略的19c特有陷阱：_disable_ksq_lock未启用
19c默认关闭了备库上的锁优化开关，而实时查询场景下，MRP与用户会话对同一数据块的CR请求会反复触发ksqcmi锁升级，造成隐性等待。
- 检查当前值：
SELECT ksppinm, ksppstvl FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND ksppinm = '_disable_ksq_lock' - 若返回
FALSE，需在备库spfile中加入：_disable_ksq_lock=TRUE，然后重启至MOUNT再启用APPLY - 该参数在19c文档中未公开，但Oracle Support Note 2872569.1明确将其列为DG实时查询性能调优关键项
真正卡住MRP的往往不是网络或磁盘，而是19c在只读+应用混合状态下对内部锁、字典访问和I/O调度路径的重新约束。不改参数、不调配置，只靠加资源，基本无效。
