Chapter 19
Providing Backup and Recovery
Capability for a Complex SDM
Preparing for Database Backups
This chapter describes how to define elements in the SDM so that your databases and
journals can easily be backed up and restored.
There are two kinds of backups:


Backup of the Definition Database, Record Database (and, if you are using the TM
module, the Thesaurus Database) and journal files. This backup occurs when you
schedule it and should also occur for the following activities:

before using HVU OPEN/DIRECT to load a database

before using DMQ 1 to update a database

before and after making changes to your database definition
Backup of a journal file. This backup occurs when the journal file becomes full.
1
DMQ is not available on Windows.
Providing Backup and Recovery Capability for a Complex SDM  509
Scheduled Backups
To protect against media or system failure, you should make periodic backup copies of
the database files. In order to guarantee that the spare copy is always current, you should
ensure that a “snapshot” of the DDB and RDB be taken at specified intervals. You can
take such a “snapshot” by copying the DDB, RDB, and TDB—if you have a Thesaurus
Database—and their journals to tape or to a different disk from that of the current files.
DDB
DDB
Journal A
RDB
DDB
Journal B
RDB
Journal A
RDB
Journal B
COPY
DDB
DDB
Journal A
DDB
Journal B
RDB
RDB
Journal A
RDB
Journal B
Figure 19-1: Scheduled copy of complete database and journals
To perform a scheduled backup, you use a backup utility on your host operating system.
Because database files that are open when a backup is performed cannot be read,
backups require exclusive access to the database by the job performing the backup. A
backup job is a host system command procedure that contains commands that execute
utilities necessary for the backup procedure.
510  Providing Backup and Recovery Capability for a Complex SDM
Following are the steps for performing a backup on a database:
1
Deactivate the database and disconnect all users using that database from the Kernel.
DMSA> ASSIGN/DB DB=dbname DEACTIVATE=YES
DMSA> DISCONNECT KERNEL=kernel_name DB=dbname
DMSA> EXIT
2
All database files being backed up must be closed before execution of a backup
procedure.
3
Using operating system utilities, make a backup copy of the Definition Database,
Record Database files (including all data and index files), thesaurus database files,
and journals by copying them to tape or to another disk. To identify these files,
examine the DDL for the relevant database or run DMDDBE on the relevant
database with ACTION=ONE and OBJECT_TYPE=FILES_ALL to extract the list
of files.
4
Reset the journals to an empty condition so each journal is ready to record new
changes to the database.
5
Reactivate the database.
DMSA> ASSIGN/DB DB=dbname DEACTIVATE=NO
If you plan to do scheduled backups, you need to plan how often they are done. In
deciding how often to schedule backups, consider the following:

Update intensity
How many transactions typically occur within a given time period?

File size
How large do you want journals to become? Larger files take longer to copy and
restore.

Recovery speed
What restrictions do you face in restoring a database after a failure occurs?

Database unavailability
How often and for what period of time can users be locked out of the database while
a backup is being made?
Backup When a Journal File Is Full
If you have defined journals for you database, you have defined both an A journal and a B
journal. There are two so that if one fills up, the Kernel can begin to fill up the other.
Providing Backup and Recovery Capability for a Complex SDM  511
You need to write a backup job that tells the Kernel what to do when a journal fills up.
This is necessary because if both journals fill up, updates can no longer be made to the
database; there is no place to record the new activity.
Use the SDM DDB_JOURNAL parameters A_BACKUP_JOB='file_descriptor' and
B_BACKUP_JOB='file_descriptor' to specify the files that contain the commands for
backing up journal file A and B, respectively. Commands in a backup job should include
the following steps:
1.
Electronically send you a message stating that the journal is full and the full journal
backup process is being performed.
2.
Make a backup copy of the full journal to disk or to tape. To avoid confusion, put
this backup copy in a location other than that for regularly scheduled backups.
3.
Using the DMJ RESET action, empty the full journal so that it can accept entries
after the other journal file fills up.
Table 19-1 contrasts scheduled backups with full journal backups.
512  Providing Backup and Recovery Capability for a Complex SDM
Table 19-1: Scheduled backups and full journal backups contrasted
Preparation for backup
Scheduled Backups
Full Journal Backups
Write a procedure that
backs up RDB, DDB, and
journals and resets both
journals.
Write commands for a job
that backs up and resets the
full journals. In the SDM
JOURNAL definition
A_BACKUP_JOB and
B_BACKUP_JOB
parameters, specify file
descriptors for these files
containing these commands.
(You can use DMDBA
screen 85.)
(If you have a TDB, do the
same for it.)
When the backup is
initiated
At regular designated
intervals of time that you
determine.
When one journal file
becomes full.
How the backup is
initiated
You submit the backup
procedure.
The Kernel switches from
the full journal to the empty
journal and submits the
appropriate backup job as
defined by the
A_BACKUP_JOB or
B_BACKUP_JOB
parameter.
Note: A_BACKUP_JOB and B_BACKUP_JOB parameters and DMDBA screen mode
are not available on Windows. Journal backups must be performed using Windows
operating system utilities.
Providing Backup and Recovery Capability for a Complex SDM  513
Backup Sets
A BASIS backup set consists of files that hold either copies of the DDB and RDB, or the
copies of the journal files for the DDB and RDB. As indicated in Figure 19-2, there are
two types of backup sets: data and journal.
Main Device
Alternate Device
DDB
DJA
DJB
RJA
RJB
RDB
Data
Backup
Files
Journal
Backup
Files
Data
Data
Data
Data
Journal
Journal
Journal
Journal
Backup Device
Figure 19-2: DDB, RDB, their journal files, and devices storing them
514  Providing Backup and Recovery Capability for a Complex SDM
It is important that the backup files be stored on a different device or medium from
devices storing the DDB and RDB and the journal files. By storing the backup files on
another device or medium, you are guaranteeing that you will be able to restore the
database in case of a media failure. Normally, backups are made to tape.
In addition to determining which kind of backup files to make and on which device or
medium they are to be stored, you need to decide how often to make backups and how
many backup sets you are going to keep at a time. Suppose you determine that a
“snapshot” of your database should be taken once a week on Monday.
Snapshots of DDB
and RDB
Copies of Filled
Journal Files
A
Mon
(12/5)
Tue
Wed
Thu
Fri
Mon
(12/12)
Tue
B
A
Wed
Thu
Fri
Figure 19-3: Database backups and copies of journal files
Because you have the Monday “snapshot,” you are guaranteed that you can restore your
database to last Monday’s status in case of a media failure. Although this is reassuring,
you are still losing the changes that were made to the database after the “snapshot” was
taken. To remedy this situation, estimate the number of copies of the filled journal files
for the DDB and RDB that you want to save between “snapshots.”
You will need to decide not only how often to back up your database and journal files but
also how many copies or backup cycles of the DDB and RDB you want to keep in the
data backup set. Up to 250 backup sets can be declared for one database. When
determining the number of backup sets needed, it is a good idea to be generous.
Providing Backup and Recovery Capability for a Complex SDM  515
In deciding how many backup cycles to keep, consider the following:

Volume of activity
When there is a high volume of activity, keep more copies so data loss is minimal.

Archival and auditing requirements
Legal and organizational requirements may dictate what period of time you must be
able to recover.

Disk space availability
Depending on the space available for copies, you might be able to retain only a
limited number of backup copies.
The minimum number of data backup sets should be, at least, one greater than the number
of data file backup cycles. For example, if the DDB requires 5 backup cycles and the
RDB requires 5 backup cycles, then the minimum number of data backup sets is 11.
The minimum number of journal backup sets should also be at least one greater than the
number of journal file backup cycles needed to save all the journal files created between
full database backups. For example, if the journal for the DDB and the journal for the
RDB each require 5 backup cycles, then the minimum number of journal backup sets is
11.
The minimum number of backup sets must be at least one greater than the number of
backup cycles because you should do a backup before freeing a backup set.
Using Host System Backup Utility
Use your host system backup utility to make backups. Use of your boot system backup
utility is recommended for all operating systems.
Preparing for Recovery of Changes Between Full Backups
Recovery from a media failure is possible by replaying the changes that BASIS logs in a
journal file. The journal file, used to log the changes made to the database between full
backups of the database, is initially kept on disk and can be periodically backed up to tape
or disk.
516  Providing Backup and Recovery Capability for a Complex SDM
A journal file contains audit information which indicates when transactions start and
finish, the modified data in the form of after-images, and possibly before-images. Beforeimages are used to back out changes. These images are saved by setting the
SAVE_BEFORE_IMAGES parameter equal to YES in the JOURNAL definition in the
SDM. The before-image is a “snapshot” of the actual record before a change was made.
After-images are automatically saved in the journal file. These images are used to replay
completed transactions. Figure 19-4 gives you an idea of what is entered in the journal
file if the before-images are saved along with the after-images for a successful transaction.
Thursday, January 15, 8:01
Day's work begins
8:10:01
= Successful transaction
8:23:15
= Aborted transaction
= Before image
= After image
8:45:32
Figure 19-4: Before-images and after-images stored in journal file
Providing Backup and Recovery Capability for a Complex SDM  517
Although the aborted transactions are also recorded in this journal file, they have no effect
on the database if the journal file is used to restore the database.
Dual Journaling
The names of the DDB journal files (A and B) are defined when the database is first
created. For more information, see “Overview of Database Definition and Development.”
You can name the RDB journal files (A and B) in the JOURNAL definition in the SDM.
The journal files are in pairs so that when one journal becomes full, the other one can be
used.
You can also define two additional RDB journal files (A_COPY and B_COPY) in the
JOURNAL definition in the SDM. These additional files are used only for the added
security of dual journaling. Before you decide to use dual journaling, you should
consider whether their use merits the additional storage required for these journals. As
Figure 19-5 shows, these additional journal files should be stored on a device different
from that used for the main journal files and the RDB.
518  Providing Backup and Recovery Capability for a Complex SDM
Third Device
A_COPY
B_COPY
Main Device
Alternate Device
RDB
RJA
RJB
Figure 19-5: RDB journals and journal copies stored on different devices
Providing Backup and Recovery Capability for a Complex SDM  519
520  Providing Backup and Recovery Capability for a Complex SDM