HP (Hewlett-Packard) HP-UX 11i v3 Landscape Lighting User Manual


 
62 Understanding Veritas Volume Manager
Dirty region logging
SmartSync recovery accelerator
The SmartSync feature of Veritas Volume Manager increases the availability of
mirrored volumes by only resynchronizing changed data. (The process of
resynchronizing mirrored databases is also sometimes referred to as
resilvering.) SmartSync reduces the time required to restore consistency, freeing
more I/O bandwidth for business-critical applications. If supported by the
database vendor, the SmartSync feature uses an extended interface between
VxVM volumes and the database software to avoid unnecessary work during
mirror resynchronization. For example, Oracle
®
automatically takes advantage
of SmartSync to perform database resynchronization when it is available.
Note: The SmartSync feature of Veritas Volume Manager is only applicable to
databases that are configured on raw volumes. You cannot use it with volumes
that contain file systems. Use an alternative solution such as the Oracle
Resilvering feature of Veritas File System (VxFS).
You must configure volumes correctly to use SmartSync. For VxVM, there are
two types of volumes used by the database, as follows:
Data volumes are all other volumes used by the database (control files and
tablespace files).
Redo log volumes contain redo logs of the database.
SmartSync works with these two types of volumes differently, so they must be
configured as described in the following sections.
To enable the use of SmartSync with database volumes in shared disk groups,
set the value of the volcvm_smartsync tunable to 1. For a description of
volcvm_smartsync, see “Tunable parameters” on page 475.
Data volume configuration
The recovery takes place when the database software is started, not at system
startup. This reduces the overall impact of recovery when the system reboots.
Because the recovery is controlled by the database, the recovery time for the
volume is the resilvering time for the database (that is, the time required to
replay the redo logs).
Because the database keeps its own logs, it is not necessary for VxVM to do
logging. Data volumes should be configured as mirrored volumes without dirty
region logs. In addition to improving recovery time, this avoids any run-time I/O
overhead due to DRL, and improves normal database write access.