ORA-01122, ORA-01251 or data blocks reported as corrupted (文档 ID 422031.1)

In this Document

Symptoms

Changes

Cause

Solution

References

---

APPLIES TO:

Oracle Database - Enterprise Edition - Version 9.2.0.1 to 10.2.0.1 [Release 9.2 to 10.2]
IBM AIX on POWER Systems (64-bit)
** Checked for relevance on 24-Feb-2012**
** Checked for relevance on 05-AUG-2014 **

IBM AIX Based Systems (64-bit)
AIX5L Based Systems (64-bit)
This problem affects all RDBMS releases on AIX5L Based Systems using data files on raw devices over the following OS maintenance levels.

bos.rte.lvm 5.2.0.97 (5200-09-03) and later
bos.rte.lvm 5.3.0.53 (5300-05-04) and later

SYMPTOMS

Oracle reports errors while reading the header of some data files, or control files. For example, following erros could be reported during instace startup.

On data file:

ORA-01122: database file 26 failed verification check 
ORA-01110: data file 26: '/dev/rccrac_data09' 
ORA-01251: Unknown File Header Version read for file number 26

On control file:

Hex dump of Absolute File 0, Block 1 in trace file /oracle/app/oracle/admin/cc/udump/cc_ora_811272.trc
***
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Fractured block found during control file header read
Data in bad block -
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
consistency value in tail: 0x00000000
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0

dbv on the offending data file also reports all blocks as corrutped. For example:

DBVERIFY - Verification starting : FILE = /dev/rccrac_deutb 
Page 1 is influx - most likely media corrupt 
Corrupt block relative dba: 0x00000001 (file 0, block 1) 
Fractured block found during dbv: 
Data in bad block: 
type: 0 format: 0 rdba: 0x00000000 
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00 
spare1: 0x0 spare2: 0x0 spare3: 0x0 
consistency value in tail: 0x00000000 
check value in block header: 0x0

CHANGES

Problem can be seen after a system reboot or after changes to Logical Volumes

CAUSE

Problem is due to Logical Volumes losing its DS_LVZ property. This causes Oracle to start reading the data files at the wrong offset (4k).  For examople, consider a new Logical Volume created as:

mklv -y'asm_tst_data' -t'jfs2' -a'e' -T O -w n -r n -S 64k asmtst 200 hdisk2 hdisk3 hdisk4

LM should have property DS_LVZ set,  as -T O flag was used.

Command: lslv -L asm_tst_data

should show something like  "DEVICESUBTYPE : DS_LVZ". Then, any operation that causes the Vary off in the Volume Group (for example a reboot or  varyoffvg) would eliminate the DS_LVZ flag from the Logical Volume. This is, lslv -L  would no longer display "DEVICESUBTYPE : DS_LVZ". Therefore, Oracle will read the datafile at incorrect offset and will report the errors.

SOLUTION

To implement the solution, please execute the following steps:

Problem is caused by defect IY94343 in AIX Operating System.

Solution is to apply fix: (see http://www-1.ibm.com/support/docview.wss?uid=isg1IY94343 )

Comments from link:

5200-10 - use AIX APAR IY94347
5300-06 - use AIX APAR IY94343
5300-07 - use AIX APAR IY94343

Note: Affected local volumes (LVs) could be fixed using command:

# chlv -T O <lv name> 

This command should set  DEVICESUBTYPE : DS_LVZ again into the affected LVs. Please, do not execute this command on standard 4kb LVs. LVs device must also be in a closed state.

REFERENCES

NOTE:1088018.1 - Master Note for Handling Oracle Database Corruption Issues