今日早上巡检发现一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: |
|
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/