TurboIMAGE/XL Database Management System Reference Manual (30391-90012)

314 Chapter7
Logging and Recovery
Recovery Options
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 and synchronizing with log files.
• 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.
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.
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.