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."
[REV BEG]
If you plan on using TurboSTORE/iX 7x24 True-Online Backup, your
database must be closed so that you can set these flags to enable
the roll-forward feature. For subsequent true-online backups, you
have an option to set the ACCESS and RECOVERY flags. Remember
that before you start the roll-forward recovery, the RECOVER flag
must be enabled and ACCESS flag be disabled.[REV END]
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
[REV BEG]
After a hard system failure, and before roll-forward recovery can begin,
you must restore the database to the state it was in when backup was
done. This is done by running the DBRESTOR program (if DBSTORE was used
for backup, 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.
If you restored a database backed up with TurboSTORE/iX 7x24 True-Online
Backup (with ONLINE=START or ONLINE=END option), you may need to enable
recovery and disable access. Refer to the DBUTIL >>SHOW command and the
following example.[REV END] If the flags were set as recommended prior to
making the backup copy, no changes are needed.
:RUN DBUTIL.PUB.SYS
:
>>PURGE ORDERS Note: this is damaged database.
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.
HWMPUT is disabled.
Restart is disabled.
>>EXIT
END OF PROGRAM
[REV BEG]
In the above example, recovery is enabled and access is disabled. You do
not need to change flags.
If you used TurboSTORE/iX 7x24 True-Online Backup (with ONLINE=START or
ONLINE=END option), you would use RESTORE command as follows:
:restore *orderssf;orders;show
>> TURBO-STORE/RESTORE VERSION C.55.07 B5152AA <<
(C) 1986 HEWLETT-PACKARD CO.
RESTORE *orderssf;orders;SHOW
FRI, APR 18, 1997, 12:03 PM
WILL RESTORE 7 FILES ; NUMBER OF FILES ON MEDIA 7
FILENAME GROUP ACCOUNT VOLUME RESTRICTIONS SECTORS CODE MEDIA
ORDERS .RECTOL .QALANG DISC :C 16 PRIV 1
ORDERS01.RECTOL .QALANG DISC :C 96 PRIV 1
ORDERS02.RECTOL .QALANG DISC :C 96 PRIV 1
ORDERS03.RECTOL .QALANG DISC :C 1584 PRIV 1
ORDERS04.RECTOL .QALANG DISC :C 80 PRIV 1
ORDERS05.RECTOL .QALANG DISC :C 128 PRIV 1
ORDERS06.RECTOL .QALANG DISC :C 160 PRIV 1
DATABASE INFORMATION:
TURBOIMAGE DATABASE: ORDERS .RECTOL .QALANG
FILES RESTORED : 7
FILES RESTORED : 7
:
:RUN DBUTIL.PUB.SYS
HP30391C.07.00 TurboIMAGE/XL: DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1987
>>show orders flags
For database ORDERS
Maintenance word is not present.
Access is enabled.
Autodefer is disabled.
Dumping is disabled.
Rollback recovery is disabled.
Recovery is disabled.
ILR is disabled.
Mustrecover is enabled.
Logging is enabled.
Prefetch is disabled.
Indexing is disabled.
HWMPUT is disabled.
Restart is disabled.
>>exit
In the above example, you will need to disable the access flag and enable
the recovery flag.
[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."
[REV BEG]
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
recommended that you use DBSTORE or TurboSTORE/iX 7x24 True-Online Backup
(with ONLINE=START or ONLINE=END option) to generate backup copies.
For flexibility, in the event that you might use the STORE command
without ONLINE=START or ONLINE=END option 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 of DBRECOV.
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.[REV END]
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[REV BEG] if
DBSTORE was used. If TurboSTORE/iX 7x24 True-Online Backup (with
ONLINE=START or ONLINE=END option) was used to backup the database
and AUTO option is used, this may not be the first file in the
series. If logging to disk, TurboIMAGE/XL automatically locates
the first log file in the given logging cycle after checking for
the logid in the root file. When TurboSTORE/iX 7x24 True-Online
Backup (with ONLINE=START or ONLINE=END option) is used, necessary
information such as the log file name in use, log file record
numbers, date, and time of backup is recorded in the root file
before backup. When the database is restored from this backup,
the SHOW database ALL command of DBUTIL displays this
information.[REV END]
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.
[REV BEG]
3. Restore the backup of the database; this backup was created at the
beginning of the current logging maintenance cycle. Use the SHOW
database command of DBUTIL to find out which log file will be used
to start recovery. If the TurboSTORE/iX 7x24 True-Online Backup
(with ONLINE=START or ONLINE=END option) was used for backup, the
log file name is displayed. Otherwise, it will be the first log
file in this logging cycle.[REV END]
4. Enter the following MPE/iX command:
:RUN DBRECOV.PUB.SYS
[REV BEG]
5. If you used the MPE/iX STORE command without ONLINE=START or
ONLINE=END option to store the database when you started your
logging cycle, enter the >CONTROL NOSTORE command of DBRECOV.[REV
END]
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.
[REV BEG]
If you want to use TurboSTORE/iX 7x24 True-Online Backup (with
ONLINE=START or ONLINE=END option) for roll-forward recovery, follow the
steps below. For this illustration, it is assumed that you are starting
with the first log cycle with the AUTO option, and recovery is needed
after two backups.
1. Create a logid with the AUTO option.
2. Build a logfile, LOGF001.
3. Use DBUTIL to set the logid and enable the logging flag. You may
optionally set the MUSTRECOVER flag as well.
4. Start the log process:
:LOG logid,START
5. Back up the database using TurboSTORE/iX 7x24 True-Online Backup
(with ONLINE=START or ONLINE=END option) and logfile LOGF001. Let
this be backup number 1.
6. Access the database for modifications. The current log file is
LOGF005.
7. Back up the database, while open for access, using TurboSTORE/iX
7x24 True-Online Backup (with ONLINE=START or ONLINE=END option).
Let this be backup number 2.
Note that LOGF005 was in use. At this point, you have an option
to store log files LOGF001 to LOGF004 to another storage media for
added protection. You can then purge them from the system if you
want to continue the log process beyond logfile LOGF999.
8. Continue accessing the database until there is an interruption
(for example, a system failure). The current log file is LOG009.
9. Reboot the system using the START RECOVERY option.
10. Optionally store the damaged database. Purge database using
DBUTIL.
11. Restore the database from backup number 2.
12. Use DBUTIL to disable access and enable recovery. You may use
SHOW database ALL to get backup information.
13. Use DBRECOV for roll-forward recovery. The root file contains
information about the starting point for recovery. The recovery
will start with the logfile LOGF005, following the backup
(DBQUIESCE log records).
14. You can back up the recovered database using TurboSTORE/iX 7x24
True-Online Backup (with ONLINE=START or ONLINE=END option) to
keep recovery time short. Remember the access flag is disabled
and recovery is enabled. When you restore from this backup for
roll-forward recovery, you will not need to execute step 12 above.
15. At this point, you can either restart the logging process
(continue with LOGF009) or start a new log process with LOGF001.
If you want to start a new log process, you will need to stop the
log process and remove (optionally store and purge) the log files
used so far, LOGF005 through LOGF009 (or LOGF001 through LOGF009,
if you did not purge in step 7).
Note that if you plan on using TurboSTORE/iX 7x24 True-Online Backup
(with ONLINE=START or ONLINE=END option) for an existing database and
logging is already enabled, you will not need to execute steps 1 through
4.
[REV END]
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 and the recovery flag is 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.