sql_trace跟踪分析方法

今天在一套生产的库中执行脚本查询锁住的对象，执行下面一个SQL：

select username, lockwait, status, machine, program
  from v$session
 where sid in (select session_id from v$locked_object);

结果这么简单的一条语句竟然执行了30多秒，然后在其它环境中都是秒出，这显然有问题，那么我们该如何定位问题所在呢？

SQL_TRACE是Oracle提供的用于进行SQL跟踪的手段，是强有力的辅助诊断工具。我们可以通过sql_trace去分析下为什么上面的sql会这么慢。

#对当前的会话开启sql_trace

SQL> alter session set sql_trace=true;

Session altered

SQL> select username, lockwait, status, machine, program
  from v$session
 where sid in (select session_id from v$locked_object);

no rows selected

#关闭当前会话的sql_trace
SQL> alter session set sql_trace=false;

Session altered.

接下来找到对应的trace文件，利用tkprof工具将得到的trace文件格式化，输出结果如下：

可以看到执行了36s之多，明显有问题的地方就是执行计划里面显示X$KTADM这张表竟然有2000万之多，显然有问题！还有X$KTCXB表显示有70多万，显然也不正确。

可以看到实际值与之相差很多。这说明数据字典中记录的统计信息与实际情况不符合，那么我们只需要重新收集这两张表的统计信息即可。

然后我们再去执行同样的语句结果就秒出了！