Use the following procedure to create a clone database.
Although you can write to clone databases, they are generally used
for read-only activities such as running reports.
About this task
If the primary 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 primary database and can affect the recoverability
of both databases. While the cloned database will initially use a
different log chain from the primary database, the primary 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 primary 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. You can
use the AS SNAPSHOT option, but this provides
only an instantaneous copy of the database 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.
- Connect to the primary database using the following command:
db2 connect to db_name
- Suspend the I/O write operations on the primary 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.
- Create one or multiple split mirrors from the primary database
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
the 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
using the following command:
db2 set write resume for database
- Catalog the mirrored database on the secondary system.
Note: By default, a mirrored database cannot exist on the same
system as the primary database. It must be located 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 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 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 will share the same 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 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.