DB2 Version 9.7 for Linux, UNIX, and Windows

High availability through log shipping

Log shipping is the process of copying whole log files to a standby machine either from an archive device, or through a user exit program running against the primary database. A scheduled job on the standby issues the ROLLFORWARD DATABASE command at a specified interval to keep the standby current in terms of log replay.

To set up log shipping, you configure the database with user exit programs and log archiving enabled, initialize the standby, modify one of the sample user exit files (you can find more information about them in "Log management user exit samples") to either archive the logs to a shared device or send the log files to the standby's log path, and schedule a job so that the standby processes the log files. For a detailed overview of setting up log shipping, see this article.

After your log shipping solution is configured, the standby database is continuously rolling forward through the log files produced by the production machine. When the production machine fails, a failover occurs (you either initiate this manually or create a script to do this) and the following takes place: The standby machine has its own resources (for example, disks), but must have the same physical and logical definitions as the production database. When using this approach, create the initial standby database by using restore utility (from a backup of the primary database) or by using the split mirror function if that is available.
To ensure that you are able to recover your database in a disaster recovery situation consider the following:
If you want to control which log files are to be rolled forward on the standby machine, you can disable the retrieval of archived logs by using the NORETRIEVE option with the ROLLFORWARD DATABASE command. The benefits of this are:
Note:
  1. When the standby database processes a log record indicating that an index rebuild took place on the primary database, the indexes on the standby server are not automatically rebuilt. The index will be rebuilt on the standby server either at the first connection to the database, or at the first attempt to access the index after the standby server is taken out of rollforward pending state. It is recommended that the standby server be resynchronized with the primary server if any indexes on the primary server are rebuilt. You can enable indexes to be rebuilt during rollforward operations if you set the logindexbuild database configuration parameter.
  2. If the load utility is run on the primary database with the COPY YES option specified, the standby database must have access to the copy image.
  3. If the load utility is run on the primary database with the COPY NO option specified, the standby database should be resynchronized, otherwise the table space will be placed in restore pending state.
  4. There are two ways to initialize a standby machine:
    1. By restoring to it from a backup image.
    2. By creating a split mirror of the production system and issuing the db2inidb command with the STANDBY option.
    Only after the standby machine has been initialized can you issue the ROLLFORWARD DATABASE command on the standby system.
  5. Operations that are not logged will not be replayed on the standby database. As a result, it is recommended that you resynchronize the standby database after such operations. You can do this through online split mirror and suspended I/O support.