ORA-00600: 內部錯誤程式碼, 引數: [ktspfmdb:objdchk_kcbnew_3], [9], [93111], [4],

dcswinner發表於2012-10-15
OBJ

今日早上巡檢發現一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
Platforms affected Generic (all / most platforms affected)

Fixed:

This issue is fixed in

Symptoms:

Related To:

  • (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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章