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:
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. |
If you intend to create database archives, specify a value for the LOGMODE parameter of A or L when you start the application server.
To use the SQLEND ARCHIVE command when LOGMODE=A:
SHOW USERS
You see a list of the users connected to the application server. Some of these users could be accessing data in the database.
SQLEND ARCHIVE DVERIFY
You should verify the directory whenever you create a database archive by specifying the DVERIFY parameter for the SQLEND ARCHIVE command. If you do not verify the directory, inconsistencies in the control information are recorded in the database archive. A subsequent restoration using that archive would fail. When you verify the directory, the system displays a message if it finds an error, and does not create the database archive.
Write the information that this message provides on the external label of each tape reel or cartridge. Include the date, time, and type of archive (database). See Labeling Your Archive Tapes for further instructions on how to use this information. During a restoration, the same information is provided, so you can easily verify that you are using the proper tape volumes.
ARI0299A Ready archive output volume. Enter the CUU.
Type the following and press ENTER:
181
READY
A delay can occur as the database is copied to tape. The system continues to request that you mount new tapes until the database archive is completed. The number of tapes you are required to mount depends on the size of your database.
When the archive is completed and the database is copied, you see the following message:
ARI0292I ARCHIVE is completed.
| Note: | While the archive is being created you can still enter operator commands. |
When the application server stops, you see the messages:
ARI0032I The database manager has terminated. ARI0043I Database manager return code is 0.
You have finished creating the database archive.
If you run the application server with LOGMODE=L, the SQLEND ARCHIVE command ensures that you have an unbroken sequence of log archives by creating the log archive (if there is information in the log) before the database archive. You use the SQLEND ARCHIVE command when LOGMODE=L in the same way you do when LOGMODE=A, except that two tapes are needed for the procedure shown here -- one for the database archive and one for the log archive, if a log archive is to be taken. It is possible to use a single tape by creating the log archive on disk. For more detail, see Log Archiving to Disk.
Using the SQLEND ARCHIVE DVERIFY with LOGMODE=L allows you to create a valid log archive, if there is information in the log, even if the system finds an error in the directory. However, in this situation, a database archive is not created.
To use the SQLEND ARCHIVE command when LOGMODE=L, do the following:
ARI0254I The database manager is initiating a log archive.
When the log archive is complete, the database
manager will process the database archive request.
The following messages prompt you for the output medium:
ARI0252I Medium: tape 183
ARI0246D The above information describes the log archive
about to be done. Enter either:
CONTINUE to proceed using the output medium
indicated, or
CHANGE to change this medium.
CONTINUE
If you reply CHANGE, you can direct the log archive to disk. For more details on the CHANGE option, see Log Archiving to Disk.
READY
A delay may occur while the database manager archives the log to tape. When the log is archived, you see the following message:
ARI0292I ARCHIVE is completed.
| Note: | While the log archive is being created, you can still enter operator commands. |
User archives are database archives (LOGMODE=A or L) done with user facilities such as the VMBACKUP Management System (VMBACKUP-MS) or the BACKUP command of the Data Restore Feature. User archives include the database directory and all minidisks, 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.
| Note: | If you use VMBACKUP-MS to create user archives, you must specify that the database directory and dbextent minidisks are non-CMS minidisks. |
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. |
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 or disk 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:
For a description of this process refer to Example of an SQLEND LARCHIVE.
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 database machine 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. |
If you intend to create log archives, specify LOGMODE=L when you start your application server. You can create your archive on tape, disk, or on a combination of these media. There are different ways to start the process. The preferred method is to issue an SQLEND LARCHIVE operator command, which instructs the application server to copy the log to tape or disk as it shuts down.
To use the SQLEND LARCHIVE command to create a log archive on tape:
To display a list of the users currently connected to the application server, type the operator command:
SHOW USERS
SQLEND LARCHIVE
ARI0239I External labeling of this archive is:
Type: log archive
Timestamp: 12-09-92 14:41:00
ARI0252I Medium: tape 183
Write the information that this message provides on the external label of each tape reel or cartridge. Include the date, time, and type of archive (log). See Labeling Your Archive Tapes for further instructions on how to use this information. During a restoration, the same information is provided, so you can easily verify that you are using the proper tape volumes.
ARI0239I External labeling of this archive is:
Type: log archive
Timestamp: 12-09-92 14:41:00
ARI0252I Medium: tape 183
ARI0246D The above information describes the log archive
about to be done. Enter either:
CONTINUE to proceed using the output medium
indicated, or
CHANGE to change this medium.
Type CONTINUE and press ENTER. (If you reply CHANGE, you can direct the log archive to disk. For more details, see Log Archiving to Disk.)
If the tape becomes full, you will be told to mount another. After you mount the new tape, type READY and press ENTER. You will be asked for more tapes until the log archive is completed. The number of tapes required depends on the size of your log.
When the log is completely archived, the following message is displayed:
ARI0292I Archive is completed.
| Note: | You can still enter operator commands while the archive is being created. |
| Caution |
|---|
|
Before you create log archives on disk, be aware that disks are exposed to user errors (erasing a file containing an archive), and the remote possibility of hardware problems such as head crashes. To minimize the impact of hardware problems, ensure that all log archive disk files are physically located on disk volumes that are not used for the various database extents. You can back up the log archives yourself to achieve a higher level of recoverability. |
The output disk can be either a standard CMS minidisk or a shared file system (SFS) directory. If it is a CMS minidisk, the database machine must access it in read or write mode before you start the application server. If it is an SFS directory, the database machine must access it before you start the application server.
You might experience delays if you use a remote shared file system (SFS) directory. If these delays are causing problems with archiving the log, use a lower ARCHPCT value when starting the application server.
The disk must contain enough space to hold the archived log. You must monitor the space and erase old log archives to free space if need be, as the database manager does not check that enough space exists. To calculate the size of the CMS minidisk or shared file system directory needed to contain the log archives, use this formula:
(log disk size) x (SLOGCUSH %) x (maximum number of log archives on this disk)
Where:
To use the SQLEND LARCHIVE command to create a log archive on disk:
SQLEND LARCHIVE
ARI0239I External labeling of this archive is:
Type: log archive
Timestamp: 12-09-92 14:41:00
ARI0252I Medium: tape 183
ARI0246D The above information describes the log archive
about to be done. Enter either:
CONTINUE to proceed using the output medium
indicated, or
CHANGE to change this medium.
Type CHANGE and press ENTER, or type CONTINUE if you want to direct the log archive to tape. You will see the following message:
ARI0263D To direct the log archive to tape, enter TAPE followed
by the tape address (CUU) to be used.
To direct the log archive to disk, enter DISK followed
by the disk file's file name, file type, and file mode.
If you chose DISK, the default file is:
SQLMACH3 12099201 ??
DISK = = fm
where fm is the file mode of the disk to which you want to write the log archive and the two equal signs give you the default file name and file type chosen by the system. In this example, the default file name is SQLMACH3, and the default file type is 12099201. You can change these by supplying your own values.
ARI0292I Archive is completed.
| Note: | You can still enter operator commands while the archive is being created. |
You can avoid having to define your disk each time you issue an SQLEND LARCHIVE, by using a file definition. To change the default medium to disk and to archive your log:
FILEDEF ARILARC DISK fn ft fm (PERM BLKSIZE 28672
where fn, ft, and fm are the file name, file type, and file mode of your choice. The file name and file type you specify will not be used by the system, since it uses defaults of its own. You must only specify them so that the command will have valid syntax. The file mode you specify will be used by the system to determine on which disk to write the archive.
| Note: | After a restore operation, the FILEDEF for ARILARC is inoperative. You
must specify it again by either:
|
The LRECL and RECFM are automatically set by the log archive utility, and should not be specified on the FILEDEF. You must specify a BLKSIZE in the FILEDEF command. The BLKSIZE must be a multiple of 4 kilobytes, up to a maximum of 28. For optimum performance, follow these guidelines:
For more information on the FILEDEF command, see the VM/ESA: CMS Command Reference manual for your VM system.
SQLEND LARCHIVE
ARI0239I External labeling of this archive is:
Type: log archive
Timestamp: 12-09-92 15:02:23
ARI0252I Medium: disk SQLMACH3 12099202 A1
ARI0246D The above information describes the log archive
about to be done. Enter either:
CONTINUE to proceed using the output medium
indicated, or
CHANGE to change this medium.
Notice that "Medium" has changed to disk SQLMACH3 12099202 A1.
ARI0292I Archive is completed.
When you direct a log archive to disk, the name of the application server is used as the file name, and the date of the log archive as the file type. The date has the format mmddyynn, where the value nn is the number of the log archive taken on that day: for example, 01 is the first log archive of the day. (Your system may use a different format.)
You can change the file name and file type of a log archive file when you enter the file mode. If you do, you should choose a new file name and/or file type to help you restore the log archive in the right sequence.
When you direct log archiving to disk, a new file is created for each log archive. If you have a continuous operation environment and the log archive files are not removed to other storage facilities, the disk eventually gets full. If a "disk full" error occurs, you will not be able to use another user ID to perform maintenance on that disk. You must shut down the application server, and do the maintenance from the machine side. Thus you should periodically transfer the log archive files to other disks to ensure that the disk always has enough space to store another log archive.
You can perform this maintenance through another user ID when the database manager is running, in one of three ways:
#CP DETACH daddr
where daddr is the address of the disk used for log archiving. This disk is now available for maintenance. Link to the disk and transfer the log archive files to other disks.
#CP LINK id vdev1 vdev2 W
where id is the user ID to which the disk belongs, vdev1 is the disk address specified in the system directory, and vdev2 is the original disk address recorded in step 2a.
If the operator forgets to relink the disk and uses the same file mode for the next log archive, a message is displayed to indicate that the device used for log archiving does not exist. The operator should then issue the CP LINK command.
Do not detach and make any changes to the work disk (A-disk), service disk (V-disk), production disk (Q-disk), or other database disks. These disks are crucial for running the database manager. Use a separate disk to store the files created by the log archive.
In methods 2 and 3 above, the database manager ensures that it is the sole writer of the disk for log archiving at archive time. If this is not the case, it sends a message to the operator, and suspends the archive until the situation is corrected. In method 1, the checking is done by the shared file system.
When a medium for log archiving is decided, the database manager establishes the links, checking that the medium is a disk. If it detects that other machines have the disk linked in write mode, it displays a list of user IDs with the write link, and the address to which they are linked. The operator is prompted to detach all the write links before proceeding to the log archive, or to quit the link checking and change the medium for the archive. If too many links to the disk exist, including read-only and read/write links, some of the read-only links may have to be detached.
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.