Home > Veritas Storage Foundation™ for DB2 Manual Pages

DB2ED_VMCLONEDB (1)

User Commands

NAME
SYNOPSIS
AVAILABILITY
DESCRIPTION
OPTIONS
EXAMPLES
NOTES
SEE ALSO

NAME

db2ed_vmclonedb - create or shutdown a clone database using snapshot volumes from a primary database

SYNOPSIS

db2ed_vmclonedb -D DB2DATABASE [ -I DB2INSTANCE ] -g snap_dg

-o mount | recoverdb | restartdb,new_db=db_name,server_name=server -f SNAPPLAN [ -r relocate_path ]

db2ed_vmclonedb -D DB2DATABASE [ -I DB2INSTANCE ] -o update_status | umount,new_db=db_name,server_name=server

-f SNAPPLAN [ -r relocate_path ]

AVAILABILITY

This command is part of Veritas Storage Foundation for DB2. To determine whether this product is installed on an \1 system, type:

lslpp -L VRTSdb2ed

DESCRIPTION

When used in a two-host configuration, the db2ed_vmclonedb command can only be run on the secondary host. The command imports the disk group snap_dg, mounts the file systems on the snapshot volumes, and starts a clone database on the secondary host. It can also reverse the process by shutting down the DB2 database, unmounting the file systems, and deporting the snapshot volumes.

When used in a single-host configuration, the db2ed_vmclonedb command mounts the file systems on the snaphshot volumes and creates a clone database on the primary 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.

The snapshot image is created by the db2ed_vmsnap command on the primary host.

When the -o recoverdb option is used, the clone database is recovered automatically, using all available redo logs.

If the clone database is down as a result of using db2ed_vmclonedb -o umount or rebooting the system, you can restart it with the -o restartdb option.

When you are done using the clone database, db2ed_vmclonedb with the -o umount option can shut it down and unmount all snapshot file systems.

OPTIONS

The following options are supported:

-D DB2DATABASE

Specifies the name of the DB2 database for which a snapshot image will be created.

-I DB2INSTANCE

Specifies the name of the DB2 instance used to create the snapshot. This is required when cloning a database under a different instance.

-g snap_dg

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

-o

Specifies snapshot image options:

mount | recoverdb | restartdb

Specifies what to do with the snapshot image. The -o mount option mounts the file systems so you can use them to do a backup. The -o recoverdb option recovers the database automatically. The -o restartdb option restarts the clone database if it is down. A clone database must exist to use the -o restartdb option.

update_status | umount

Specifies what to do with the snapshot image after shutting down the clone database. The -o update_status option updates the database status information in the VxDBA repository. This option is only required when the clone database is recovered manually (that is, when -o mount is used). The -o umount option unmounts all snapshot file systems.

new_db=db_name

Specifies the name of the clone database.

server_name=server

Specifies the name of the primary database server.

-f SNAPPLAN

Indicates the name of the snapplan used by db2ed_vmsnap.

-r relocate_path

Specifies the initial mount point for the snapshot image. If you are creating a clone in a single-host configuration, -r is required. Otherwise, it is an optional argument. The system administrator needs to create and change the owner of this mount point to the DB2 instance owner. The db2ed_vmclonedb command will fail if the DB2 instance owner does not have access rights to this mount point.
The -r relocate_path option is not allowed if SNAPSHOT_MODE=offline. If -r relocate_path is used in -o mount | recoverdb, then it is required to restart or unmount the clone database.

EXAMPLES

EXAMPLE 1

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

$ /opt/VRTS/bin/db2ed_vmclonedb -D udb1 -g SNAP_vm1dg -f sp_1 -o recoverdb,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:20:55
Mounting /clone_1/fs1_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol1_dg1.
Mounting /clone_1/fs2_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol2_dg1.
Mounting /clone_1/fs3_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol3_dg1.
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-02-06 09:21:46

EXAMPLE 2

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

$ /opt/VRTS/bin/db2ed_vmclonedb -D udb1 -g SNAP_vm1dg -f sp_1 -o recoverdb,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:19:36
Mounting /clone_1/fs1_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol1_dg1.
Mounting /clone_1/fs2_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol2_dg1.
Mounting /clone_1/fs3_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol3_dg1.
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.
DBT1000I  The tool completed successfully.
db2ed_vmclonedb ended at 2006-02-06 09:20:20

EXAMPLE 3

In this example, file systems are mounted on the same host and a clone database is created 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 the same host as the primary database:

$ /opt/VRTS/bin/db2ed_vmclonedb -D udb1 -g SNAP_vm1dg -f sp_1 -o mount,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:26:40
Mounting /clone_1/fs1_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol1_dg1.
Mounting /clone_1/fs2_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol2_dg1.
Mounting /clone_1/fs3_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol3_dg1.
If the database CLONE1 is recovered manually, you must run
db2ed_vmclonedb -o update_status to change the snapshot status.
db2ed_vmclonedb ended at 2006-02-06 09:27:12

The snapshot status (database_recovered) is updated for a clone database on the primary host after manual recovery has been completed:

$ /opt/VRTS/bin/db2ed_vmclonedb -D udb1 -f sp_1 -o update_status,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:28:53
The snapshot status has been updated.
db2ed_vmclonedb ended at 2006-02-06 09:29:04

EXAMPLE 4

In this example, file systems are mounted on a secondary host and a clone database is created 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 udb1 -g SNAP_vm1dg -f sp_1 -o mount,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:13:40
Mounting /clone_1/fs1_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol1_dg1.
Mounting /clone_1/fs2_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol2_dg1.
Mounting /clone_1/fs3_vm1dg on /dev/vx/dsk/SNAP_vm1dg/SNAP_vol3_dg1.
If the database CLONE1 is recovered manually, you must run
db2ed_vmclonedb -o update_status to change the snapshot status.
db2ed_vmclonedb ended at 2006-02-06 09:13:53

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 -D udb1 -f sp_1 -o update_status,new_db=clone1,server_name=kagu -r /clone_1

db2ed_vmclonedb started at 2006-02-06 09:15:53
The snapshot status has been updated.
db2ed_vmclonedb ended at 2006-02-06 09:16:08

NOTES

db2ed_vmclonedb must be run as the target DB2 instance owner and must be run on the secondary host specified in the snapplan. The user and group ID of the DB2 instance owner on the secondary host should be the same as on the primary host. If cloning to a different instance owner, the group ID must be the same as the original instance owner on the primary host.

Before creating the clone database, the system administrator first needs to create the initial mount point for the snapshot image (as in -r relocate_path ) and change the owner of this mount point to the DB2 instance owner. If -r relocate_path is not specified when creating the clone database on a secondary host in a two-host configuration, all corresponding file system mount points from the primary host need to be created and their owner needs to be set to the DB2 instance owner.

The db2ed_vmclonedb command runs without interaction from the user.

DB2ED_VMCLONEDB (1)

Table of contents