love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

11.2.0.4版本仍然存在的一个未修复Bug ora-00600 [13013]

之前某客户的报表系统在运行业务期间遭遇Ora-00600 [13013]错误;该错误本质上来讲是非常常见的;如果大家搜索也会发现有部分bug的存在。然而根据的要求,必须要有一个最终结论。熟悉我们来看下报错:

ORA-00600: internal error code, arguments: [13013], [5001], [3636415], [98890439], [54], [98890439], [17], [], [], [], [], []

针对该错误,Oracle mos有文档进行了解释,这里不多说:

ORA-600 [13013] [a] [b] [c] [d] [e] [f]

Arg [a] Passcount
Arg [b] Data Object number
Arg [c] Tablespace Relative DBA of block containing the row to be updated
Arg [d] Row Slot number
Arg [e] Relative DBA of block being updated (should be same as [c])
Arg [f] Code

根据查询我们可以很容易定位到是什么表:

这里为什么表名称带时间呢?我们进一步看下报错的业务代码:

其中上述代码为存储过程FSD.PR_PT_PARTY_FIN_REPT_H 中一部分代码;这里之所以出现了表名称带月份的原因是因为存储过程在执行时传入了相关参数;这一点从报错的trace文件中也可以验证这一点:

ORA-00600: internal error code, arguments: [13013], [5001], [3636415], [98890439], [54], [98890439], [17], [], [], [], [], []

……

al8sqlp: at 0x7ffee7411240

[49474542 5250204E 5F54505F 54524150]  [BEGIN PR_PT_PART]

[49465F59 45525F4E 445F5450 485F4C54]  [Y_FIN_REPT_DTL_H]

[2C313A28 3B29323A 444E4520 DE54003B]  [(:1,:2); END;.T.]

我们进一步来看下trace文件的堆栈信息:

从堆栈来看在update时报错。由于该问题发生的时间比较久了,用户之前已经对表进行了重建,因此现在在客户环境无法再重现了。因此我们只能自己想办法了。

经过分析Oracle 有2个bug的描述是非常像的。

Bug 16086769 – ORA-600 [13011] ORA-600 [13013] when executing a DML if the WHERE clause includes an added column with a default value (Doc ID 16086769.8)

Bug 12345717 – ORA-600 [13013] or hang/spin from MERGE into table with added column (Doc ID 12345717.8)

其中下面这篇文档虽然提及到的是merge报错,但是文中提到的堆栈信息基本上一致;同时该文档提供了脚本的测试验证脚本;这里我们在测试环境中(版本和PSU跟客户环境一致)进行了测试并复现了该问题。如下是简单的测试过程:

进一步分析上述trace文件发现,确实存在针对列的compcol操作:

kflag

[0] CMPCOL

cmpp (2) c1 02

[1] CMPCOL

cmpp (2) c1 03

[2] CMPCOL

cmpp (1) 43

[3] UPDCOL

updp (5) 78 78 78 78 78

updrowFastPath: kddlkr objn 80978 table 0  rowid 00013c52.014005a7.1 code 17

updThreePhaseExe:objn=80978 pass=4999 stat=2 err=17

updThreePhaseExe:began locking pass 5000

这里tab1测试表前面2个列是含非null default的。因此存在cmpcol操作。对于第三个不含not null default的,则操作为updcol。

下面我们来调整数据库参数规避该问题:

此时的dml trace中的内容如下:

可见此时是没有任何问题的,通过调整该参数成功避免了该问题。

该问题本质上是Oracle 11.1引入的一个新特性;然而也引入了一些Bug。从测试来看在11.2.0.4.180717 这个版本都仍然存在。不过我们测试12.2.0.1版本已经不存在这个问题(既然参数保持默认值)。

Leave a Reply

You must be logged in to post a comment.