Using Database FlashSnap to Clone a Database


		< Previous \| TOC \| Index \| Next >

Using Database FlashSnap to Clone a Database

In a single-host configuration, the dbed_vmclonedb command creates a clone database on the same 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 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 vxdbavol=vol_name is required.

Caution When creating a clone database, all Storage Checkpoints in the original database are discarded.

Prerequisites

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.
See Summary of database snapshot steps

See Validating a snapplan (dbed_vmchecksnap

See Creating a snapshot (dbed_vmsnap)
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.
See Establishing a mandatory archive destination

Usage Notes

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.
In a two-host configuration, the vxdbavol=vol_name option is required.
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.

To mount a database and recover it manually

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[,vxdbavol=vol_name] -f SNAPPLAN \

[-H ORACLE_HOME] [-r relocate_path]
Recover the database manually.
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 -f SNAPPLAN [-r relocate_path]

Example: Mounting the file systems without bringing up the clone database

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 -f snap1 -r /clone

dbed_vmclonedb started at 2006-03-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.

Altering instance_name paramter in initpune.ora.

Altering instance_number paramter in initpune.ora.

Altering thread paramter in initpune.ora.

Starting automatic database recovery.

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-03-02 15:34:59

The database is recovered manually using dbinitdb command.

The database status (database_recovered) needs to be 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 \

-f snap1 -r /clone

dbed_vmclonedb started at 2006-03-02 15:35:16

The snapshot status has been updated.

dbed_vmclonedb ended at 2006-03-02 15:35:42

Example: Mounting the file systems without recovering the clone database

In this example, file systems are mounted 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 -g SNAP_PRODdg \

-o mountdb,new_sid=NEWPROD,vxdbavol=SNAP_arch -f snap2

dbed_vmclonedb started at 2006-03-09 23:26:50

Mounting /clone/arch on /dev/vx/dsk/SNAP_PRODdg/SNAP_arch.

Mounting /clone/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db.

All redo-log files found.

Altering instance_name paramter in initpune.ora.

Altering instance_number paramter in initpune.ora.

Altering thread paramter in initpune.ora.

Starting automatic database recovery.

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-03-09 23:27:17

The database is recovered manually.

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 \

-f snap2

dbed_vmclonedb started at 2006-03-09 23:34:01

The snapshot status has been updated.

dbed_vmclonedb ended at 2006-03-09 23:34:35

To clone the database automatically

Use the dbed_vmclonedb command as follows:

$ /opt/VRTS/bin/dbed_vmclonedb -S ORACLE_SID -g snap_dg \

-o recoverdb,new_sid=new_sid[,vxdbavol=vol_name] -f SNAPPLAN \

[-H ORACLE_HOME] [-r relocate_path]

Where:

ORACLE_SID

Represents the name of the Oracle database used to create the snapshot.

snap_dg

Represents the name of the diskgroup that contains all the snapshot volumes.

new_sid

Specifies the ORACLE_SID for the clone database.

vxdbavol

Represents the volume that contains the snapplan data.

This name is provided after you run dbed_vmsnap -o snapshot.

SNAPPLAN

Represents the name of the snapplan file.

ORACLE_HOME

Represents the ORACLE_HOME setting for the ORACLE_SID database.

relocate_path

Represents the name of the initial mount point for the snapshot image.

Note When cloning a database on a secondary host, ensure that PRIMARY_HOST and SECONDARY_HOST parameters in the snapplan file are different.

When the -o recoverdb option is used with dbed_vmclonedb, the clone database is recovered automatically using all available archive logs. If the -o recoverdb option is not used, you can perform point-in-time recovery manually.

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 -f snap1 -r /clone

dbed_vmclonedb started at 2006-03-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 paramter in initpune.ora.

Altering instance_number paramter in initpune.ora.

Altering thread paramter in initpune.ora.

Starting automatic database recovery.

Database NEWPROD (SID=NEWPROD) is running.

dbed_vmclonedb ended at 2006-03-02 14:43:05

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

$ /opt/VRTS/bin/dbed_vmclonedb -S PROD -g SNAP_PRODdg \

-o recoverdb,new_sid=NEWPROD,vxdbavol=SNAP_arch -f snap2

dbed_vmclonedb started at 2006-03-09 23:03:40

Mounting /clone/arch on /dev/vx/dsk/SNAP_PRODdg/SNAP_arch.

Mounting /clone/prod_db on /dev/vx/dsk/SNAP_PRODdg/SNAP_prod_db.

All redo-log files found.

Altering instance_name paramter in initpune.ora.

Altering instance_number paramter in initpune.ora.

Altering thread paramter in initpune.ora.

Starting automatic database recovery.

Database NEWPROD (SID=NEWPROD) is running.

dbed_vmclonedb ended at 2006-03-09 23:04:50


^ Return to Top	< Previous \| TOC \| Index \| Next >

ORACLE_SID	Represents the name of the Oracle database used to create the snapshot.
snap_dg	Represents the name of the diskgroup that contains all the snapshot volumes.
new_sid	Specifies the ORACLE_SID for the clone database.
vxdbavol	Represents the volume that contains the snapplan data. This name is provided after you run `dbed_vmsnap -o snapshot`.
SNAPPLAN	Represents the name of the snapplan file.
ORACLE_HOME	Represents the ORACLE_HOME setting for the ORACLE_SID database.
relocate_path	Represents the name of the initial mount point for the snapshot image.