DB2 Version 10.1 for Linux, UNIX, and Windows

Using a split mirror to clone a database

Use the following procedure to create a clone database in an environment outside of a DB2® pureScale® environment. Although you can write to clone databases, they are typically used for read-only activities such as running reports.

About this task

If the primary database was configured for log archiving, the cloned database shares the log archiving configuration. If the archive log location is accessible to the cloned database, this can cause the cloned database to archive log files to the same location as the primary database and can affect the recoverability of both databases. While the cloned database initially uses a different log chain from the primary database, the primary database can eventually use the same log chain value as the cloned database. To avoid recoverability issues, change the log archiving destination for the cloned database to be different from that of the primary database before you run the db2inidb command.

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

Procedure

To clone a database:

Connect to the primary database by using the following command:
```
db2 connect to db_name
```
Suspend the I/O write operations on the primary database by using the following command:
```
db2 set write suspend for database
```
While the database is in suspended state, you should not be running other utilities or tools. You should be only making a copy of the database. You can optionally flush all buffer pools before you issue SET WRITE SUSPEND to minimize the recovery window. This can be achieved by using the FLUSH BUFFERPOOLS ALL statement.
Create one or multiple split mirrors from the primary database by using the 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 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 EXCLUDE LOGS with the SET WRITE command, do not include the log files in the copy.
Resume the I/O write operations on the primary database by using the following command:
```
db2 set write resume for database
```
Catalog the mirrored database on the secondary system.
By default, a mirrored database cannot exist on the same system as the primary database. It must be on a secondary system that has the same directory structure and uses the same instance name as the primary database. If the mirrored database must exist on the same system as the primary 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 by using the following command:
```
db2start
```
Initialize the mirrored database on the secondary system:
```
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 that is required to relocate the database.
Note:
- This command rolls back transactions that are in flight when the split occurs, and starts a new log chain sequence so that any logs from the primary database cannot be replayed on the cloned database.
- If the primary database was configured for log archiving, the cloned database shares the log archiving configuration. This means that the cloned database attempts to archive log files to the same location used by the primary database if that location is accessible to the cloned database. Although the cloned database initially uses a different log chain from the primary database, there is nothing to prevent the primary database from eventually using the same log chain value as the cloned database. This might cause the primary database to archive log files on top of the log files that are archived by the clone database, or vice versa. This might affect the recoverability of both databases. You should change the log archiving destination for the cloned database to be different from that of the primary database to avoid these issues.