Validating a snapplan (db2ed_vmchecksnap)
Prev Using Database FlashSnap for backup and off-host processing Next

Validating a snapplan (db2ed_vmchecksnap)

After creating a snapplan, the next steps are to validate the snapplan parameters and check whether the snapshot volumes have been configured correctly for creating snapshots. If validation is successful, the snapplan is copied to the repository. The snapplan is validated using the db2ed_vmchecksnap command with the -o validate option.

Consider the following prerequisites and notes before validating a snapplan:

Prerequisites

  • The database must be up and running while executing the db2ed_vmchecksnap command.

Usage notes

  • The db2ed_vmchecksnap command must be run as the DB2 instance owner.

  • The default behavior is to force validation. Use the -n option if you want to skip validation.

  • After validating the snapplan, you have the option of modifying the snapplan file to meet your storage configuration requirements.

  • When using db2ed_vmchecksnap to validate the snapplan and storage, you can save the validation output. The system administrator can use this information to adjust the storage setup if the validation fails.

  • If a snapplan is updated or modified, you must re-validate it. It is recommended that snapplans are revalidated when changes are made in the database disk group.

  • The db2ed_vmchecksnap command must be used on the primary host.

  • See the db2ed_vmchecksnap(1M) manual page for more information.

To validate a snapplan

  1. Change directories to the working directory your snapplan is stored in:

            $ cd /working_directory

  2. Validate the snapplan using the db2ed_vmchecksnap command:

    $ /opt/VRTS/bin/db2ed_vmchecksnap -D DB2DATABASE \
-f SNAPPLAN -o validate

    In an HA environment, you must modify the default snapplan, use the virtual host name defined for the resource group for the PRIMARY_HOST and/or SECONDARY_HOST, and run validation.

In the following example, a snapplan, snap1, is validated for a snapshot image in a single-host configuration. The primary host is host1 and the working directory is /export/snap_dir.

$ cd /export/snap_dir 
$ /opt/VRTS/bin/db2ed_vmchecksnap -D PROD -f snap1 -o validate$
SNAPSHOT_MODE is online_snapshot
PRIMARY_HOST is host1
SECONDARY_HOST is host1
The version of PRIMARY_DG-PRODdg is 140.
SNAPSHOT_DG is SNAP_PRODdg
SNAPSHOT_PLAN_FOR is database
Examining DB2 volume and disk layout for snapshot
Volume prodvol1 on PRODdg is ready for snapshot.
Original plex and DCO log for prodvol1 is on PRODdg1.
Snapshot plex and DCO log for prodvol2 is on PRODdg2.
Volume prodvol2 on PRODdg is ready for snapshot.
Original plex and DCO log for prodvol2 is on PRODdg1.
Snapshot plex and DCO log for prodvol2 is on PRODdg2.
SNAP_PRODdg for snapshot will include: PRODdg2
ALLOW_REVERSE_RESYNC is NO
The snapplan snap1 has been created.

In the following example, a snapplan, snap2, is validated for a snapshot image in a two-host configuration. The primary host is host1, the secondary host is host2, and the working directory is /export/snap_dir.

$ cd /export/snap_dir
$ /opt/VRTS/bin/db2ed_vmchecksnap -D PROD -f snap2 -o validate
SNAPSHOT_MODE is online_snapshot
PRIMARY_HOST is host1
SECONDARY_HOST is host2
The version of PRIMARY_DG-PRODdg is 140.
SNAPSHOT_DG is SNAP_PRODdg
SNAPSHOT_PLAN_FOR is database
Examining DB2 volume and disk layout for snapshot.
Volume prodvol1 on PRODdg is ready for snapshot.
Original plex and DCO log for arch is on PRODdg1.
Snapshot plex and DCO log for arch is on PRODdg2.
Volume prodvol2 on PRODdg is ready for snapshot.
Original plex and DCO log for prod_db is on PRODdg1.
Snapshot plex and DCO log for prod_db is on PRODdg2.
SNAP_PRODdg for snapshot will include: PRODdg2
ALLOW_REVERSE_RESYNC is NO
The snapplan snap2 has been created.
Prev Up Next
Creating multi-mirror snapshots Home Displaying, copying, and removing a snapplan (db2ed_vmchecksnap)