Using Database FlashSnap to clone a database
Prev Cloning a database (db2ed_vmclonedb) Next

Using Database FlashSnap to clone a database

In a single-host configuration, the db2ed_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 db2ed_vmclonedb command imports the snapshot disk group, 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.

Prerequisites

  • You must be logged in as the DB2 instance owner.

  • Before you can use the db2ed_vmclonedb command, review the procedure for taking a snapshot of a database, especially the steps required to validate a snapplan and to create the 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 db2ed_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 DB2 instance owner.

  • If SNAPSHOT_MODE is set to offline, a two-host configuration is required.

Usage notes

  • The db2ed_vmclonedb command can be used on either the primary the secondary host as specified in the snapplan.

  • 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 server_name=svr_name option is required. The svr_name value specifies the server on which the primary database resides.

  • See the db2ed_vmclonedb(1M) manual page for more information.

Note:

When using the -o recoverdb option to clone a database, any database within the target instance that has the same name as the primary database to be cloned will be temporarily uncataloged and therefore unavailable.

Warning:

If the primary database is being cloned on the same host and within the same instance, it will be temporarily uncataloged while db2ed_vmclonedb is running. The database will be recataloged on completion of db2ed_vmclonedb.

To mount a database and recover it manually

  1. Start and mount the clone database to allow manual database recovery:

    $ /opt/VRTS/bin/db2ed_vmclonedb -D DB2DATABASE -g snap_dg \
-o mount,new_db=db_name,server_name=svr_name -f SNAPPLAN \
[-r relocate_path]

  2. Recover the database manually.

    • Create a configuration file with content similar to the following:

      DB_NAME=old_db,new_db
DB_PATH=old_dbpath,new_dbpath
INSTANCE=old_instance,new_instance
LOG_DIR=old_logdir,new_logdir
CONT_PATH=old_containerpath1,new_containerpath1
CONT_PATH=old_containerpath2,new_containerpath2

    • Run the following command:

      db2inidb newdb as snapshot relocate using configfile

      When this command is run, DB2 initiates a crash recovery and brings up the clone database.

      After this command is run, the primary database is uncataloged.

    • Recatalog the primary database:

      db2 catalog database DB2DATABASE on dpbath

    For detailed information about manual database recovery, refer to your DB2 documentation.

  3. Update the snapshot status information for the clone database in the SFDB repository:

    $ /opt/VRTS/bin/db2ed_vmclonedb -D PROD -I inst01 \
-o update_status,new_db=newprod,server_name=kagu \
-f snap1 -r /clone

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/db2ed_vmclonedb -D PROD -g SNAP_PRODdg \
-o mount,new_db=NEWPROD,server_name=kagu -f snap1 -r /clone
db2ed_vmclonedb started at 2006-04-01 13:30:12
Mounting /clone/testvol on /dev/vx/dsk/SNAP_PRODdg/SNAP_testvol.
Mounting /clone/udb_home on /dev/vx/dsk/SNAP_PRODdg/SNAP_udb_home.

If the database NEWPROD is recovered manually, you must run
db2ed_vmclonedb -o update_status to change the snapshot status.
db2ed_vmclonedb ended at 2006-04-01 13:30:24

The database is recovered manually using db2inidb.

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/db2ed_vmclonedb \
-o update_status,new_db=NEWPROD,server_name=kagu \
-f snap1 -r /clone
db2ed_vmclonedb started at 2006-04-01 13:37:09
The snapshot status has been updated.
db2ed_vmclonedb ended at 2006-04-01 13:37:23

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/db2ed_vmclonedb -D PROD -g SNAP_PRODdg \
-o mount,new_db=NEWPROD,server_name=kagu -f snap2 -r /clone
db2ed_vmclonedb started at 2006-03-10 13:21:32
Mounting /clone/PROD_HOME on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol1.
Mounting /clone/PROD_TBS on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol2.

If the database NEWPROD is recovered manually, you must run
db2ed_vmclonedb -o update_status to change the snapshot status.
db2ed_vmclonedb ended at 2006-03-10 13:22:08

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/db2ed_vmclonedb -o update_status,new_db=NEWPROD \
-f snap2
db2ed_vmclonedb started at 2006-03-10 13:39:49
The snapshot status has been updated.
db2ed_vmclonedb ended at 2006-03-10 13:40:01

To clone the database automatically

Note:

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

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

$ /opt/VRTS/bin/db2ed_vmclonedb -D PROD -g SNAP_PRODdg \
-o recoverdb,new_db=NEWPROD,server_name=kagu -f snap1 -r /clone
db2ed_vmclonedb started at 2006-03-10 14:03:32
Mounting /clone/PROD_HOME on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol1.
Mounting /clone/PROD_TBS on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol2.
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the directory
cache is refreshed.
DBT1000I  The tool completed successfully.
db2ed_vmclonedb ended at 2006-03-10 14:04:04

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

$ /opt/VRTS/bin/db2ed_vmclonedb -D PROD -g SNAP_PRODdg \
-o recoverdb,new_db=NEWPROD,server_name=kagu -f snap2 -r /clone
db2ed_vmclonedb started at 2006-03-10 14:03:32
Mounting /clone/PROD_HOME on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol1.
Mounting /clone/PROD_TBS on /dev/vx/dsk/SNAP_PRODdg/SNAP_prodvol2.
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the directory
cache is refreshed.
DBT1000I  The tool completed successfully.
db2ed_vmclonedb ended at 2006-03-10 14:04:04

More Information

Summary of database snapshot steps

Validating a snapplan (db2ed_vmchecksnap)

Creating a snapshot (db2ed_vmsnap)

Prev Up Next
Cloning a database (db2ed_vmclonedb) Home Shutting down the clone database and unmounting file systems