Preparing For Database Validator Operations - HP StorageWorks P9000 User Manual

Oracle on LVM (VxVM):
If LVM is used, the LDEVs after LVM mapping must obey the two separation rules:
◦
data/control files separate from redo log files, and same block size.
If LVM is used, configure the LUs before enabling Database Validator checking using
◦
RAID Manager. The LVM performs some writes to disk as part of the configuration process.
Once the LUs are configured, the LVM does not issue any more writes, so Database
Validator checking can be enabled.
◦ If you need to change the LVM configuration of an LU that is set as a target of Oracle
data checking, first delete the settings of the target LUs and disable the Oracle check
function (Database Validator), and then change the configuration. After changing the
configuration, you can re-enable Database Validator and reset the LUs as targets of
Oracle data checking.
LVM block size must be a multiple of the Oracle block size, so that whole (integral) Oracle
◦
blocks with checksums are written to disk.
◦ The Oracle block size must be less than or equal to the minimum of the LVM stripe size
and the largest block size that LVM will not fracture (known as "Logical Track Group" in
LVM), which is 256 KB in LVM.
When adding new physical volumes (PVs) to a logical volume (LV) that is to be used as
◦
an Oracle data file, control file, or redo log, you must re-enable the data validation for
the LV in order to have H.A.R.D. checking take effect.
Similarly, in order to no longer perform H.A.R.D. checking on PVs that have been removed
◦
from an LV that had been previously used by Oracle, H.A.R.D. checking should be
explicitly disabled on the device corresponding to the PV.
◦ If host-based mirroring (for example, LVM mirroring) is used, all component PV mirrors
must be H.A.R.D.-enabled; otherwise, the entire logical volume (LV) is exposed to data
corruption. That is, if a user takes an unmirrored H.A.R.D.-enabled LV and makes it
mirrored "on the fly" without H.A.R.D.-enabling all sides of the mirror, that entire LV is
exposed.
LVM bad block relocation will not be allowed on PVs that are H.A.R.D.-enabled.
◦
Oracle and LVM (VxVM) on HA Cluster Server:
Some HA cluster software may write data to volumes at regular intervals. Make sure to
◦
adjust the validation target range for such software. Its LVM area must be out of checking
for Database Validator by using the -vs <bsize> SLBA ELBA option.

Preparing for Database Validator operations

To implement the Database Validator function effectively, you need to consider the following points:
1. Setup and configuration: Particular consideration is required for P9500 volume setup and
Oracle volume mapping:
All requirements and restrictions in
observed (for example, raw files, data/control files separate from redo log files, block
size, stripe size, LVM bad block relocation, HA cluster software, and host-based mirroring).
All mapping operations should be done with Database Validator checking disabled.
Identify all LUs that will be the targets of Database Validator checking, and write down
the path(s) for each LU (port, TID, LUN). Make sure that all paths use FEDs that support
the Database Validator function.
Important: Mapping information between the Oracle files and the LDEVs is very helpful
for investigation of configuration and database recovery. We strongly recommend that
you record this information at setup time.
12 Preparing for Database Validator operations
"Requirements and restrictions" (page 9) must be