AWR报告中Exadata Server Configuration、Exadata Server Health Report、Exadata Performance Statistics三章节直接暴露Cell瓶颈：前者标出配置不一致（如补丁版本或Flash Cache大小差异），健康报告揭示OFFLINE DISKS或OPEN ALERTS等失效状态，性能统计中Smart Scan效率低于85%或Flash Cache命中率骤降则锁定I/O路径问题。
AWR报告里哪几个Exadata章节直接暴露Cell瓶颈
看AWR报告时，别跳过Exadata专属模块——它不是装饰，而是Cell级问题的第一道显影剂。关键就三块：Exadata Server Configuration、Exadata Server Health Report、Exadata Performance Statistics。前两块告诉你“有没有问题”，第三块告诉你“问题在哪台Cell上、是什么类型”。
配置差异会用颜色标出：比如某台Cell的cell software version比其他低一个补丁号，或flash cache size明显偏小，这类不一致本身就是潜在瓶颈源；健康报告里出现OFFLINE DISKS或OPEN ALERTS（如CELL-01234），说明该Cell已部分失效；性能统计中若某Cell的smart scan efficiency持续低于85%，或cell flash cache read hits骤降，基本可锁定为I/O路径瓶颈。
如何用AWR裸数据查具体Cell的I/O延迟和Smart Scan失败率
AWR报告只给汇总值，真要定位到某台Cell的毫秒级延迟或Smart Scan被绕过的具体比例，得查底层视图。核心是DBA_HIST_CELL_GLOBAL和DBA_HIST_CELL_IO_RECOVERY，它们记录每台Cell每小时的原始指标。
-
DBA_HIST_CELL_GLOBAL里重点关注IO_WAITS、IO_WAITS_SEC（单位秒）、SMART_SCAN_BYTES_RETURNED与BYTES_PROCESSED的比值——比值 - 用
cell_name字段关联DBA_HIST_CELL_GLOBAL和DBA_HIST_CELL_IO_RECOVERY，后者里的RECOVERED_IO_COUNT突增，往往对应Cell内部Flash Cache故障或网络丢包 - 别漏掉
DBA_HIST_CELL_THREAD，它记录Cell内部线程等待，THREAD_WAIT_TIME异常高（>100ms）说明Cell CPU或调度已饱和
cell external table smart scan等待事件飙升时怎么交叉验证
当cell external table smart scan等待时间暴涨，不能只盯着这个事件本身——它只是现象，背后可能是Cell资源争用、网络拥塞或外部表设计缺陷。必须做三路交叉验证：
- 查
DBA_HIST_SYSTEM_EVENT中该事件的TIME_WAITED，同时对比同时间段cell flash cache read hits是否同步下跌（说明Flash Cache失效迫使Cell退化为直读磁盘） - 用
DBA_HIST_CELL_GLOBAL查对应Cell的NETWORK_IN_KBYTES和NETWORK_OUT_KBYTES，若NETWORK_IN_KBYTES远高于SMART_SCAN_BYTES_RETURNED，证明谓词下推失败，全量文件被拉到DB节点 - 检查外部表定义：是否用了不支持Smart Scan的格式（如gzip未启用
ORACLE_LOADER）？是否WHERE条件含函数导致谓词无法下推？这类问题在V$SQL里查sql_text就能确认
基线对比时容易忽略的Cell维度陷阱
建基线时多数人只比AWR报告整体指标，但Exadata的Cell瓶颈常表现为“局部恶化+全局掩盖”：一台Cell性能跌50%，其余9台正常，整体Average Active Session可能只涨5%。所以基线必须按Cell粒度建。
执行CREATE_BASELINE时，别只用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE默认参数；要配合DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE，指定cell_name作为过滤维度，并把DBA_HIST_CELL_GLOBAL纳入基线快照采集范围。否则基线里根本看不到Cell级波动，等真出问题时再回溯，裸数据可能已被AWR清理策略删掉。
