ASH无法反映高并发只读事务性能表现，因其不采样无等待、亚秒级、纯ON CPU的活跃会话；真实压力需通过v$session会话数、v$sysstat执行量及v$im_segments缓存命中率等指标捕捉。
ASH 在 Oracle 23c 中无法直接反映高并发只读事务的“性能表现”，因为它根本不会对纯只读、无等待、无资源争用的会话采样——这类事务大概率压根不出现在 v$active_session_history 里。
为什么高并发只读事务在 ASH 中“隐身”
Oracle ASH 的采样逻辑是：每秒检查一次所有 STATUS = 'ACTIVE' 且 STATE = 'WAITING' 或刚完成等待进入 CPU 运行的会话。但高并发只读事务（如简单 SELECT + 结果集小 + 全内存访问）往往：
- 执行时间远小于 1 秒，未被采中
- 不触发任何等待事件（event 为 ON CPU 或空）
- 若使用 Result Cache 或 In-Memory Column Store，连逻辑读都大幅下降，更难留下痕迹
- Escrow 列控制等新特性进一步压缩了锁/闩争用，反而让 ASH “更安静”
查不到不等于没压力：替代观测点必须切换
别在 v$active_session_history 里死磕 SQL_ID 和 EVENT，转向以下三个更敏感的实时指标：
- v$session 中 status = 'ACTIVE' 且 command = 3（SELECT）的会话数突增，配合 sql_id 聚合看分布
- v$sysstat 里 execute count、parse count (hard)、CPU used by this session 的分钟级增幅（用 DBA_HIST_SYSSTAT 回溯时注意采样间隔）
- v$im_segments（In-Memory）或 v$result_cache_memory 的命中率骤降，说明只读流量已冲垮缓存层
如果非要从 ASH 挖线索：过滤条件必须极窄且带上下文
真要扫 ASH，不是查“有没有只读事务”，而是查“只读事务在哪卡住了”。典型场景是并发 SELECT 触发了意外争用：
- 检查 event IN ('latch: shared pool', 'cursor: pin S wait on X', 'enq: KO - fast object checkpoint')，这些常出现在高并发硬解析或对象刷新时
- 加强过滤：sample_time > SYSDATE - 1/288（最近 5 分钟）、session_type = 'FOREGROUND'、sql_id IS NOT NULL
- 必须 GROUP BY sql_id, plan_hash_value, event，否则并行查询的多个 PX 进程会把同一条 SQL 计成 N 倍
- 示例语句：
SELECT sql_id, plan_hash_value, event, COUNT(*) samples<br>FROM v$active_session_history<br>WHERE sample_time > SYSDATE - 1/288<br> AND session_type = 'FOREGROUND'<br> AND event IN ('latch: shared pool', 'cursor: pin S wait on X')<br>GROUP BY sql_id, plan_hash_value, event<br>ORDER BY samples DESC;
Escrow 特性下更要警惕“假平静”
Oracle 23c 的 Escrow Column Concurrency Control 让高频只读+轻量更新混跑更稳，但也掩盖了真实瓶颈：
- 它不产生传统锁等待，所以 enq: TX 类事件消失，但可能引发 gc current block busy（RAC）或 read by other session（单机缓冲区争用）
- 这类事件在 ASH 中采样率低、持续时间短，容易被忽略
- 此时应同步看 v$segment_statistics 中对应表的 logical reads 和 buffer busy waits 累计值变化速率，比 ASH 更早暴露毛刺
真正高并发只读的压力，从来不在 ASH 的“有无”，而在它“不该有却出现”的那几行 event —— 那些零星闪现的 latch、cursor、gc 等待，才是系统开始喘气的信号。盯着它们比统计“有多少条 SELECT 出现在 ASH 里”有用十倍。
