Cloning a Database (dbed_vmclonedb)

This section explains how to create a clone database using the snapshot volumes. You can use snapshots of a primary database to create a clone of the database at a given point in time. You can then implement decision-support analysis and report generation operations that take their data from the database clone rather than from the primary database to avoid introducing additional burdens on the production database.

A clone database can also serve as a valid backup of the primary database. See Backing Up the Database from Snapshot Volumes (dbed_vmclonedb) for more information. You can backup the primary database to tape using snapshot volumes.

The resynchronization functionality of Database FlashSnap allows you to quickly refresh the clone database with up-to-date information from the primary database. Reducing the time taken to update decision-support data also lets you generate analysis reports more frequently.

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.

Prerequisites

• You must be logged in as the Oracle database administrator.
• Before you can use the dbed_vmclonedb command, you must complete the steps in Summary of Database Snapshot Steps, Validating a Snapplan (dbed_vmchecksnap), and 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. For further details, 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

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

Example

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.

The database is recovered manually using dbinitdb.

The database status (database_recovered) needs to be updated for a clone database on the primary host after manual recovery has been completed.

Example

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.

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.

  To clone the database automatically

Use the dbed_vmclonedb command as follows:

Where:

• ORACLE_SID is the name of the Oracle database used to create the snapshot.
• snap_dg is the name of the diskgroup that contains all the snapshot volumes.
• new_sid specifies the ORACLE_SID for the clone database.
• vxdbavol is the volume that contains the snapplan data. This name is provided after you run dbed_vmsnap -o snapshot.
• SNAPPLAN is the name of the snapplan file.
• ORACLE_HOME is the ORACLE_HOME setting for the ORACLE_SID database.
• relocate_path is 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.

For information on cloning a database using the GUI, see Using the VERITAS Storage Foundation for Oracle Graphical User Interface.

Example

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

Example

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

Shutting Down the Clone Database and Unmounting File Systems

When you are done using the clone database, you can shut it down and unmount all snapshot file systems with the dbed_vmclonedb -o umount command. If the clone database is used on a secondary host that has shared disks with the primary host, the -o umount option also deports the snapshot disk group.

  To shut down the clone database and unmount all snapshot file systems

Use the dbed_vmclonedb command as follows:

Example

In this example, the clone database is shut down and file systems are unmounted for a clone on the same host as the primary database (a single-host configuration).

Example

In this example, the clone database is shut down, file systems are unmounted, and the snapshot disk group is deported for a clone on a secondary host (a two-host configuration).

Restarting a Clone Database

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.

  To start the clone database

Use the dbed_vmclonedb command as follows:

For information on restarting the clone database using the GUI, see Using the VERITAS Storage Foundation for Oracle Graphical User Interface.

Example

In this example, the clone database is re-started on the same host as the primary database (a single-host configuration).

Example

In this example, the clone database is re-started on the secondary host (a two-host configuration).

Recreating Oracle tempfiles

After a clone database is created and opened, the tempfiles are added if they were residing on the snapshot volumes. If the tempfiles were not residing on the same file systems as the datafiles, dbed_vmsnap does not include the underlying volumes in the snapshot. In this situation, dbed_vmclonedb issues a warning message and you can then recreate any needed tempfiles on the clone database as described in the following procedure.

  To recreate the Oracle tempfiles

1. If the tempfiles were not residing on the same file systems as the datafiles, dbed_vmclonedb will display the WARNING and INFO messages similar to the following:
            WARNING: Not all tempfiles were included in snapshot for $ORACLE_SID,
            there is no snapshot volume for 
            /clone_path/temp02.dbf.
            WARNING: Could not recreate tempfiles for $ORACLE_SID due to lack of 
            free space.
            INFO: The sql script for adding tempfiles to $ORACLE_SID is at 
            /tmp/add_tf.$ORACLE_SID.sql.

   ---

     Note    $ORACLE_SID is the name of the clone database.

   ---

2. A script named add_tf.$ORACLE_SID.sql is provided in the /tmp directory for the purpose of recreating Oracle tempfiles. This script contains the SQL*Plus commands to recreate the missing tempfiles.
3. Make a copy of the /tmp/add_tf.$ORACLE_SID.sql script and open it to view the list of missing tempfiles.

   An example of the add_tf.$ORACLE_SID.sql script is shown below:

   
     $ cat /tmp/add_tf.$ORACLE_SID.sql
     -- Commands to add tempfiles to temporary tablespaces.
     -- Online tempfiles have complete space information.
     -- Other tempfiles may require adjustment.
     ALTER TABLESPACE TEMP ADD TEMPFILE 
     '/clone_path/temp01.dbf'
     SIZE 4194304 REUSE AUTOEXTEND ON NEXT 1048576 MAXSIZE 33554432 ;
     ALTER TABLESPACE TEMP ADD TEMPFILE 
     '/clone_path/temp02.dbf' REUSE;
     ALTER DATABASE TEMPFILE '/clone_path2/temp02.dbf' 
     OFFLINE;
4. Evaluate whether you need to recreate any temp files. If you want to recreate tempfiles, proceed to the next step.
5. In the add_tf.$ORACLE_SID.sql file, edit the sizes and default path names of the tempfiles as needed to reside on cloned volumes configured for database storage.

   ---

     Note    Do not run the script without first editing it because path names may not exist and the specified mount points may not contain sufficient space.

   ---

6. After you have modified the add_tf.$ORACLE_SID.sql script, execute it against your clone database.
7. After you have successfully run the script, you may delete it.