一套AIX上的9.2.0.6系统，应用的某条查询语句执行时频繁报ORA-00600:[7005]错误，alert告警日志内容如下:
Errors in file /oracle/admin/BIDW/udump/bidw2_ora_3252288.trc:
ORA-00600: internal error code, arguments: [7005], [192], [], [], [], [], [], []
Mon Dec 7 15:20:27 2009
Errors in file /oracle/admin/BIDW/udump/bidw2_ora_3252288.trc:
ORA-00600: internal error code, arguments: [7005], [192], [], [], [], [], [], []
Mon Dec 7 15:20:27 2009
Trace dumping is performing id=[cdmp_20091207152027]
Mon Dec 7 15:20:28 2009
Thread 2 advanced to log sequence 909143
Current log# 7 seq# 909143 mem# 0: /oradata2/bidw/BIDW/redo2_3
...............
Mon Dec 7 15:21:10 2009
Errors in file /oracle/admin/BIDW/udump/bidw2_ora_3600486.trc:
ORA-00600: internal error code, arguments: [7005], [192], [], [], [], [], [], []
Mon Dec 7 15:21:11 2009
Errors in file /oracle/admin/BIDW/udump/bidw2_ora_3600486.trc:
ORA-00600: internal error code, arguments: [7005], [192], [], [], [], [], [], []
相关的trace文件列出了问题SQL语句:
Dump file /oracle/admin/BIDW/udump/bidw2_ora_3252288.trc
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
*** SESSION ID:(436.20428) 2009-12-07 15:20:26.734
*** 2009-12-07 15:20:26.734
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [7005], [192], [], [], [], [], [], []
Current SQL statement for this session:
select /*t.consume_month,
*/
nvl(t.cust_count, 0),
nvl(t.net_count, 0),
nvl(t.item_1, 0),
nvl(t.item_2, 0),
nvl(t.item_3, 0),
nvl(t.item_4, 0),
nvl(t.item_5, 0),
nvl(t.item_6, 0),
nvl(t.item_7, 0),
nvl(t.item_8, 0),
nvl(t.item_9, 0),
nvl(t.item_10, 0),
nvl(t.item_11, 0),
nvl(t.item_12, 0)
from (with t as (select t.consume_month consume_month,
t.cust_count cust_count,
min(t.net_count) net_count,
round(sum(case
when substr(t.statis_month, 5, 2) = 01 then
t.call_duration / t.net_count
else
0
end),
0) item_1,
round(sum(case
when substr(t.statis_month, 5, 2) = 02 then
t.call_duration / t.net_count
else
0
end),
0) item_2,
round(sum(case
when substr(t.statis_month, 5, 2) = 03 then
t.call_duration / t.net_count
else
0
end),
0) item_3,
round(sum(case
when substr(t.statis_month, 5, 2) = 04 then
t.call_duration / t.net_count
else
0
end),
0) item_4,
round(sum(case
when substr(t.statis_month, 5, 2) = 05 then
t.call_duration / t.net_count
else
0
end),
0) item_5,
round(sum(case
when substr(t.statis_month, 5, 2) = 06 then
t.call_duration / t.net_count
else
0
end),
0) item_6,
round(sum(case
when substr(t.statis_month, 5, 2) = 07 then
t.call_duration / t.net_count
else
0
end),
0) item_7,
round(sum(case
when substr(t.statis_month, 5, 2) = 08 then
t.call_duration / t.net_count
else
0
end),
0) item_8,
round(sum(case
when substr(t.statis_month, 5, 2) = 09 then
t.call_duration / t.net_count
else
0
end),
0) item_9,
round(sum(case
when substr(t.statis_month, 5, 2) = 10 then
t.call_duration / t.net_count
else
0
end),
0) item_10,
round(sum(case
when substr(t.statis_month, 5, 2) = 11 then
t.call_duration / t.net_count
else
0
end),
0) item_11,
round(sum(case
when substr(t.statis_month, 5, 2) = 12 then
t.call_duration / t.net_count
else
0
end),
0) item_12
from hwkr.tr_sc_138_consume_analyse_m t
where t.op_code = '1145'
and t.new_join_flag = '0'
and t.statis_month >=
to_number(substr(to_char(:1, 'yyyymm'), 1, 4) || '01')
and t.statis_month <= to_number(to_char(:2, 'yyyymm'))
group by t.consume_month, t.cust_count)
select to_number(substr(t.consume_month, 5, 2)) consume_month,
t.cust_count,
t.net_count,
t.item_1,
t.item_2,
t.item_3,
t.item_4,
t.item_5,
t.item_6,
t.item_7,
t.item_8,
t.item_9,
t.item_10,
t.item_11,
t.item_12
from t
union all
select 99,
sum(t.cust_count),
sum(t.net_count),
sum(t.item_1),
sum(t.item_2),
sum(t.item_3),
sum(t.item_4),
sum(t.item_5),
sum(t.item_6),
sum(t.item_7),
sum(t.item_8),
sum(t.item_9),
sum(t.item_10),
sum(t.item_11),
sum(t.item_12)
from t) t, hwkr.tr_sc_138_m s
where s.months = t.consume_month(+)
order by s.months
----- Call Stack Trace -----
ksedmp <- ksfdmp <- kgeriv <- kgesiv <- ksesic1
<- kprcdt <- rpiacp <- kprbbnda <- kprbbnd <- qes3tExecSQL
<- qerleStart <- rwsstd <- qersoStart <- qerjoFetch <- opifch2
<- opifch <- opiodr <- ttcpip <- opitsk <- opiino
<- opiodr <- opidrv <- sou2o <- main <- start
----------------------------------------
SO: 7000003c3970640, type: 4, owner: 7000003c3708368, flag: INIT/-/-/0x00
(session) trans: 7000003dbd0d170, creator: 7000003c3708368, flag: (41) USR/- BSY/-/-/-/-/-
DID: 0002-012E-0001F21C, short-term DID: 0000-0000-00000000
txn branch: 0
oct: 3, prv: 0, sql: 700000437fc5fd8, psql: 700000437fc5fd8, user: 214/BIOP
O/S info: user: , term: , ospid: 1234, machine: BIDM2
program:
client info: 10.110.16.106
last wait for 'db file scattered read' blocking sess=0x0 seq=21 wait_time=28955
file#=129, block#=10088, blocks=3
temporary object counter: 0
----------------------------------------
Plan Table
--------
-------------------------------------------------------------------------------------------------------------------------
| Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
| SELECT STATEMENT | | 0 | 0 | 0 | | | | | |
| MERGE JOIN OUTER | | 0 | 0 | 0 | | | | | |
| SORT JOIN | | 0 | 0 | 0 | | | | | |
| TABLE ACCESS FULL | TR_SC_138_M | 0 | 0 | 0 | | | | | |
| SORT JOIN | | 0 | 0 | 0 | | | | | |
| VIEW | | 0 | 0 | 0 | | | | | |
| | | 0 | 0 | 0 | | | | | |
| UNION-ALL | | 0 | 0 | 0 | | | | | |
| VIEW | | 0 | 0 | 0 | | | | | |
| TABLE ACCESS FULL | SYS_TEMP_4255117445| 0 | 0 | 0 | | | | | |
| SORT AGGREGATE | | 0 | 0 | 0 | | | | | |
| VIEW | | 0 | 0 | 0 | | | | | |
| TABLE ACCESS FULL | SYS_TEMP_4255117445| 0 | 0 | 0 | | | | | |
-------------------------------------------------------------------------------------------------------------------------
经过研究发现可能是9.2.0.6版本上的Bug 3390566 "OERI / dump from functional indexes on TIMESTAMP columns"，当使用存在TIMESTAMP列的函数索引时可能引发该Bug。这个Case同时提交了SR，Oracle GCS建议通过避免使用该索引的Workaround方式，因为原执行计划利用到了星型变化，故可以通过设置STAR_TRANSFORAMTION_ENABLED=FALSE来避免使用索引。当然长久之计还是升级到9.2.0.7以上版本(MOS宣称此Bug在该版本修复了)。
Setting STAR_TRANSFORAMTION_ENABLED=FALSE has been successfully used.
As a permanent solution, it is recommended to start planning for an upgrade to a supported Database Server version.
Currently supported Server versions are ver. 10.2, 11.1 and 11.2 with their latest patchsets.
Bug 3390566 is solved since 9.2.0.7.
Advantages for being on the latest patchset of a supported release:
+ new bugs can only be logged against latest patchset release of supported versions
+ backports can only be requested against latest patchset release of supported versions
+ most stable release since a lot of bugs are already fixed in the successive patchsets