归档模式本身无开销，关键在于归档日志生成量和切换频率背后的真实负载；需通过awr报告load profile中redo size per second是否异常偏高来判断，结合top 5 timed events中的log file switch (archiving needed)等待事件、redo log space requests非零值、sql statistics中rows processed与executions双高语句，以及v$transaction和v$sess_io动态视图交叉验证，才能准确定位根因。
归档模式本身不产生开销，真正要盯的是“归档日志生成量”和“归档切换频率”背后的真实负载——awr 报告里有明确路径可查，不是靠猜。
看 Load Profile 里的 Redo size per second 是否异常偏高
这是最直接的信号。归档日志暴增，本质是 redo 写得多；redo 写得多，要么事务多、要么单条 DML 影响行数大、要么无索引更新导致反复读块再改块。
-
Redo size per second> 10 MB/s（常规 OLTP 环境）就该警觉；若达 50+ MB/s，基本可断定存在批量 DML 或低效更新 - 对比正常时段报告：同一时间段（比如都是上午 10–11 点），
Redo size per second翻倍或更高，说明不是业务自然增长，而是执行逻辑出了问题 - 注意单位：AWR 里默认是 bytes，别误读成 KB 或 MB；实际值可能显示为
12489231，即约 12.5 MB/s
查 Top 5 Timed Events 里是否有 log file switch (archiving needed)
这个等待事件一出现，就说明归档进程跟不上日志生成速度，是 I/O 或配置瓶颈的铁证。
- 如果它在 Top 5 里且占比 > 5%，尤其伴随
Redo size per second高企，基本锁定归档路径写入慢或 redo 日志组太小 - 同时检查
Redo log space requests（在 Instance Activity Stats 部分）：非零值说明 LGWR 曾因没空闲日志而等待，需扩容或加组 - 别只盯着事件名——点开 “Background Wait Events” 子节，确认
ARCH进程的平均等待时间是否持续 > 500ms，这是归档写慢的直接证据
翻 SQL Statistics 重点筛 Rows Processed 和 Executions 双高的语句
AWR 的 SQL 排序默认按 Buffer Gets 或 Elapsed Time，但归档压力来自 DML 的 redo 产出量，必须手动聚焦这两列。
- 筛选条件：
Rows Processed> 10000 且Executions> 100 的语句，大概率是 ETL 脚本、定时批更或应用层未分页的全表更新 - 特别留意
SQL_ID对应的执行计划：PLAN_HASH_VALUE若长期不变但Rows Processed突增，很可能是 WHERE 条件失效（如绑定变量为空）导致全表扫更新 - 如果 Top SQL 列表里根本没看到 DML，别停在这——AWR 会漏掉短连接、未缓存的 JDBC 批量操作，得切到
DBA_HIST_ACTIVE_SESS_HISTORY查sql_opname IN ('INSERT','UPDATE','DELETE')
验证是否真由 DML 引发：用 V$TRANSACTION 和 V$SESS_IO 对比
AWR 是快照汇总，有时不够实时；这两个动态视图能帮你交叉确认当前活跃事务的 redo 消耗特征。
- 运行
SELECT addr, xidusn, xidslot, xidsqn, used_ublk, used_urec FROM V$TRANSACTION ORDER BY used_ublk DESC;：看used_ublk（回滚块）和used_urec（回滚记录）是否远高于平时——高值意味着单事务修改大量数据 - 关联
V$SESSION查对应SID，再查V$SESS_IO中的BLOCK_CHANGES：该值直接反映 session 产生的 redo 量，> 10000 就值得立刻跟踪 - 注意：
V$TRANSACTION只显示未提交事务；若业务用自动提交（autocommit），就得依赖 AWR 或 ASH 历史分析
真正容易被忽略的点是：归档开销从来不是孤立存在的。它要么暴露了 SQL 写法缺陷（比如无 WHERE 的 UPDATE），要么揭示了存储链路退化（比如迁移后归档目录落在慢盘上），要么反衬出 redo 日志配置僵化（比如还用 100MB 日志文件扛 50MB/s redo）。AWR 报告只是线索入口，关键在把 Redo size per second、等待事件、SQL 行数、IO 统计这几条线串起来，才能准确定位根因。
