ORA-00600: 内部错误代码, 参数: [ktspfmdb:objdchk_kcbnew_3], [9], [93111], [4],

今日早上巡检发现一pda库的alert日志出现如下错误，而且还在每个几分钟持续的报着这个错误。

Errors in file /home/app/oracle/diag/rdbms/pdaprdb/pdaprdb1/trace/pdaprdb1_ora_18426.trc  (incident=64036):
ORA-00600: 内部错误代码, 参数: [ktspfmdb:objdchk_kcbnew_3], [9], [93111], [4], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Oct 15 11:41:45 2012
Sweep [inc][64036]: completed
Mon Oct 15 11:50:30 2012
Errors in file /home/app/oracle/diag/rdbms/pdaprdb/pdaprdb1/trace/pdaprdb1_ora_18426.trc  (incident=64037):
ORA-00600: 内部错误代码, 参数: [ktspfmdb:objdchk_kcbnew_3], [9], [93111], [4],
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Oct 15 11:51:25 2012

查看trace文件：

DDE: Problem Key 'ORA 600 [ktspfmdb:objdchk_kcbnew_3]' was flood controlled (0x2) (incident: 57251)

*** 2012-10-15 08:40:27.926
ORA-00600: 内部错误代码, 参数: [ktspfmdb:objdchk_kcbnew_3], [9], [93111], [4], [], [], [], [], [], [], [], []

*** 2012-10-15 08:40:33.935
BH (0x14cf2e96f8) file#: 28 rdba: 0x070031b9 (28/12729) class: 1 ba: 0x14c8fca000
  set: 77 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 0 obj: 96472 objn: 96472 tsn: 9 afn: 28 hint: f
  hash: [0x18e3127198,0x18e3127198] lru: [0x112ecc1108,0x15df15f688]
  ckptq: [NULL] fileq: [NULL] objq: [0x1851a19390,0x1851a19390] objaq: [0x1851a19380,0x1851a19380]
  st: SCURRENT md: NULL fpin: 'qeilwhnp: qeilbk' tch: 4 le: 0xf2ff07dc8
  flags: remote_transfered force_cr_override
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
Dump of buffer cache at level 10 for tsn=9 rdba=117453241
BH (0x14cf2e96f8) file#: 28 rdba: 0x070031b9 (28/12729) class: 1 ba: 0x14c8fca000
  set: 77 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 0 obj: 96472 objn: 96472 tsn: 9 afn: 28 hint: f
  hash: [0x18e3127198,0x18e3127198] lru: [0x112ecc1108,0x15df15f688]
  ckptq: [NULL] fileq: [NULL] objq: [0x1851a19390,0x1851a19390] objaq: [0x1851a19380,0x1851a19380]
  st: SCURRENT md: NULL fpin: 'qeilwhnp: qeilbk' tch: 4 le: 0xf2ff07dc8
  flags: remote_transfered force_cr_override
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
GLOBAL CACHE ELEMENT DUMP (address: 0xf2ff07dc8):
  id1: 0x31b9 id2: 0x1c pkey: OBJ#96472 block: (28/12729)
  lock: S rls: 0x0 acq: 0x0 latch: 22
  flags: 0x20 fair: 0 recovery: 0 fpin: 'qeilwhnp: qeilbk'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0xf0063e7
  lcp: (nil) lnk: [NULL] lch: [0x14cf2e9828,0x14cf2e9828]
  seq: 316 hist: 397 227 144:0 213 7 144:5 192 491 352 197 48 121 227
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x08000000 sflg: 0x2000 state: SCURRENT tsn: 9 tsh: 4
      addr: 0x14cf2e96f8 obj: 96472 cls: DATA bscn: 0xa1f.6f821b29
  buffer tsn: 9 rdba: 0x070031b9 (28/12729)
  scn: 0x0a1f.6f821b29 seq: 0x01 flg: 0x06 tail: 0x1b290601
  frmt: 0x02 chkval: 0x2d76 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000014C8FCA000 to 0x00000014C8FCC000
14C8FCA000 0000A206 070031B9 6F821B29 06010A1F  [.....1..)..o....]
14C8FCA010 00002D76 00000002 000178D8 6F821AAA  [v-.......x.....o]

........

REDO RECORD - Thread:1 RBA: 0x0040c9.0003853c.009c LEN: 0x0048 VLD: 0x01
SCN: 0x0a21.b562f669 SUBSCN:  1 10/15/2012 02:01:47
(LWN RBA: 0x0040c9.0003853c.0010 LEN: 0003 NST: 0001 SCN: 0x0a21.b562f668)
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:18.3 ENC:0
Reuse redo entry
Range reuse: tsn=2 base=12609664 nblks=1024
 
REDO RECORD - Thread:1 RBA: 0x0040c9.00039b52.01c8 LEN: 0x0048 VLD: 0x01
SCN: 0x0a21.b5630ba2 SUBSCN:  2 10/15/2012 02:01:50
(LWN RBA: 0x0040c9.00039914.0010 LEN: 0600 NST: 0001 SCN: 0x0a21.b5630954)
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:18.3 ENC:0
Reuse redo entry
Range reuse: tsn=2 base=12699520 nblks=128
 
REDO RECORD - Thread:1 RBA: 0x0040c9.00039b58.0048 LEN: 0x0048 VLD: 0x01
SCN: 0x0a21.b5630ba6 SUBSCN:  2 10/15/2012 02:01:50
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:18.3 ENC:0
Reuse redo entry
Range reuse: tsn=2 base=12593408 nblks=128
 
REDO RECORD - Thread:1 RBA: 0x0040c9.00039b5d.0124 LEN: 0x0048 VLD: 0x01
SCN: 0x0a21.b5630baa SUBSCN:  1 10/15/2012 02:01:50
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:18.3 ENC:0
Reuse redo entry
Range reuse: tsn=2 base=12622080 nblks=128
。。。。。。

查看metalink信息：

Bug 12323180  ORA-600 [ktspfmdb:objdchk_kcbnew_3] due to re-used block read into cache

 This note gives a brief overview of bug 12323180.
 The content was last updated on: 07-SEP-2012
 Click here for details of each of the sections below.

Affects:

Product (Component)	Oracle Server (Rdbms)
Range of versions believed to be affected	Versions BELOW 12.1
Versions confirmed as being affected	11.2.0.2
Platforms affected	Generic (all / most platforms affected)

Fixed:

This issue is fixed in

12.1 (Future Release) 11.2.0.3 (Server Patch Set) 11.2.0.2.7 Patch Set Update 11.2.0.2 Bundle Patch 17 for Exadata Database 11.2.0.2 Patch 20 on Windows Platforms

Symptoms:	Related To:
Internal Error May Occur (ORA-600) ORA-600 [ktspfmdb:objdchk_kcbnew_3]	(None Specified)

Description

An current image of a block may be read into the buffer cache
after the block has been re-used leading to ORA-600 [ktspfmdb:objdchk_kcbnew_3]
or similar.
 
Rediscovery Notes:
  The in-cache block image is likely to show that it was pinned
  from location "kdswh01: kdstgr".
 
Workaround
  None  other than flushing the buffer_cache and retrying the operation.
 

Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

References

Bug:12323180 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article

根据metalink的信息，说这个oracle的bug，且这个bug已经在11.2.0.3上已经解决。但是这个数据库的版本已经是11.2.0.3的了。

根据实际的错误情况，已经metalink的信息，确实找不到什么解决办法，本打算重启一下数据库实例，但是想到还有不少应用在跑，但是量不是很大，数据库的负载非常低，因此我在数据库里重新刷新了一下buffer cache。再观察alert日志情况。当执行网alter syste flush buffer_chace后，这个错误没有再报了。不知道有谁还碰到这个问题，有没有其他的解决办法？

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12129601/viewspace-746466/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12129601/viewspace-746466/