dbed_vmclonedb

NAME

dbed_vmclonedb - create or shutdown a clone database using snapshot volumes from a primary database

SYNOPSIS

AVAILABILITY

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

swlist VRTSdbed

DESCRIPTION

When used in a two-host configuration, the dbed_vmclonedb command can only be run on the secondary host. The command imports the disk group snap_dg, mounts the file systems on the snapshot volumes, and starts a clone database on the secondary host. It can also reverse the process by shutting down the Oracle database, unmounting the file systems, and deporting the snapshot volumes. When creating the clone in a two-host configuration, -o vxdbavol=vol_name is required.

When used in a single-host configuration, the dbed_vmclonedb command 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.

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.

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 and unmount all snapshot file systems. If the clone database is used on the secondary host in a two-host configuration that has shared disks with the primary host, the -o umount option also deports the snapshot diskgroup.

OPTIONS

The following options are supported:

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

vxdbavol=vol_name

Specifies the volume that contains snapplan data. This name is not determined by the user. It is provided after you run dbed_vmsnap -o snapshot. This parameter is required when creating or removing the clone in a two-host configuration.

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

-r relocate_path

Specifies the initial mount point for the snapshot image. If you are creating a clone in a single-host configuration, -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.

EXAMPLES

EXAMPLE 1

In the following example, a clone of the primary database is automatically created on the same host as the primary database:

EXAMPLE 2

In the following example, a clone of the primary database is created on a secondary host:

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:

The snapshot status (database_recovered) is updated for a clone database on the primary host after manual recovery has been completed:

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:

The snapshot status (database_recovered) is updated for a clone database on a secondary host after manual recovery has been completed:

NOTES

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.

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 \
-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_vmsnap (1M), dbed_vmsnapplan (4)

VERITAS Storage Foundation for Oracle Administrator's Guide