备库归档路径与数据文件不可共用同一磁盘组，否则mrp0恢复时随机读与顺序写争抢io导致延迟翻倍；需物理隔离存储、合理设置archive_lag_target（推荐300）、并行度匹配asm条带能力，并禁用备库自动统计收集。
备库归档路径和数据文件在同一个磁盘组？立刻拆开
这是最常被忽略的性能瓶颈：备库上 db_recovery_file_dest（或手动配置的 log_archive_dest_n）和 datafile 物理路径落在同一块磁盘、同一asm磁盘组，甚至同一nvme设备分区。恢复进程（mrp0）一边读归档日志，一边写重做应用后的数据块，随机读+顺序写+元数据更新全挤在同一io队列里，延迟直接翻倍。
实操建议：
- 用
SELECT NAME, PATH FROM V$ASM_DISKGROUP JOIN V$ASM_ALIAS USING (GROUP_NUMBER)确认归档路径所在磁盘组 - 查数据文件位置：
SELECT FILE_NAME FROM DBA_DATA_FILES，对比是否混用同一磁盘组 - 若共用，优先将归档路径迁到独立、低延迟的存储——不是“另一个LUN”，而是物理隔离的控制器+通道，比如单独挂载的SSD盘或专用ASM磁盘组
- 迁移后必须重启
MRP0进程（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL→DISCONNECT→ 重新启动）才能生效
ARCHIVE_LAG_TARGET 设为 0 会加剧I/O争用
很多人以为设成 0 就能“实时归档”，结果发现备库I/O毛刺更频繁。实际上，ARCHIVE_LAG_TARGET = 0 会让主库每秒都触发归档检查，高频调用 ARCH 进程写归档，而这些归档又立刻被备库的 ARCH 和 MRP0 同时争抢读取——尤其当归档路径与数据文件共享存储时，小IO风暴就来了。
实操建议：
- 除非业务要求秒级RPO且已确认存储无瓶颈，否则不要设为 0；推荐值是
300（5分钟），平衡延迟与IO压力 - 检查当前值：
SHOW PARAMETER ARCHIVE_LAG_TARGET - 修改后无需重启实例，但需注意：该参数只影响主库归档节奏，不影响备库恢复逻辑
- 如果已设为 0 且出现
enq: RO - fast object reuse或大量db file sequential read等待，优先调高此值再观察
并行恢复（PARALLEL_EXECUTION_MESSAGE_SIZE）没配对ASM条带宽度
启用 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4 后，I/O反而变慢？大概率是并行进程数超过了底层ASM磁盘组的条带能力。比如磁盘组使用 EXTERNAL REDUNDANCY + 单块SAS盘，强行开 8 个并行恢复进程，所有进程都在争同一块磁盘的寻道能力，吞吐不升反降。
实操建议：
- 先查ASM磁盘组条带信息：
SELECT NAME, TYPE, STRIPE_COLUMN FROM V$ASM_DISKGROUP；STRIPE_COLUMN值越小，并行度上限越低 - 一般规则：并行度 ≤ 磁盘组中物理磁盘数 × 2（SSD）或 × 1（HDD）；例如 4 块NVMe盘，最大设
PARALLEL 8，但首次建议从PARALLEL 2起步 -
PARALLEL_EXECUTION_MESSAGE_SIZE必须同步调整，默认 2148 是保守值，高吞吐场景可设为65536减少消息交互开销 - 改完后观察
V$MANAGED_STANDBY中PROCESS列的MRP0状态，以及SELECT EVENT, WAIT_TIME_MILLI FROM V$SESSION_WAIT WHERE EVENT LIKE '%I/O%'
未禁用备库上的自动统计信息收集
备库默认继承主库的 STATISTICS_LEVEL = TYPICAL，一旦夜间窗口打开，ORA$AT_OS_OPT_SY_<number></number> 这类自动任务就会扫描数据文件生成统计信息——而此时 MRP0 正在持续写入，两个重量级后台进程在相同数据文件上并发执行随机读，I/O队列瞬间拉满，log file sync 和 db file scattered read 等待飙升。
实操建议：
- 立即关闭：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('auto optimizer stats collection', NULL, NULL) - 验证是否生效：
SELECT CLIENT_NAME, STATUS FROM DBA_AUTOTASK_CLIENT，确认状态为DISABLED - 不要依赖
STATISTICS_LEVEL = BASIC，它只禁用部分收集，不拦自动任务 - 如果业务强依赖统计信息（如备库也跑只读报表），改为手工调度，避开MRP活跃时段，并指定
NO_INVALIDATE => TRUE避免硬解析冲击
真正卡住I/O的，往往不是参数没开，而是多个看似合理的设置在物理层叠在一起——归档路径、并行度、统计任务、ASM条带，四者只要有一个没对齐底层硬件能力，优化就变成负优化。动手前，先看 iostat -x 1 或 asmcmd ls -l 确认真实路径归属，比调参重要得多。
