Veritas Storage Foundation™ 5.0.1 for Oracle RAC Installation, Configuration, and Administrator's Guide Extracts for the HP Serviceguard Storage Management Suite on HP-UX 11i v3

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 a two-host configuration, the dbed_vmclonedb command imports the snapshot
disk group SNAP_dg, mounts the file systems on the snapshot volumes, and starts a clone
database. It can also reverse the process by shutting down the clone database, unmounting the
file systems, and deporting the snapshot disk group. When creating the clone off host, -o
sfdbvol=vol_name is required
WARNING! When creating a clone database, all Storage Checkpoints in the original database
are discarded.
Table 5-9 Recover Database Notes
• You must be logged in as the Oracle database administrator.
• Before you can use the dbed_vmclonedb command, you must validate a snapplan and
create a snapshot. The volume snapshot must contain the entire database.
• The system administrator must provide the database administrator with access to the
necessary volumes and mount points.
• Before you can use the dbed_vmclonedb command with the -r relocate_path option (which
specifies the initial mount point for the snapshot image), the system administrator must
create the mount point and then change the owner to the Oracle database administrator.
• If SNAPSHOT_MODE is set to offline or instant, a two-host configuration is required and -r
relocate_path is not allowed.
• The Oracle database must have at least one mandatory archive destination.
Prerequisites
• The dbed_vmclonedb command can be used on the secondary host.
• In a single-host configuration, -r relocate_path is required. This command is also
needed if the name of the clone database is different than the primary database.
• The initialization parameters for the clone database are copied from the primary database.
This means that the clone database takes up the same memory and machine resources as
the primary database. If you want to reduce the memory requirements for the clone database,
shut down the clone database and then start it up again using a different init.ora file that
has reduced memory requirements. If the host where dbed_vmclonedb is run has little
available memory, you may not be able to start up the clone database and the cloning
operation may fail.
• See the dbed_vmclonedb(1M) manual page for more information.
Usage Notes
To mount a database and recover it manually:
1. Start and mount the clone database to allow manual database recovery:
# /opt/VRTS/bin/dbed_vmclonedb -S ORACLE_SID -g snap_dg -o
mountdb,new_sid=new_sid,server_name=server_name[,sfdbvol=vol_name]
-f SNAPPLAN [-H ORACLE_HOME] [-r relocate_path]
2. Recover the database manually.
3. Update the snapshot status information for the clone database in the VxDBA repository:
# /opt/VRTS/bin/dbed_vmclonedb -o update_status,
new_sid=new_sid,server_name=server_name -f SNAPPLAN [-r
relocate_path]
Example: Mounting the file systems without bringing up the clone database
1. In this example, file systems are mounted without bringing up the clone database. The clone
database must be manually created and 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
Cloning a Database (dbed_vmclonedb) 77