This section describes how to create archives to protect your database against system failure. If a system failure occurs while you are taking an archive, see Restarting from a System Failure While Archiving.
Database archives are tape copies of the directory and dbextents that are carried out using the database manager archiving facilities:
| Note: | Before issuing SQLEND ARCHIVE, you should disable the DB2 Server for VSE online support by issuing the CIRT transaction. See Online Support Considerations. |
The ARCHIVE command should be used only when you need to take a database archive to free log space but cannot afford to shut down the application server. Thus, you might want to schedule an SQLEND ARCHIVE for every Friday night, and periodic online archives during the week.
Log space used by completed logical units of work is freed. Log space reflecting changes that are not completely included in the database archive (as of its begin-archive checkpoint) cannot be reused until the next database archive that completely includes the changes.
Set the ARCHPCT value lower than the SLOGCUSH value, which determines when the log overflow procedure is started. When the log is filled to the percentage indicated in SLOGCUSH, the LUW that was running the longest is backed out. (Although this procedure allows the log space to be reclaimed by another forced online database archive, it can frustrate the user whose application was almost finished.)
Ideally, your log should be large enough so that the ARCHPCT value is never reached. If this value were reached at an inconvenient time (say when the operator is not at the console), database activity could stop. To prevent this from happening, you should use the ARCHIVE command to do online database archives when activity on the system is low.
Also, if you do have a database archive taken because ARCHPCT is reached, remember you cannot use this archive to recover from user logic errors. Like an online database archive initiated with the ARCHIVE command, it contains changes from incomplete LUWs, so you still need the log if this archive is the source for a restore.
When a database archive is taken online, using database manager facilities only, other work usually continues. If, however, a condition arises during the archive that requires a checkpoint to be taken, other work must wait until the archive process completes. Such conditions include:
| Note: | You can use the SHOW LOG operator command to monitor available log space to assist you in scheduling database archives. See the DB2 Server for VSE & VM Operation manual for description of operator commands. |
User archives are database archives (LOGMODE=A or L) that are done with user facilities, such as the VSE/VSAM IDCAMS Backup/Restore feature. User archives include the database directory and all dbextents, but not the logs.
Because database manager archiving facilities are DASD-independent, they do not take advantage of particular DASD characteristics to improve performance. Some user facilities exploit these characteristics, and can archive and restore your database more quickly in some situations.
To begin archiving your database with user facilities, stop the application server and issue:
SQLEND UARCHIVE
After all logical units of work have been finished, the database manager indicates in the log history that a user archive will be taken, then prompts the operator to take the archive, and ends. (If LOGMODE=L and the log contains information, it takes a log archive before ending.) When the application server ends, the operator should take the user archive. The next time the application server is started, it displays a message to confirm that the user archive was done.
| Note: | Confirmation of a successful user archive is required at the next startup. If the operator specifies a restore (STARTUP=R or U) the next time the application server is started, the system assumes that the user archive was not taken. If the system does not prompt the operator to confirm that a user archive was created, this means that the archive was not recognized (whether or not it was successful), and it must be repeated. |
| Note: | Do not stop the server with SQLEND QUICK and then take a user archive because the user archive will not contain consistent data. |
Figure 70 shows the control statements needed to archive a database using multiple tape allocations, and using the VSE/VSAM IDCAMS command. The database in this example, has a directory called BDISK, and seven dbextents called DDSK1-DDSK7. For information about this command, see the Using VSE/VSAM Commands and Macros manual.
Figure 70. Example of VSE/VSAM BACKUP Command for a User Archive
Log space is freed after a successful user archive has been confirmed at the next startup. If you take user archives and it becomes necessary to free log space when the database manager is running, you must use either the log or database archiving facilities supplied with this product to free the log space.
For log archives, set LOGMODE=L when starting the application server, and for database archives, set LOGMODE=A. In both cases, this will ensure that database archives are automatically taken if the log fills to the ARCHPCT value. Or, if you prefer to schedule your online archives yourself, periodically issue the LARCHIVE command for log archives, or the ARCHIVE command for database archives.
| Note: | You can use the SHOW LOG operator command to monitor available log space to assist you in scheduling user archives. |
A log archive is a copy on tape of all the active pages of the database log except for the last one, the log history area. To use log archiving, set LOGMODE to L. A log archive can only be performed with database manager facilities supplied with this product.
Log archives can be used with database archives taken with either database manager facilities or user facilities. Each sequence of log archives must be preceded by at least one database archive.
The log archive process can be started in the following ways:
| Note: | Before issuing SQLEND LARCHIVE, you should disable the DB2 Server for VSE online support by issuing the CIRT transaction. For more information, see Online Support Considerations. |
Set the ARCHPCT value lower than the SLOGCUSH value, which determines when the log overflow procedure is run and thereby protects the log from overflowing. (see SLOGCUSH.) When the log is filled to the percentage indicated in SLOGCUSH, the LUW that was running the longest is backed out. (Although this procedure allows the log space to be reclaimed by the online log archive, it can also frustrate the user whose application almost completed.)
Because a log archive finishes faster than a database archive, it has less performance impact if it is done when the database manager is running. If log archives are occurring at inopportune times, however, you may want to periodically issue LARCHIVE when activity on the database manager is low. Be sure the log is large enough so the ARCHPCT limit is not reached before your scheduled log archive.
When an online log archive is requested, the database manager allows any LUWs that are active to finish, but prevents any new ones from starting. A message is displayed that tells how many LUWs are active. When they are complete, the database manager takes a checkpoint and creates the log archive. During the checkpoint, access to the database is disabled and any users or applications that try to start a new LUW will be in a lock wait.
You can monitor the locking contention caused by the online log archive by using the SHOW operator commands from the operator's console. However, you cannot issue SHOW commands from ISQL to monitor the lock contention.
In most situations, only a slight delay occurs before the checkpoint is taken, but if there are long-running LUWs, it can be longer. In a worst-case scenario, a long-running LUW can delay the log archive checkpoint long enough so that the SLOGCUSH value is reached, and the database manager must roll back the longest-running LUW to free log space.
If you find that users are experiencing long delays because the database manager is trying to take a checkpoint, you can issue the SHOW operator commands to determine which user is delaying the start of the checkpoint, and then issue the FORCE command to end that user's LUW.
During the creation of the log archive, normal access to the database is usually resumed. If, however, a condition arises during the archive that requires a checkpoint to be taken, other work must wait until the archive process completes. Such conditions include:
| Note: | You can use the SHOW LOG operator command to monitor available log space to assist you in scheduling log archives. |
Because there are different types of archives, and each may require multiple tape volumes, it is a good idea to label the tapes externally in case you have to restore the database.
When the database manager prompts the operator to mount the tape to record the archive, it also displays a message that includes the date, time, and type of archive (database or log). For example:
ARI0239I External labeling of this archive is:
Type: log archive
Timestamp: 12-09-92 14:41:00
ARI0252I Medium: tape 183
The timestamp and type of archive provide identifying information about this archive, and should be written on the external label of each tape reel or cartridge. The label information is provided by the database manager for the first volume of the archive. If your archive requires more than one tape volume, add your own sequential identification to each label (for example, Tape1 of 2, Tape2 of 2).
When the database is restored, the database manager checks if there are any log archives associated with the database archive. If log archives exist, a list of them is displayed, and the time and date of each is provided. The information on the external label can be matched against this list to find the correct tapes to use for the restore.