联系：手机/微信(+86 17813235971) QQ(107644445)
标题：ORA-00600: internal error code, arguments: [16513], [1403] 恢复
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
接到客户请求,存储异常断电之后,一个40多T的经分数据库无法正常启动,通过各方一系列操作之后,数据库依旧无法open,报错信息为:ORA-00600: internal error code, arguments: [16513], [1403], [28]
Sun Feb 14 00:20:09 BEIST 2021 SMON: enabling cache recovery Sun Feb 14 00:20:09 BEIST 2021 ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0f27.13cd4fc3): Sun Feb 14 00:20:09 BEIST 2021 select ctime, mtime, stime from obj$ where obj# = :1 Sun Feb 14 00:20:09 BEIST 2021 Errors in file /oracle10g/db/admin/xifenfei/udump/xifenfei1_ora_177254.trc: ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], [] Sun Feb 14 00:20:10 BEIST 2021 Errors in file /oracle10g/db/admin/xifenfei/udump/xifenfei1_ora_177254.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], [] Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 177254 ORA-1092 signalled during: ALTER DATABASE OPEN...
通过对启动过程进行跟踪
=====================
PARSING IN CURSOR #5 len=52 dep=1 uid=0 oct=3 lid=0 tim=194171381576991 hv=429618617 ad='afcee60'
select ctime, mtime, stime from obj$ where obj# = :1
END OF STMT
PARSE #5:c=0,e=257,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=194171381576990
BINDS #5:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=1104b8ed0 bln=22 avl=02 flg=05
value=28
EXEC #5:c=0,e=422,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=194171381577472
WAIT #5: nam='db file sequential read' ela= 274 file#=1 block#=110 blocks=1 obj#=36 tim=194171381577809
WAIT #5: nam='db file sequential read' ela= 257 file#=1 block#=78943 blocks=1 obj#=36 tim=194171381578123
WAIT #5: nam='db file sequential read' ela= 253 file#=1 block#=111 blocks=1 obj#=36 tim=194171381578416
WAIT #5: nam='db file sequential read' ela= 226 file#=1 block#=62 blocks=1 obj#=18 tim=194171381578692
=====================
PARSING IN CURSOR #6 len=142 dep=2 uid=0 oct=3 lid=0 tim=194171381579134 hv=361892850 ad='df87eb0'
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,
DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
END OF STMT
PARSE #6:c=0,e=368,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,tim=194171381579133
BINDS #6:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=1105af9a8 bln=22 avl=02 flg=05
value=92
EXEC #6:c=0,e=531,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,tim=194171381579736
WAIT #6: nam='db file sequential read' ela= 232 file#=1 block#=102 blocks=1 obj#=34 tim=194171381580011
WAIT #6: nam='db file sequential read' ela= 251 file#=1 block#=54 blocks=1 obj#=15 tim=194171381580307
FETCH #6:c=0,e=615,p=2,cr=2,cu=0,mis=0,r=1,dep=2,og=3,tim=194171381580369
STAT #6 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=2 pw=0 time=584 us)'
STAT #6 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=1 pw=0 time=282 us)'
WAIT #5: nam='db file sequential read' ela= 260 file#=4290 block#=365090 blocks=1 obj#=0 tim=194171381580721
FETCH #5:c=10000,e=3327,p=7,cr=7,cu=0,mis=0,r=0,dep=1,og=4,tim=194171381580817
*** 2021-02-14 02:32:40.430
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c bl ksedst1 70000090FC00AE4 ? 000000000 ?
ksedmp+0290 bl ksedst 104C1CA58 ?
ksfdmp+02d8 bl 03F4BD0C
kgeriv+0108 bl _ptrgl
kgesiv+0080 bl kgeriv 7000008F6DB5890 ? 00000000C ?
7000008F6DB5890 ? 0FFFFFDC3 ?
0FFFFFFBF ?
ksesic2+0060 bl kgesiv 5FFFEC580 ? 500000000 ?
FFFFFFFFFFEC590 ? 0F5FAF808 ?
7000008F5FAF7E8 ?
kqdpts+0158 bl ksesic2 408100004081 ? 000000000 ?
00000057B ? 000000000 ?
00000001C ?
A006150571B05EF0 ?
1100CF0A8 ? 000000001 ?
kqrlfc+0274 bl kqdpts 000000000 ?
kqlbplc+00b4 bl 03F4E6A8
kqlblfc+0230 bl kqlbplc 00000009D ?
adbdrv+1a9c bl 03F4B66C
opiexe+2db4 bl adbdrv
opiosq0+1ac8 bl opiexe 1103B418C ? 000000000 ?
FFFFFFFFFFF9008 ?
kpooprx+016c bl opiosq0 300F1E1D4 ? 000000000 ?
000000000 ? A4FFFFFFFF9798 ?
000000000 ?
kpoal8+03cc bl kpooprx FFFFFFFFFFFB814 ?
FFFFFFFFFFFB5C0 ?
1300000013 ? 100000001 ?
000000000 ? A40000000000A4 ?
000000000 ? 1103B4378 ?
opiodr+0b2c bl _ptrgl
ttcpip+1020 bl _ptrgl
opitsk+117c bl 01FBD04C
opiino+09d0 bl opitsk 1EFFFFD7E0 ? 000000000 ?
opiodr+0b2c bl _ptrgl
opidrv+04a4 bl opiodr 3C102B1398 ? 404C6FF30 ?
FFFFFFFFFFFF7A0 ? 0102B1390 ?
sou2o+0090 bl opidrv 3C02705B3C ? 440663000 ?
FFFFFFFFFFFF7A0 ?
opimai_real+01bc bl 01FB9BF4
main+0098 bl opimai_real 000000000 ? 000000000 ?
__start+0098 bl main 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
报错比较明显,数据库在查询obj$取obj#=28的数据的时候无法正常获取到该数据,从而报错ORA-600 16513错误.通过对相关block进行分析,发现有事务异常
BBED> p ktbbh.ktbbhitl[1]
struct ktbbhitl[1], 24 bytes @44
struct ktbitxid, 8 bytes @44
ub2 kxidusn @44 0x5c00
ub2 kxidslt @46 0x0a00
ub4 kxidsqn @48 0x48b4fc01
struct ktbituba, 8 bytes @52
ub4 kubadba @52 0x22928531
ub2 kubaseq @56 0xe383
ub1 kubarec @58 0x01
ub2 ktbitflg @60 0x0120 (NONE)
union _ktbitun, 2 bytes @62
b2 _ktbitfsc @62 0
ub2 _ktbitwrp @62 0x0000
ub4 ktbitbas @64 0x95c2ff13
通过一些技巧处理规避掉该事务,然后启动库报熟悉的ORA-01555错误
相对比较简单参考(在数据库open过程中常遇到ORA-01555汇总),数据库顺利open成功,完成春节后第一个大库的恢复
