如何使用Oracle Exadata环境中的AWR诊断Smart Scan-Oracle-PHP中文网

Exadata中AWR通过cell table/index smart scan等待事件平均延时（应＜2ms，＞30ms表明路径受阻）、IO offload比率及实时视图综合诊断Smart Scan实效性。

如何使用oracle exadata环境中的awr诊断smart scan

Exadata环境中的AWR能直接反映Smart Scan是否生效、效果如何，但必须看对指标——只盯“等待事件平均时间”或“SQL执行时间”会漏掉关键信号。

查`cell table smart scan`和`cell index smart scan`等待事件的平均延时

这两个等待事件是Smart Scan的“心跳”。正常情况下，它们的AVERAGE_WAIT应稳定在2ms以下；超过10ms就该警惕，超过30ms基本可判定智能扫描路径受阻。

不是所有SQL都触发这两个事件——只有走全表扫描、分区扫描且谓词可下推到存储层的语句才可能产生
如果某SQL本该Smart Scan，却完全没出现这两个事件，说明根本没进入智能扫描路径（比如被Quarantine拦截、谓词含函数/绑定变量类型不匹配）
用如下SQL快速定位异常快照：

SELECT s.snap_id, 
       TO_CHAR(s.begin_interval_time,'YYYY-MM-DD HH24:MI') snap_time,
       e.event_name,
       ROUND(e.time_waited_micro/1000/e.total_waits, 2) avg_ms,
       e.total_waits
FROM dba_hist_system_event e
JOIN dba_hist_snapshot s ON e.snap_id = s.snap_id AND e.dbid = s.dbid
WHERE e.event_name IN ('cell table smart scan', 'cell index smart scan')
  AND e.total_waits > 0
  AND s.begin_interval_time >= SYSDATE - 3
ORDER BY avg_ms DESC, s.snap_id DESC
FETCH FIRST 10 ROWS ONLY;

核对`cell physical IO bytes eligible for predicate offload`与实际传输量

这个指标代表“理论上可被存储节点过滤的数据量”，而cell physical IO interconnect bytes是“实际从存储传到数据库的字节数”。两者的差值，就是Smart Scan节省的IO。

理想情况：cell physical IO interconnect bytes ≪ cell physical IO bytes eligible for predicate offload（比如后者是前者的1/10）
异常情况：两者几乎相等 → Smart Scan未生效，全部数据块以Passthru模式传输
常见诱因：SQL_ID被加入Quarantine、时区升级后谓词无法下推、存储索引失效（V$CELL_STATE中storageIndexEnabled为NO）

结合`DBA_HIST_SQLSTAT`下钻具体SQL的Smart Scan使用率

单条SQL是否真正受益，不能只看等待事件，得看它在历史快照中“有多少次执行用了Smart Scan”。关键字段是io_cell_offload_eligible_bytes和io_interconnect_bytes。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

计算公式：(io_cell_offload_eligible_bytes - io_interconnect_bytes) / NULLIF(io_cell_offload_eligible_bytes, 0) → 越接近1.0越好
注意：io_cell_offload_eligible_bytes = 0意味着该SQL从未满足Smart Scan条件（如走了索引唯一扫描、用了不可下推的函数）
若某SQL在不同快照中该比率波动极大（比如从0.95降到0.05），重点检查是否被动态Quarantine、或执行计划突变导致谓词丢失

别忽略`V$SQL`和`V$SESSION`里的实时线索

AWR是“事后回放”，而实时诊断常需交叉验证。当发现AWR中Smart Scan指标异常时，立刻查当前会话：

SELECT sql_id, sql_text FROM v$sql WHERE sql_id = 'xxx' AND io_cell_offload_eligible_bytes > 0 —— 确认SQL本身支持offload
SELECT event, p1text, p1, p2text, p2 FROM v$session_wait WHERE sid = AND event LIKE 'cell%' —— 看是否卡在cell smart table scan的提交阶段（p1=cell hash，p2=wait count）
SELECT * FROM v$cell_state WHERE state != 'online' —— 排除存储节点临时离线或Quarantine状态未清除

真正难处理的，往往不是Smart Scan“没开”，而是它开了却“没省多少IO”——这时候问题通常藏在存储索引的列选择性、谓词写法（比如TO_CHAR(col) = '2024'）、或Quarantine策略的粒度控制上，AWR只能告诉你“结果坏了”，定位根因还得靠这些实时视图和SQL重写验证。