asm 磁盘报错

alter_asm.logStarting background process ARB0
Fri Mar 04 11:20:06 2016
ARB0 started with pid=28, OS id=29603 
NOTE: assigning ARB0 to group 3/0x9784476d (DG01DATA) with 10 parallel I/Os
Fri Mar 04 11:20:07 2016
Sweep [inc][5808]: completed
Errors in file /u01/app/11.2.0/grid/log/diag/asm/+asm/+ASM2/trace/+ASM2_arb0_29603.trc  (incident=5809):
ORA-00600: internal error code, arguments: [kfdAuPivotVec2], [133], [256], [18], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Fri Mar 04 11:21:17 2016
NOTE: AMDU dump of disk group DG01DATA created at /u01/app/11.2.0/grid/log/diag/asm/+asm/+ASM2/tracetrc
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
ORACLE_HOME = /u01/app/11.2.0/grid
System name:    SunOS
Node name:      racdb2
Release:        5.10
Version:        Generic_144488-04
Machine:        sun4u
Instance name: +ASM2
Redo thread mounted by this instance: 0 <none>
Oracle process number: 28
Unix process pid: 29771, image: oracle@racdb2 (ARB0)
*** 2016-03-04 11:22:28.208
*** SESSION ID:(85.63) 2016-03-04 11:22:28.208
*** CLIENT ID:() 2016-03-04 11:22:28.208
*** SERVICE NAME:() 2016-03-04 11:22:28.208
*** MODULE NAME:() 2016-03-04 11:22:28.208
*** ACTION NAME:() 2016-03-04 11:22:28.208
 
ARB0 relocating file +DG01DATA.256.765474779 (104 entries)*** 2016-03-04 11:22:28.849
DDE: Problem Key 'ORA 600 [kfdAuPivotVec2]' was flood controlled (0x6) (incident: 5811)
ORA-00600: internal error code, arguments: [kfdAuPivotVec2], [133], [256], [18], [], [], [], [], [], [], [], []
OSM metadata struct dump of kfdatb:
kfdatb.aunum:                     90048 ; 0x000: 0x00015fc0
kfdatb.shrink:                        0 ; 0x004: 0x0000
kfdatb.ub2pad:                        0 ; 0x006: 0x0000
kfdatb.auinfo[0].link.next:           8 ; 0x008: 0x0008
kfdatb.auinfo[0].link.prev:           8 ; 0x00a: 0x0008
kfdatb.auinfo[1].link.next:          12 ; 0x00c: 0x000c
kfdatb.auinfo[1].link.prev:          12 ; 0x00e: 0x000c
kfdatb.auinfo[2].link.next:          16 ; 0x010: 0x0010
kfdatb.auinfo[2].link.prev:          16 ; 0x012: 0x0010
kfdatb.auinfo[3].link.next:          20 ; 0x014: 0x0014
kfdatb.auinfo[3].link.prev:          20 ; 0x016: 0x0014
kfdatb.auinfo[4].link.next:          24 ; 0x018: 0x0018
kfdatb.auinfo[4].link.prev:          24 ; 0x01a: 0x0018
kfdatb.auinfo[5].link.next:          28 ; 0x01c: 0x001c
kfdatb.auinfo[5].link.prev:          28 ; 0x01e: 0x001c
kfdatb.auinfo[6].link.next:          32 ; 0x020: 0x0020
kfdatb.auinfo[6].link.prev:          32 ; 0x022: 0x0020
kfdatb.spare:                         0 ; 0x024: 0x00000000
Dump of ate#:0
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff
Dump of ate#:1
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff
Dump of ate#:2
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff
Dump of ate#:3
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff
Dump of ate#:4
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff
Dump of ate#:5
OSM metadata struct dump of kfdate:
kfdate.discriminator:                 1 ; 0x000: 0x00000001
kfdate.allo.lo:                       0 ; 0x000: XNUM=0x0
kfdate.allo.hi:                 9437183 ; 0x004: V=1 I=0 H=0 FNUM=0xfffff错误信息频繁的报，忘高手支持解决。

解决方案 »

  1.   

    Bug 10621169  I/O errors during RAC ASM recovery may drop redo and cause metadata corruptions / ORA-600 - superseded This note gives a brief overview of bug 10621169. 
     The content was last updated on: 28-JUN-2013
     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) Note that this fix has been superceded by the fix in Bug:14467061 
    Fixed:This issue is fixed in
    12.1.0.1 (Base Release)
    11.2.0.3 (Server Patch Set)
    11.2.0.2.3 Database Patch Set Update
    11.2.0.2 Bundle Patch 6 for Exadata Database
    11.2.0.2 Patch 7 on Windows Platforms
    Symptoms:Related To:Corruption (Physical)
    Internal Error May Occur (ORA-600)
    ORA-600 [kfcRcvRead10]
    ORA-600 [kfdAuPivotVec2]
    ORA-600 [kfdAuDealloc2]
    Automatic Storage Management (ASM)
    RAC (Real Application Clusters) / OPS
    DescriptionIf SMON fails an instance recovery due to disk I/O errors and
    those I/O errors result in a force dismount, but other nodes in the 
    cluster do not suffer those same I/O errors then ASM meta data can 
    become corrupt and/or ORA-600 [kfcRcvRead10] errors can occur.
     
    Workaround
     None
     
    Note:
     The 11.2 fixes for this issue are missing a code change and so are incomplete.
     For interim patches please use the fix under bug 14467061 instead of this fix.
     For "fixed" versions above please also see bug 14467061 for versions where
     the missing part of the fix is included.