Error Message

-- Errors from Oracle DB logs:

type: 6 format: 2 rdba: 0x0552be74
last change scn: 0x0000.0000.35868cbe seq: 0x2 flg: 0x04
spare3: 0x0
consistency value in tail: 0x8cbe0602
check value in block header: 0x57ef
computed block checksum: 0x0
 
Reading datafile 'arc_vdata_11.dbf' for corrupt data at rdba: 0x0552be7d (file 21, block 1228413)
Read datafile mirror 'volume-01'  (file 21, block 1228413) found same corrupt data (no logical check)
Read datafile mirror 'volume-02' (file 21, block 1228413) found same corrupt data (no logical check)
2025-05-27T05:00:34.130609-07:00
Corrupt Block Found
 
-- Errors in Infoscale stack:
 
No errors were observed in Infoscale stack.
 

Oracle Database Corruption Issues in FSS Environments when obj_ioship=on  is set on volumes under FSS diskgroup. When a volume is created under FSS disk group, obj_ioship is set to off by default and this can be set it on to enable IO ship at volume level.
 
Arctera tested with ODM and FSS with obj_ioship=off  ( which is default ) and did not see any corruption.
 
 

The recommendation is to keep the  obj_ioship=off for all the volumes.
 
Command to change the ioship to off.
#  unmount the filesystem
# vxvol -g set obj_ioship=off

Note: In case VVR replication is configured, please pause the replication , make the changes and resume the replication

Command to check the ioship on or off

# vxprint -g -F %vol_ioship_capable

Note: Arctera engineering working to fix this problem in the upcoming versions. As of now, it is recommended to keep the default value for the IOSHIP.