最常被忽略的I/O瓶颈根源是备库归档与数据文件共用同一物理存储：需检查并隔离ASM磁盘组、调高ARCHIVE_LAG_TARGET至300、匹配并行恢复数与ASM条带宽度，并用iostat -xdm 1监控w_await和avgqu-sz。
查备库磁盘是否被归档和数据文件共用
这是最常被忽略的i/o瓶颈根源：备库上 db_recovery_file_dest（或手动配置的 log_archive_dest_n）路径与 dba_data_files 物理位置落在同一asm磁盘组、同一块nvme设备分区，甚至同一sas盘lun。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→ 断开连接 → 重新启动
iostat -xdm 1 看出w_await飙升就基本坐实了
iostat -xdm 1 是定位DG备库IO瓶颈最快的一线工具。关键不是看吞吐量，而是看等待时间。哪怕 wMB/s 看似不低，只要 w_await 持续 >20ms（机械盘）或 >5ms（SSD），就说明写入正在排队。
常见误判点：
- 用
dd测序写带宽“很快”，不代表Oracle随机写不卡——dd测的是单流大块顺序写，MRP0是多线程小块随机读+顺序写混合 -
%util长期 >85% 且avgqu-sz>2，说明IO队列已堆积，不是“还能跑”，而是“正在堵” - 重点关注
vdb（或你实际数据盘设备名）的w_await和await，别只盯着sda（系统盘）
ARCHIVE_LAG_TARGET = 0 会放大IO争用
设成0看似“实时”，实则让主库每秒触发归档检查，ARCH进程高频写归档，备库ARCH和MRP0立刻争抢同一存储上的文件——尤其当归档和数据混用时，小IO风暴就来了。
实操建议：
- 检查当前值：
SHOW PARAMETER ARCHIVE_LAG_TARGET - 除非业务RPO要求秒级且已确认存储无瓶颈，否则一律设为
300（5分钟） - 如果已设为0且出现
enq: RO - fast object reuse或大量db file sequential read等待，优先调高再观察 - 该参数只影响主库归档节奏，修改后无需重启实例，但对备库I/O压力有直接影响
并行恢复没配对ASM条带宽度反而拖慢
开 PARALLEL 4 后I/O变慢？大概率是并行数超过了底层ASM磁盘组的实际条带能力。比如EXTERNAL冗余+单块SAS盘，强行开8个MRP进程，所有进程都在抢同一磁头寻道。
实操建议：
- 先查ASM条带信息：
SELECT NAME, TYPE, STRIPE_COLUMN FROM V$ASM_DISKGROUP -
STRIPE_COLUMN值越小，并行度上限越低（例如值为2，建议并行数 ≤2） - 并行数不是越多越好，要匹配物理磁盘数量和RAID级别——RAID10四盘组，最大有效并行通常为4
- 调整后观察
iostat的avgqu-sz是否下降，而非只看吞吐量数字
真正卡住DG同步的，往往不是SQL或网络，而是磁盘上那一层看不见的IO调度冲突。归档路径和数据文件是否物理隔离、w_await 是否持续超标、ARCHIVE_LAG_TARGET 是否被误设为0、并行恢复数是否超过ASM条带能力——这四个点，任何一个没对齐，MRP0就会在后台默默排队。
