备库应用速度慢需分层排查：先查v$managed_standby中mrp0状态，applying_log表示正在应用，wait_for_log说明日志未传输，wait_for_gap表明存在归档断档；apply lag仅为估算值不可信，真实延迟须结合sequence#推进、i/o与内存指标（如pga不足致direct temp读）及主库undo压力综合判断。
备库应用速度慢，不是调几个参数就能解决的，核心得先确认瓶颈在哪一层：是日志没传过来、传过来但没写进归档、还是归档写了但MRP进程压根没在应用——每层对应完全不同的排查路径和操作。
查V$MANAGED_STANDBY确认MRP是否真在干活
MRP进程状态是判断应用是否启动的唯一依据，V$DATAGUARD_STATS里的apply lag只是估算值，不能信。
-
PROCESS='MRP0'且STATUS='APPLYING_LOG'：说明正在应用，继续看SEQUENCE#是否随时间推进 -
STATUS='WAIT_FOR_LOG'或'IDLE'：日志根本没收到，问题出在传输层，回头查主库V$ARCHIVED_LOG和V$MANAGED_STANDBY中LGWR/RFS状态 -
STATUS在APPLYING_LOG和WAIT_FOR_GAP之间反复跳：说明有日志断档，检查ARCHIVE_LAG_TARGET是否过小、网络是否丢包、LOG_ARCHIVE_DEST_n里有没有DELAY没关
确认备库I/O和内存是否拖后腿
MRP进程应用大事务时，全靠PGA做排序/哈希/undo回滚，SGA里buffer cache反而用得少。内存不足会导致磁盘临时段刷写，应用速度断崖下跌。
-
v$sgastat中free memory持续低于100MB，或gv$memory_dynamic_components显示SGA_TARGET使用率＞95%：压缩SGA，把空间让给PGA -
PGA_AGGREGATE_TARGET设太小（如＜2GB）：MRP解析大DML时频繁写temp段，直接拉低吞吐；建议设为SGA_TARGET的40%～50%，且不低于2GB - 禁用
MEMORY_TARGET：它会让Oracle动态挪PGA内存，而MRP对PGA连续性极度敏感，一挪就抖 - 查
v$sysstat里physical reads direct temporary tablespace是否突增：确认是不是PGA不够被迫落盘
调并行度和IO参数前先看硬件底子
并行度不是越高越好，盲目设PARALLEL 8可能让CPU和I/O更堵——尤其当备库磁盘本身是SATA或RAID5时。
-
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL N：N值建议=CPU核数×1.5，上限不超过8；改完必须cancel再disconnect重启MRP才生效 -
PARALLEL_EXECUTION_MESSAGE_SIZE设4096：减少进程间消息拷贝开销，但需配合filesystemio_options=SETALL和disk_asynch_io=TRUE才起作用 -
DB_BLOCK_CHECKSUM=FALSE慎用：虽能省点CPU，但会掩盖底层存储静默错误，只在确认存储绝对可靠时临时启用 - 异步IO必须验证：
lsattr -E -l hdiskX（AIX）或blockdev --getra /dev/sdX（Linux）确认底层设备真正支持
别碰AWR报告查apply慢
AWR里log file parallel write平均2ms，不代表DG传输快；它只反映LGWR写本地日志文件耗时，和网络、备库I/O、MRP解析完全无关。
- 真要定位卡点，连上主备库实时查：
V$MANAGED_STANDBY（看LGWR/RFS/MRP三者状态）、V$ARCHIVED_LOG（比对SEQUENCE#三段差值）、tcpdump -i any port 1521（抓包看ACK延迟和重传） -
V$DATAGUARD_STATS的transport lag和apply lag默认60秒心跳，在跨公网或高抖动链路下严重失真，不能用于秒级诊断 - 如果
APPLIED_TIME和COMPLETION_TIME差值长期＞5分钟，说明MRP应用慢，而不是传输慢——这时候再回看内存、I/O、并行度
最常被忽略的是：RAC环境只查一个节点的视图，其他实例的MRP卡住完全看不见；还有就是主库undo压力导致MRP反复重试，但DBA只盯着备库undotbs1死磕——其实备库根本不生成undo，所有问题根子都在主库。
