ORACLE异常sql解析的案例

数据库版本为Oracle 12.2.0.1，可能是南方一些比较着急的单位当年选择这个版本，大多数人是从11.2.0.4直接到19.18。开发写了一个sql，导致oracle解析时长时间未结束，cpu消耗过高，大致如下：

（上图仅为示例）实际us 和load average 都很高，操作系统cpu资源耗尽。

会话状态为WAITED SHORT TIME，貌似没等待，只是最近执行的很快，等待事件也很有迷惑性SQL*Net more data from client，可以理解为从客户端发送更多数据给服务器进程，通常都是空闲类。

如果仔细观察，可以看到异常点：LAST_CALL_ET很长时间了，92秒未结束（真实情况会一直运行），从LOGON_TIME也可以看出端倪，是好几天之前登录上来的会话。

看看活动占比

由于一直在解析，所以还看不到文本，v$sql中也没有呢。

抓个最近15分钟内ash报告看看

其他很空

看整体等待事件会话统计

这里检查sql应改为如下更合适：

sql 复制代码

select event,count(0) from v$session 
where wait_class<>'Idle' or state <> 'WAITING' group by event;

目前看：

1、会话"没有"异常等待事件（sql不同时不会有阻塞情况）

2、活动的sql"没有"具体文本

3、ash报告只有硬解析情况，仍然"没有"sql内容

看似空空，硬解析高，cpu高，到底什么原因呢？

对于有sql_id但是v$sql中看不到文本的，可以试试底层视图

sql 复制代码

set serveroutput on size unlimited pages 100 lin 200
col SQL_TEXT_1000 for a60

SELECT 
  kglobt03 AS sql_id,
  kglnahsh AS hash_value,
  kglnaobj AS sql_text_1000,
  kglnatim AS first_load_time,
  kglhdadr AS handle_address
FROM x$kglob
WHERE kglhdadr = kglhdpar  -- 只查询父游标
  AND kglobt02 != 0        -- 排除非SQL对象
  AND kglobt03='gxp4mukrxqbj6';

输出如下：

或

sql 复制代码

set serveroutput on size unlimited pages 100

SELECT kglnaobj  
FROM x$kglcursor
WHERE kglobt03 = 'gxp4mukrxqbj6'
    AND kglhdadr = kglhdpar;

较为全面的诊断方法可以通过hanganalyze，会把数据库当前状态输出到一个trc中

sql 复制代码

oradebug setmypid
oradebug unlimit
oradebug hanganalyze 3

输出如下：

查看这个trc内容

说明没有阻塞，继续下翻

能看到详细的sql文本（还在解析中的），具体的os id和sid等信息也都能看到。

查看堆栈信息

可以理解为"查询编译阶段中间结果算法"

查询当前的锁也能看到一些特殊现象

如果sql文本不同，那么就是下面这样了：

不存在阻塞情况，会话都是active的，这时就是3个CU锁：

演示sql如下：

很多括号导致的高CPU，一直在解析。

换做oracle 19c或26ai 这些版本就没事了，秒出结果。

换做达梦8，也能秒出

解决方法：开发人员修改代码，去掉这些重复的括号，如果sql里超过5层，就解决开发。