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 may 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 in 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.
[REV BEG]
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 database. 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.
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 transaction.
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.[REV END]
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.
Roll-forward recovery requires user logging and a backup copy of the
database. The database backup must be synchronized with the beginning of
the log file.
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.
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.
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.
* Creating database backup copies.
* Performing actual recoveries when required.
NOTE In the event of a system failure and subsequent start recovery
operation and 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.
The overhead required by the logging process depends on the number and
type of modifications that are logged and the database structure. 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. Overhead and recovery time also depend on the
type of recovery being used.
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.