遭遇ORA-07445 的一個BUG

問題描述：
早上剛上班，開發的報告說一個很簡單的查詢不能執行，查詢語句如下：
SELECT * FROM DEAL WHERE CODE IN ('12', '13') ORDER BY BEGINDATE desc
我自己登陸上去，查詢一下，果然報錯，錯誤資訊如下：
SQL> SELECT * FROM DEAL WHERE CODE IN ('12', '13') ORDER BY BEGINDATE desc;
SELECT * FROM DEAL WHERE CODE IN ('12', '13') ORDER BY BEGINDATE desc
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

ERROR:
ORA-03114: not connected to ORACLE

[@more@]

這是一個最簡單的查詢，是一個簡單的查詢兩種型別的交易，然後把這些交易按照交易開始時間進行一個倒序排列。後來也沒大注意，結果一會功夫，收到了系統的報警郵件，alert檔案中有ORA-07445錯誤，錯誤資訊如下：
Errors in file /u01/app/oracle/admin/stream/udump/stream_ora_11780.trc:
ORA-07445: exception encountered: core dump [qkkMatchPrefix2()+72] [SIGSEGV] [Address not mapped to object] [0x000000004] [] []
檢視相關的trace檔案，裡面全部是一堆記憶體的dump天書。後來查了半天，終於發現了一點眉目，這個問題和下面的bug很相似：
4540140 Dump (qkkMatchPrefix2) from INLIST with subpartitions
上面這點資訊是在ORACLE 10.2.0.3 的patch的bug fix中看到的，而deal表是按照begindate進行的range分割槽，每10天一個分割槽，然後對code進行了子hash分割槽。因此從這裡看到，這個錯誤和上面的bug fix中的描述是一致。隨後換了幾個機器，都有這個bug存在。
當時的DB環境如下：
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - Production

OS環境如下：
[oracle@stream bdump]$ more /etc/issue
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)

總結：每個版本的oracle都會有很多bug，還是應該及時跟蹤一下每個版本的bug，出現問題的時候容易快速的定位和解決。