HP 3000 Manuals HP 3000 Manuals
The Mirror Database
Transaction logging and regular backups are good maintenance. However,
if databases must be accessible at all times and cannot be down even for
maintenance, then a different maintenance method is needed. A system can
be set up for constant access or "high availability," and still have
controlled maintenance.
The mirror database is the fundamental element in creating a high
availability database system. This system consists of two identical
databases on two separate computer systems. One database is housed on a
primary system and is constantly accessible to users and application
programs. The other "mirror" database resides on the secondary system
and is used for maintenance.
To establish a mirror database, the following requirements are necessary:
* Two systems--one primary, one secondary.
* Two identical copies of the database(s) are needed, one copy on
the primary system, one on the secondary system.
* All transactions on the primary system must be logged to a
permanent file.
* Periodically, the log file containing the transactions must be
moved or copied to the secondary system, and used to update the
database(s) on the secondary system. It is recommended that the
log file be kept on a private volume separate from the database or
on magnetic tape.
After the secondary system is established, it can be used to make backups
of the database. The primary system never has to be brought down for
maintenance.
Transferring Log Files
The GETLOG command with the AUTO option and the CHANGELOG command provide
the capability to schedule secondary system backups through various
methods of logging. Listed below are four ways of copying log files from
the primary to the secondary system. The method chosen should depend on
the maintenance needs.
1. Copying files over a direct DSLINE from the primary to the
secondary system.
2. Logging to a private volume, entering the CHANGELOG command to
start a new log file, copying the closed log file to another
private volume, and physically transporting that second private
volume to the secondary system.
3. Logging to disk, entering the CHANGELOG command to start a new log
file, copying the closed log file from disk to tape, and restoring
the log file from tape to a disk on the secondary system.
4. Logging directly to tape and mounting the tape on the secondary
system.
Figure 7-3 illustrates the four methods of copying log files as
listed above.
![[]](../../pic3k/M012332/FFN363c50.gif)
Figure 7-3. Transferring Log Files to the Secondary System
Maintaining the Mirror Database
After the mirror database system is set up, the DBRECOV STOP-RESTART
feature is used to maintain the secondary database. To start the initial
DBRECOV procedure, the user must make sure logging is enabled on the
primary system and that either the MPE/iX GETLOG AUTO option or CHANGELOG
is being used. These MPE/iX options make logging without interruption on
the primary system possible, thus increasing the availability of the
databases. For more information on logging options refer to "Logging
Preparation" and "Logging Maintenance" earlier in this chapter. Appendix
G provides a brief outline of logging to disk and logging to tape.
After the log files are transferred to the secondary system (the mirror
database system), they are applied to the mirror database using the
DBRECOV roll-forward recovery process. The STOP-RESTART feature of
DBRECOV is the key to making the mirror database system a workable
maintenance method; for a detailed discussion of this feature, refer to
the next section entitled "Performing DBRECOV STOP-RESTART." This feature
adds the capability to CON[TINUE] or STOP the recovery process on the
secondary system if DBRECOV cannot find the next log file in the log set.
Whenever DBRECOV cannot find the next log file in a log set, the recovery
process on the secondary system can be stopped, the databases can be
backed up, and recovery can then be restarted from the point it was
stopped. The primary system never has to be brought down for backups.
DBRECOV applies the chained log files starting with the first log file
created when logging was enabled. It continues to process each log file
in the log set consecutively until it cannot find the next log file in
the set. It then prompts the user at the console to CON[TINUE] or STOP
the recovery process.
If the reply is CON[TINUE], DBRECOV keeps searching for the next log
file. When the next log file is found, DBRECOV resumes roll-forward
recovery on the mirror database. The CON[TINUE] or STOP prompt appears
as long as DBRECOV cannot find the next log file in the log set. DBRECOV
is stopped if the STOP reply is entered and a RESTART file containing all
the necessary information to restart recovery is created.
After the DBRECOV process is stopped, backup of the database in a
consistent state can be done and limited database maintenance on the
secondary system can be performed. Some DBUTIL functions cannot be
performed while the DBRECOV process is stopped. If the database is in
RESTART mode, the following DBUTIL processes cannot be performed:
* Access is not allowed in order to keep the database logically
consistent.
* Resetting the maintenance word is not allowed. If the maintenance
word were to be reset, RESTART would be impossible.
* Purging or erasing the database is not allowed. If either of
these options were used in DBUTIL, the recovery process would be
invalidated. (The user must run DBRECOV,ABORT or DBRECOV,PURGE
before purging or erasing the database.)
DBRECOV,RESTART restarts the roll-forward recovery process from the point
it was stopped. DBRECOV uses the information in the RESTART file to
restart recovery. DBRECOV continues until, once again, it cannot find
the next log file in the log set. The prompt to CON[TINUE] or STOP is
displayed and backup of the database can again be done.
If RESTART recovery from the current STOP point cannot be done,
DBRECOV,ABORT can be used. Recovery can no longer be restarted from the
same point that it was stopped once aborted because the RESTART file is
purged. The database flags are returned to the same settings as before
the recovery process was started.
If ABORT fails to abort recovery because of an inconsistent RESTART file,
DBRECOV,PURGE can be used to delete the current RESTART file before
beginning the mirror database process again.
Performing DBRECOV STOP-RESTART
The processes involved in using the STOP-RESTART feature of DBRECOV are
discussed here. They are broken down as follows:
* Stopping DBRECOV
* Storing the Databases
* Restarting DBRECOV
The following sections are included if problems are encountered while
performing STOP-RESTART:
* Aborting DBRECOV
* Purging a RESTART file
Stopping DBRECOV.
DBRECOV rolls forward all log files in the log set on the secondary
system, one at a time. When DBRECOV cannot find the next log file in a
log set, it prints the following message on the console:
DBRECOV - Reply CON or STOP when filexxx is ready.
A message for the user is displayed in the $STDLIST file:
UNABLE TO OPEN LOG FILE filexxx
REPLY 'CONTINUE' OR 'STOP' ON CONSOLE.
The filexxx is the log file that DBRECOV is trying to find. If that log
file has been closed on the primary system and is ready to be moved over
to the secondary system, transfer it to the secondary system and reply
CON or CON[TINUE] on the console. DBRECOV will look for filexxx again.
The roll-forward process continues as long as the next log file has been
copied over correctly and is available to DBRECOV.
The next log file may not be ready yet. For example, the primary system
might still be logging transactions, or the log file might have been
renamed or be on a tape that was not mounted. This provides an
opportunity to STOP recovery and perform maintenance on the database.
Refer to "Storing the Databases" next in this chapter. To stop recovery,
simply reply STOP at the console. A list of the databases involved in
recovery are displayed in the $STDLIST file. At this point, DBRECOV
creates a RESTART file containing all the necessary information to
continue the recovery process when the RESTART option is requested; it
also enables the RESTART flags and disables the access flags of the
databases that are recorded in the RESTART file.
DATABASE(S) WITH RECOVERY SUSPENDED:
base1.group.acct
base2.group.acct
:
This is a list of the databases that are in the RESTART file. These
database names are specified later when either the RESTART or ABORT
options are used. The RESTART file name is the same as the logid name
used in the GETLOG and the LOG,START commands when logging was enabled on
the primary system.
DBRECOV then prints the name of the log file it needs to restart
recovery, the record number beginning an internal structure, the number
of records currently in the staging file, and the actual file name of the
RESTART file for that recovery process:
RESTART RECOVERY WITH LOG FILE: filexxx
QUIET BLOCK BEGINS AT RECORD recordnumber
NUMBER OF RECORDS IN STAGING FILE numrecs
RESTART FILE NAME: filename
The user is returned to MPE/iX, where the command DBUTIL >>SHOW database
name FLAGS can be used to display the recovery state, that is, whether
the database in recovery has been set for RESTART.
When running multiple recovery processes from the same log file, the user
needs to equate the logid, that is the formal file designator for the
RESTART file, to a unique file name for each recovery process. The new
file name is the RESTART FILE NAME for that specific recovery process.
Storing the Databases.
The databases can be backed up at this time. It is important to store
all files involved in recovery since the last successful RESTART. In
other words, the database administrator should store the databases, the
current RESTART file, and all log files that were processed since the
last successful DBRECOV,RESTART. If the RESTART file is not stored with
the database backups, it is modified when recovery is restarted. Without
the previous RESTART file or the log files, the database backup copies
cannot be used to RESTART recovery in case the current RESTART fails.
The RESTART file and the databases have associated time stamps telling
DBRECOV which RESTART file goes with which databases. When DBRECOV is
restarted, the time stamp in the RESTART file is changed. If the RESTART
file is not stored, the time stamps will not match, and the RESTART will
not succeed.
The method used to store the databases, RESTART file, and log files
depends on the medium used for user logging, as follows:
* If logging to tape, the log files are already stored on a
transportable medium and backing them up is not necessary.
However, the log files must be grouped with the database and
RESTART file backups. If the user does not keep track of which
log files go with which databases, the RESTART of recovery from a
backup is not possible. To restart recovery from a backup, the
user needs to restore the tapes containing the following:
* The databases.
* The RESTART file.
* All log files processed since the last successful RESTART.
When running DBRECOV, the tapes containing the log files
must be mounted in the correct sequence according to the
tape volume labels.
* If logging to disk, remember to store the log files that were
rolled forward since the last successful RESTART along with the
RESTART file and the databases. Logging to disk makes it easier
to keep the log files grouped with the databases and RESTART file
because all the log files can be stored at the same time when
recovery is stopped. Use an MPE/iX STORE command with the "@"
option (rather than a DBSTORE) to backup all the files on a
minimum number of tapes. If it is necessary to restart from a
backup, all the necessary files will be together.
Using naming conventions makes storing the files to tape much easier.
The logging naming conventions should be used. For example, if the
database is ORDERS, name the logid ORDERRS (where RS represents RESTART),
and the log file ORDER001. The user can store all the files with one
MPE/iX command as follows:
:STORE ORDER@
NOTE To avoid incompatible time stamps, it is important to store the
RESTART file at the same time that the databases are stored. If
logging to disk, also make sure to store all log files processed
since the last successful restart.
Restarting DBRECOV.
To restart the recovery process after the next log file in the set is
transferred, or the database maintenance is completed, enter the
following RUN command:
:RUN DBRECOV.PUB.SYS,RESTART
DBRECOV requests the name of one of the databases in the RESTART file:
WHICH DATABASE?
If the user types in the name of a nonexistent database, another prompt
for the database recorded in the RESTART file appears. Once again enter
the name of a database in the RESTART file. From the database name that
is entered, DBRECOV determines the name of the RESTART file, tries to
open it, and restarts the recovery process. If the RESTART file is
successfully opened but is not a RESTART file, the following error
message is printed:
filename is not a DBRECOV RESTART file
and the user is returned to the MPE/iX prompt. This error usually occurs
when another file with the same name as the RESTART file has been created
on the system. Make sure the file is a RESTART file, and try RESTART
again. If the RESTART file cannot be located, go back to the previous
tape, restore the databases which should have their own RESTART file and
log files stored with them, and run DBRECOV,RESTART from that point. The
log files between the previous and the current STOP point are
reprocessed, and the roll-forward process continues with the current log
file.
When the correct RESTART file is opened, DBRECOV looks at the file to
make sure that the version numbers are compatible with the version of
DBRECOV being run. If the version numbers do not match, DBRECOV prints
the following error message:
RESTART FILE NOT COMPATIBLE WITH THIS VERSION OF DBRECOV
and the user is returned to the MPE/iX prompt. This message means that
another version of DBRECOV is running other than the version that created
the current RESTART file. Install the correct version of TurboIMAGE/XL
and run DBRECOV,RESTART again.
If the user logon is not the same as the logon when DBRECOV was
suspended, the following message is printed:
must be logged on as same user and account where DBRECOV was
suspended
Log on using the same user and account names that were used when DBRECOV
was originally suspended, and run DBRECOV again.
When the RESTART file is opened, DBRECOV tries to open all databases
identified in the RESTART file. For each database that cannot be opened,
DBRECOV displays the following message:
Can't re-open DATABASE basename
RESTART is terminated and the user is returned to the MPE/iX prompt.
Make sure the correct databases are on the system. If the databases are
the correct ones, but they still cannot be opened, use the DBRECOV,ABORT
command (discussed in the next section) and RESTART recovery from the
previous STOP point.
When all the databases have been opened, DBRECOV checks to make sure all
the databases in the RESTART file are set for RESTART. When DBRECOV
encounters a database not in RESTART mode, it displays the message:
DATABASE basename IS NOT IN RESTART MODE
RESTART TERMINATED
RESTART is terminated and the user is returned to the MPE/iX prompt.
Make sure the correct databases are loaded on the system. If the
databases are the correct ones and RESTART is still not accepted, use the
DBRECOV,ABORT (discussed in the next section) command and RESTART from
the previous STOP point.
To start the recovery process again, find out why the databases are not
in RESTART mode and try to correct the problem. If the problem cannot be
corrected, take either of the following steps:
* Go to the previous STOP point and use the databases and RESTART
file stored to restart roll-forward recovery, or
* ABORT the current RESTART process. Disable user access on the
primary databases and make a copy for the secondary system. Begin
a new logging process on the primary system and a new recovery
process on the secondary system.
If all databases are found, and they are in RESTART mode, then the time
stamps in the database root file are compared to the time stamp in the
RESTART file. If they do not agree, the following DBRECOV error message
is printed:
RESTART TIME STAMPS DON'T AGREE WITH DATABASE TIME STAMPS
This indicates incompatibility of the RESTART file and the databases.
The user is returned to the MPE/iX prompt. Use the same steps given
above to recover from a time stamp error. After all the compatibility
checks have passed, DBRECOV prints a table of the databases to be
recovered:
DATABASE(S) TO BE RESTARTED:
base1.group.acct
base2.group.acct
:
The user is then prompted to confirm the restart:
CONTINUE WITH RECOVERY (N/Y)?
Respond Y or YES to continue, or type N or NO (or press carriage return)
to return to the STOP point. If any of the databases cannot be opened
during recovery, an MPE/iX file error is returned and DBRECOV RESTART is
terminated. When this happens, go back to the previous STOP point and
use the databases, log files, and the RESTART file to RESTART recovery.
If a log file in the log set has been damaged or the user cannot RESTART
recovery for any reason, ABORT the current recovery process and begin the
mirror database process again. When the recovery process terminates, the
user is returned to the MPE/iX prompt.
Two ways of continuing to mirror the databases are listed here:
* Go to the previous STOP point and use the databases, log files,
and RESTART file stored to restart roll-forward recovery. This
option is not valid if there is a missing or damaged log file.
* Disable user access on the primary databases and make a copy for
the secondary system. Begin a new logging process on the primary
system and a new recovery process on the secondary system.
CAUTION When recovery is aborted (refer to the following discussion),
the current RESTART file is purged and RESTART must be done from
the previous STOP point.
Aborting DBRECOV.
To run the ABORT option:
:RUN DBRECOV.PUB.SYS,ABORT
Just like the RESTART option the prompt for a database in the RESTART
file appears:
WHICH DATABASE?
If a nonexistent database name is entered, an error message is printed
and the user is prompted once again to enter the name of a database in
the RESTART file. Using the database name entered, DBRECOV determines
the name of the RESTART file and tries to open it. If the file is opened
and is not a RESTART file, the following DBRECOV error message is
printed:
filename is not a DBRECOV RESTART file.
and the user is returned to the MPE/iX prompt. This error usually occurs
when another file with the same name as the RESTART file has been created
on the system. Make sure the file is a RESTART file and try running
DBRECOV,ABORT again.
When the correct RESTART file is opened, DBRECOV looks at the file to
make sure that it has the same version numbers as the version of DBRECOV
being run. If the version numbers do not match, DBRECOV prints the
following error message:
RESTART FILE NOT COMPATIBLE WITH THIS VERSION OF DBRECOV
and the MPE/iX prompt is returned. This message means the version of
DBRECOV is not the same as the version that created the current RESTART
file. Install the correct version of TurboIMAGE/XL and run DBRECOV,ABORT
again.
If the user logon is not the same as the logon when DBRECOV was
suspended, the following message is printed:
must be logged on as same user and account where DBRECOV was
suspended
Log on using the same user and account names that were used when DBRECOV
was originally suspended, and run DBRECOV again.
When the RESTART file is successfully opened, DBRECOV identifies all the
databases in the RESTART file, and verifies that they are in RESTART
mode. DBRECOV then checks the time stamps in the RESTART file and the
databases to make sure they match. If the time stamps do not match, the
following message is printed:
RESTART TIME STAMPS DON'T AGREE WITH DATABASE TIME STAMPS
This indicates incompatibility of the RESTART file with the data bases.
The MPE/iX prompt is returned. Locate the correct RESTART file, and run
DBRECOV,ABORT again.
After the RESTART file is opened, DBRECOV tries to open all databases
identified in the RESTART file. For each database that cannot be opened,
DBRECOV displays the following message:
Can't re-open DATABASE basename
CONTINUE WITH ABORT (N/Y)?
DBRECOV then allows the user to make sure that the ABORT is desired. If
not all databases are in the RESTART file, it may mean that this a
different set of databases. Respond Y or YES to continue the ABORT, and
N, NO (or press carriage return) to stop the ABORT.
DBRECOV then checks to make sure all the databases in the RESTART file
are set for RESTART. When DBRECOV encounters a database not in RESTART
mode, it prompts:
DATABASE basename IS NOT IN RESTART MODE
CONTINUE (N/Y)?
Respond Y or YES to continue the ABORT, and N, NO (or press carriage
return) to stop the ABORT.
When all compatibility checks have passed, DBRECOV displays all databases
in the RESTART file:
DATABASE(S) WITH RECOVERY TO BE ABORTED:
base1.group.acct
base2.group.acct
:
If not all of the databases can be opened, DBRECOV prints an MPE/iX file
error and prompts the user to continue with the ABORT:
CONTINUE WITH ABORT (N/Y)?
Respond Y or YES to continue the ABORT, and N, NO (or press carriage
return) to stop the ABORT.
After ABORT is successfully completed, the current RESTART file is
purged, the MPE/iX prompt is returned,and the user can issue a DBUTIL
>>SHOW command. The RESTART flag is disabled, and the database access
flag is reset to the state it was in before DBRECOV was run.
Purging a RESTART File.
If the RESTART option fails at the current STOP point, the user can ABORT
the current recovery process and RESTART the databases from the previous
STOP point. However, if the ABORT option fails, the DBRECOV,PURGE
command can be used as a last resort to delete the useless RESTART file
before restarting with a backup of the databases and RESTART file of a
previous STOP point.
CAUTION When using PURGE on a RESTART file, RESTART must be done from
the previous STOP point.
:RUN DBRECOV.PUB.SYS,PURGE
DBRECOV prompts for the name of the RESTART file:
ENTER RESTART FILENAME?
Enter the filename displayed when DBRECOV was stopped. DBRECOV opens the
file and verifies that it is actually a RESTART file. If DBRECOV is
unable to open the RESTART file, an error message is printed and DBRECOV
is terminated. The user can either determine that the file is not a
RESTART file and delete it, or can RESTART recovery from a previous STOP
point. When a RESTART file is restored from a backup, the previous
RESTART file writes over the current RESTART file.
If the RESTART file is successfully opened, DBRECOV displays the table of
databases in the RESTART file:
RESTART FILE CONTAINS FOLLOWING DATABASE(S):
base1.group.acct
base2.group.acct
:
All the databases will be opened, and DBRECOV checks if they are all
enabled for RESTART. If they are all in RESTART mode, the following
message is printed and DBRECOV is terminated:
DATABASE base1.group.acct IS IN RESTART MODE.
DATABASE base2.group.acct IS IN RESTART MODE.
RECOVERY SUSPENDED - USE DBRECOV,ABORT TO ABORT RECOVERY.
Run DBRECOV,ABORT to purge the RESTART file.
If none of the databases in the RESTART file are set for RESTART, the
RESTART file is purged with no further confirmation.
If some of the databases are not found, DBRECOV prompts for confirmation
to purge the RESTART file:
Can't re-open DATABASE basename.
CONTINUE WITH PURGE (N/Y)?
DBRECOV allows you to make sure that you wish to purge this recovery
process. If not all databases are in the RESTART file, this could be a
different set of databases. Respond Y or YES to purge the RESTART file,
or N, NO, (or press carriage return) to stop.
Occasionally, DBRECOV can terminate abnormally due to a bad log file in
the log set or a system failure. If the user cannot RESTART recovery
from the previous STOP point because of a damaged or missing log file,
PURGE the current RESTART file and begin the mirror recovery process
again. Listed below are the four basic steps used to reestablish the
mirror database system after an abnormal termination of DBRECOV:
1. Disable user access on the primary system and store the databases
from the primary system.
2. Purge the databases on the secondary system.
3. Restore the databases from the primary system onto the secondary
system.
4. Start a new log set, enable user access on the primary system and
start roll-forward recovery on the secondary system.
Controlling the Logging Process
Backups on the secondary system are made more efficient by controlling
the logging processes on the primary system. Some important factors to
consider before enabling logging on the primary system follow:
* When logging to tape and to allow roll-back recovery, the database
must be on the system volume set. Logging to tape eliminates the
step of storing log files with the databases once they are rolled
forward on the secondary system. However, keep track of log file
tapes that correspond with each database and RESTART file backup
tapes. Logging to tape requires a dedicated tape drive.
* When logging to disk and to allow roll-back recovery, the database
and the user log file must be on the same volume set. Logging to
disk enables storing log files and the databases on a single tape
using an MPE/iX STORE command rather than a DBSTORE command. When
logging to disk, remember to backup all log files that were
processed after the last DBRECOV,RESTART along with the databases
and RESTART file.
* When naming data sets, follow proper naming conventions. This
will make storing the databases, log files, and RESTART file much
easier and eliminate the use of several different tapes for the
log files. If naming conventions are followed, an MPE/iX STORE
command using the "@" sign followed by the database name can be
used to store the log files, database, and RESTART file.
* When changing log files, either let the GETLOG AUTO option switch
to the next log file automatically and/or manually issue a
CHANGELOG command to close the current log file and open the next
file in the log set.
* When using the STOP-RESTART option, the log file name and the
logid must be different.
Log File Size.
Determine the size of the log files, based on how far behind the
secondary system will be, and how often backups will be done. To keep
the secondary system as close to a mirror image of the primary database
as possible, log files should be made small so that they will be filled
quickly and can be sent to the secondary system frequently. Of course,
making the log files small means spending more time transferring log
files from the primary to the secondary system. It also means that the
CHANGELOG maximum file limit of 999 will be exhausted quickly. In the
event that this limit is exhausted, stop, backup the database, and
reinitiate logging on the primary system.
One disadvantage of having several small log files is in the application
of STOP-RESTART. DBRECOV prompts to CON[TINUE] or STOP recovery if it is
between log files in a log set, and it cannot find the next log file.
Therefore, the prompts to CON[TINUE] or STOP are more frequent when there
are several small log files.
An alternate logging option would be to set the log file size very large
and just manually change to the next log file by issuing the CHANGELOG
command. The idea is to continually fill the log file with transactions.
When you are ready to copy the log file over to the secondary system,
change to the next log file on the primary system, copy the current one
to the secondary system, and start recovery. This method requires
someone at the system console to monitor the logging and database
maintenance processes. If you want to schedule backups on the secondary
system around certain times of the day, for example, at the beginning and
end of a work day, use this logging procedure on the mirror database.
You can log a full shift's transactions and then manually issue a
CHANGELOG command at the system console to create a new log file in the
log set. Even if the GETLOG command AUTO option was specified when
logging was enabled, a manual CHANGELOG command can also be issued at any
time. The closed log file is transferred to the secondary system, and
the DBRECOV roll-forward recovery process can be continued on the
secondary databases.
After the log file has been processed, DBRECOV looks for the next log
file in the log set on the secondary system. If the next log file on the
primary system is in use, the user is prompted to CON[TINUE] or STOP. At
this point, recovery can be stopped and the secondary database can be
stored and await the arrival of the next log file at the end of the
shift. Remember to store the RESTART file and the current, unprocessed
log files with the databases.