Section 13.10. High Availability Through Online Split Mirroring and Suspended IO Support

13.10. High Availability Through Online Split Mirroring and Suspended I/O Support

Although the online backup method provides the ability to take a database backup without having to bring down the database, for a large database this process, and the process of restoring from the backup, could be time-consuming.

DB2's split mirroring and suspended I/O support solve this problem. With split mirroring, you can take a disk mirror image of the current database using your operating system's utility and put this mirror image into a new database. This process has the following advantages over the traditional DB2 backup method:

• It eliminates backup operation overhead from the primary server.

• It is a faster way to set up a new database using the mirror image. No DB2 restore operation is necessary.

13.10.1. Split Mirroring Key Concepts

Splitting a mirror means creating an "instantaneous" copy of the primary database by writing the data to a hard disk. When required, this disk copy can be used to clone a new, but identical database.

The method you choose to split the mirror is not within the control of DB2. You could take a file system copy of the database directory if you wish. However, we strongly recommend that you use any intelligent storage devices, such as the IBM Enterprise Storage Server (ESS), known as "Shark," and the EMC Symmetrix 3330. Using the FlashCopy technology, the ESS can establish near-instantaneous copies of the data entirely within itself. The instant split feature of EMC TimeFinder software on Symmetrix is also capable of splitting the mirror in a similar manner.

A split mirror of a database includes the entire contents of the database directory, all the table space containers, and the local database directory. The active log directory may or may not be included, depending on how you want to clone your database, which will be discussed later.

When splitting the mirror, it is important to ensure that there are no page writes occurring on the source database. DB2's suspended I/O support allows online splitting mirroring without shutting down the database. While the database is in write-suspended mode, all of its table spaces are placed in SUSPEND_WRITE state. All operations continue to function normally. However, some transactions may have to wait if they require disk I/O. These transactions will proceed normally once the write operations on the database are resumed. Use the following commands to suspend and resume write operations on a database.

To suspend write operations:

 SET WRITE SUSPEND FOR DATABASE 

To resume write operations:

 SET WRITE RESUME FOR DATABASE 

Because the split mirror was taken while the database was in write-suspend mode, it is not usable right away. You must use the db2inidb command to initialize the split mirror database to a functional state. The syntax for the db2inidb command is:

 db2inidb database_alias as snapshot | standby | mirror [relocate using config_file] 

You can choose to initialize the split mirror database in three different ways.

• Snapshot uses the split mirror to clone a database.

• Standby uses the split mirror to create a standby database.

• Mirror uses the split mirror as a backup image of the primary database.

If you use the Snapshot or the Standby option, by default, the split mirror database cannot exist on the same system as the primary database, because it must have the same directory structure and use the same instance name as the primary database. (You cannot share the same database directory between two databases.) If the mirrored database must exist on the same system as the primary database, you can use the db2relocatedb utility or the RELOCATE USING option of the db2inidb command to accomplish this. This restriction does not apply to the Mirror option (you will see why in section 13.10.4, Creating a Backup Image of the Primary Database Using the db2inidb Mirror Option.).

13.10.2. Cloning a Database Using the db2inidb Snapshot Option

When you clone a database using the db2inidb command and the snapshot option, the split mirror database goes through a crash recovery during the initialization. After the crash recovery is completed, the database is usable. It cannot roll forward any log files from the source database.

Follow these steps to create a clone database using the db2inidb snapshot option.

1.	Suspend I/O on the source database by issuing: CONNECT TO source-database SET WRITE SUSPEND FOR DATABASE
2.	Split the mirror. This process differs from vendor to vendor. Please consult the storage vendor documentation applicable to your device on how to create a split mirror. Regardless of the variations on the split mirror process, all of the following must be split at the same time: The entire contents of the database directory All the table space containers The local database directory The active log directory, if it does not reside on the database directory
3.	You can resume I/O on the source database by issuing the following command (note that you must use the same connection session from step 1 when issuing this command): SET WRITE RESUME FOR DATABASE
4.	Make the split mirror accessible. On the target server, create the same DB2 instance as it is on the primary server. Restore all the items obtained from step 2 to exactly the same paths as they are on the primary server. Run the following command to catalog the database on the target server: CATALOG DATABASE database-name as database_alias on path where database_alias must match the database alias of the primary database, and path must match the database path of the primary database (use the LIST DB DIRECTORY command to display the database path).
5.	Initialize the split mirror database to be a clone database. Start the instance on the target server using the db2start command. Initialize the split mirror database using the snapshot option: db2inidb database_alias as snapshot This db2inidb command initiates a crash recovery, which rolls back all uncommitted transactions at the time of split mirroring, thereby making the database consistent. It is essential to have all the log files from the source that were active at the time of the split. The active log directory must not contain any log file that is not a part of the split mirror. After the completion of the crash recovery, the database is available for operation.

13.10.3. Creating a Standby Database Using the db2inidb Standby Option

When you create a database using the standby option, no crash recovery takes place. The split mirror database will be placed in a roll forward pending state following the initialization process. The log files of the source database must be applied on the target database before it is usable.

To create a standby database using the db2inidb standby option, follow these steps.

1.	Suspend I/O on the source database. SET WRITE SUSPEND FOR DATABASE
2.	Split the mirror. Use the appropriate method to split mirror from the primary database: The entire contents of the database directory All the table space containers The local database directory You do not need to split the active log directory in this scenario.
3.	Resume I/O on the source database. SET WRITE RESUME FOR DATABASE
4.	Make the split mirror accessible. Follow the same steps in the snapshot scenario to make the split mirror accessible. If the active log directory of the primary database does not reside in the database directory, then you must manually create this on the target server. (This is because the active log directory is not included in the split mirror in this scenario.)
5.	Initialize the spilt mirror database as a standby database. The following command initializes the database and puts it in a rollforward pending state, so logs from the source database can be applied. db2inidb database_alias as standby
6.	Roll forward the logs obtained from the source database. Copy all the logs currently in the active log directory of the source database to the active log directory of the target database. Issue the following command to roll forward the logs: ROLLFORWARD DB database_alias TO END OF LOGS AND COMPLETE

After the roll forward process is completed, the database is ready for use.

13.10.4. Creating a Backup Image of the Primary Database Using the db2inidb Mirror Option

You can use the mirror option of the db2inidb command to create a quick mirror file backup of a primary database. The split mirror can be used to restore the primary database if needed. This procedure can be used instead of performing the backup and restore database operations on the primary database.

The following are the steps to create a backup image of the source database using the db2inidb mirror option.

1.	Suspend I/O on the source database. SET WRITE SUSPEND FOR DATABASE
2.	Split the mirror. Use the appropriate method to split mirror from the primary database: The entire contents of the database directory All the table space containers The local database directory You do not need to split the active log directory in this scenario.
3.	Resume I/O on the source database. SET WRITE RESUME FOR DATABASE
4.	Restore the primary database using the split mirror image. There is no "target" database in this scenario. The intent of this scenario is to use the mirror copy to recover the primary database when needed. Stop the instance using the db2stop command. Copy the data files of the split mirror database over the original database. Start the instance using the db2start command. Issue the following command to initialize the split mirror database. This replaces the source database with the split mirror image and places it into a rollforward pending state, so logs can be reapplied. db2inidb database_alias as mirror Roll forward the database to end of logs. After the roll forward process is completed, the database is ready for use. ROLLFORWARD DB database_alias TO END OF LOGS AND COMPLETE

13.10.5. Split Mirroring in Partitioned Environments

In a partitioned database environment, you must suspend the I/O on each partition during the split mirror process, but the I/O must be resumed on each partition afterwards. The same applies to the db2inidb tool, which must be run on each mirrored partition to initialize the database.

Because each partition is treated independently, the partitions can be suspended independently of one another. That means you do not need to issue a db2_all to suspend I/O on all of the partitions. The recommended way is to suspend the partitions individually. In this case, you must suspend the catalog partition last, because an attempt to suspend I/O on any of the non-catalog nodes requires a connection to the catalog partition for authorization. If the catalog partition is suspended, then the connection attempt may hang.

The db2inidb tool does not require any connections to the database. Therefore, you can run the tool independently on each split mirror, or you can use db2_all to run it on all partitions simultaneously. The only requirement is for the database manager to be started.

For example, to suspend writes on a database with three partitions, 0, 1, 2, with partition 0 being the catalog partition, issue:

 export DB2NODE=1 db2 terminate db2 connect to database_alias db2 set write suspend for database export DB2NODE=2 db2 terminate db2 connect to database_alias db2 set write suspend for database export DB2NODE=0 db2 terminate db2 connect to database_alias db2 set write suspend for database 

To run db2inidb on all partitions simultaneously, issue:

 db2_all "db2inidb database_alias as standby|snapshot|mirror"