若log file switch (archiving needed)等待时间占比超10%且远高于checkpoint incomplete，则归档跟不上；需核对Redo与Archived size/s比率、归档路径I/O、ARCH进程状态及数量，并检查queued值和日志切换频率。
查AWR里log file switch (archiving needed)是否真占大头
打开AWR报告，直奔Top 5 Timed Events页。如果log file switch (archiving needed)的Time Waited占比超过总DB Time的10%，且绝对值明显高于log file switch (checkpoint incomplete)，就基本锁定归档跟不上——不是日志写得快，是归档搬得慢。
注意：这个等待只在归档模式下出现，且必须是ARCH进程没来得及把当前日志打包走，LGWR才被迫等。别把它和log file sync或log file parallel write混在一起看。
- 如果
log file switch (archiving needed)高，但log file switch (checkpoint incomplete)也同步升高，说明归档慢引发了连锁反应，DBWR被拖住，检查点也卡了 - 如果只有
log file switch (archiving needed)高，而ARCH进程数在v$bgprocess里显示正常（比如ARCH0~ARCH3都在），那问题大概率在归档目标本身
看Redo size/s和Archived Size/s是否严重不匹配
翻到AWR报告的“Redo Statistics”或“Instance Activity Stats”节，对比两个关键数字：
Redo size per second（单位MB/s） vs Archived size per second（单位MB/s）
- 前者来自
v$sysstat中redo size增量除以快照时长，反映真实产生量 - 后者需手动算：查
v$archived_log中最近一小时blocks * block_size总和 ÷ 3600，或用SELECT ROUND(SUM(blocks*block_size)/1024/1024/3600,2) FROM v$archived_log WHERE first_time > SYSDATE-1/24; - 若归档速率长期低于redo生成速率的80%，归档队列必然堆积，
v$archive_dest里queued列会持续非零
确认归档目标路径是否存在I/O瓶颈
归档慢90%以上是路径问题，不是参数问题。先查LOG_ARCHIVE_DEST_1实际指向哪：
SELECT destination, status, queued, bind, delay_mins FROM v$archive_dest WHERE dest_id = 1;
- 如果
destination指向NFS、低速SAN或满容量本地目录，queued字段会不断增长，iostat -x 1 5在该挂载点上必然看到%util > 90%、w_await飙升 - 如果路径是本地SSD，但
log file parallel write平均等待也高（>5ms），说明LGWR和ARCH在争同一块盘——必须物理隔离：联机日志和归档日志绝不能放在同一块物理磁盘或同一LUN -
delay_mins > 0表示人为延迟归档，但生产环境极少启用；若为非零，得确认是不是误配了DELAY属性
检查ARCH进程是否被卡住或数量不足
默认log_archive_max_processes=2，高负载下完全不够用。查实时状态：
SELECT process, status, thread#, sequence#, blocks FROM v$managed_standby WHERE process LIKE 'ARCH%';
- 如果多个
ARCH进程长期停留在CONNECTED或WAIT_FOR_LOG，但blocks几乎不涨，说明它们在等LGWR写完下一个日志，本质还是I/O或日志组太小 - 如果只有
ARCH0活跃，其余全NOT ACTIVE，说明没启用多进程归档，可设ALTER SYSTEM SET log_archive_max_processes=4;（别超CPU核数一半） - 注意：
v$archive_dest中transmit_mode为ASYNC时，主库不等备库确认，归档慢不影响log switch；但若为SYNC，则归档延迟会直接转成log file switch (archiving needed)等待
归档慢最易被忽略的点是：它不报错，只默默堆积。v$archive_dest里的queued值和v$log_history里频繁切换的时间戳，比任何平均等待数字都更早暴露问题。
