DB2 Server for VM: System Administration

Reconfiguring and Reformatting the Logs

During the life of a database, you may occasionally need to change the physical configuration of the logs. You can use SQLCDBEX to move the logs. See Moving Log Disks for more information. 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.

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 both log reconfiguration and log reformatting is called a COLDLOG. To do a COLDLOG, run the IBM-supplied SQLLOG EXEC, For more information, see Running the SQLLOG EXEC.

Log Reconfiguration

You must reconfigure the logs if you do any of the following.

Change the size of your logs or switch to a different device type
Change the location of one log (for single logging) or both logs (for dual logging). You may be able to use the SQLCDBEX exec to move the log, and if so, a COLDLOG is not necessary. See Moving Log Disks for more information.
Switch from single logging to dual logging. If your source log disk is undamaged, and the target disk is the identical type and size, SQLCDBEX can be used to copy the log and preserve its contents.

To reconfigure the logs:

Take a database archive if you are running with LOGMODE=A or L, because the contents of the log (including the history area) will be erased.
Update the MDISK control statements for the log minidisks in the VM directory entry for the database virtual machine. For a description of these statements, see Figure 90.
Start the SQLLOG EXEC. For information, see Running the SQLLOG EXEC.

If you are using archiving (LOGMODE=A or L), you must create a new database archive immediately after running the SQLLOG EXEC. This ensures that the archive copy of the database correctly reflects the size of the logs and whether or not dual logging is in effect. Since the SQLLOG EXEC changes the LOGMODE to Y, you cannot set LOGMODE to L or A until you have taken a database archive. To create the new archive:

Start the application server in multiple user mode, and specify LOGMODE=Y, STARTUP=W, and SYSMODE=M (both are defaults) on the SQLSTART EXEC.
When startup is complete, enter the SQLEND ARCHIVE or SQLEND UARCHIVE command. If you issue SQLEND UARCHIVE, take a user archive when the application server is shut down.
Start the application server with your normal LOGMODE.

Log Reformatting

You must reformat the logs if you do any of the following:

When you switch from LOGMODE=A or L to Y or N.
When you cannot do a warm start because of a logical error in the current log
When you want to avoid log recovery in restoring a database from a back-level database archive.
When you switch from dual logging to single logging.

To reformat the logs:

Take an archive if you are running with LOGMODE=A or L, because the contents of the log will be erased (but not the history area). If you are switching from LOGMODE=L to Y or N, you can take either a log archive or a database archive. If you are switching from dual logging to single logging and you use LOGMODE=L, you can take a log archive. For other log reformatting situations, take a database archive.
Start the SQLLOG EXEC. For information, see Running the SQLLOG EXEC.

Running the SQLLOG EXEC

The SQLLOG EXEC begins the COLDLOG operation by starting the application server (with the SQLSTART EXEC) in single user mode (SYSMODE=S) with STARTUP=L, LOGMODE=Y, and DUALLOG=Y (if two logs are defined) or DUALLOG=N (if one log is defined).

This EXEC resides on the service minidisk (V-disk); it can be run only from a database machine. Its format is:

>>-SQLLOG----Dbname(server_name)---+------------+---------------> '-dcssID(id)-' >-----+-----------+---+----------------------------+----------->< '-AMODE(nn)-' '-LOG1(cuu1)-+------------+--' '-LOG2(cuu2)-'

Dbname(server_name)

The server_name variable identifies the application server.

dcssID(id)

Specify this parameter only if you have created discontiguous saved segments for the DB2 Server for VM code and want to use them; otherwise omit it. You can specify ID instead of DCSSID; no other abbreviation is valid. For information about starting the application server to use a saved segment, see Chapter 8, Saved Segments.

AMODE(nn)

This parameter is optional. It specifies the type of addressing the database manager runs in.

The AMODE(24) option only needs to be specified when user-written exits do not support 31-bit addressing. In this case, AMODE(24) must be specified when running the SQLLOG EXEC. For a description of this parameter, see AMODE.

LOG1(cuu1)

This parameter must be specified if you are reconfiguring the logs and not just reformatting them. cuu1 is the virtual device address of your first log minidisk (ddname LOGDSK1).

LOG2(cuu2)

This parameter must be specified if you are reconfiguring the logs (not just reformatting them) and want dual logging. Omit it if you want only single logging. cuu2 is the virtual device address of your second log minidisk (ddname LOGDSK2).

Notes:

Specifying LOG2 and omitting LOG1 is an error condition.
Specifying LOG1 and omitting LOG2 causes the deletion of any entry in the database resid SQLFDEF CMS file for a second log minidisk (LOGDSK2), and causes the application server to be started with DUALLOG=N (single logging).
If both LOG1 and LOG2 are omitted, the log minidisk entries in the database resid SQLFDEF CMS file determine whether the COLDLOG operation is started with DUALLOG=N or Y.
The LOG1 cuu1 value replaces the virtual device address of the first log minidisk entries in the resid SQLFDEF CMS file.
The LOG2 cuu2 value replaces the virtual device address of the second log minidisk entries in the resid SQLFDEF CMS file if entries are present, or adds the appropriate entries if none yet exist.
Message ARI2010I is issued if an abnormal end occurred the last time the application server was stopped. In this case, the log or logs are required for a warm start of the application server.
The SQLLOG EXEC prompts you to either reformat or reconfigure the log minidisks. Reformatting the log erases only the log data. The history data is saved. Reconfiguring the log erases both the log data and the history data. (For more information, see History Area.)
Respond CONTINUE to message ARI0688D (for single logging) or ARI6129D (for dual logging). Respond 0 to message ARI0944D to reformat the log, or 1 to reconfigure the log.
Respond 1 to message ARI0944D only if:
- You are moving the logs to a new minidisk. Do this even if you are using dual logging but are only moving one log.
- You are changing the size of the log. (If you use dual logging, you must increase the size of both logs, as their sizes must always be identical.)
- You are adding a log (switching from single logging to dual logging). In this situation, respond 1 (YES) to reconfigure both the log that you are adding and the one that already exists.
Attention: Be sure that you are accessing the correct minidisk before you respond 1 to message ARI0944D to reconfigure the log minidisk.
If the SQLLOG EXEC (or the database manager itself, during the COLDLOG) ends with an error, rerun it after correcting the error condition.

For example, suppose you are using database archiving (LOGMODE=A) and dual logging. Your userid is USER1. Another user of the database, USER2, has committed a LUW that made many erroneous updates to the database, and you want to restore the database from a back-level database archive copy. To avoid the log recovery processing that this would entail, you decide to reformat the logs:

Take a database archive in case anything goes wrong:
```
   SQLEND ARCHIVE DVERIFY
```
Reformat the logs of the database (USER1DB):
```
   SQLLOG DB(USER1DB)
```
Respond 0 to message ARI0944D to reformat the log minidisks.

Now suppose that USER2 makes many changes to the database and consistently causes the database manager to take online archives because the log has been filled. You decide to increase the size of the logs:

Issue an SQLEND ARCHIVE DVERIFY command, knowing that the history area is going to be erased.
Update the MDISK directory entries for the log minidisks, which are defined at virtual device addresses 502 and 503.

Start SQLLOG to reconfigure the logs:

   SQLLOG DB(USER1DB) LOG1(502) LOG2(503)

Respond 1 to message ARI0944D to reconfigure the log minidisks because the physical size of the logs has been altered. Reconfiguring the logs allows the database manager to use the additional space.

Now suppose that USER2 has added so much data to the database that you must add more dbextents to the database. Unfortunately, your computer center does not allow use of any more DASD space. You therefore decide to switch to single logging temporarily and use the freed DASD space for another dbextent. To reduce the risk of DASD failure on the remaining log, you switch to log archiving and take frequent log archives:

Take a database archive because you are switching to single logging mode:
```
   SQLEND ARCHIVE DVERIFY
```
Delete the MDISK directory entry for the 503 minidisk, but do not change the entry for the 502 minidisk.
Issue the SQLLOG EXEC to change to single logging:
```
   SQLLOG DB(USER1DB) LOG1(502)
```
Respond 0 to message ARI0944D to reformat the log minidisks, so that the history area is preserved. Even though this is a log reconfiguration, there is no need to FORMAT and RESERVE the remaining log minidisk, as you have not increased the size of the remaining log or moved it.

Switching Log Data between Logs

If you are recovering using dual logging, and the primary log does not contain readable data, the database manager automatically switches to the secondary log. If the primary log can be read but it is corrupt, follow these steps to recover using the data on the secondary log:

Replace the primary log disk by following the procedures in Replacing a Log Minidisk. This uses the CMS FORMAT and RESERVE commands on the minidisk containing the primary log.
Warm start the application server.
This will cause it to compare the two logs, and copy the contents of the secondary log onto the primary log minidisk.

If this procedure fails to recover the database, you must restore it from the last database archive, or do a COLDLOG operation to reformat the logs.

History Area

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.

If the history area is erased, 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 the database manager cannot allow you to restore the database using a database archive and subsequent log archives.

As the final step in a database, user, or log archive, the database manager archives the newly updated history area into the archive file ARIHSDS ARCHIVE on the database machine work disk. This copy will be used to restore the history area in the event that it is corrupted. This reduces the risk of not being able to do a restore using log archives because of an unrecoverable error in the history area.

Before doing a log reconfiguration, the database manager saves the history area in file ARIHSDS PRECLDLG on its work disk. If a restore is done immediately after a log reconfiguration (meaning that the new history area is empty), this old history area will automatically be restored. This area may also be used for restoring back-level databases: if the database to be restored is found here, not in the current history area, you may choose to restore the old area to the current log. If you do so, associated log archives may be applied because they will now be found in the log's history area. Note that, because the old history area is restored to the log, no records of any archives taken after the COLDLOG reconfiguration will be available.

You can always restore the database from a back-level or a current database archive. But if the history area is erased, you lose the ability to restore the database using any log archive taken prior to this erasure. Also, if the database archive was taken online (with the ARCHIVE command), the database could be restored to an inconsistent state. For example, a LUW could have made changes before the archive was taken, and then be rolled back after the archive finished. When the database archive is restored, the changes made before the archive was taken are in the database, but any changes made after the archive will be lost.

Whenever a log minidisk is reconfigured, by you directly or by the SQLLOG EXEC, the history area is lost. (The SQLLOG EXEC always prompts you with message ARI0944D before erasing the history area.)

How the Database Manager Uses the History Area

The following description is not intended to be comprehensive; it only provides general background information about log archive recovery processes using the history area.

To display the history area, issue the operator command SHOW LOGHIST. For a discussion of this command, see the DB2 Server for VSE & VM Operation manual.

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 would be in an internal (unreadable) format. For ease of description, the records of the history area are shown 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 requested 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 because 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:
 
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      <---
RESTORE                  RESTORE                   RESTORE

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       <---

The database manager 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 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 respond END RESTORE after only two of the log archives are 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      <---

After 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 scans forward in the history area until it either reaches the end of the history area or until it finds:

A record that indicates a COLDLOG was taken.
A record that indicates LOGMODE was switched to N.
A record that indicates LOGMODE was switched to Y.
A RESTORE record.
Two database archive records in a row (no log archive records in between).
Records that indicate a switch to LOGMODE=A, and a database archive while using LOGMODE=A. (When the database is archived, the log is reclaimed without a log archive. This breaks the continuity of the log archives.)

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 9:

   Database Archive 1   <---
   Log Archive 1        <---
   Log Archive 2        <---
   Log Archive 3        <--- New
   Log Archive 4        <---     Restore
   Log Archive 5        <---             Set
   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        <---    Restore Set Copied Forward
   Log Archive 5        <---
   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 to the state it was in before the first restore. The changes recorded in Log Archives 10 and 11 are lost.

The important points to remember from this discussion are:

You can issue the SHOW LOGHIST command to determine what log archives will be restored. To determine the restore set, scan backwards in the command output until the appropriate database archive is reached; then scan forward to determine what log archives are associated with that database archive. When you reach a recovery event that breaks the continuity of the log archives, you have reached the end of the restore set.
If you responded END RESTORE and later want to restore the subsequent log archives, you must restore a back-level database archive whose associated log archives include those that were skipped by the issuing of the END RESTORE command.

If the database manager cannot find the database archive in the current history area or in the history area saved by the last COLDLOG reconfiguration (if one exists), 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.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]