dbed_vmsnap

NAME

dbed_vmsnap - create or resynchronize a snapshot image of an Oracle database. The command also allows you to reverse resynchronize a snapshot image of an Oracle database.

SYNOPSIS

AVAILABILITY

VERITAS Storage Foundation for Oracle. To determine whether this product is installed on a HP-UX system, enter:

swlist VRTSdbed

DESCRIPTION

The dbed_vmsnap command is used on the primary host and creates a snapshot of an Oracle database by splitting the mirror volumes used by the database. The 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, offline, or instant).

The snapshot image created by dbed_vmsnap is a frozen image of an Oracle database's datafiles. You can choose whether to include archive log volumes in the snapshot. dbed_vmsnap ensures that a backup control file is created when the snapshot database is created, which allows for complete data recovery, if needed.

When the SNAPSHOT_MODE parameter is set to online in the snapplan, dbed_vmsnap puts the tablespaces into backup mode when the snapshot is created. After dbed_vmsnap finishes creating the snapshot, it takes the tablespaces out of backup mode, switches the log files to ensure that the extra redo logs are archived, and then creates a snapshot of the archived logs. If SNAPSHOT_MODE is set to instant, dbed_vmsnap will create a snapshot regardless of whether the database is up or down, and will not put the tablespace into backup mode. In this case, the snapshot of the archive log is not needed. However, the online redo logs are required for creating a clone database. 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.

If the primary and secondary hosts specified in the snapplan are different, the volume snapshot will be put into a disk group and the disk group will be deported.

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).

You can use Database FlashSnap commands in a high availability (HA) environment. See the NOTES section below for details.

OPTIONS

The following options are supported:

-S ORACLE_SID

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

-f SNAPPLAN

Specifies the name of the snapplan for the ORACLE_SID instance.

-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 Oracle commands. (That is, the volumes were synchronized without using VERITAS Storage Foundation for Oracle 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, dbed_vmsnap returns values you will need to run dbed_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 dbed_vmclonedb.

-o reverse_resync_begin

Begins reverse resynchronization. To mount the database snapshot volumes, mount the file systems that are configured for the primary database and bring up the database snapshot image as the primary database. This operation requires the original primary database to be offline so it remains unchanged. Reverse resynchronization can be run after dbed_vmsnap -o snapshot or after the database is cloned and shut down with the dbed_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 any of the following operations depending on your needs: dbed_vmsnap -o reverse_resync_begin, dbed_vmclonedb -o restartdb.

-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.

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 before or after the snapshot was created are discarded. The dbed_vmsnap -o reverse_resync_commit command cannot be undone and should be used with extreme caution.

If the Oracle authentication password file is used for the database, it needs to be recreated using the ORAPWD utility after reverse resynchronization is performed.

NOTES

dbed_vmsnap must be run as the Oracle DBA user. 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 Oracle DBA user 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 dbed_vmsnap command runs without interaction from the user.

It is recommended that you maintain different snapplans in a directory. After a snapplan is created, run the dbed_vmchecksnap utility to validate it. If a snapplan is modified or changed, you must revalidate it by running dbed_vmchecksnap.

You can use Database FlashSnap commands in a high availability (HA) environment. The following limitations apply:

• In an HA environment, you must modify the default snapplan to use the virtual host name defined for the database resource group for the PRIMARY_HOST and/or the SECONDARY_HOST parameters and validate the snapplan before creating the snapshot.

The snapshot is created by running:

• In an HA environment, the primary database must be down before you perform reverse resynchronization. When VERITAS Cluster Server (VCS) detects that the primary database is down, however, it starts a failover process and the VxDBA repository is unmounted and the dbed_vmsnap command is aborted.

To work around this issue:

1. As root, temporarily freeze the VCS resource group for the database:

2. Shut down the primary database.

3. Run reverse resynchronization:

4. After reverse resynchronization changes are committed, verify that the database has been started in ARCHIVELOG mode. This information is provided in the status messages that appear after committing reverse resynchronization changes.

5. Unfreeze the resource group:

Database FlashSnap commands are integrated with Storage Checkpoint functionality. It is possible to display and mount Storage Checkpoints carried over with snapshot volumes to a secondary host. Hovever, the following limitations apply:

• Any mounted Storage Checkpoints must be unmounted before running the following commands:

dbed_vmsnap -S ORACLE_SID -f SNAPPLAN \
-o reverse_resync_begin
dbed_vmclonedb -o umount,new_sid=new_sid \
-f SNAPPLAN
• It is only possible to mount a Storage Checkpoint carried over with the snapshot volumes in a two-host configuration if the snapshot volumes were mounted with the dbed_vmclonedb command with the -o mount option without the use of -r relocate_path.
• Storage Checkpoints carried over with the snapshot volumes can be mounted before a clone database is created using dbed_vmclonedb with the -o mount option. After a clone database is created using dbed_vmclonedb with the -o recoverdb option, however, Storage Checkpoints are no longer present.
• After running dbed_vmsnap -o reverse_resync_commit Storage Checkpoints created on the original database or on the clone database are deleted.

SEE ALSO

dbed_vmchecksnap (1M), dbed_vmclonedb (1M), dbed_vmsnapplan (4)

VERITAS Storage Foundation for Oracle Administrator's Guide