Top SQL Command Types按sql_opcode分类统计，直接反映系统真实业务行为，如UPDATE占比飙升90%提示行锁争用或批量改写异常，且抗硬解析干扰，需结合Program、Module定位来源，并注意Duration设置对ASH数据完整性的影响。
Top SQL Command Types能暴露真实业务行为模式
它不按sql文本或sql_id聚合，而是按sql_opcode（如2=insert、6=update、7=delete）分类统计，直接反映“系统此刻在干什么”——比如update占比突然飙升90%，说明不是慢查询问题，而是大量行锁争用或业务批量改写逻辑异常。
比Top SQL列表更抗硬解析干扰
当应用未绑定变量、频繁拼接字面量时，v$sql里可能有几百个不同sql_id，但它们的sql_opcode都是6（UPDATE），在Top SQL Command Types里会合并成一条高占比记录。你不会被碎片化SQL淹没，而是立刻看到“全是UPDATE在抢资源”。
- 常见错误：盯着Top SQL列表里排第一的
sql_id优化，结果它只占总DB Time的0.3%，而底下几十个相似UPDATE加起来占了65% - 关键判断点：如果
UPDATE或INSERT的% Activity > 40%，且enq: TX - row lock contention同步升高，基本可锁定是业务层并发更新冲突 - 注意
sql_opcode值：2=INSERT、3=SELECT、6=UPDATE、7=DELETE、47=MERGE，别把MERGE误当成UPDATE看
结合Program和Module字段才能准确定位来源
单独看Command Type没意义，必须和Program（如jdbc thin client）、Module（如OrderService.updateStock）联动——否则你只知道“UPDATE很多”，但不知道是哪个微服务、哪段代码在刷库。
- 典型场景：
UPDATE占比高 +Program=oracle@host (J000)→ 检查DBMS_SCHEDULER作业是否配置了高频重跑 -
UPDATE占比高 +Module含BatchJob→ 确认批处理是否漏加WHERE条件导致全表扫改 - 陷阱：某些ORM框架（如MyBatis）会把所有操作都标为
UNNAMED，此时得靠Client_Identifier或Machine反查应用日志
Duration填错会让Command Types数据失真
ASH报告依赖内存中v$active_session_history的采样，该缓冲区默认只保留约1小时数据。若你输的duration跨度过大（比如设为120分钟），而实际采样窗口只有50分钟，那Command Types统计会严重偏低——因为后70分钟根本没数据可算。
- 安全做法：用相对时间，如输入
-15查最近15分钟；绝对时间务必确认SAMPLE_TIME范围覆盖目标区间 - 验证方法：生成报告后，翻到“Load Profile”页，看“Total DB Time (s)”是否合理（比如15分钟采样，DB Time应接近900秒×AAS，明显偏小就说明数据缺失）
- 别信默认值：交互时脚本默认
report_type是html，但duration默认是60分钟——对瞬时问题来说，这个值太大，容易漏掉峰值
真正难的是把UPDATE占比高这个信号，和Blocking Session Status为VALID、Session State为ON CPU的Top Session关联起来——前者告诉你“在改什么”，后者告诉你“谁在卡住别人”。这两个维度不串起来看，就只是半截线索。
