客户9208数据库出现ORA-600[ktspfupdst-1]错误。
错误信息为:
Sat Mar 31 02:50:48 2012
Errors in file /oracle/app/admin/orcl/udump/orcl1_ora_1896900.trc:
ORA-00600: internal error code, arguments: [ktspfupdst-1], [], [], [], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation
其实从错误信息本身就可以初步判断,问题应该和用户取消当前的操作有关。问题多半是由于用户取消当前操作后,Oracle在进行恢复处理时,引发了异常。
详细TRACE信息为:
*** 2012-03-31 02:50:48.509
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ktspfupdst-1], [], [], [], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation
Current SQL statement for this session:
INSERT INTO TAB001_3
(
COL_CODE ,
A_CODE ,
C_CODE ,
S_ID ,
SER_NUM ,
S_TYPE ,
C_ID ,
A_ID ,
N_TYPE ,
B_ID ,
P_ID ,
P_ID_N ,
S_STAT ,
U_TIME ,
P_MODE ,
S_KIND ,
V_TYPE ,
O_MODE ,
A_TIME ,
C_TIME ,
AC_TIME ,
A_R_TIME ,
S_MODE ,
T_CODE ,
S_NUMBER ,
P_CODE ,
D_CODE ,
S_FLAG ,
S_TIME ,
DE_CODE ,
D_C_CODE ,
D_STAFF ,
CI_TYPE ,
O_TIME ,
SU_FLAG ,
SU_FLAG ,
D_A_CODE,
CH_CODE ,
GR_ID ,
RE_CODE )
SELECT '30',c.b_region,'',a.id_no,trim(a.p_no),'',a.c_id,a.c_no,'',a.s_code,'',
'',decode(substr(a.r_code,2,1),'A','1','K','1','C','2','I','4','J','4','a','5','b','5','3'),
to_char(a.r_time,'yyyymmddhh24miss'),decode(b.c_flag,'A','2','B','1'),
'','01','1',to_char(a.o_time,'yyyymmddhh24miss'),to_char(a.o_time,'yyyymmddhh24miss'),'',to_char(a.o_time,'yyyymmddhh24miss'),
'S','','','','','2','',
'','','','',to_char(a.o_time,'yyyymmddhh24miss'),'U',decode(substr(a.r_code,2,1),'A','0','K','0','1'),
c.b_region,'',a.g_id,c.r_code
FROM tab2 a,tab3 b, tab4 c
WHERE a.s_code = b.s_code
AND substr(a.b_code,0,2) = b.r_code
AND b.r_code = c.r_code
AND mod(a.id_no,10) = 3
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp+0148 bl ksedst 1029746FC ?
ksfdmp+0018 bl 01FD4014
kgerinv+00e8 bl _ptrgl
kgeasnmierr+004c bl kgerinv 000000001 ? 000000000 ?
000000005 ? 000000001 ?
000000001 ?
ktspfupdst+0540 bl kgeasnmierr 110006308 ? 1103994E8 ?
102A9239C ? 000000000 ?
000000005 ? 000000010 ?
000000020 ? 000000006 ?
ktspstchg+00e4 bl ktspfupdst 000000060 ? 300000004 ?
FFFFFFFFFFF6E48 ?
50601CE000000ED ?
3B401B34C5D02F2A ?
B92000004000020 ?
kdoiur+062c bl ktspstchg 000000000 ? 700000C39D779E8 ?
000000000 ?
kcoubk+00e4 bl _ptrgl
ktundo+0988 bl kcoubk 1010CCD80 ? FFFFFFFFFFF76C0 ?
100ED51C0 ? FFFFFFFFFFF7150 ?
1101FAF78 ? 1102567C0 ?
700000C396A1300 ? 000000002 ?
ktubko+03bc bl ktundo 1840DFB30 ?
3B401B3400000002 ?
000000000 ? 000000000 ?
FFFFFFFFFFF85D8 ?
700000C80A1E880 ? 2FFFF8540 ?
FFFFFFFFFFF8780 ?
ktuabt+0638 bl ktubko DF000000DF ?
FFFFFFFFFFF8690 ? 000000000 ?
FFFFFFFFFFF85D8 ? 102973880 ?
700000C844FA418 ?
ktcrab+02b4 bl ktuabt 700000C80A1E840 ? 200017CD8 ?
ktcrsp+026c bl ktcrab 100F698E4 ? 000000001 ?
ksures+0074 bl ktcrsp 700000C844FA448 ?
opiexe+3380 bl 01FD4138
opiall0+102c bl opiexe 400000000 ? 110002A48 ?
FFFFFFFFFFFA0A0 ?
kpoal8+0a78 bl opiall0 5EFFFFBED4 ? 22103A43F8 ?
FFFFFFFFFFFA5B8 ? 000000000 ?
FFFFFFFFFFFA508 ? 1103A4B00 ?
6FF00000738 ?
24000000007FFF ?
opiodr+08cc bl _ptrgl
ttcpip+0cc4 bl _ptrgl
opitsk+0d60 bl ttcpip 11000CF90 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
opiino+0758 bl opitsk 000000000 ? 000000000 ?
opiodr+08cc bl _ptrgl
opidrv+032c bl opiodr 3C00000018 ? 4101FAF78 ?
FFFFFFFFFFFF7B0 ? 0A000F350 ?
sou2o+0028 bl opidrv 3C0C000000 ? 4A00E8B50 ?
FFFFFFFFFFFF7B0 ?
main+0138 bl 01FD3A28
__start+0098 bl main 000000000 ? 000000000 ?
可以看到,当前执行的是一条插入语句。查询MOS发现,问题和ORA-00600 [ktspfupdst-1] During DML on ASSM Segment [ID 388599.1]描述的完全一致。
首先当前插入的表所在表空间使用的是ASSM,其次这个插入操作被取消,而且所有堆栈信息与bug 3370468描述的完全一致。
虽然这个bug在9.2.0.5被fixed,但是不排除在9.2.0.8被重新引入的可能性。Oracle给出的解决方案除了升级到10.2以及10.1.0.3以上外,还可以尝试用dbms_repair.segment_fix_status过程来修正问题对象。
如果只是单次的问题,且无法重现,最简单的方法莫过于直接MOVE,确保ASSM空间管理的异常不会导致表中后续数据的插入和读取。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-722674/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-722674/