The following information describes the usage of the backup-while-open
(BWO) facility. BWO flags and the BWO recovery field can be retrieved
or updated using the IGWABWO service described in Call for Data Set Backup-While-Open Support. The BWO indicators are described in Table 1.
For environments that require high-availability, it might not be
possible or desirable to stop or quiesce an application to produce
consistent backup copies of the application's data sets.
For these environments DFSMSdfp provides support to allow SMS-managed
VSAM data sets that are open for output to be backed up. The support
is only useful for applications (such as database systems) that can
recover a restored database to a point of consistency. This is typically
done from a log (forward recovery log) maintained by the application
that contains record images of all changed (added, deleted, or updated)
records. These images can then be reapplied to a backup copy of the
database, logically recreating the status of the database at a particular
point in time.
The support provided by BWO might not be necessary for online applications
that can quiesce the database data sets to ensure no output or update
activity against the data set while the backup is in progress. Quiescing
a data set in this context means the data set is closed and unallocated.
The following discussion of the operation of this support uses
these terms:
- Database manager-the application that controls access to the data
sets to be processed. In order for BWO support to be effective, the
database manager must have some logging facility to allow point-in-time
reconstruction of a database.
- Backup manager-the applications or products that perform the backup
and restore functions, such as DFSMShsm and DFSMSdss.
- Recovery manager-the component that manages the inventory of recovery
logs and applies the changes from the appropriate log(s) to the restored
data set.
The following paragraphs describe the relationships between the
BWO support and a user of BWO. Refer to
Table 1 for
the various states of the BWO flags in the following discussion. The
BWO indicators are retained in the catalog. The BWO flag states are
set or reset using the DFSMSdfp callable system service IGWABWO.
- At initial allocation (IDCAMS DEFINE, IDCAMS or TSO ALLOCATE,
JCL and dynamic allocation), the data set is not enabled for BWO (default,
BWO flag state is 000).
- The database manager should check the BWO flags prior to opening
the data set to ensure it is not downlevel (BWO flag state is 101
or 001). If the data set is downlevel, the recovery manager must
be used to apply log changes to the data set.
- The database manager must set flag BWO1 (BWO flag state 100) on
for each data set that is allowed to be backed up while open for output.
This authorizes the backup manager to initiate backups without serializing
the data set, whether or not it is being accessed by the application.
- The backup manager must retrieve the BWO flags prior to the start
of the backup. If BWO1 is on, then a backup can be taken without any
serialization; otherwise, normal data set serialization must be performed
by the backup manager.
When the backup completes, the backup manager
must retrieve the BWO flags again. If the BWO flag state has changed,
then at some point during the backup an action occurred that prevented
creation of a valid backup. The backup manager should discard the
backup just created.
- When the data set needs to be recovered, it is first restored
using the backup manager. Data sets are serialized during restore
to prevent applications from accessing them. The backup manager must
set the BWO flags at the completion of the restore to indicate whether
the restore was done using a backup copy that was created with or
without serialization.
- If the backup was taken without serialization, the BWO flags must
be set to 101.
- If the backup was taken with serialization, the BWO flags must
be set to 000.
In either case, the application administrator should decide
whether or not to apply recovery logs.
The database manager
should not allow access to the data set until the recovery manager
has completed processing.
- The recovery manager should change the BWO flags to 001 before
opening the data set, apply the logs, and then set the flags to 000
to indicate that the data set has been processed and is consistent.
The database manager can then reestablish normal access to the data
set (thus opening the data set for use).
- For a data set that is enabled for BWO, in certain instances the
system prevents starting a backup copy without serialization (for
example, during a CI/CA split) by setting the BWO flags to 010. This
indicates a backup should not be started without serialization (BWO1
off), and that a backup that is currently in process should be considered
invalid. When the condition that prevented the starting of a backup
is ended, the system resets the BWO flags to 110. This indicates
that a backup can now be started without serialization, and that any
backup in progress should be discarded.
- If the database data sets are accessed by batch programs (when
the database manager is not accessing the data sets) that do not create
forward recovery logs, the database manager should clear the BWO1
flag and set the BWO3 flag at close (that is, OX1). The setting of
the BWO2 flag should not be changed. If the backup manager discovers
this BWO state at the end of backup without serialization, the backup
is not valid and should be discarded. The backup manager can start
a backup with serialization if the BWO flag state is 011, but the
flags should be reset to 000.
Note: - Since backups can result in heavy I/O activity, you might want
to take backups during the time of least activity against the data
set to avoid affecting the application response time.
- The BWO flags are not locked between reading and setting them
with IGWABWO. The application is responsible for providing serialization
when the settings of the flags are changed.
- KSDS data sets require special consideration. Inserts and updates
can result in control interval (CI) and control area (CA) splits.
Backups taken without serialization during CI and CA splits are discarded
by the IBM® products to prevent
missing or duplicate records in the backup copies.
The frequency
of CI and CA splits depends on the insert activity, the update activity
that increases the lengths of records, and the amount of free space
in CI and CA. For KSDS data sets that are BWO enabled, run backups
during periods of low inserts and updates or ensure adequate free
space in control intervals and control areas.
- Backups without serialization can be taken (on data sets defined
with share option 1 or 2) when:
- The database contains alternate indices in the upgrade set.
- The database is accessed by pathnames, or with ddname or dsname sharing.
- Data sets can be opened regardless of the setting of the BWO flags.
It is the database manager's responsibility to determine whether the
contents of the data set are consistent.
- The database manager can use the BWO recovery field to store information
(such as the log RBA or log timestamp) for the recovery manager to
use in locating the appropriate recovery logs.
- BWO concept only applies to logical data set backup/restore. It
does not apply to physical data set backup/restore or full volume
dump/restore.
Table 1 describes the meaning of each
of the BWO (BWO1, BWO2, and BWO3) indicators.
Table 1. Backup-While-Open IndicatorsBWO Setting |
Description |
---|
000 |
Data set does not support backup without serialization. |
001 |
Forward recovery in progress. Reset to 000 after recovery. |
010 |
A CI/CA split for a BWO data set is in progress. Do not start
backup. If backup in progress, discard at end. This state can exist
at open if the database manager abended during split. Database action
depends on database manager. The data set might need restore and forward
recovery or backout of changes if AIXs are present. |
011 |
The database manager closed a BWO data set and a CI/CA split
had occurred when it was previously open. Backup manager should reset
it to 000 and serialize to back up, not a BWO candidate. The database
manager should change this state to 110 at open. |
100 |
A BWO data set has been opened by the database manager. Back
up without serialization. |
101 |
Data set has been restored and requires forward recovery before
it can be used. Reset it to 001 before forward recovery. |
110 |
A CI/CA split has occurred and completed on a BWO data set.
This state can exist at open if the database manager abended. Back
up without serialization. Reset it to 100 before backup. |
111 |
An invalid state. |