Preparing for database validator operations – HP XP Array Manager Software User Manual
Page 16
Once the LUs are configured, the LVM does not issue any more writes so Database Valid-
ator 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). 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).
This is 256 KB in LVM.
• When adding new physical volumes (PVs) to a logical volume (LV) to be used as an Oracle
data file, control file, or redo log, re-enable the data validation for the LV in order to have
HARD checking take effect on the new PVs.
• Similarly, in order to have HARD checking no longer performed on PVs that have been
removed from an LV that had previously been used by Oracle, HARD checking should be
disabled on the device corresponding to the PV.
• If host-based mirroring (for example, LVM mirroring) is used, all component PV mirrors must
be HARD-enabled; otherwise the entire logical volume (LV) is exposed to data corruption.
That is, if a user takes an unmirrored HARD-enabled LV and makes it mirrored “on the fly”
without HARD-enabling all sides of the mirror, the entire LV is exposed.
• LVM bad block relocation is not allowed on PVs that are HARD-enabled.
• Oracle and LVM (VxVM) on HA Cluster Server:
• Some HA cluster software may write data to volumes at regular intervals. Be sure to adjust
the validation target range for such software. The 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 HP Database Validator function effectively, consider the following:
1.
Setup and configuration: Particular consideration is required for storage system volume setup
and Oracle volume mapping:
• All requirements and restrictions listed in “
be observed (for example, raw files, data/control files separate from redo log files, block
size, stripe size, LVM bad block relocation, HA cluster software, host-based mirroring, etc.).
• 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, GID, LUN). Make sure that all paths use CHAs that support the
Database Validator function.
Important: Mapping information between the Oracle files and the LDEVs is very helpful for in-
vestigation of configuration and database recovery. We strongly recommend that you record
this information at setup time.
2.
Error recovery: Potential error causes and corresponding recovery procedures should be confirmed
before the database goes into production phase.
3.
Redundancy: Redundant system design (for example, cluster, disaster recovery, etc.) is strongly
recommended to be combined with this functionality to take over immediately after the failure
detection and to minimize downtime.
Preparing for Database Validator Operations
16