核心表AUTOTRACE結果出錯

yangtingkun發表於2007-07-26

今天在跟蹤一個系統檢視的執行計劃的時候,意外發現了這個小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$KGLOBX$KGLCURSOR表,發現二者的列完全一致,且裡面部分記錄也完全一樣。懷疑Oracle在這裡出了bug

訪問其他核心表未發現類似的現象。

不過一般很少會去關心核心表的訪問和執行計劃,因此這個bug也不會造成什麼影響。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4227/viewspace-69363/,如需轉載,請註明出處,否則將追究法律責任。

相關文章