Oracle 查询慢排查

最新推荐文章于 2026-05-19 05:21:32 发布

原创最新推荐文章于 2026-05-19 05:21:32 发布 · 9.6k 阅读

15 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#oracle #sql

生产环境中，Oracle RAC查询出现偶尔缓慢的问题，通过更换数据连接池、切换数据库节点定位到是节点1的问题。进一步查找发现SQL_ID，清空问题SQL在节点1的shared pool后，查询恢复正常。原因是Oracle节点的shared pool缓存导致的查询效率问题。

生产环境Oracle 查询慢排查

现象是生产环境Oracle rac有一个查询很慢（比较少用），查询大概10秒钟才返回，但是有时又很快，而且其他的查询都没问题。
但是把sql语句单独在pl/sql 上执行也很快，执行计划也没有啥问题，有走索引。
打开debug日志，发现不了什么，就是数据库返回的时间很慢，又不是每次都必现。
初步怀疑是druid的问题、或者是oracle rac集群的问题。
开始疑难杂症必备的排除大法。
把数据库连接池druid换成springboot 默认的hikari，现象依旧。排除了druid的问题。
把数据源配置改为只连接到节点1，现象依旧。排除oracle rac的问题。
把数据源配置改为只连接到节点2，查询变快了。
所以定位到是数据库节点1的问题。
所以还是百度下，搜到类似现象。搜索关键字是关键(oracle一个节点查询慢,另一个节点查询快)
在这里插入图片描述
现象非常一致，想了一下，非常有可能是这个原因。
接下来问题是不知道这个sql的SQL_ID。也可以清空所有shared pool ，执行alter system flush shared_pool;这样风险比较大。
所以还是优先找到SQL_ID

select *
 from (select sa.SQL_ID,sa.SQL_TEXT,
        sa.SQL_FULLTEXT,
        sa.EXECUTIONS "执行次数",
        round(sa.ELAPSED_TIME / 1000000, 2) "总执行时间",
        round(sa.ELAPSED_TIME / 1000000 / sa.EXECUTIONS, 2) "平均执行时间",
        sa.COMMAND_TYPE,
        sa.PARSING_USER_ID "用户ID",
        u.username "用户名",
        sa.HASH_VALUE
     from v$sqlarea sa
     left join all_users u
      on sa.PARSING_USER_ID = u.user_id
     where sa.EXECUTIONS > 10 and u.username='UUY'
     order by (sa.ELAPSED_TIME / sa.EXECUTIONS) desc)
 where rownum <= 10;

同个这个sql找到平均耗时最长的几个sql，找到了问题sql

select address, hash_value, sql_text   

  from v$sqlarea    
 where sql_id = '8h96b2czq4n1f';

找到address=000000255D74D848
hash_value=1063407662

接下来清空节点1的这个耗时长的sql的shared pool

call sys.dbms_shared_pool.purge('000000255D74D848,1063407662','C');

再次查询

select address, hash_value, sql_text   

  from v$sqlarea    
 where sql_id = '8h96b2czq4n1f';

已经清空。
节点1的查询也恢复正常了。

总结一下，我的理解是oracle 节点会把sql语句解析后的结果缓存在shared pool中，这样每次遇到相同的sql就无需再次解析，直接调用。不知道什么情况下（可能太久没有重启），有一个节点的这个sql的shared pool出现问题，没有走索引了，所以流到这个节点的这个sql都查询很慢，而在另一个节点没有影响。

解决方法可以重启节点（清空所有缓存）、手动清空所有shared pool、手动清空出问题这条sql的shared pool