Home > Veritas Storage Foundation™ for Oracle Manual Pages
DBED_VMSNAP (1M) |
Maintenance Commands |
-o snapshot [ -F ] | resync
dbed_vmsnap -S ORACLE_SID -f SNAPPLAN
-o reverse_resync_begin | reverse_resync_commit | reverse_resync_abort
pkginfo -l VRTSdbed
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).
The Veritas Database FlashSnap functionality provides both snapshot status information and snapshot database status information for various stages of snapplan and snapshot procedures. You can obtain both the snapshot status and the database status from the command line using the dbed_vmchecksnap command with the -o list option. The snapshot status and database status information may also appear in error messages. For a complete list of status values, see the Veritas Storage Foundation for Oracle Database Administrator's Guide, Appendix C.
You can use Database FlashSnap commands in a high availability (HA) environment. See the NOTES section below for details.
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 server name of the primary database. Make a note of these values so you have them when running dbed_vmclonedb.
After aborting reverse resynchronization, you can run any of the following operations depending on your needs: dbed_vmsnap -o reverse_resync_begin, dbed_vmsnap -o resync, dbed_vmclonedb -o restartdb.
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.
As a good practice, it is recommended to remove the old archive logs after reverse resynchronization is performed.
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:
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. However, 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:
dbed_vmsnap -S ORACLE_SID -f SNAPPLAN -o snapshot- 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 SFDB 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:
# hagrp -freeze ResourceGroup2. 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. As root, unfreeze the VCS resource group for the database:# dbed_vmsnap -S ORACLE_SID -f SNAPPLAN -o reverse_resync_begin# hagrp -unfreeze ResourceGroup
- 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, \ server_name=svr_name -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 Veritas Storage Foundation for Oracle RAC Installation and Configuration Guide ~
Last updated: 10 Apr 2006
Copyright ©2009 Symantec Corporation
All rights reserved.