备库mrp进程i/o慢的主因是standby redo log尺寸小于主库online redo log及db_recovery_file_dest路径冲突；调大standby日志组尺寸至≥主库最大日志、将恢复区迁至本地nvme盘可显著提升physical writes至10mb/s以上。
备库MRP进程写I/O慢，v$sysstat里physical writes只有1MB/s
这不是磁盘本身不行——用dd测出来几百MB/s，说明底层存储没问题。问题出在MRP进程写入路径上：它不是直接写数据文件，而是通过Oracle的缓冲区缓存+DBWn刷盘机制走的，中间夹着LRU链、检查点队列、脏块排序等环节。当db_cache_size设得过大（比如占了SGA 70%），但备库只读不写业务，大量缓存被无效占用，反而挤占了MRP所需的内存资源和CPU调度优先级。
- 查
v$sysstat确认是否真卡在物理写：SELECT name, value FROM v$sysstat WHERE name IN ('physical writes', 'physical writes direct', 'physical writes from cache') - 对比
v$pgastat中total PGA allocated和cache hit percentage，若PGA hit低且physical writes from cache远高于physical writes direct，说明MRP正被拖在buffer cache路径里 - 临时验证：把
db_cache_size调小到原值的40%～50%，重启备库观察physical writes是否跳升至20MB/s以上
standby redo log尺寸小于主库online redo log，导致RFS频繁等待
RFS进程收到主库日志后，必须先写进standby redo log，MRP才能从中读取应用。如果备库standby redo log组大小（比如100MB）比主库最大的online redo log（比如200MB）小，RFS写到一半就发现空间不够，只能停住等MRP消费完当前组——但MRP又因为I/O慢而消费不动，形成死锁式延迟。
- 查主库最大日志尺寸：
SELECT MAX(bytes)/1024/1024 mb FROM v$log - 查备库standby日志状态：
SELECT group#, bytes/1024/1024 mb, status FROM v$standby_log，重点看status是否长期卡在ACTIVE - 重建规则：备库
standby redo log每组尺寸 ≥ 主库MAX(v$log.bytes)，且组数 ≥ 主库v$log组数 + 2（例如主库9组，备库至少12组） - 重建命令示例：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 '/path/to/stdby10.log' SIZE 200M，加完再删旧组（确保旧组STATUS为UNASSIGNED）
备库DB_RECOVERY_FILE_DEST和DB_CREATE_FILE_DEST落在同一块慢盘上
MRP应用日志时，既要解压归档（如果启用了LOG_ARCHIVE_DEST_2压缩）、写standby redo、又要刷数据文件变更，全挤在同一个挂载点，IO争用直接拉垮吞吐。尤其当这个挂载点是NFS或云厂商的通用型SSD（IOPS限速明显），physical writes掉到1MB/s就是典型症状。
- 查当前路径：
SHOW PARAMETER db_recovery_file_dest和SHOW PARAMETER db_create_file_dest - 用
iostat -x 1 5盯%util和await，若某设备%util > 90%且await > 20ms，基本锁定瓶颈盘 - 迁移动作：停MRP → 把
DB_RECOVERY_FILE_DEST指向本地NVMe盘（如/u02/fast_recovery_area）→ 调大db_recovery_file_dest_size→ 重启MRP - 切记：不要把
DB_RECOVERY_FILE_DEST设成ASM磁盘组——ASM对小块随机写优化不足，备库场景下反而更慢
STANDBY_FILE_MANAGEMENT=AUTO触发额外字典查询拖慢MRP
这个参数本意是自动同步主库新建的数据文件，但每次MRP解析一条日志，只要涉及文件操作（哪怕只是检查是否存在），就会去查obj$、ts$等核心字典表。在高并发归档场景下，这些查询会抢走MRP的CPU时间片，还可能引发latch争用，让physical writes进一步恶化。
- 查当前设置：
SHOW PARAMETER standby_file_management - 确认是否真需要AUTO：如果主库从不新增数据文件（比如固定表空间结构），直接关掉最省事
- 关闭命令：
ALTER SYSTEM SET standby_file_management=MANUAL SCOPE=BOTH（执行后无需重启） - 后续若主库真加了文件，手动在备库执行
ALTER DATABASE CREATE DATAFILE ... AS ...补上即可，比AUTO稳定得多
standby redo log尺寸错配和DB_RECOVERY_FILE_DEST路径冲突这两项，80%以上的“同步像蜗牛”案例都踩过。改完别急着看最终lag，先盯住v$sysstat里physical writes是否突破10MB/s——这才是I/O通路真正打开的信号。
