Oracle Data Guard备库IO过高的根本原因是RFS与MRP争抢同一ASM磁盘组，尤其当STRIPE_COLUMN≤4且SRL、数据文件、归档路径共用+DATA时；应将SRL和归档移至独立磁盘组（如+RECO），调大SDU至32767，并确保MRP正常应用。
oracle data guard 备库 io 过高，根本原因往往不是“传输慢”，而是恢复进程（mrp）与归档写入（rfs）、日志应用争抢同一组 asm 磁盘组 —— 特别是当 stripe_column 值偏小、条带并行度受限时，i/o 瓶颈会立刻暴露。
为什么备库 RFS + MRP 会抢同一磁盘组
默认配置下，RFS 进程把接收到的 redo 写入 standby redo logfile（SRL），而 MRP 进程从 SRL 或归档日志中读取并应用。如果 SRL 和主数据文件（+DATA）都放在同一个 ASM 磁盘组（比如 DATA），RFS 的连续写 + MRP 的随机读就会形成严重 I/O 争用。
- 查当前 ASM 条带设置：
SELECT NAME, TYPE, STRIPE_COLUMN FROM V$ASM_DISKGROUP;；STRIPE_COLUMN≤ 4 表示并行写上限低，容易堆积 - 确认 SRL 位置：
SELECT GROUP#, THREAD#, SEQUENCE#, BYTES, STATUS FROM V$STANDBY_LOG;，比对其所在磁盘组是否和DB_CREATE_FILE_DEST相同 - 检查归档路径是否也落在同一磁盘组：
SHOW PARAMETER log_archive_dest_2，看LOCATION=是否指向+DATA
如何分离 RFS 写入路径与数据文件路径
核心动作是把 standby redo logfile 和归档日志强制落到独立磁盘组（如 +RECO），让 RFS 的写和 MRP 的读不碰主数据盘。
- 添加新 SRL 到独立磁盘组：
ALTER DATABASE ADD STANDBY LOGFILE '+RECO' SIZE 2048M;（注意：必须先STOP MRP） - 删掉旧 SRL：
ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;（对应原在+DATA的组） - 修改归档路径指向新位置：
ALTER SYSTEM SET log_archive_dest_2='SERVICE=primary_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=primary_db LOCATION=+RECO' SCOPE=BOTH; - 确保
log_archive_dest_state_2是ENABLE，且standby_file_management保持AUTO
SDU 设置不当会放大网络层 IO 压力
过小的 SDU（Session Data Unit）会让 LNS/RFS 频繁拆包收发小块 redo，增加网络往返和本地 buffer copy 次数，间接抬高 CPU 和 I/O 负载。
- 检查当前 SDU：
SELECT * FROM V$SESSION_CONNECT_INFO WHERE SID = (SELECT SID FROM V$MYSTAT WHERE ROWNUM = 1);查SDU_SIZE字段 - 全局调整：在
sqlnet.ora加DEFAULT_SDU_SIZE=32767（最大值，需两端一致） - 或针对监听器单独设：
SDU=32767放入listener.ora的SID_DESC块内 - 改完重启监听器：
lsnrctl reload；注意：客户端连接需重连才生效
MRP 应用慢导致归档堆积，反过来压垮 I/O
MRP 卡住或应用速率远低于接收速率时，归档日志持续写入但无法及时清理，+RECO 磁盘组空间耗尽或碎片化，也会表现为 I/O 延迟飙升。
- 确认 MRP 是否运行：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';；若STATUS不是APPLYING_LOG，说明已 hang - 查最近未应用的归档：
SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG WHERE APPLIED = 'NO' AND DEST_ID = 2 ORDER BY FIRST_TIME DESC; - 避免用
duplicate from active database重建时卡住：务必显式分配多个AUXILIARY CHANNEL（如ch001–ch008），否则单通道在 70TB+ 环境下极易因 ASM IO 吞吐瓶颈挂起
真正关键的不是“加资源”，而是让 RFS 写、MRP 读、归档落盘三者物理隔离；STRIPE_COLUMN 值和 SDU 设置看似底层，但一旦错配，IO 问题会顽固复现，且监控里看不到明显错误，只看到平均等待时间缓慢爬升。
