版本注意事項

|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. Otherwise, |subsequent connection attempts may hang if they require flushing dirty pages |from the buffer pool to disk. These 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 perform a crash recovery using the WRITE RESUME option of the |RESTART command.

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

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