ORA-600: [kddummy_blkchk]

老杨 2019-04-18
10
0 0
摘要:测试环境发现一个ORA-600错误,简单重现了一下。错误信息如下:FriMar223:28:492012CorruptBlockFound...

问题描述

测试环境发现一个ORA-600错误,简单重现了一下。
错误信息如下:

Fri Mar 2 23:28:49 2012
Corrupt Block Found
TSN = 4, TSNAME = USERS
RFN = 4, BLK = 395, RDBA = 16777611
OBJN = 0, OBJD = 53647, OBJECT = /6ee738c_AccessorUtilities, SUBOBJECT =
SEGMENT OWNER = PUBLIC, SEGMENT TYPE = Invalid TYPE
Fri Mar 2 23:32:48 2012
Errors IN file /home/xxx/db/admin/ora1020410/udump/ora1020410_ora_13198.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [4], [419], [18038], [], [], [], []


专家解答

对应的TRACE文件信息为:

*** 2012-03-02 23:28:48.194
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [kddummy_blkchk], [4], [395], [18038], [], [], [], []
CURRENT SQL statement FOR this SESSION:
ALTER TABLE fnd_lobs MODIFY LOB (file_data) (allocate extent (SIZE 4000m))
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          CALL     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF0F118E10 ? 7FFF0F118E70 ?
                                                   7FFF0F118DB0 ? 000000000 ?
ksedmp()+610         CALL     ksedst()             000000000 ? 000000001 ?
                                                   7FFF0F118E10 ? 7FFF0F118E70 ?
                                                   7FFF0F118DB0 ? 000000000 ?
ksfdmp()+21          CALL     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF0F118E10 ? 7FFF0F118E70 ?
                                                   7FFF0F118DB0 ? 000000000 ?
kgerinv()+161        CALL     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFF0F118E10 ? 7FFF0F118E70 ?
                                                   7FFF0F118DB0 ? 000000000 ?
kseinpre()+56        CALL     kgerinv()            0068CAD20 ? 007247B10 ?
                                                   7FFF0F118E70 ? 7FFF0F118DB0 ?
                                                   000000000 ? 000000000 ?
ksesin()+177         CALL     kseinpre()           7FFF0F118E70 ? 7FFF0F118DB0 ?
                                                   7FFF0F119B70 ? 7FFF0F118DB0 ?
                                                   000000000 ? 000000000 ?
kco_blkchk()+1451    CALL     ksesin()             0058F5B08 ? 000000003 ?
                                                   000000000 ? 000000004 ?
                                                   000000000 ? 00000018B ?
kcoapl()+1411        CALL     kco_blkchk()         7FFF0F11B600 ? 000000000 ?
                                                   7FFF0F11B668 ? 000002000 ?
                                                   000000000 ? 000000001 ?
kcbapl()+336         CALL     kcoapl()             7FFF0F11B600 ? 0A7C8A000 ?
                                                   000000001 ? 000000004 ?
                                                   000002000 ? 000000000 ?
kcrfw_redo_gen()+12  CALL     kcbapl()             7FFF0F11B600 ? 0A7FE0968 ?
402                                                7F924BFF6E14 ? 000000000 ?
                                                   000000000 ? 000000000 ?
kcbchg1_main()+5258  CALL     kcrfw_redo_gen()     000000002 ? 7FFF0F11A4C8 ?
                                                   7FFF0F11A650 ? 7F924BFF6E14 ?
                                                   000000000 ? 000000001 ?
kcbchg1()+125        CALL     kcbchg1_main()       000000000 ? 000000002 ?
                                                   7FFF0F11AD08 ? 7FFF0F11AD38 ?
                                                   000000000 ? 000000000 ?
ktuchg()+1533        CALL     kcbchg1()            000000000 ? 000000002 ?

查询了一下MOS,可以看到和文档Bug 8198906 – OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents [ID 8198906.8]描述的内容最为接近,在分配EXTENTS的过程中被中止,会导致这个错误的产生,而确认影响的版本就是当前的版本。
为了验证确实属于这个问题,下面尝试重现问题:

SQL> SELECT * FROM V$VERSION;
BANNER
----------------------------------------------------------------
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS FOR Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> CREATE TABLE T_LOB (ID NUMBER, CONTENTS CLOB);
TABLE created.
SQL> ALTER TABLE T_LOB MODIFY LOB (CONTENTS) (ALLOCATE EXTENT (SIZE 1M));
TABLE altered.
SQL> SELECT TABLESPACE_NAME FROM USER_TABLES WHERE TABLE_NAME = 'T_LOB';
TABLESPACE_NAME
------------------------------
USERS
SQL> SELECT SUM(BYTES)/1024/1024 FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME = 'USERS';
SUM(BYTES)/1024/1024
--------------------
            6616.375
SQL> CONN TEST/TEST
Connected.
SQL> ALTER TABLE T_LOB MODIFY LOB (CONTENTS) (ALLOCATE EXTENT (SIZE 4096M));
TABLE altered.
SQL> ALTER TABLE T_LOB MODIFY LOB (CONTENTS) (ALLOCATE EXTENT (SIZE 8192M));
ALTER TABLE T_LOB MODIFY LOB (CONTENTS) (ALLOCATE EXTENT (SIZE 8192M))
*
ERROR at line 1:
ORA-00607: Internal error occurred while making a CHANGE TO a DATA block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [4], [273907],
[18038], [], [], [], []

可以看到如果分配EXTENT的大小不超过表空间的大小,那么操作可以成功,而如果分配EXTENT的大小超过了表空间的大小,则Oracle分配操作失败,这就引发了bug的产生,并导致了ORA-600[kddummy_blkchk]。
Oracle在10.2.0.5和11.2.0.1中fixed了这个bug,而这个bug影响的版本比较广,10.2.0.4、10.2.0.3、9.2.0.8和9.2.0.6这几个常用版本均在确认影响的版本内。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
Oracle
订阅
欢迎订阅Oracle频道,订阅之后可以获取最新资讯和更新通知。
墨值排行
今日本周综合
近期活动
全部
相关课程
全部