The information below about the db2inidb utility supersedes the information in the Version 7.2 What's New book.
db2inidb is a tool shipped with DB2 that can perform crash recovery or put a database in rollforward pending state.
Suspended I/O supports continuous system availability by providing a full implementation for online split mirror handling, that is, splitting a mirror without shutting down the database. If you cannot afford to do offline or online backups on a large database, you can do backups or system copies from a mirror image by using suspended I/O and a split mirror image.
Suspended I/O prevents disk writes while the split mirror image of a database is being taken. All database operations besides online backup and restore should function normally while a database is suspended. However, some operations may wait for I/O writes to resume if dirty pages must be flushed from the buffer pool or log buffers to the logs. These operations should resume normally once the database I/O is resumed. It is important that the database I/O be resumed from the same connection that it was originally suspended and that no other operations be performed from this connection until the database I/O resumes. Otherwise, subsequent connection attempts may hang if they require flushing dirty pages from the buffer pool to disk.
Subsequent connections will complete once database I/O resumes. If your connection attempts are hanging, and it has become impossible to resume the I/O from the connection that you used to suspend it, then you will have to run the RESTART command with the WRITE RESUME option. When used in this circumstance, the RESTART command will resume I/O writes without performing crash recovery. The RESTART command with the WRITE RESUME option will only perform crash recovery when you use it after a database crash.
In a partitioned database environment, you don't have to suspend I/O writes on all partitions simultaneously. You can suspend a subset of one or more partitions in order to create split mirrors to perform offline backups. If the catalog node is included in the subset, it must be the last partition to be suspended.
Mirroring a database primarily involves copying the entire contents of the database directory, and the local database directory. The local database directory, sqldbdir, is located at the same level of the file structure as the main database directory. In addition, if the log directory and table space containers are not in the database directory, then they must also be copied. Since the split mirrored database is dependent on these directory paths, the paths that these directories are copied to must be identical to those of the primary system. This means that the instance must also be the same. As a result of this dependency, it is not possible to create a mirror database on the same system as the primary database unless the new "relocate" option of the db2inidb tool is used.
The purpose of the "relocate" option is to relocate a database on a given system using a specified configuration file. This can involve changing the internal database directory, container directory, log directory, instance name and database names. Assuming the database directory, container directories and log directory were successfully mirrored to different directory paths on the same system as the primary database, the db2inidb tool can be used along with the "relocate" option to update the mirrored database's internal paths. A usage scenario with this option can be found below.
Depending on how the storage devices are being mirrored, the uses of db2inidb will vary. The following uses assume that the entire database is mirrored consistently through the storage system.
In a multinode environment, the db2inidb tool must be run on every partition before the split mirror can be used from any of the partitions. The db2inidb tool can be run on all partitions simultaneously by using the db2_all command.
Making a Clone Database
The objective here is to have a clone of the primary database to be used on another system. The following procedure describes how a clone database may be made:
db2 set write suspend for database
db2 set write resume for database
After running the command, the primary database should be back to a normal state.
db2start
db2inidb database_name AS SNAPSHOT
You can also use this process to perform an offline backup, but if restored on the primary database, this backup cannot be used to roll forward, because the log chain will not match.
Using the Split Mirror as a Standby Database
As the mirrored (standby) database is continually rolling forward through the logs, new logs that are being created by the primary database are constantly fetched from the primary system. The following procedure describes how the split mirror can be used as a standby database:
db2 set write suspend for database
db2 set write resume for database
db2inidb database_name AS STANDBY
Using the Split Mirror as a Backup Image
The following procedure describes how to use the mirrored database as a backup image to restore over the primary database:
db2inidb database_name AS MIRROR
Splitting a Mirror onto the Same System as the Primary Database
The following procedure describes how to use the "relocate" option of the db2inidb tool to mirror a database onto the same system as the primary database. The example assumes that the database will be used under a new instance.
db2 set write suspend for database
db2 set write resume for database
db2start
db2inidb database_name as STANDBY relocate using config_file