|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