Recovery models for DB2

The types of recovery you can use with geodatabases in DB2 are version recovery, which uses circular logging; roll-forward recovery, which uses archive logging; or high-availability disaster recovery (HADR).

Note:

Be sure to recover all databases that make up the ArcSDE geodatabase when restoring an ArcSDE for DB2 for z/OS geodatabase.

• Version recovery and circular logging

  Circular logging uses a ring of log files to record changes to the database. When the last log in the ring is filled, the first file is reused. Since transaction information can be overwritten, when you use circular logging, roll-forward recovery is not possible; however, recovery is generally not needed during data loads. Circular logging is the default logging model.

• Roll-forward recovery and archive logging

  If you want to use roll-forward recovery, the recommended recovery method for use with ArcSDE geodatabases, use archive logging. Archive logging does not overwrite log files; rather, it creates additional logs to record all transactions since the last backup. You need more disk space to use archive logging since logs are not reused as in circular logging.

• HADR

  High-availability disaster recovery is a database replication feature available in DB2 that protects your data by replicating data changes from a source (primary) database to a target database (standby database). If the primary database goes down, you can switch to the standby database while you recover the primary database.

  You can specify one of three synchronization modes for HADR: synchronous, near synchronous, or asynchronous.

  In synchronous mode, a change made to the primary database is not committed to the primary database until the associated logs have been written to the transaction logs on the standby database. This keeps the two databases synchronized because no change goes into the primary database that isn't saved in a log file (and is, therefore, recoverable) on the standby database. This mode has the greatest impact on the primary database's performance.

  For near synchronous mode, a change made to the primary database is not committed to the primary database until the associated logs have been written to memory on the standby database. This is almost as effective as synchronous mode and has less of an impact on the primary database. However, if the standby database fails after the data was committed to the primary, the transferred data could be lost and the two databases could be rendered inconsistent.

  Database transaction COMMITs on the primary database are not affected by the communication of log records to the standby database. In this mode, there is more of a chance for data between the two databases to become inconsistent. There are other replication options that can be used with DB2, including SQL replication and Q replication. Consult your DB2 documentation for more information.

To restore your geodatabase, you can use the RECOVER DATABASE command or the Restore Data wizard from DB2 Control Center. The geodatabase can be restored to an existing database or to a new database. The following are notes on recovering to a new database:

• If you are recovering to a new database, you must be connected to the instance.
• If you recover to a new database on another server and your source and destination servers are not using the default code page, you need to create your database on the destination machine with the correct code page before you perform the restore. If you do not do this and your production code page is different from that of the source, the restore utility assumes the default code page. This results in an SQL2548N error.
• When you recover to a new database, the recovery history file from the backup image becomes the recovery history file of the new database.

When you perform a full database recovery of a recoverable database, there can be no other connections to the database other than the connection that is made when the database is recovered. When a full database backup is restored, DB2 checks to be sure that all the table spaces referenced in the backup image are present in the database to which the data is being restored. (This could be an existing database or a new, empty database.) If it finds that a table space is missing or inaccessible, the recovery operation fails.

To avoid this, you can perform a redirected restore operation. This allows you to specify new table spaces to which you can restore table spaces from the backup image that were missing from the target database. For details on how to perform a redirected restore, consult your DB2 documentation.

If you are only restoring individual table spaces of a recoverable database, the database can remain online as long as users are not connected to the table spaces you are trying to restore.

Tip

• You can automate archiving and retrieval of log files with a user exit program. To use this, you must set the logarchmeth1 configuration parameter to USEREXIT.

  For details on how to develop and use a user exit program, consult your DB2 documentation.

• If your database is partitioned, you must run the RECOVER DATABASE command from the catalog partition. When you recover a partitioned database to a specific point in time, all the partitions listed in the db2nodes.cfg file are affected. When you recover to the end of the logs, you can specify which partitions are affected by the recovery. If you do not designate specific partitions, all partitions in the db2nodes.cfg file are affected.