HP 3000 Manuals HP 3000 Manuals
Recovery Options
The logging and recovery system is used to bring databases back to the
same state at the time of a system failure; this state does not include
incomplete transactions. TurboIMAGE/XL provides several types of
recovery options:
* Default recovery mode
* Dynamic roll-back recovery
* Intrinsic Level Recovery (ILR)
* Roll-forward recovery
* Roll-back recovery
* Mirror database
The recovery options are described briefly below. Dynamic roll-back
recovery, ILR, roll-forward recovery, roll-back recovery, and the mirror
database are discussed in detail later in this chapter. A brief
description of these recovery and logging options is found in appendix G,
"Recovery and Logging Quick Reference." Use the information in this
chapter and in appendix G to determine which recovery and logging options
to choose. The recovery option is based on available database backup,
logging resources, and performance requirements.
Default Recovery Mode. In default recovery mode, TurboIMAGE/XL uses an
MPE/iX file system service, Transaction Management (XM), to ensure the
structural integrity of the database following a system failure. All
modifications to the database (DBPUTs, DBDELETEs, and DBUPDATEs) are
automatically logged to an MPE/iX XM log file. However, this XM log file
is only written to disk when one of the following situations is true:
* A system-specified time has elapsed.
* A request is made by a process to flush the log file to disk, for
example, a call to DBEND mode 2 or 4.
* The XM buffer is full.
XM ensures that the TurboIMAGE/XL intrinsics are applied to the log file
in a serial manner. If a system failure occurs, those completed
intrinsics that have not been written to disk are not recovered. Thus,
one or more completed DBPUTs, DBDELETEs, and DBUPDATEs can be lost, but
the internal structure of the database remains consistent. Recovery with
DBRECOV must be performed at system startup time before anyone modifies
the database.
Dynamic Roll-Back Recovery. Dynamic roll-back recovery is a method of
recovery that uses XM. XM ensures the physical and logical integrity of
the databases. Dynamic roll-back allows a more timely recovery of
databases than is possible with DBRECOV. Dynamic roll-back eliminates the
overhead incurred when a database is enabled for user logging and permits
database access to continue, even when recovering a database.
It provides the most thorough protection for logical database
transactions.[REV BEG] Dynamic transaction can span one or more
databases. The dynamic transaction spanning multiple databases is termed
dynamic multiple database transaction, or DMDBX. Dynamic roll-back
handles both program aborts and system failures without downtime for
recovery, and your database will not be left with an incomplete
transaction. Dynamic roll-back also allows programs to selectively abort
any ongoing transaction.[REV END]
TurboIMAGE/XL uses XM to dynamically roll back uncommitted dynamic
transactions. Dynamic roll-back requires using the three intrinsics:
DBXBEGIN, DBXEND, and DBXUNDO.
Dynamic roll-back recovery can be used with roll-forward recovery to
handle disk media failures.
Intrinsic Level Recovery (ILR). Intrinsic Level Recovery (ILR) is a
recovery method provided within TurboIMAGE/XL. ILR ensures that all
completed DBPUTs and DBDELETEs are recovered. On TurboIMAGE/XL, ILR is
equivalent to calling DBEND mode 2 after every intrinsic. It is
recommended that ILR not be used. It is not required for the DBRECOV
roll-back recovery. See "Intrinsic Level Recovery" in this chapter for
more information.
Roll-Forward Recovery. Roll-forward recovery is another method of
recovery provided within TurboIMAGE/XL. It is used to ensure the
structural and logical integrity of the database. Roll-forward recovery
is used after a hard system failure such as a disk head crash or after
problems occurring while roll-back recovery is in process.
[REV BEG]
Roll-forward recovery requires user logging and a backup copy of the
database. The recovery time needed is generally more than roll-back
recovery. The database backup may have been done using DBSTORE,
TurboSTORE/iX 7x24 (with ONLINE=START or ONLINE=END option), or other
similar programs and must be synchronized with the current log file.
If DBSTORE was used for storing the database, DBRESTORE needs to be used
to restore the database. The correct log file is the first log file and
recovery commences from the beginning of the log file.
If TurboSTORE/iX 7x24 True-Online Backup was used (with ONLINE=START or
ONLINE=END option) to back up the database, the RESTORE command of MPE is
used to restore the database. The recovery may even commence from the
middle of a log file in use when backup was initiated. To find out the
logfile from which recovery will start, use the SHOW databasename ALL
command of DBUTIL. Refer to the TurboSTORE/iX True-Online Backup
discussion later in this chapter.[REV END]
Roll-Back Recovery. Roll-back recovery is another method of recovery
provided within TurboIMAGE/XL. It is used to ensure the structural and
logical integrity of the database. Roll-back recovery is used after a
"soft" system crash such as a system failure or loss of working memory.
[REV BEG]
Roll-back recovery requires user logging. A backup copy of the database
is recommended (for protection in the event of a hard disk failure), but
not required. The time taken to perform roll-back is generally much less
than roll-forward recovery.[REV END]
Mirror Database. In addition to the recovery methods mentioned
previously, roll-forward recovery can be used to mirror a database for
constant access or "high availability" while providing controlled
maintenance using a DBRECOV feature called STOP-RESTART. Backups and
down-time can be regulated with this maintenance method which consists of
two identical databases on two separate computer systems. The mirror
database resides on the secondary system and is maintained with user
logging, DBRECOV, and periodic DBSTOREs.
Logging and Recovery Considerations
To ensure database integrity, the following responsibilities need to be
assigned to specific individuals:
* Enabling and disabling the logging and recovery processes.[REV
BEG]
* Creating database backup copies and synchronizing with log
files.[REV END]
* Performing actual recoveries when required.
NOTE In the event of a system failure and subsequent recovery operation
when using private volumes, logging will not resume until these
private volumes have been mounted. Enter the MPE/iX VMOUNT command
into the SYSSTART file to resume logging.
[REV BEG]
The overhead required by the logging process depends on the number and
type of modifications that are logged and the database structure. Both
overhead and recovery time also depend on the type of recovery being
used. For roll-forward recovery, the time needed for recovery depends on
the number of transactions that were written to the log file following
the last backup of the database. For roll-back recovery, the time needed
to roll back the last incomplete transaction is generally much less than
roll-forward recovery.[REV END]
Dynamic roll-back recovery can process program aborts. This is
significant because the TurboIMAGE/XL logging and recovery system is not
intended to be a solution for transactions that fail to complete in real
time due to a program abort. Because subsequent transactions may be
dependent on a transaction interrupted by a program abort, the recovery
system does not suppress transactions that fail for this reason.
Instead, TurboIMAGE/XL logs an abnormal DBEND to the log file so that the
transaction can be recovered.
NOTE Transactions that fail due to program aborts can be suppressed with
the NOABORTS control option in DBRECOV as long as all processes are
stopped immediately after a program abort and the database is
recovered. Any delay in executing recovery with the NOABORTS
option could result in erroneous data or recovery failure due to
transaction interdependence.
Alternatively, when using roll-forward recovery, the STOPTIME option
could be used to recover transactions that logged up to a time preceding
the program abort. See the discussion on DBRECOV in chapter 8.
As a secondary function, the transaction logging system can be a useful
tool for auditing. The log file is actually a programmatically
accessible journal of all modifications to items in the database. The
log file provides information about previous entries as well as the
current state of the database. The DBMEMO logging intrinsic, containing
user text, provides a method of accessing and interpreting the log files.