log file sync在ASH中高频分布是提交风暴的典型特征：应查gv$active_session_history中每秒采样数（TRUNC(sample_time,'SS')分组）、P1>10000的高延迟样本、SQL_ID与DML紧邻的LEAD(event)模式，结合SESSION_ID/SESSION_SERIAL#追踪提交节奏，定位应用层事务粒度缺陷。
直接看 log file sync 在 ASH 中的分布密度
高频小事务最典型的症状不是 CPU 高或 SQL 慢，而是大量会话在极短时间内反复卡在 log file sync 上。ASH 的秒级采样刚好能捕捉这种“脉冲式等待”。别只查 AWR 报告里那个平均 665μs 的数字——它掩盖了真实毛刺。你应该用 gv$active_session_history 按时间切片查：同一秒内有多少个采样落在 log file sync 上？如果某秒出现 20+ 条记录，基本可断定是提交风暴。
实操建议：
- 用
SAMPLE_TIME截断到秒级（TRUNC(sample_time, 'SS')），再按秒分组统计count(*) - 过滤条件必须加
event = 'log file sync'和session_state = 'WAITING'，避免混入 ON CPU 或其他事件 - 注意 RAC 环境下要查
gv$视图，并用inst_id对齐实例，否则会漏掉跨实例的同步瓶颈
关联 SQL_ID 和提交频率，识别“隐形提交者”
很多应用没显式写 COMMIT，但 JDBC 的 autoCommit=true 或 ORM 框架（如 Hibernate 的 flush + commit 组合）会在每条 DML 后自动触发提交。ASH 里的 SQL_ID 字段能帮你揪出这些“提交源头”。关键是：不要只看单条 SQL 的执行次数，要看它每次执行后是否紧跟着一次 log file sync 采样。
实操建议：
- 用
LEAD()窗口函数匹配同一会话中“DML SQL_ID → 紧邻的 log file sync”模式：LEAD(event) OVER (PARTITION BY session_id, session_serial# ORDER BY sample_time) - 重点排查
SQL_OPCODE= 2（INSERT）、6（UPDATE）、7（DELETE）且后续 100ms 内出现log file sync的组合 - 若发现某个
SQL_ID出现频次远高于其所在应用模块的业务逻辑预期（例如每秒插入 500 行却提交 500 次），就是优化切入点
检查 P1 参数值，判断日志写入是否真卡在 I/O
log file sync 的 P1 是 wait time（微秒），但它在 ASH 中记录的是采样时刻的瞬时等待值，不是最终耗时。所以不能直接拿 ASH 里的 P1 去算平均延迟。真正有用的是看它的分布：如果大量采样 P1 > 10000（即 >10ms），说明有实际 I/O 延迟；如果 P1 集中在 100~500 范围，更可能是 LGWR 调度延迟或 log buffer 争用，而非磁盘慢。
实操建议：
- 加条件
WHERE p1 > 10000查高延迟样本，再关联sample_time查当时 LGWR 的log file parallel write是否同步飙升 - 对比
gv$sysstat中redo writes和redo write time的比值，若 write time 占比突增，才指向存储问题 - 别被
log_buffer大小误导：19c 默认 100MB 已足够，盲目调大反而加剧 LGWR 批量写压力
用 SESSION_ID + SESSION_SERIAL# 追踪单一会话的提交节奏
高频小事务常来自某类客户端连接池（如 Spring Boot 的 HikariCP），它们复用连接但未开启批量提交。ASH 中同一个 SESSION_ID/SESSION_SERIAL# 若在 1 秒内出现 5+ 次 log file sync，基本可锁定该会话为“提交狂魔”。这时需要结合应用日志确认是否开启了 rewriteBatchedStatements=true（MySQL）或等效的 Oracle 批量 API（如 executeBatch）。
实操建议：
- 查
gv$session关联gv$active_session_history，获取该会话的machine、program、sql_id，定位具体服务节点 - 注意
SESSION_SERIAL#必须和SESSION_ID联合使用，单独SESSION_ID在 RAC 或会话复用场景下不唯一 - 如果发现大量会话都呈现相同节奏（如每 200ms 一次提交），大概率是应用层定时任务或轮询逻辑导致，而非数据库配置问题
ASH 分析高频小事务的核心陷阱在于：把等待事件当结果，而不是把它当作线索去反推应用行为。真正耗时的从来不是那一次 log file sync，而是它背后暴露的事务粒度设计缺陷——这点容易被 DBA 忽略，却恰恰是开发最该介入的地方。
