Home > Veritas Storage Foundation™ for DB2 Manual Pages

DB2ED_VMSNAP (1)

User Commands

NAME
SYNOPSIS
AVAILABILITY
DESCRIPTION
OPTIONS
NOTES
SEE ALSO

NAME

db2ed_vmsnap - create or resynchronize a snapshot image of a DB2 database. The command also allows you to reverse resynchronize a snapshot image of a DB2 database.

SYNOPSIS

db2ed_vmsnap -D DB2DATABASE -f SNAPPLAN

-o snapshot [ -F ] | resync

db2ed_vmsnap -D DB2DATABASE -f SNAPPLAN

-o reverse_resync_begin | reverse_resync_commit | reverse_resync_abort

AVAILABILITY

This command is part of Veritas Storage Foundation for DB2. To determine whether this product is installed on an \1 system, type:

lslpp -L VRTSdb2ed

DESCRIPTION

The db2ed_vmsnap command is used on the primary host and creates a snapshot of a DB2 database by splitting the mirror volumes used by the database. The snapshot functionality is useful if you want to use a secondary host for backup or a clone database for off-host processing work (such as decision-support analysis and report-generation operations, for example).

The db2ed_vmsnap command can also resynchronize the split images back to the current database image or resynchronize the original volume from the data in the snapshot. You can use the snapshot image on either the same host as the database or on a secondary host provided storage is shared by the two hosts. The file containing the snapplan specifies the snapshot scenarios (such as online_snapshot, online_mirror, or offline).

The snapshot image created by db2ed_vmsnap is a frozen image of the specified DB2 database.

When the SNAPSHOT_MODE parameter is set to online_snapshot or online_mirror in the snapplan, db2ed_vmsnap puts the database into WRITE SUSPEND mode when the snapshot is created. After db2ed_vmsnap finishes creating the snapshot, it takes the database out of WRITE SUSPEND mode. For online_snapshot, the online redo log must be included in the snapshot if a clone database is to be started. If SNAPSHOT_MODE is set to offline, online redo logs are required and the primary database needs to be down when the snapshot is created. The database will not be placed into WRITE SUSPEND mode.

The snapshot functionality is useful if you want to use a secondary host for backup or a clone database for off-host processing work (such as decision-support analysis and report-generation operations, for example).

OPTIONS

The following options are supported:

-D DB2DATABASE

Specifies the name of the DB2 database for which a snapshot image will be created.

-f SNAPPLAN

Specifies the name of the snapplan for the DB2DATABASE database.

-o snapshot [ -F ] | resync

Specifies whether to create a snapshot or synchronize the snapshot image with the current database image. Using the -F option with -o snapshot prepares the volumes for being snapshot and forces snapshot creation.

The -F option can be used after a snapshot operation has failed and the problem was fixed without using Veritas Storage Foundation for DB2 commands. (That is, the volumes were synchronized without using Veritas Storage Foundation for DB2 commands.) In this situation, the status of the snapplan will appear as unavailable for creating a snapshot. The -F option ignores the unavailable status, checks for the availability of volumes, and creates the snapshot after the volumes pass the availability check.

After the snapshot is created, db2ed_vmsnap returns values you will need to run db2ed_vmclonedb. These values include the snapshot disk group, the snapplan name, and the VxDBA repository volume (for a two-host configuration). Make a note of these values so you have them when running db2ed_vmclonedb.

-o reverse_resync_begin

Begins reverse resynchronization. This operation mounts the database snapshot volumes, mounts the file systems that are configured for the primary database, and brings up the database snapshot image as the primary database. This operation requires the original primary database to be inactive so it remains unchanged. Reverse resynchronization can be run after db2ed_vmsnap -o snapshot or after the database is cloned and shut down with the db2ed_vmclonedb command.

-o reverse_resync_abort

Aborts reverse_resync_begin and mounts the original volumes back with the file systems that are configured to use the volume. This operation is only allowed after -o reverse_resync_begin is complete and cannot be used if the reverse resynchronization is committed (-o reverse_resync_commit).

After aborting reverse resynchronization, you can run db2ed_vmclonedb -o restartdb to restart the clone database if it was previously brought up. You can also re-run db2ed_vmsnap -o reverse_resync_begin if the SNAPPLAN_MODE is set to online_snapshot and a clone database was brought up.

-o reverse_resync_commit

Commits the reverse resynchronization changes after you have verified that they are acceptable. The operation resynchronizes the original volume from the data in the snapshot. Upon completion, the content of the original database is discarded. This operation cannot be undone and should be used with extreme caution.

Caution: Upon completion of reverse resynchronization, the content of the original database is discarded. Storage Checkpoints taken on either the original database or the clone database after the snapshot was created are discarded. Storage Checkpoints taken before the snapshot was created are preserved. The db2ed_vmsnap -o reverse_resync_commit command cannot be undone and should be used with extreme caution.

NOTES

db2ed_vmsnap must be run as the DB2 instance owner. The superuser cannot use this command to create a snapshot, since there is no guarantee that the database will be in a consistent state.

Before the DB2 instance owner can use this command, however, the system administrator needs to prepare Veritas Volume Manager persistent FastResync on the existing database volumes and assign disks for snapshot volumes.

The db2ed_vmsnap command runs without interaction from the user.

It is recommended that you create a local working directory to store your snapplans in.

After a snapplan is created, run the db2ed_vmchecksnap utility to validate it. If a snapplan is modified or changed, you must revalidate it by running db2ed_vmchecksnap.