Symantec logo

Validating a snapplan (dbed_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 dbed_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 dbed_vmchecksnap command.

Usage Notes 

  • The dbed_vmchecksnap command must be run as the Oracle database administrator.
  • After validating the snapplan, you have the option of modifying the snapplan file to meet your storage configuration requirements.
  • When using dbed_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 revalidate it. It is recommended that snapplans are revalidated when changes are made in the database disk group.
  • The dbed_vmchecksnap command can be used on the primary or secondary host.
  • See the dbed_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 dbed_vmchecksnap command:

    $ /opt/VRTS/bin/dbed_vmchecksnap -S-D ORACLE_SID \

    -H ORACLE_HOME -f SNAPPLAN -o validate


      Note   In 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/dbed_vmchecksnap -S PROD -H /oracle/product/9i \

-f snap1 -o validate

PRIMARY_HOST is host1

SECONDARY_HOST is host1

The version of PRIMARY_DG-PRODdg is 110.

The primary diskgroup PRODdg is a shared disk group

SNAPSHOT_DG is SNAP_PRODdg

SNAPSHOT_MODE is online

The database is running in archivelog mode.

ARCHIVELOG_DEST is /prod_ar

SNAPSHOT_PLAN_FOR is database

SNAPSHOT_ARCHIVE_LOG is yes

ARCHIVELOG_DEST=/prod_ar is mount on /dev/vx/dsk/PRODdg/prod_ar.

Examining Oracle volume and disk layout for snapshot

Volume prod_db on PRODdg is ready for snapshot.

Original plex and DCO log for prod_db is on PRODdg01.

Snapshot plex and DCO log for prod_db is on PRODdg02.

SNAP_PRODdg for snapshot will include: PRODdg02

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/dbed_vmchecksnap -S PROD -H \

/oracle/product/9i -f snap2 -o validate

PRIMARY_HOST is host1

SECONDARY_HOST is host2

The version of PRIMARY_DG-PRODdg is 110.

The primary diskgroup PRODdg is a shared disk group

SNAPSHOT_DG is SNAP_PRODdg

SNAPSHOT_MODE is online

The database is running in archivelog mode.

ARCHIVELOG_DEST is /mytest/arch

SNAPSHOT_PLAN_FOR is database

SNAPSHOT_ARCHIVE_LOG is yes

ARCHIVELOG_DEST=/mytest/arch is mount on /dev/vx/dsk/PRODdg/arch.

Examining Oracle volume and disk layout for snapshot.

Volume arch on PRODdg is ready for snapshot.

Original plex and DCO log for arch is on PRODdg01.

Snapshot plex and DCO log for arch is on PRODdg02.

Volume prod_db on PRODdg is ready for snapshot.

Original plex and DCO log for prod_db is on PRODdg01.

Snapshot plex and DCO log for prod_db is on PRODdg04.

SNAP_PRODdg for snapshot will include: PRODdg02

ALLOW_REVERSE_RESYNC is no

The snapplan snap2 has been created.