Release Notes

13.3 How to Use Suspended I/O for Database Recovery

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:
1. Suspend I/O writes on the primary database by entering the following command:
```
     db2 set write suspend for database
```
2. Use operating system and disk subsystem level commands to split the mirror from the primary database. Ensure that you split both the data and the logs.
3. Resume I/O writes on the primary database by entering the following command:
```
     db2 set write resume for database
```
  After running the command, the primary database should be back to a normal state.
4. Mount the split mirror of the primary database on another system.
5. Start the database instance on the other system, by entering the following command:
```
     db2start
```
6. Start the DB2 crash recovery by entering the following command:
```
db2inidb database_name AS  SNAPSHOT
```
  Note:
  This command will remove the suspend write state and roll back the changes made by transactions that were occurring at the time of the split.
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:
1. Suspend I/O writes on the primary database:
```
	db2 set write suspend for database
```
2. Use operating system and disk subsystem level commands to split the mirror from the primary database. Ensure that you only split the data and not the logs.
3. Resume the I/O writes on the primary database so that it goes back to normal processing.
```
	db2 set write resume for database
```
4. Mount the split mirror of the database to another system.
5. Start the primary database instance by using the db2start command.
6. Place the mirror in roll forward pending:
```
	db2inidb database_name AS STANDBY
```
  Note:
  This command will remove the suspend write state and place the mirrored database in rollforward pending state.
7. Copy logs by setting up a user exit program to retrieve log files from the primary system to ensure that the latest logs will be available for this mirrored database.
8. Roll forward the database to the end of the logs.
9. Go back to step g and repeat this process until the primary database is down.
10. Roll forward the database to the end of the logs, using the AND STOP option to bring the database back online. It will now be ready to use.
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:
1. Stop the primary database instance with the db2stop command.
2. Use operating system and disk subsystem commands to copy the mirrored data back on top of the primary database. Do not copy back the log files. The logs on the primary database must be used for rollforward operations.
3. Start the primary database instance with the db2start command.
4. Run the following command to place the mirrored database in a rollforward pending state and to remove the suspend write state:
```
db2inidb database_name AS MIRROR
```
5. Roll forward the database to the end of the logs, using the AND STOP option to bring the database back online. It will now be ready to use.
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.
1. Create a new instance on the current system.
2. Suspend I/O writes on the primary database:
```
	db2 set write suspend for database
```
3. Use the operating system and disk subsystem level commands to split the mirror from the primary database.
  Note:
  The database directory, local database directory, container directories, and log directory must be copied to the new instance. If the container directories or the log directory exist under the database directory, then only the database directory and local database directory need to be copied.
4. Resume I/O writes on the primary database so that it goes back to normal processing:
```
	db2 set write resume for database
```
5. Create a configuration file with the following information:
  DB_NAME=name,optional_new_name
  DB_PATH=primary_db_dir_path,mirrored_db_dir_path
  INSTANCE=primary_instance,mirror_instance
  LOG_DIR=primary_db_log_dir,mirrored_db_log_dir
  CONT_PATH=primary_db_container_#1_path,
  mirrored_db_container_#1_path ...
  CONT_PATH=primary_db_container_#n_path,
  mirrored_db_container_#n_path
  NODENUM=node_#
  
  Note:
  The LOG_DIR and the CONT_PATH fields are required only if the log directory and container directories exist outside of the database directory. All of the other fields are required, except for NODENUM, which will default to zero if not specified.
6. Start the database from the newly created instance:
```
	db2start
```
7. Relocate the mirrored database, remove the suspended state, and place the mirror in the rollforward pending state:
```
	db2inidb database_name as STANDBY relocate using config_file
```
8. Copy logs by setting up a user exit program to retrieve log files from the primary database to ensure that the latest logs will be available for this mirrored database.
9. Roll forward the database to the end of the logs.
10. Go back to step h and repeat this process until the primary database is down.
11. Roll forward the database to the end of the logs, using the AND STOP option to bring the database back online. It will now be ready to use.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]