今天在跟踪一个系统视图的执行计划的时候，意外发现了这个小bug。

数据库版本9204 for Solaris。现象其实很简单，查询V$SQL视图的基表X$KGLCURSOR，发现AUTOTRACE给出的执行计划是扫描另一个核心表X$KGLOB。

SQL> SELECT COUNT(*) FROM X$KGLCURSOR;

COUNT(*)
----------
169800

1 row selected.

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=11 Card=1)
1 0 SORT (AGGREGATE)
2 1 FIXED TABLE (FULL) OF 'X$KGLOB' (Cost=11 Card=100)

对这个语句进行SQL_TRACE：

SQL> ALTER SESSION SET SQL_TRACE = TRUE;

Session altered.

SQL> SELECT COUNT(*) FROM X$KGLCURSOR;

COUNT(*)
----------
169807

1 row selected.

SQL> ALTER SESSION SET SQL_TRACE = FALSE;

Session altered.

而Trace文件中得到的执行计划是正确的：

PARSING IN CURSOR #1 len=32 dep=0 uid=0 oct=3 lid=0 tim=13924902108484 hv=2433647412 ad='dee36710'
SELECT COUNT(*) FROM X$KGLCURSOR
END OF STMT
PARSE #1:c=0,e=12843,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=13924902108471
EXEC #1:c=0,e=80,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=13924902108826
FETCH #1:c=2620000,e=2568180,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=13924904677105
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=13924904678308
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=0 r=0 w=0 time=2568154 us)'
STAT #1 id=2 cnt=169807 pid=1 pos=1 obj=282 op='FIXED TABLE FULL X$KGLCURSOR (cr=0 r=0 w=0 time=2492440 us)'

看来错误是AUTOTRACE造成的。那么看看X$KGLOB是那些视图的基表：

SQL> select view_name from v$fixed_view_definition where view_definition like '%x$kglob%';

VIEW_NAME
------------------------------
GV$ACCESS
GV$OBJECT_DEPENDENCY
GV$DB_OBJECT_CACHE
GV$DB_PIPES

4 rows selected.

X$KGLOB中的记录和对象信息有很大关系，对比X$KGLOB和X$KGLCURSOR表，发现二者的列完全一致，且里面部分记录也完全一样。怀疑Oracle在这里出了bug。

访问其他核心表未发现类似的现象。

不过一般很少会去关心核心表的访问和执行计划，因此这个bug也不会造成什么影响。