During the life of a database, you may occasionally need to change the physical configuration of the logs. Such reconfigurations are necessary if, for example, you need to move logs from one DASD device to another.
At other times, you will need to reset the contents of the log logically. This is referred to as log reformatting and is required, for example, when you switch from LOGMODE=A or L to LOGMODE=Y or N.
| log reconfiguration and reformatting |
|---|
|
In this section, the term log reconfiguration means that the history area has been erased. Log reformatting means that history area has not been erased. Both erase the current database updates saved in the log. |
The operation that performs log reformatting is called a COLDLOG, and is done by setting the initialization parameters STARTUP=L and LOGMODE=Y. Log reconfiguration will include the log reformatting step.
If the last shutdown was abnormal, bringing up the database using STARTUP=L and LOGMODE=Y will result in warning message ARI2010I, indicating that the current log is required for warm start or database recovery. If you have already reconfigured the log, this warning will be too late, since the log data will have been erased already.
Log reconfiguration erases the history area of the log. You should consider reconfiguring your log if you are using the database manager archive facility (LOGMODE=A or L) and want to do any of the following:
To reconfigure the logs:
The continuity of log archives is broken whenever a COLDLOG reconfigure is done, so log archives taken prior to a log reconfiguration cannot be used in a restore. You should create a new archive copy of the database immediately after you complete the COLDLOG operation. This action will ensure that the archive copy of the database correctly reflects the size of the logs and whether or not dual logging is in effect.
If you use log archiving, note that a database archive, not a log archive, is needed. Reconfiguring the log breaks the continuity of the log archives, so the database archive is needed to serve as a new starting point for the log archives. (See Figure 73.)
To create the new archive:
You must reformat the logs if you do any of the following:
To reformat the logs:
The distinction between a log reconfiguration and log reformatting is the effect each has on an internally used portion of the log known as the history area. This is a portion of the log that the database manager uses to keep track of recovery events such as database archives, log archives, restores, COLDLOGs, and the switching of log modes. Log reconfiguration causes the history area to be erased; log reformatting does not.
Be aware that whenever you move the log, change its size, or delete the VSAM data set used for it, its history area is erased. If this happens, the database manager cannot tell which log archives belong with which database archives, or if the continuity of log archiving was broken. In fact, it cannot tell whether you were using log archiving at all, so it cannot allow you to restore the database using a database archive and subsequent log archives.
You can always restore the database from a back-level database archive or a current database archive, but if you lose the history area, you lose the ability to restore using any log archive that was taken before this loss. Also, if the database archive was taken online (with the ARCHIVE command), the database may be restored to an inconsistent state. For example, a LUW could have made changes before the archive was taken, and then been rolled back after the archive finished. When the database archive is restored, the changes made before the archive was taken will be in the database, but any changes made after the archive will be lost.
The following description is not intended to be comprehensive; it only provides general background information about log archive recovery processes using the history area.
Suppose that you take a database archive (using either database manager or user facilities), followed by four log archives. The history area of the log would contain one record for each of these events:
Database Archive 1 Log Archive 1 Log Archive 2 Log Archive 3 Log Archive 4
The records in the history area itself are in an internal (unreadable) format. For ease of description, they are shown here in an externalized form.
If you now request another database archive, then because the database manager is running with LOGMODE=L, it first takes another log archive of the current log (Log Archive 5 in the example below). If you then take three subsequent log archives, the history area would contain the following records:
Database Archive 1 Log Archive 1 Log Archive 2 Log Archive 3 Log Archive 4 Log Archive 5 Database Archive 2 Log Archive 6 Log Archive 7 Log Archive 8
When you take an archive, the database manager generates identification information based on the processor's time-of-day clock. When you restore the database, the database manager reads this information in the database archive tape file before it looks at the history area.
During a restore, you may be prompted to take a log archive of the current log to save the changes up to the point of the restore. When you restore the database from the restore set containing this log archive (and actually restore the log archive), it is erased from the log history's restore set since it is put back into the current log.
When the database manager identifies the database archive tape that is being restored, it writes a record in the history area to indicate that a restore is being done. Next, it looks for the corresponding database archive record in the history area.
For example, suppose you start the application server with STARTUP=R, and mount the Database Archive 2 tape file. The database manager looks for the corresponding record in the history area, by searching in reverse chronological order, from the most recent to the least recent entries. When it finds it, it determines the log archives associated with the database archive by reading forward in the history area until the RESTORE record is reached. Log Archive 9 is taken before the restore set is determined. This set of records is referred to as the restore set.
Read back to the Read forward to
Database Archive identify associated
Write a RESTORE record: Record: log records:
RESTORE RESTORE RESTORE
Database Archive 1 Database Archive 1 Database Archive 1
Log Archive 1 Log Archive 1 Log Archive 1
Log Archive 2 Log Archive 2 Log Archive 2
Log Archive 3 Log Archive 3 Log Archive 3
Log Archive 4 Log Archive 4 Log Archive 4
Log Archive 5 Log Archive 5 Log Archive 5
Database Archive 2 Database Archive 2 <--- Database Archive 2 <---
Log Archive 6 Log Archive 6 Log Archive 6 <---
Log Archive 7 Log Archive 7 Log Archive 7 <---
Log Archive 8 Log Archive 8 Log Archive 8 <---
Log Archive 9 Log Archive 9 Log Archive 9 <---
The database manager copies the restore set records after the RESTORE record.
Database Archive 1 Log Archive 1 Log Archive 2 Log Archive 3 Log Archive 4 Log Archive 5 Database Archive 2 <--- Log Archive 6 <--- Restore set Log Archive 7 <--- Log Archive 8 <--- Log Archive 9 <--- RESTORE Database Archive 2 <--- Log Archive 6 <--- Restore set copied forward Log Archive 7 <--- Log Archive 8 <--- Log Archive 9 <---
It then displays the restore set to the console using messages. If you restore all the log archives associated with the database archive, the history area remains as shown above, except that Log Archive 9 is erased from the restore set copied forward when it is restored to the current log. If, however, you respond END RESTORE to one of the prompts, the database manager deletes the remaining log archive records from the history area. For example, suppose you responded END RESTORE after only two of the log archives had been processed. The final two log archives in the history area are deleted:
Database Archive 1 Log Archive 1 Log Archive 2 Log Archive 3 Log Archive 4 Log Archive 5 Database Archive 2 Log Archive 6 Log Archive 7 Log Archive 8 Log Archive 9 RESTORE Database Archive 2 Log Archive 6 <--- Only two log archives are restored Log Archive 7 <---
When the restore is ended, processing continues and two more log archives are taken. Now the history area looks like this:
Database Archive 1 Log Archive 1 Log Archive 2 Log Archive 3 Log Archive 4 Log Archive 5 Database Archive 2 Log Archive 6 Log Archive 7 Log Archive 8 Log Archive 9 RESTORE Database Archive 2 Log Archive 6 Log Archive 7 Log Archive 10 <--- New log archives Log Archive 11 <---
If you must again restore the database and use Database Archive 2, the restore set will contain Log Archives 6, 7, 10, and 11. Because the database manager determines the restore set by scanning backwards in the history area until it finds a corresponding database archive record, the original Database Archive 2 record (the one before the RESTORE) is never reached. Consequently, it is impossible to use Log Archive 8 or 9 when restoring the database from Database Archive 2.
The only way to restore Log Archive 8 or 9 after you responded END RESTORE is to restore from a back-level database archive. This archive must have continuous log archives to the log archive you want to restore.
In our example, to restore the database to its status immediately before the restore, start the application server to do a restore, and restore Database Archive 1. The database manager scans backwards to the first occurrence of a Database Archive 1 record. (There is only one occurrence.) When it finds the record, it then scans forward in the history area until it either reaches the end of the history area or until it finds:
These records indicate a break in the continuity of the log archives. If you restore Database Archive 1 in our example, the restore set copied forward in the history area includes Log Archive 8:
Database Archive 1 <--- Log Archive 1 <--- New Log Archive 2 <--- Restore Log Archive 3 <--- Set Log Archive 4 <--- Log Archive 5 <--- Database Archive 2 <--- Log Archive 6 <--- Log Archive 7 <--- Log Archive 8 <--- Log Archive 9 <--- RESTORE <--- Indicates end of restore set Database Archive 2 Log Archive 6 Log Archive 7 Log Archive 10 Log Archive 11 RESTORE Database Archive 1 <--- Log Archive 1 <--- Log Archive 2 <--- Log Archive 3 <--- Log Archive 4 <--- Log Archive 5 <--- Restore Set Copied Forward Log Archive 6 <--- Log Archive 7 <--- Log Archive 8 <--- Log Archive 9 <---
During the actual restore, only the log archives are applied. Database Archive 2 is skipped, because all the change activity is recorded in the continuous log archives.
When the database is restored, it reverts back to the state it was in before the first restore. The changes recorded in Log Archives 10 and 11 are lost.
The important points about the history area are:
If the database manager cannot find the database archive in the current history area, a message is displayed saying the database archive is unknown. You are given the opportunity to do a COLDLOG (if one has not yet been done) to reformat the log. The COLDLOG is necessary because since the database manager cannot determine a recovery set, none of the log archive records in the history area applies, and hence the database manager cannot confirm that the current log applies.
The lack of a database archive record in the history area implies either that the database archive is very old, or that you have mounted the wrong database archive tape file. If you are intentionally restoring an old database archive, you must do a COLDLOG to avoid applying changes recorded in the current log.