版本注意事項

|9.1 Chapter 8. Recovering a Database

|9.1.1 How to Use Suspended I/O

| | | | |

|In Chapter 8."Recovering a Database", the following section on using |the suspended I/O function has been added and updated:

|Note:: The information below about the db2inidb utility supersedes |the information in the Version 7.2 What's New book. |

|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.

| |

|Making a Clone Database

|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: |
1. |Suspend I/O writes on the primary database by entering the following command:
```
|     db2 set write suspend for database
```
2. |Use operating system level commands to split the mirror from the primary |database.
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 database from another system.
5. |Start the database instance 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 rollback the changes made by transactions |that were in-flight at the time of the split. |
  |
|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. |
|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 the operating system level commands to split the mirror from the primary |database.
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. |Place the mirror in roll forward pending and roll forward the mirror.
```
|	db2inidb database_name AS STANDBY
```
  |
  |Note:
  This command |will remove the suspend write state and place the mirrored database in roll |forward pending state. |
6. |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.
7. |Roll forward the database to the end of the logs.
8. |Go back to step f and repeat this process until the primary database is |down. |
|
|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. |Use operating system commands to copy the mirrored data and logs on top |of the primary database.
2. |Start the database instance by entering the following command:
```
|     db2start
```
3. |Run the following command to place the mirrored database in a roll-forward |pending state and to remove the suspend write state.
```
|db2inidb database_name AS MIRROR
```
4. |Roll forward the database to the end of the logs. |
|
|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 level commands to split the mirror from the primary |database.
  |Note:
  The database directory, container directories and |log directory must be copied to different directories. If the container directories |or the log directory exist under the database directory, then only the database |directory needs 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 only required 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 roll forward 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. |
|

[ 頁面頂端 | 前一頁 | 下一頁 | 目錄 | 索引 ]