Oracle Exadata查询优化咨询：高并行度扫描耗时久无DB资源利用率

1. 验证并行执行是否真正生效 #

首先确认并行提示和会话设置是否实际触发了并行扫描：

• 查询会话的并行度信息：

  SELECT sid, serial#, qcsid, degree, req_degree 
  FROM v$session 
  WHERE username = '&YOUR_USERNAME';
  

  查看degree是否等于指定的128，若远低于期望值，说明并行未正确启用。
• 检查执行计划中的并行操作：

  SELECT * 
  FROM v$sql_plan 
  WHERE sql_id = '&YOUR_SQL_ID' 
    AND operation LIKE 'PX%';
  

  若结果为空，说明CBO未选择并行执行计划。
• 确认表的并行属性：

  SELECT degree, instances 
  FROM user_tables 
  WHERE table_name = '&TABLE_NAME';
  

  若表的degree为1，建议显式指定表的并行度提示：/*+ PARALLEL(&TABLE_NAME 128) */，避免提示失效。

2. 调整并行度与相关参数 #

52核Exadata上，128的并行度可能过高，导致进程调度开销抵消并行收益：

• 尝试降低并行度至CPU核心数的1~1.5倍（如52或64），对比查询耗时。
• 检查并行进程池配置：

  SHOW PARAMETER parallel_min_servers;
  

  若parallel_min_servers为0，建议设置为核心数的一半（如26），减少并行进程启动的延迟：

  ALTER SESSION SET parallel_min_servers = 26;
  

• 临时关闭自适应多用户并行调整（避免系统自动降低并行度）：

  ALTER SESSION SET parallel_adaptive_multi_user = FALSE;
  

3. 排查存储层IO瓶颈 #

Exadata的性能瓶颈常出在存储层，需验证存储节点状态：

• 查看存储节点负载：

  cellcli -e 'LIST CELL DETAIL'
  

  重点关注CPU_UTILIZATION、IO_RATE指标，若单节点负载过高，说明表数据分布不均。
• 检查IORM（智能IO管理）是否限流：

  cellcli -e 'LIST IORM PLAN DETAIL'
  

  若查询被分配的IO优先级过低，需调整IORM计划。
• 检查表的压缩状态：

  SELECT compression, compress_for 
  FROM user_tables 
  WHERE table_name = '&TABLE_NAME';
  

  未启用压缩的表可通过混合列压缩提升扫描效率：

  ALTER TABLE &TABLE_NAME MOVE COMPRESS FOR QUERY HIGH ONLINE;
  

4. 更新表统计信息 #

过时的统计信息会导致CBO生成错误的执行计划：

EXEC DBMS_STATS.GATHER_TABLE_STATS(
    OWNNAME => '&YOUR_USERNAME',
    TABNAME => '&TABLE_NAME',
    ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
    METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
    CASCADE => TRUE
);

5. 优化查询本身 #

• 避免使用SELECT *，只查询业务需要的列，Exadata的Smart Scan会跳过不需要的列，大幅减少IO量。
• 若查询结果无需返回客户端，仅用于中间计算，可考虑将结果写入分区表或临时表，利用Exadata的批量写入优化。

6. 分析等待事件定位瓶颈 #

查询会话的等待事件，明确耗时来源：

SELECT event, wait_time, seconds_in_wait 
FROM v$session_wait 
WHERE sid = '&YOUR_SESSION_SID';

• 若等待事件为cell smart table scan且等待时间长，需聚焦存储层优化；
• 若出现latch free、enqueue等等待，需排查锁或并发冲突问题。

内容的提问来源于stack exchange，提问作者Nivas S