Veritas Storage Foundation 5.1 SP1: Storage and Availability Management for Oracle (5900-1504, April 2011)

Cloning an existing database using a Storage Checkpoint must be done on the
same host.
You have the option to manually or automatically recover the database when
using the dbed_clonedb command:
■ Manual (interactive) recovery, which requires using the -i option, of the clone
database allows the user to control the degree of recovery by specifying which
archive log files are to be replayed.
■ Automatic (non-interactive) recovery, which is the default usage of the
command, recovers the entire database and replays all of the archive logs. You
will not be prompted for any archive log names.
Before cloning the Oracle instance, the following conditions must be met:
■ You must first create a Storage Checkpoint.
See “Creating Storage Checkpoints using dbed_ckptcreate”
on page 212.
■ You must be logged in as the database administrator.
■ Make sure you have enough space and system resources to create
a clone database on your system.
■ A clone database takes up as much memory and machine resources
as the primary database.
Prerequisites
■ The dbed_clonedb command is used to create a copy of a
database, cloning all existing database files to new locations.
■ The ORACLE_SID and ORACLE_HOME environment variables must
be set to the primary database.
■ It is assumed that the user has a basic understanding of the
database recovery process.
■ See the dbed_clonedb(1M) manual page for more information.
Usage notes
■ Note that the database cloning using Instant Checkpoint is not
supported for Oracle RAC.
■ When you clone the database by using Checkpoint, the node can
be any node in the same Oracle RAC cluster but the archive log
destination is required to be on CFS file system. Otherwise, you
must manually copy the archive log files.
Limitations for
Oracle RAC
Table 11-2 lists the options for the dbed_clonedb command.
Using Database Storage Checkpoints and Storage Rollback
Database Storage Checkpoint Commands
222