|In Chapter 8."Recovering a Database", the following section on |using the suspended I/O function has been added and updated:
|db2inidb is a new tool shipped with DB2 that can perform crash recovery and |put a database in roll forward 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 a customer cannot afford doing |offline or online backups on a large database, backups or system copies can be |done from a mirror image by using suspended I/O and split mirror.
|Suspended I/O prevents disk writes to ensure that the split mirror image of |a database is consistent. All database operations, beside online backup |and restore, should function normally while a database is suspended. |However, some operations may hang while attempting to flush dirty pages 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. Otherwise, a subsequent connection attempt may hang if it |requires flushing dirty pages from the buffer pool to disk.
|Mirroring a database primarily involves copying the entire contents of the |database directory. It is also necessary to copy the log directory and |any table space containers if they are not located in the database |directory. Since the split mirrored database is dependent on these |directory paths, the paths that these directories are copied to must be |identical to those from the primary system. This implies that the |instance must also be the same. As a result of this dependency, it is |not possible to mirror a database on the same system as the primary 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 names, and log |directory, changing the instance name and changing the database name. |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 multi-node environment, the db2inidb tool must be run on every |partition before the split image can be used from any of the |partitions. The db2inidb tool can be run on all partitions |simultaneously.
|The objective here is to have a clone of the primary database to be used |for read-only purposes. 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 for 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. |
|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
|
|The following procedure describes how to use the mirrored database as a |backup image to restore over the primary database: |
| db2start
|db2inidb database_name AS MIRROR
|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