arch进程cpu高未必真在归档，需先验证其是否正常工作：查v$archive_dest的status和error字段，若error非空（如ora-00257）则cpu消耗多源于重试；再结合v$archived_log日志生成量、v$dataguard_stats的transport/apply lag判断归档压力来源；并检查arcn进程状态、并行配置及备库mrp是否卡住，避免误判伪高负载。
ARCH进程CPU高，先确认是不是它真在“干活”
操作系统层看到ora_arcn_进程CPU占用高，不等于DB内部ARCH真在密集归档——可能是伪高：比如归档目标不可写、磁盘满、LOG_ARCHIVE_DEST_n配置错误导致ARCH反复重试，或归档日志堆积后触发批量压缩/传输。先查v$archive_dest状态：STATUS列是否为VALID，ERROR列是否有非空值（如ORA-00257: archiver error. Connect internal only, until freed.）。若ERROR非空，CPU消耗大概率来自重试逻辑而非归档本身。
查ARCH实际归档压力：看v$archived_log和v$dataguard_stats
归档压力不是靠进程CPU%判断的，得看单位时间生成/发送量：
-
SELECT TRUNC(first_time), COUNT(*) FROM v$archived_log WHERE first_time > SYSDATE - 1 GROUP BY TRUNC(first_time) ORDER BY 1;—— 若单日归档日志数突增3倍以上（比如从2000条涨到7000条），说明业务日志量激增，ARCH自然吃CPU -
SELECT name, value FROM v$dataguard_stats WHERE name IN ('transport lag', 'apply lag');—— 若transport lag持续>30秒，说明ARCn在拼命推日志但网络或备库接收慢，会拉高CPU；若apply lag大而transport lag小，则问题在备库，主库ARCH其实已“交货”，CPU高另有原因
检查ARCn是否被强制串行化或参数配置失当
Oracle默认启动多个ARCn进程（如ARC0, ARC1），但以下情况会让它们退化成“一个干、其余等”：
-
LOG_ARCHIVE_MAX_PROCESSES设得太小（如=1），或被隐式限制：12c+中若启用了ENABLE_PLUGGABLE_DATABASE=TRUE且PDB频繁开关，可能触发BUG导致ARCn无法动态扩展 - 归档目标路径挂载为NFS且未加
noac选项，每次写日志都触发属性同步，ARCn陷入I/O等待+重试循环，top里显示CPU高，实为系统调用抖动 - 设置了
LOG_ARCHIVE_DEST_n带SYNC属性但未配LGWR传输，强制ARCn走“写完再确认”流程，放大单次归档延迟，引发排队
验证方式：SELECT process, status, thread#, sequence# FROM v$managed_standby WHERE process LIKE 'ARC%'; —— 正常应看到多个ARCn处于CONNECTED或WAIT_FOR_LOG；若仅一个ARC0为ACTIVE，其余长期NOT ACTIVE，就是并行能力被锁死了。
别漏掉备库端的“反向拖累”
主库ARCH CPU高，有时是备库在“求救”：
- 备库
MRP0进程卡住（如因坏块、索引失效、STANDBY_FILE_MANAGEMENT=AUTO下新增数据文件失败），主库ARCn会持续重传相同日志，形成“发→拒收→重发”死循环 - 备库
v$managed_standby中CLIENT_PROCESS = 'LGWR'但STATUS = 'IDLE'，说明主库LGWR已切归档，但备库没收到通知，ARCn被迫补位重传 - 查主库
v$archive_dest_status的TRANSMIT_MODE和VALUE：若为ASYNC但VALUE列显示0（表示零字节传输），基本可断定备库接收层故障
真正棘手的是：这类问题在AWR里不显山露水——DB CPU占比可能不高，但log file sync或control file sequential read等待事件飙升，ARCn线程在内核态反复sleep/wake，表现为CPU使用率毛刺高、平均负载上不去。
