Below is an extract from oracle alert log after vxdisk resize operation indicating corrupted block.
===== BEGIN Oracle alert log ================
Mon Dec 09 06:00:33 2013
Hex dump of (file 83, block 101646) in trace file /u01/admin/diag/rdbms/SIDA/databaseA/trace/SIDA_008_7272312.trc
Corrupt block relative dba: 0x1d402d73 (file 83, block 101646)
<..>
Reading datafile '/SIDA/data/tables_10m_sida01.dbf' for corruption at rdba: 0x14c18d0e (file 83, block 101646)
Reread (file 83, block 101646) found same corrupt data (no logical check)
======= END Oracle alert log =================
The problem occurs during the execution of vxdisk resize command and data is read from and written to a different location than what it is intended for. The location offset equals to the offset provided for I/O plus public region disk_offset as shown in the vxdisk list
#vxdisk list diskarray-v0_2000
.....
public: slice=3 offset=65744 len=3,460,234,960 disk_offset=48 <<< disk_offset=48
private: slice=3 offset=208 len=65536 disk_offset=48 <<< disk_offset=48
The problem is fixed in a Private Hotfix VxVM 5.1SP1RP4 HF7 for cdsdisk format. Please refrain from performing dynamic LUN resizing using the vxdisk resize command before applying the required fix.
The hotfix VxVM 5.1SP1RP4HF7 can be obtained by contacting Veritas support, procedure to contact Veritas support is located at https://www.veritas.com/support/contact_techsupp_static.jsp.
Applies To
The issue only applies to configuration where ALL of the following apply:
1. System running Veritas Volume Manager (VxVM) version 5.1SP1RP2P2HF13 or higher on P2 release, 5.1SP1RP2P3 and later including 5.1SP1RP4 and it's private fixes on Linux. The problem doesn't affect VxVM 6.0 and above.
2. disk resize operation is performed using "vxdisk resize" during active I/Os to the disk.
The problem affects all VxVM disk types, namely, simple, CDS (Cross Platform Support), sliced. The data corruption happens only during the execution of the "vxdisk resize" command.