Using a split mirror to clone a database in a Db2 pureScale environment

Use the following procedure to create a clone database in a Db2 pureScale environment. Although you can write to clone databases, they are generally used for read-only activities such as running reports.

About this task

If the source database was configured for log archiving, the cloned database will share the same log archiving configuration. If the archive log location is accessible to the cloned database, this could cause the cloned database to archive log files to the same location as the source database and can affect the recoverability of both databases. While the cloned database will initially use a different log chain from the source database, the source database could eventually use the same log chain value as the cloned database. You should change the log archiving destination for the cloned database to be different from that of the source database before running the db2inidb command to avoid recoverability issues.

You cannot back up a cloned database, restore the backup image on the original system, or roll forward through log files produced on the original system. The cloned database provides an instantaneous copy of the database only at that time when the I/O is suspended; any other outstanding uncommitted work will be rolled back after the db2inidb command is executed on the clone.

Procedure

To clone a database:

Connect to the source database using the following command:
```
db2 connect to <db_namd>
```
Configure the General Parallel File System (GPFS) on the secondary cluster by extracting and importing the settings of the primary cluster. On the primary cluster, run the following GPFS command:
```
mmfsctl filesystem syncFSconfig -n remotenodefile
```
where remotenodefile is the list of hosts in the secondary cluster.
On the standby cluster, list the cluster manager domain using the following command:
```
db2cluster -cm -list -domain
```
On the standby cluster, stop the cluster manager on each host in the cluster using the following command:
```
db2cluster -cm -stop -host host -force
```
Note: The last host which you shut down must be the host from which you are issuing this command.
Stop the GPFS cluster on the secondary system using the following command:
```
db2cluster -cfs -stop -all
```
Suspend the I/O write operations on the source database using the following command:
```
db2 set write suspend for database
```
Note: While the database is in suspended state, you should not be running other utilities or tools. You should only be making a copy of the database. You can optionally flush all buffer pools before issuing SET WRITE SUSPEND to minimize the recovery window. This can be achieved using the FLUSH BUFFERPOOLS ALL statement.
Determine which file systems must be suspended and copied using the following command:
```
db2cluster -cfs -list -filesystem
```
Suspend each GPFS file system that contains data or log data using the following command:
```
/usr/lpp/mmfs/bin/mmfsctl filesystem suspend-write
```
where filesystem represents a file system that contains data or log data.
Note: When the GPFS file systems are suspended, only write operations are blocked.
Create one or multiple split mirrors from the source database using appropriate operating system-level and storage-level commands.
Note:
- Ensure that you copy the entire database directory, including the volume directory. You must also copy the log directory, recovery database directories, ctrl_file_recov_path directories (if enabled), and any container directories that exist outside the database directory. To gather this information, refer to the DBPATHS administrative view, which shows all the files and directories of the database that need to be split.
- If you specified the EXCLUDE LOGS with the SET WRITE command, do not include the log files in the copy.
Resume the GPFS file systems that were suspended using the following command for each suspended file system:
```
/usr/lpp/mmfs/bin/mmfsctl filesystem resume
```
where filesystem represents a suspended file system that contains data or log data.
Resume the I/O write operations on the source database:
```
db2 set write resume for database
```
Start the GPFS cluster on the secondary system using the following command:
```
db2cluster -cfs -start -all
```
Start the cluster manager using the following command
```
db2cluster -cm -start -domain domain
```
Catalog the mirrored database on the secondary system:
Note: By default, a mirrored database cannot exist on the same system as the source database. It must be located on a secondary system that has the same directory structure and uses the same instance name as the source database. If the mirrored database must exist on the same system as the source database, you can use the db2relocatedb utility or the RELOCATE USING option of the db2inidb command to accomplish this.
Start the database instance on the secondary system using the following command:
```
db2start
```
Initialize the mirrored database on the secondary system using the following command:
```
db2inidb database_alias as snapshot
```
If required, specify the RELOCATE USING option of the db2inidb command to relocate the clone database:
```
 db2inidb database_alias as snapshot relocate using relocatedbcfg.txt
```
where the relocatedbcfg.txt file contains the information required to relocate the database.

Note: This command rolls back all transactions that are in flight at the time of the split. It also sets a new log chain for the cloned database, to differentiate the log files it produces from the log files produced by the source database.
Ensure that the cloned database uses a separate log archive from the source database. All database configuration parameters of the cloned database are set to the same values as the source database. If the location of the log archive (specified by the logarchmeth1/logarchmeth2 database configuration) is set to a shared location that can be accessed by both the source database and the cloned database, specify a different location for the log archive of the cloned database:
```
db2 update db cfg for <database_alias> using logarchmeth1 <archive_location_for_cloned_database>
```