Home > Veritas Storage Foundation™ for Oracle Manual Pages

DBED_CLONEDB (1)

User Commands

Table of contents


NAME

dbed_clonedb - clone an Oracle database to the same or a different instance, allowing the two databases to co-exist

SYNOPSIS

To create a clone database:

dbed_clonedb -S CLONE_SID -m MOUNT_POINT [-h] [-i]


-c CKPT_NAME [-p pfile_modification_file]

To unmount or restart a clone database:

dbed_clonedb -o umount | restartdb [-d] [-h]


AVAILABILITY

Veritas Storage Foundation for Oracle. To determine whether this product is installed on an \1 system, enter:

lslpp -L VRTSdbed


DESCRIPTION

The dbed_clonedb command is used to create a copy of an existing Oracle database (the primary database), cloning all existing files to new locations. Cloning an existing Oracle database requires a writable Storage Checkpoint, where a clone database needs to be started on the same host as the existing database. The primary database remains unaffected. For Oracle RAC database, the clone database is started as a single instance, on the node where the dbed_clonedb command is executed. The node needs to be within the RAC database cluster.

To use dbed_clonedb, the current environment must be configured correctly for the primary database. This means that the ORACLE_SID and ORACLE_HOME environment variables must be set correctly for the primary database. Be sure you have enough space to create a clone database on your system. For Oracle RAC database, the archive log destination is required to be on Veritas Cluster File System.

dbed_clonedb brings up a mounted, writable clone of an Oracle instance. The new instance is given a new name and mount point, as specified by arguments to the command. The mount point should be identical to that used to mount the Storage Checkpoint. The dbed_clonedb command is designed to work with a mounted, writable Storage Checkpoint of an Oracle instance. If the Storage Checkpoint has not been mounted (for example, using the dbed_ckptmount command), dbed_clonedb will automatically mount the Storage Checkpoint as read-write at the specified mount point. The new Oracle instance is given a new name, and datafiles are on a new location, as specified by arguments to dbed_clonedb.

For online and instant Storage Checkpoints, all available archive logs will be played back for the recovery process. If the -i option is specified, dbed_clonedb will prompt you to complete the Oracle recovery process with the new database. This allows you the option of performing point-in-time recovery. For information about Oracle recovery, see the Oracle Backup and Recovery Guide for your version of Oracle.


OPTIONS

The following options are supported:
-S CLONE_SID
The name of the clone database to be created from the original.
-m MOUNT_POINT
The location of the database files to be cloned. It should be identical to the mount point supplied to the dbed_ckptmount command used when mounting the Storage Checkpoint.
-c CKPT_NAME
Specifies the name of the Storage Checkpoint to use for creating the new database instance. If the Storage Checkpoint is not mounted at the specified mount point, it is mounted automatically during the cloning process.
-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.
-o umount | restartdb
The -o umount option shuts down the clone database and unmounts the Storage Checkpoint file system. The -o restartdb option mounts the Storage Checkpoint file system and starts the clone database. The -o restartdb option will not attempt to recover the clone database.
-d
This option is only for use with the -o umount option. If the -d option is specified, the Storage Checkpoint used to create the clone database will be removed along with the clone database.
-i
Sets interactive mode.
-h
Shows command help.


NOTES

For online and offline Storage Checkpoints, dbed_clonedb requires that extra space be allocated for re-creating Oracle control files and online redo logs, if these files are not on a file system with Oracle datafiles. This is because these types of files are not normally incorporated into a Storage Checkpoint. After mounting the Storage Checkpoint and before running the dbed_clonedb command, extra file system space may be mounted along with the Storage Checkpoint to provide space for Oracle control files and online redo logs. Alternately, symbolic links can be used to point to available space. For instant Storage Checkpoints, the file systems on which control files and redo logs are located will also be included in the Storage Checkpoint. During the cloning process, the control files and online redo logs from the Storage Checkpoint are used to recover the database.

For additional information about instant Storage Checkpoints, see dbed_ckptcreate(1M).

For instant Storage Checkpoints, dbed_clonedb uses the online redo logs for database recovery. Rolling forward is not allowed for instant Storage Checkpoints. For instant Storage Checkpoints, only database-level (including control files and redo logs) rollback is allowed. Individual datafiles and tablespaces cannot be rolled back. Cloning an Oracle RAC database with an instant Storage Checkpoint is not supported.

dbed_clonedb is designed to work with VxFS file systems or CFS file systems, and mounted Storage Checkpoints. Other types of file system are not supported by dbed_clonedb.

The -p pfile_modification_file allows modification to the memory-related parameters of the clone database's initialization parameter file. See the 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.

For a database located on a mounted Storage Checkpoint, dbed_clonedb assumes that the files that Oracle will attempt to open during the cloning process will be the originals. Because of this, you should change all symbolic links pointing to datafiles to relative links. The dbed_clonedb command examines Oracle datafiles for symbolic links that point to an absolute destination. If it finds absolute links, dbed_clonedb exits immediately with an error message. See the ln online manual page for more information about symbolic links.

The ORACLE_SID and ORACLE_HOME environment variables must be set correctly to use dbed_clonedb. If they are not set, then the dbed_clonedb command will not run.

When aborting a cloning operation, rerun the script as follows:

1
Check that the clone/new instance has been started.
2
If the clone/new instance is not running, rerun the dbed_clonedb command.
3
If the clone/new instance is running, shut down the clone/new Oracle instance.
4
Unmount the clone and remount it using the CLI.
5
Restart the dbed_clonedb command.

EXAMPLES

To clone an Oracle database with manual Oracle recovery:

$ /opt/VRTS/bin/dbed_clonedb -S clone -m /local/oracle9/1 \.br
-c Checkpoint_988813047 -i

To clone an Oracle database with automatic Oracle recovery:


$ /opt/VRTS/bin/dbed_clonedb -S clone -m /local/oracle9/1 \.br
-c Checkpoint_988813047


SEE ALSO

dbed_ckptcreate(1M), dbed_ckptdisplay(1M), dbed_ckptmount(1M), dbed_ckptplan(1M), dbed_ckptpolicy(1M), dbed_ckptquota(1M), dbed_ckptremove(1M), dbed_ckptrollback(1M), dbed_ckptumount(1M), dbed_update(1M), oracle_edition(7)

Veritas Storage Foundation for Oracle Administrator's Guide Veritas Storage Foundation for Oracle RAC Installation and Configuration Guide
Oracle Backup and Recovery Guide

Last updated: 15 Jan 2005
Copyright ©2009 Symantec Corporation
All rights reserved.