归档写入慢本质是arch进程i/o或锁瓶颈，非日志生成过多；需查awr中log file switch (archiving needed)是否进top 5、其time waited是否高于checkpoint incomplete、db time/db cpu比值是否异常拉大、avg wait是否超阈值，并结合v$archive_dest_status状态及direct path write/enq: af等待定位归档路径或asm磁盘组问题。
归档写入慢不是“归档日志生成太多”的问题，而是ARCH进程卡在I/O或锁上——AWR里log file switch (archiving needed)排进Top 5、ARCH进程wait event持续显示direct path write或enq: AF - allocate extent，基本就能锁定归档瓶颈点。
看Top 5 Timed Foreground Events里有没有log file switch (archiving needed)
这个等待事件一旦进入Top 5，说明归档跟不上日志切换节奏，不是日志生成快，是归档写不进去。关键要看三组数字：
-
log file switch (archiving needed)的Time Waited是否持续高于log file switch (checkpoint incomplete)——前者高，就是归档拖后腿；后者高，才是检查点没做完 - 同一时段
DB Time和DB CPU比值是否明显拉大（比如DB Time=1800s，DB CPU=220s）——说明大量时间耗在等待，而非计算 - 该事件的
Avg wait (ms)是否超过50ms（OLTP环境）或200ms（DSS）——单次归档写入延迟已超出存储合理响应范围
查v$archive_dest_status确认归档目标状态是否异常
AWR不直接暴露归档路径健康度，必须手动查动态视图。重点盯三个字段：
-
STATUS不是VALID（比如ERROR、DEFERRED、INACTIVE）→ 归档目标不可用，ARCH进程会轮询重试，产生大量log file switch (archiving needed) -
DELAY_MINS> 0 → 归档路径有显式延迟配置，但实际延迟远超设定值，说明底层I/O或网络已卡住 -
TRANSMIT_MODE为ASYNC但STANDBY_LOGFILE_COUNT为0 → 物理备库未启用standby redo log，主库归档无法异步传递，被迫同步阻塞
执行命令：SELECT dest_id, status, delay_mins, transmit_mode, standby_logfile_count FROM v$archive_dest_status WHERE dest_id IN (1,2);
定位归档I/O瓶颈：别只看db file sequential read，要盯direct path write和enq: AF - allocate extent
归档写入本质是文件追加操作，主要消耗在磁盘写和ASM空间分配上。这两类等待事件才是真线索：
-
direct path write平均等待>15ms +Physical Writes Per Sec突增 → 归档目标存储（如NAS、NFS）响应慢，或挂载参数不当（如noac、hard mount） -
enq: AF - allocate extent频次高（每秒>5次）+AVG_WAIT_TIME_MS>100 → ASM磁盘组空间碎片化严重，或_asm_ausize设置过小（默认1M），导致频繁扩展AU - 若
direct path write和enq: AF - allocate extent共现且占比合计>15%，优先查ASM磁盘组：SELECT group_number, state, total_mb, free_mb, type FROM v$asm_diskgroup;，free_mb
验证归档路径I/O能力：用v$asm_disk_iostat代替AWR的Tablespace IO Stats
归档日志默认写到DB_RECOVERY_FILE_DEST，该路径若使用ASM，AWR里的Tablespace IO Stats完全无效——它按表空间聚合，而归档日志文件属于RECOVERY AREA逻辑区，不归属任何用户表空间。
- 必须查
v$asm_disk_iostat，重点关注归档目标所在磁盘组的avg_read_ms和avg_write_ms（单位毫秒）：SELECT group_number, ROUND((write_time/writes)*10,2) avg_write_ms FROM v$asm_disk_iostat WHERE writes > 0 ORDER BY avg_write_ms DESC; - OLTP环境
avg_write_ms> 20ms、DSS环境 > 50ms，即表明归档写入存在物理瓶颈 - 若
write_errs > 0，立刻查对应磁盘的HEADER_STATUS：SELECT name, header_status, mode_status FROM v$asm_disk WHERE group_number = &group_num;，PROVISIONED或FAILED代表磁盘已失效
云环境（如AWS EBS gp3）必须换用v$asm_disk_iostat_sparse，它提供write_time_wait字段，能区分是ASM处理慢还是后端存储卡住。
