Home > Veritas Storage Foundation™ for Oracle Manual Pages
DBED_VMCLONEDB (1) |
User Commands |
-o mount | mountdb | recoverdb | restartdb, new_sid=new_sid,server_name=svr_name -f SNAPPLAN [ -H ORACLE_HOME ] [ -p pfile_modification_file ] [ -r relocate_path ]
dbed_vmclonedb -o update_status | umount,new_sid=new_sid,
server_name=svr_name -f SNAPPLAN [ -r relocate_path ]
lslpp -L VRTSdbed
When used in a single-host configuration, the dbed_vmclonedb command imports the disk group snap_dg, mounts the file systems on the snaphshot volumes and creates a clone database on the primary host. The command can also be used to shut down the clone database and unmount its file systems. When creating or unmounting the clone database in a single-host configuration, -r relocate_path is required so that the clone database's file systems use different mount points than those used by the primary database.
When used in an Oracle RAC database, the dbed_vmclonedb command must be run on the Veritas Cluster Volume Manager master node, and -r relocate_path is required so that the clone database's file systems use different mount points than those used by the primary database. The clone database is started as a single instance.
In all cases the server_name parameter must specify the host on which the Oracle instance ORACLE_SID runs.
The snapshot image is created by the dbed_vmsnap command on the primary host.
When the -o recoverdb option is used, the clone database is recovered automatically, using all available archive logs. As a good practice, it is recommended to remove the old archive logs after the cloning process is completed.
Caution: When creating a clone database, all Storage Checkpoints in the original database are discarded.
If the -o mountdb option is used, you can perform point-in-time recovery manually (this requires that you locate all the necessary logs).
If the clone database is down as a result of using dbed_vmclonedb -o umount or rebooting the system, you can restart it with the -o restartdb option.
When you are done using the clone database, dbed_vmclonedb with the -o umount option can shut it down, unmount all snapshot file systems and deports the snapshot diskgroup.
The -p pfile_modification_file allows modification to the memory-related parameters of the clone database's initialization parameter file. See Veritas Storage Foundation for Oracle Administrator's Guide for the complete list of parameters that may be modified. The format of the pfile_modification_file is the same as the Oracle initialization parameter file. Any parameter matching one found in the primary database's initialization parameter file will be replaced with the corresponding value from the pfile_modification_file. Any parameter not found will be added to the clone database's pfile.
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.
- -S ORACLE_SID
- Specifies the name of the Oracle database for which a snapshot image will be created.
- -g snap_dg
- Specifies the name of the diskgroup that contains all snapshot volumes.
- -o
- Specifies snapshot image options:
- mount | mountdb | recoverdb | restartdb
- Specifies what to do with the snapshot image. The -o mount option mounts the file systems so you can use them to do a backup. The -o mountdb option starts and mounts the database to allow manual database recovery. The -o recoverdb option recovers the database automatically. The -o restartdb option restarts the clone database if it is down. A clone database must exist to use the -o restartdb option.
- update_status | umount
- Specifies what to do with the snapshot image after shutting down the clone database. The -o update_status option updates the database status information in the SFDB repository. This option is only required when the clone database is recovered manually (that is, when -o mountdb is used). The -o umount option unmounts all snapshot file systems. If the clone database is in a two-host configuration, the -o umount option also deports the snapshot file systems.
- new_sid=new_sid
- Specifies the name of the clone database.
- server_name=svr_name
- Specifies the host on which the primary Oracle instance runs.
- -H ORACLE_HOME
- Specifies the ORACLE_HOME setting for the ORACLE_SID database.
- -f SNAPPLAN
- Indicates the name of the snapplan used by dbed_vmsnap.
- -p pfile_modification_file
- Specifies a file containing initialization parameters to be modified or added to the clone database's initialization parameter file prior to startup. The format of the pfile_modification_file is the same as that of the Oracle initialization parameter file.
- -r relocate_path
- Specifies the initial mount point for the snapshot image. If you are creating a clone in a single-host configuration or cloning an Oracle RAC database, -r is required. Otherwise, it is an optional argument. The system administrator needs to create and change the owner of this mount point to Oracle DBA. The dbed_vmclonedb command will fail if Oracle DBA does not have access rights to this mount point.
The -r relocate_path option is not allowed if SNAPSHOT_MODE=offline | instant. If -r relocate_path is used in -o mount | mountdb | recoverdb, then it is required to restart or unmount the clone database.
EXAMPLE 1
In the following example, a clone of the primary database is automatically created on the same host as the primary database:
$ /opt/VRTS/bin/dbed_vmclonedb -S PROD -g SNAP_PRODdg -o recoverdb,new_sid=NEWPROD,server_name=host1 -f snap1 -r /clone dbed_vmclonedb started at 2006-04-02 14:42:10 Mounting /clone/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db. Mounting /clone/prod_ar on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_ar. All redo-log files found. Altering instance_name in initnewprod.ora. Database NEWPROD (SID=NEWPROD) is running. dbed_vmclonedb ended at 2006-04-02 14:43:05
EXAMPLE 2
In the following example, a clone of the primary database is created on a secondary host:
$ /opt/VRTS/bin/dbed_vmclonedb -S PROD -g SNAP_PRODdg -o recoverdb,new_sid=NEWPROD,server_name=host1 -f snap2 dbed_vmclonedb started at 2006-04-09 23:03:40 Mounting /mytest/arch on /dev/vx/dsk/SNAP_PRODdg/SNAP_arch. Mounting /mytest/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db. All redo-log files found. Database NEWPROD (SID=NEWPROD) is running. dbed_vmclonedb ended at 2006-04-09 23:04:50
EXAMPLE 3
In this example, file systems are mounted and a clone database is created without recovering the clone database. The clone database must be manually recovered before it can be used. This example is for a clone created on the same host as the primary database:
$ /opt/VRTS/bin/dbed_vmclonedb -S PROD -g SNAP_PRODdg -o mountdb,new_sid=NEWPROD,server_name=host1 -f snap1 -r /clone dbed_vmclonedb started at 2006-04-02 15:34:41 Mounting /clone/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db. Mounting /clone/prod_ar on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_ar. All redo-log files found. Database NEWPROD (SID=NEWPROD) is in recovery mode. If the database NEWPROD is recovered manually, you must run dbed_vmclonedb -o update_status to change the snapshot status. dbed_vmclonedb ended at 2006-04-02 15:34:59
The snapshot status (database_recovered) is updated for a clone database on the primary host after manual recovery has been completed:
$ /opt/VRTS/bin/dbed_vmclonedb -o update_status,new_sid=NEWPROD,server_name=host1 -f snap1 -r /clone dbed_vmclonedb started at 2006-04-02 15:19:16 The snapshot status has been updated. dbed_vmclonedb ended at 2006-04-02 15:19:42
EXAMPLE 4
In this example, file systems are mounted and a clone database is created without recovering the clone database. The clone database must be manually recovered before it can be used. This example is for a clone created on a secondary host:
$ /opt/VRTS/bin/dbed_vmclonedb -S PROD -g SNAP_PRODdg -o mountdb,new_sid=NEWPROD,server_name=host1 -f snap2 dbed_vmclonedb started at 2006-04-09 23:26:50 Mounting /mytest/arch on /dev/vx/dsk/SNAP_PRODdg/SNAP_arch. Mounting /mytest/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db. All redo-log files found. Database NEWPROD (SID=NEWPROD) is in recovery mode. If the database NEWPROD is recovered manually, you must run dbed_vmclonedb -o update_status to change the snapshot status. dbed_vmclonedb ended at 2006-04-09 23:27:17
The snapshot status (database_recovered) is updated for a clone database on a secondary host after manual recovery has been completed:
$ /opt/VRTS/bin/dbed_vmclonedb -o update_status,new_sid=NEWPROD,server_name=host1 -f snap2 dbed_vmclonedb started at 2006-04-09 23:34:01 The snapshot status has been updated. dbed_vmclonedb ended at 2006-04-09 23:34:35
dbed_vmclonedb must be run as the Oracle DBA user and must be run on the secondary host specified in the snapplan. The user ID of Oracle DBA and the group ID of the Oracle DBA group need to be the same as the primary database.
Before creating the clone database, the system administrator first needs to create the initial mount point for the snapshot image (as in -r relocate_path ) and change the owner of this mount point to Oracle DBA. If -r relocate_path is not specified when creating the clone database on a secondary host in a two-host configuration, all corresponding file system mount points from the primary host need to be created and their owner needs to be set to Oracle DBA.
In a two-host configuration, the .odbc.ini file must be manually copied from the /etc/vx/vxdba directory on the primary server to the same location on the secondary server. This allows configuration information to be retrieved from the repository on the primary sever.
The dbed_vmclonedb command runs without interaction from the user.
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:
- 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.
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.