******为了保护隐私，本文档部分敏感字段做过处理******
OS
AS4u6x86_64
Oracle software
10.2.0.2
Happen Date
2009-2-12
Error code
ORA-00600: internal error code, arguments: [6302] , [20], [], [], [], [], [], []
Happen Status
In the Alert.log, find this:
Errors in file $udump/dbname_ora_17164.trc:
ORA-00600: internal error code, arguments: [6302], [20], [], [], [], [], [], []
View $udump/dbname_ora_17164.trc:
*** 2009-02-12 13:44:04.659
*** SERVICE NAME: (…) 2009-02-12 13:44:04.659
*** SESSION ID: (941.63651) 2009-02-12 13:44:04.659
key1 (20):63 66 68 66 67 67 67 32 30 30 38 40 31 32 36 2e 63 6f 6d 00
key2 (19):63 66 68 66 67 67 67 32 30 30 38 40 31 32 36 2e 63 6f 6d
*** 2009-02-12 13:44:04.659
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [6302], [20], [], [], [], [], [], []
Current SQL statement for this session:
INSERT INTO table1 (col1, col2, col3, col4, EMAIL, col6, col7, col8, col9, col10, col11) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11)
…初步判断在插入记录时由不可知原因出错，导致插入没成功。
通过metalink上的600查看工具搜索第一个参数，没找到完全一致的bug，但相关的bug多与索引相关。再查看该表，发现在email字段建有索引，由此怀疑可能跟该字段的索引有关。Trace文件中有：
key1 (20):63 66 68 66 67 67 67 32 38 38 38 40 38 38 38 2e 63 6f 6d 00
key2 (19):63 66 68 66 67 67 67 32 38 38 38 40 38 38 38 2e 63 6f 6d
转换出来
SQL>selectUTL_RAW.CAST_TO_VARCHAR2('6366686667676732383838403838382e636f6d00') from dual;
UTL_RAW.CAST_TO_VARCHAR2('6366
--------------------------------------------------------------------------------
[email protected]
查看table1是否有相关数据：
select * from table1 where email= '[email protected]' ;
没有记录。
select * from table1 where email like '[email protected]%' ;
有两条记录，但都是去年的交易记录了，再把email字段转成ASCII码
SQL>selectUTL_RAW.CAST_TO_RAW(email) from table1;
UTL_RAW.CAST_TO_RAW(EMAIL)
--------------------------------------------------------------------------------
6366686667676732303038403132362E636F6D00
6366686667676732303038403132362E636F6D
果然看到有一条记录的结尾为’00’！
再往下查看trace文件，找到insert语句中绑定变量的值
Bind#4
oacdty=01 mxl=128(72) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=304
kxsbbbfp=3528bbcfb8bln=128avl=18flg=01
value="[email protected]"
与此同时， alert.log由开始的一次，每6分钟两次，到后来每6分钟会抛三次这样的错误出来，经与开发人员沟通，确定除正常业务流程中会往该表插入记录外，还有一个定时任务每6分钟会把没有处理成功的交易再重试一遍。此段时间内在不断重试的是三笔交易，把该三笔交易信息取出来，再把最新的报错中trace文件也搜索一遍，确定就是此三笔交易，且email字段的值分别为：
[email protected]
[email protected]
[email protected]
竟然都是字母c开头，而脏数据也是字母c开头！！！
是索引坏了吗？这期间该表仍有新数据插入，只是不再有email字段是c开头的记录。
尝试更新一条记录的email字段为[email protected]，再次触发该600错误。
由此，更加坚定了是该索引在作怪。
遂删除索引，修复脏数据，再重建索引
drop index table1_EMAIL;
update table1 set email='[email protected]' where email like '[email protected]%';
create index table1_EMAIL on table1 (EMAIL);
一切都恢复了正常（世界从此清净了，呵呵）
看似问题解决了，现在的疑问是该脏数据在去年就已经进到该表了，为什么之前都运转正常，现在才出这个问题？也就是说，什么样的情况才能触发该错误呢？是索引该数据所在的块填满了吗？还是……？
[ 本帖最后由 sonia_zhai 于 2009-2-13 16:35 编辑 ]
|
