首页 » Cloud, ORACLE 9i-23ai » Troubleshooting ORA-00600: 内部错误代码 [kdt_bseg_srch_cbk PITL1]

Troubleshooting ORA-00600: 内部错误代码 [kdt_bseg_srch_cbk PITL1]

  • 2020/07/22
  • Cloud, ORACLE 9i-23ai
  • 242 views
  • Troubleshooting ORA-00600: 内部错误代码 [kdt_bseg_srch_cbk PITL1]已关闭评论

数据库alert log中出现了下面错误 ,环境oracle 19.3

 
ORA-00600: 内部错误代码, 参数: [kdt_bseg_srch_cbk PITL1], [2], [], [], [], [], [], [], [], [], [], []

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
[TOC00003]
----- Current SQL Statement for this session (sql_id=2avh059ktb0s4) -----
UPDATE /*+ index(a twhxxx$idx1) */ erpdb.twxxx a SET t$acip=:1 WHERE a.t$cwar=:2 AND a.t$item=:3 AND a.t$year=:4 AND a.t$peri=:5
[TOC00003-END]

[TOC00004]
----- Call Stack Trace -----

----- Abridged Call Stack Trace -----
kgeadse()+447<-kgerinv_internal()+44
<-kgerinv()+40<-kgeasnmierr()+146<-kdt_bseg_srch_cbk()+8107<-ktspfpblk()+618<-ktspfsrch()+788<-ktspscan_bmb()+498<-ktspgsp_main()+1271 
----- End of Abridged Call Stack Trace -----

Object id on Block? Y
 seg/obj: 0x13fdf3  csc:  0x00000005cf7345ac  itc: 21  flg: E  typ: 1 - DATA
     brn: 1  bdba: 0x5064d20 ver: 0x01 opc: 0
     inc: 0  exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0014.01e.0024f127 0x0144fdb4.fb70.11 --U- 1 fsc 0x0000.cf7346d5
0x02 0x001a.006.0007c114 0x010a62c9.dfa7.10 C--- 0 scn 0x00000005cf58f02b
0x03 0x000d.014.000401f2 0x0162c698.da3c.0d C--- 0 scn 0x00000005cf5fff24
0x04 0x0024.002.000e1a7e 0x014027c6.51c4.0d --U- 1 fsc 0x0000.cf7348b4
0x05 0x0023.017.000c9e62 0x01405311.1b2b.2b C--- 0 scn 0x00000005cf5d072b
0x06 0x0024.016.000e164e 0x01471792.51b0.10 C--- 0 scn 0x00000005cf65f6eb
0x07 0x0024.020.000e14a2 0x01465164.51a6.10 C--- 0 scn 0x00000005cf5d070c
0x08 0x0014.00f.0024efc4 0x01670707.fb6c.04 C--- 0 scn 0x00000005cf6004e0
0x09 0x0019.013.0008afc1 0x010a65d5.ef56.1c C--- 0 scn 0x00000005cf5912b4
0x0a 0x0011.003.00043488 0x01401236.d735.27 --U- 1 fsc 0x0000.cf734873
0x0b 0x0013.005.000a3814 0x0162fa7e.5077.1d C--- 0 scn 0x00000005cf5d0a40
0x0c 0x0024.01e.000e166d 0x01471739.51b0.06 C--- 0 scn 0x00000005cf65f647
0x0d 0x0014.007.0024efbc 0x01670dd2.fb6c.21 C--- 0 scn 0x00000005cf65f72c
0x0e 0x0024.021.000e1512 0x0146917b.51aa.18 C--- 0 scn 0x00000005cf5ffded
0x0f 0x0014.00e.0024f0b1 0x0144fe23.fb70.12 --U- 1 fsc 0x0000.cf7349c6
0x10 0x0024.020.000e1630 0x014717a9.51b0.0d C--- 0 scn 0x00000005cf65f6f0
0x11 0x000b.005.00043d4c 0x0165f224.e4b4.0a --U- 1 fsc 0x0000.cf736db4
0x12 0x0024.021.000e1478 0x0146512c.51a6.20 C--- 0 scn 0x00000005cf5d0613
0x13 0x0024.019.000e15b2 0x014691b4.51aa.10 C--- 0 scn 0x00000005cf5ffe8d
0x14 0x0014.003.0024f063 0x01670d0e.fb6c.14 C--- 0 scn 0x00000005cf654ebb
0x15 0x0014.01e.0024f12b 0x0144ff85.fb70.05 --U- 1 fsc 0x0000.cf736b47
bdba: 0x0391194d
data_block_dump,data header at 0x971f15822c
===============
tsiz: 0x7dd0
hsiz: 0x588
pbl: 0x971f15822c
76543210
flag=-0------
ntab=2
nrow=686
frre=-1
fsbo=0x588
fseo=0x82b
avsp=0x854
tosp=0x854
r0_9ir2=0x0
mec_kdbh9ir2=0x23
76543210
shcf_kdbh9ir2=----------
76543210
flag_9ir2=0-R-LNOC Archive compression: N
fcls_9ir2[0]={ }
perm_9ir2[13]={ 10 12 7 9 11 0 1 2 8 3 4 5 6 }
0x24:pti[0] nrow=108 offs=0
0x28:pti[1] nrow=578 offs=108
0x2c:pri[0] offs=0x7aa5
0x2e:pri[1] offs=0x7a0c

tab 0, row 0, @0x7aa5
tl: 5 fb: --H-FL-- lb: 0x0  cc: 10
col  0: [ 1]  80
col  1: [ 1]  80
col  2: [ 1]  80
col  3: [ 1]  80
col  4: [ 1]  80
col  5: [ 1]  80
col  6: [ 1]  80
col  7: [ 3]  c2 15 15
col  8: [ 1]  80
col  9: [ 2]  c1 05
bindmp: 00 54 0a 17 42

Note:
块上有21个ITL ,该块仍然有一些可用空间（avsp = tosp = 0x854：可用空间=总空间= 4124字节）未到ITL上限，block也未满。

ORA-00600 [PITL1]
ORA-00600 [kdt_bseg_srch_cbk PITL1]
ORA-00700: soft internal error, arguments: [kgegpa:parameter corruption]

有时会伴随ora-700,ORA-700是所谓的“软”断言。当调用者想要记下发生了意外的事实但由于失败对流程或实例没有致命影响而希望继续发生时，会触发软断言。它是在12c中引入的，并得到了一些ORA-600消息（信息性消息），而将ORA-600留给了更多关键问题。

MOS中比较符合Bug:29782211 If a table that is OLTP compressed or which has been OLTP compressed at some point in its lifetime generates any of the errors listed above,
then this bug may be the cause.

kdt_bseg_srch_cbk
====》kernel data table insert check for uncommitted space

要解决此问题：在RDBMS上修复bug 29782211，或禁用压缩对表上数据进行重组（注意禁用压缩的DDL只影响以后数据变化）。建议您在表重组期间也根据Oracle的建议增加PCTFREE, 当前表是个update，用更大的PERCENT FREE重新创建表将为ITL腾出更多空间。

如果当前表定义中是禁用压缩时，建议使用dbms_compression.get_compression_type检查数据是否为压缩。

使用dump信息可以生成rowid, 另外在dump trace中没有看到Compression level: 01 (Query Low)等关键字, 不确认该块是否启用压缩，但是”bindmp” 表示是EXADATA环境中从HCC变化的一种type 64的特殊压缩类型,这个案例安装oneoff patch解决。

Jonathan Lewis大师 在研究行迁移时，行迁移到块中的每一行都增加一个ITL，迁移到块中的行没有行标头–标志字节（fb），它是：“-FL-”，标头没有‘H’，命中了另一个bug 2420831.1

打赏

对不起，这篇文章暂时关闭评论。

上一篇：

下一篇：