DB2 Server for VM: System Administration

Establishing DASD Recovery Procedures

As the system administrator, you must establish recovery procedures for your installation. The procedures you put in place will determine the degree of protection for your database. Naturally, trade-offs exist; when you allocate system resources to protect against failures, these resources are unavailable to other users. However, if a failure occurs, the recovery takes less time.

This section discusses some of the options available. Based on this information, devise a plan that best suits your requirements.

Choosing a Log Mode

One of the first decisions you must make when designing a recovery strategy is the type of log mode you want. The log mode is an initialization parameter that you specify when you start the application server. It has four possible values:

LOGMODE=Y

All changes to the database will be recorded in a log, but no archives of the log or database will be maintained. This value is the default. Use it if you do not need to protect your data from DASD failures. The application server will run faster, since it will not require the extra time to create archives.

LOGMODE=A

All changes to the database will be recorded in a log, and regular archives of the database will be maintained. You can either create these archives yourself, or have them created automatically when the log reaches a certain threshold level.

LOGMODE=L

All changes to the database will be recorded in a log, and regular archives of the log will be maintained. You can either create these log archives yourself, or have them created automatically when the log reaches a certain threshold level (to prevent it from becoming too full to be effective).

Log archives do not contain data, but only operations that change the database. If you use this log mode, you must take an occasional database archive as well. If a failure occurs, you can use the database archive, subsequent log archives, and the current log to recover the database.

The log archives must be continuous, recording all processing that occurred since the last database or log archive. If a gap exists, it will be impossible to restore the database to its current level. (The processing that occurred during the gap can never be reapplied to the database because it was never archived.) Gaps can occur in the sequence of log archives when, for example, you switch from LOGMODE=L to some other log mode. If the continuity of the log is broken in this manner, the database manager will force a database archive before you return to LOGMODE=L processing.

LOGMODE=N

No changes to the database are recorded. This option, which is only available in single user mode, is not recommended for normal operation but can be useful in some situations. For example, it may be more efficient not to log changes if you are loading a large amount of data into a table by using the DBS utility in single user mode. If a problem occurs while you are loading, you do not need the log to recover; you can simply start over.

Once you have decided on a log mode, use it whenever you start the application server. Do not change it without thought and planning. If you must do so, you may have to carry out additional procedures. For information, refer to Switching Log Modes.

Deciding between LOGMODE=A or L

Figure 73 illustrates the relationships among the archives, the log, and the database when the log mode is A or L. You should consider several things before choosing one mode over the other.

Figure 73. Relationships among the Archives, the Log, and the Database

There are two advantages to log archiving (LOGMODE=L):

• It usually takes less time, because only the log is being archived, not the directory and dbextents. This is especially helpful when the archive is being done to free log space when the database manager is running.
• If the last database archive is unreadable or unavailable, you can bring the database back to its current status by using a back-level database manager archive or user archive, and applying to it the changes that were recorded in all subsequent logs. More recent database archives are ignored when you restore a back-level database. Two requirements must be met in order for you to use this method:
  • The log archives must be continuous. That is, you cannot have switched log modes and done a COLDLOG (with SQLLOG) or a restore since the back-level archive was created.

    Note:

    You can switch from LOGMODE=L to A and then back again without breaking the continuity of the log archives, provided that no database archive was taken while LOGMODE was set to A.

  • You have not added dbspaces, added or deleted dbextents, or reconfigured the logs since the back-level database archive was made. These operations are recorded in the database directory, so if you have carried any of them out, the directory will not be synchronized with the database changes.

A disadvantage of archiving the logs is that no logical units of work can be active during the checkpoint that immediately precedes the archive itself. Concurrent access is allowed once the checkpoint is complete, but users may experience delays both before and during the checkpoint.

Another disadvantage is that it takes longer to restore the database. For example, suppose you have been taking a database archive every Friday evening and a log archive on Tuesdays and Thursdays, and on a Friday afternoon there is a media failure on the DASD that contains the database directory. You must restore the most recent database archive (from the previous Friday), and then restore the log archives from Tuesday and Thursday as well as the changes recorded in the log that was current at the time of the failure. Because only the changes to the database are stored in the log, restoring the database is similar, in processing time, to redoing all the work from the week. If there was heavy activity that week, restoration can take a long time.

Had you used database archives (LOGMODE=A) as intermediate online archives, you would only need to restore Thursday's database archive and reapply the changes on the current log. The restore time is much shorter. On the other hand, more time would have been spent doing the intermediate archives. Because media failures are infrequent, it is usually better to take intermediate log archives instead of intermediate database archives. Depending on your own experience with media failures, it may even be worthwhile to lengthen the time between database archives taken at shutdown.

Backing Up the History Area

The database manager uses the history area of the current log to keep track of recovery events (for example, database archives and log archives). The database manager can then determine which log archives belong with which database archives. The ARIHSDS ARCHIVE file contains the updated history area. If both the work disk, containing the ARIHSDS ARCHIVE file, and the disk containing the current log are damaged or are unavailable (offsite disaster recovery scenarios), you cannot use log archives to restore the database. To be able to apply log archives, you should create a backup file of the ARIHSDS ARCHIVE file after each log archive. You can then use this backup file to rebuild the log history area.