HP 3000 Manuals HP 3000 Manuals
Roll-Forward Recovery
Roll-forward recovery can be executed to bring databases back to a
likeness of their state at the time of a hard system failure (for
example, a disk head crash or a system failure while the database is
enabled for AUTODEFER). Roll-forward recovery requires a synchronized
backup copy of the database and the log file. (Refer to "Logging
Preparation" earlier in this chapter for roll-forward logging
information.)
When executing roll-forward recovery following a system failure, the
TurboIMAGE/XL utility DBRECOV recovers the database physical and logical
integrity by re-applying (to a backup copy of the database) all the
completed transactions that were written to the log file. It does not
re-apply incomplete transactions.
Recovery of the database requires restoring the backup copy and running
the recovery system to re-execute the database modifications from the log
file. In addition, the >FILE command of the DBRECOV utility can be used
to create individual user recovery files and to return information
regarding the successful recovery or suppression of transactions. The
information from these files lets each user know where to resume
transactions within the database following recovery. Refer to the
discussion of the DBRECOV >FILE command in chapter 8.
Although the logging and recovery system is designed to successfully
re-execute transactions that completed before the system failure, some
transactions may not be recovered. The possible causes of this situation
include the following:
* One or more records could be lost in the log system buffers if the
system fails before they are written to the log file.
* A transaction may have originally failed to complete due to the
failure, and is therefore suppressed.
* A transaction may depend upon some database modification that was
suppressed. This condition indicates inadequate locking between
processes.
* An incorrect version of the database was restored. Recovery will
yield invalid and erroneous results if this occurs.
If any transaction fails to be recovered, all subsequent calls within the
same transaction block are suppressed as well. For information about
transaction blocks, refer to "FILE Command" later in this chapter.
CAUTION In the event of a system failure, do not restart logging before
running DBRECOV. Log records may have been lost due to the
system failure. If logging is resumed without a recovery, the
resulting discontinuous log file would cause invalid results in
the event of a subsequent recovery. The same is true for making
modifications to the database. The database should be disabled
for user access until recovery has completed. To prevent access
to the database after a system failure without recovery, enable
the MUSTRECOVER feature when you enable recovery.
Enabling the Roll-Forward Feature
To enable the roll-forward feature, complete the following sequence:
1. Set the logid and build a log file (if logging to disk) as shown
in steps 2 through 6 of "Logging Preparation" earlier in this
chapter.
2. For each particular database, disable access and enable the
logging and roll-forward features by entering the following DBUTIL
commands. You can also enable the MUSTRECOVER option if you wish
to use it.
>>DISABLE database name FOR ACCESS
>>ENABLE database name FOR LOGGING,RECOVERY
>>ENABLE database name FOR MUSTRECOVER
Enable any other appropriate flags as discussed in step 7 under
"Logging Preparation."
3. Make a backup copy of the database as discussed in step 8 under
"Logging Preparation."
4. Start the logging process and enable user access to the
appropriate databases as shown in "Logging Maintenance," earlier
in this chapter.
Restoring the Database Backup Copy
After a hard system failure, and before roll-forward recovery can begin,
you must restore the database to the state it was in when logging was
enabled. This is done by running the DBRESTOR program (as shown below)
or by using the MPE/iX RESTORE facility after purging the damaged
database. All databases and files must be restored to their original
group and account, and you must have privileged mode (PM) capability.
Ensure that recovery is enabled and access disabled to prevent user
modifications before the recovery system executes (refer to the DBUTIL
>>SHOW command and the following example). If the flags were set as
recommended prior to making the backup copy, no changes are needed.
:RUN DBUTIL.PUB.SYS
:
>>PURGE ORDERS
Database ORDERS has been PURGED
>>EXIT
END OF PROGRAM
:RUN DBRESTOR.PUB.SYS
WHICH DATABASE? ORDERS
DATABASE RESTORED
END OF PROGRAM
:RUN DBUTIL.PUB.SYS
>>SHOW ORDERS FLAGS
For database ORDERS
Access is disabled.
Autodefer is disabled.
Dumping is disabled.
Rollback recovery is disabled.
Recovery is enabled.
ILR is disabled.
Mustrecover is enabled.
Logging is enabled.
Prefetch is disabled.
Indexing is disabled.[REV BEG]
HWMPUT is disabled.
Restart is disabled.
>>EXIT
END OF PROGRAM
[REV END]
Several databases can log to the same log file simultaneously because
each call to DBOPEN specifies the fully qualified name of the database.
If all databases that logged to the same log file are to be recovered
simultaneously, then the appropriate backup copy of each database must be
restored prior to running the recovery system. However, if the recovery
system begins execution before a database has been restored, accidental
recovery is prevented if recovery has been disabled on the working
database, as specified earlier in "Logging Maintenance."
The TurboIMAGE/XL logging and recovery systems depend upon the exact
correspondence between the stored database backup copy and the working
database on disk at the time logging was initiated. The DBSTORE flag and
time stamp, properly used, enforce this condition. Therefore, it is
strongly recommended that you always use DBSTORE to generate backup
copies.
For flexibility, in the event that you might use the STORE command to
store the backup, the capability exists to defeat the time stamp and
DBSTORE flag mechanism, by using the NOSTAMP and NOSTORE options of the
>CONTROL command. In this case, you must assume responsibility for
maintaining the correspondence between the backup copy and the log file.
Note that a database recovered with the wrong log file causes DBRECOV to
generate erroneous data in the database and that this condition cannot
always be detected. Modifications to the database before the database is
recovered and with logging disabled also cause the recovered database to
be incorrect.
Performing Roll-Forward Recovery
To complete the transaction roll-forward process following a hard system
failure, perform the following steps:
1. Following a start recovery operation to bring up the system,
locate the applicable log file medium to be used for roll-forward
recovery. If logging to tape, the correct tape needs to be
mounted. If using the MPE/iX CHANGELOG feature and there are
multiple log file tapes, this will be the first tape in the
series. If logging to disk, TurboIMAGE/XL automatically locates
the first log file (for example, LOGF001) in the given logging
cycle after checking for the logid in the root file.
Note that the system boot-up process writes a crash record to the
last volume of the user log set. If a start recovery operation is
not performed, this will not occur, causing DBRECOV to issue a
warning.
2. Check your backup listings to see when your database was last
stored. If time permits, store your damaged database with
DBSTORE. Having a current backup of your damaged database is an
extra measure to protect against lost data due to a damaged log
file.
3. Restore the backup of the database; this backup was created at the
beginning of the current logging maintenance cycle.
4. Enter the following MPE/iX command:
:RUN DBRECOV.PUB.SYS
5. If you used the MPE/iX STORE command to store the database when
you started your logging cycle, enter the >CONTROL NOSTORE command
of DBRECOV.
6. Enter the DBRECOV >RECOVER command below (where database name is
the name of the individual database to be recovered):
>RECOVER database name [,database name2,...,database nameN]
7. Enter all other desired DBRECOV commands (>FILE, >CONTROL with
other options except NOSTORE shown above, and >PRINT.) Refer to
chapter 8 for more information.
8. If you want to recover the database(s), enter the DBRECOV >RUN
command. Otherwise, enter the >EXIT command; DBRECOV terminates,
and no recovery takes place.
>RUN
After the >RUN command is given, DBRECOV recovers the specified
databases, creates user recovery files, and terminates. After
entering the >RUN command, DBRECOV asks you to mount the log tape
(if the log file medium is tape). Continue the roll-forward
process as directed by messages returned to both the console and
the terminal screens.
9. If the CHANGELOG command or the GETLOG AUTO option was used during
logging and the logging file medium is tape or the next disk file
in the log set is missing, the following message appears on the
terminal screen and the console:
Reply CONtinue on console when logfile is ready
When the required log file is available, enter the response CON to
the console request from DBRECOV.
Note that the response is in a form similar to REPLY for a tape mount
used when storing or restoring tapes; that is, you need to supply the
Process Identification Number (PIN). For recovery to succeed, you must
have access to the log file. This implies either knowing the logging
identifier password and having system manager (SM) or operator (OP)
capability, or being the creator of the log identifier with read access
to the log file if it resides in a different logon group and account. If
the log file is on tape, the operator must reply with the proper volume
identifier.
NOTE If the operator is unsure of the volume identifier, it is displayed
on the console when the tape is mounted.
If the database creator and the creator of the log identifier are not the
same, and if the disk log file and the database are in two separate
accounts, follow the steps listed below for recovery to proceed:
1. Assign a maintenance word to the database.
2. Log on as the creator of the log identifier.
3. Fully qualify the database name when issuing the >RECOVER command.
4. Specify the maintenance word.
Recovery from a Stream File.
A stream file may specify all of the databases logging to one log file
for roll-forward recovery. If one of the databases has not been restored
at the time the stream file is run, recovery for that database is
prevented because recovery for that database is disabled if the
recommended procedures have been followed. Recovery can be completed for
all of the other specified databases that have been restored from a
backup copy with recovery enabled, as long as >CONTROL ERRORS is set
appropriately (see "DBRECOV >CONTROL" in chapter 8). This means that
ERRORS must be increased by one for each database disabled for recovery,
because an error message occurs each time a database specified in the
>RECOVER command is not enabled for recovery.
MPE/iX Cleanup Mode and Roll-Forward Recovery.
In the event of a system failure and subsequent start recovery operation,
MPE/iX attempts to clean up any user log files that were open at the time
of the failure. The cleanup procedure involves writing any records left
in the system log file disk buffer to the user log file. When using
roll-forward recovery without this cleanup, records left in memory will
still be lost. You have the option to cancel (from the console) this
cleanup procedure if the log file is on tape.
The advantage of the cleanup procedure is that fewer user log records
written just prior to the failure are lost. For tape files, the
disadvantage is the time it takes for the tape to be rewound and
sequentially scanned until the end-of-file is detected so that the
remaining records can be appended to the end.
The TurboIMAGE/XL recovery program DBRECOV does not require the cleanup
to be performed. If it is not performed, however, DBRECOV most likely
will report a sequence or checksum error when the discrepancy caused by
the failure is encountered. This would cause DBRECOV to assume the
end-of-file has been reached.
DBRECOV Abort Message
If DBRECOV aborts before recovery completes, the following information is
printed:
Abort occurred on database: dbname dbgroup dbaccount
Total database open count: #open Current open count: #open
Process user is: dbuser dbgroup dbaccount Running program: progname
Log file name: logfilename Logging ID: logid
Log file record number: nnnnnnnn Transaction type: xx
Transaction date/time from log record: day, month, dd, year,time
Last successful transaction #: nn
First log record # of last successful transaction: nn
Record the information, set the log file, locate the database store, and
contact your HP support representative.