Ap G. Recovery and Logging Quick Reference [ TurboIMAGE/XL Database Management System Reference Manual ] MPE/iX 5.0 Documentation
TurboIMAGE/XL Database Management System Reference Manual
Appendix G Recovery and Logging Quick Reference
Recovery Quick Reference
The following pages offer a very brief outline of the recovery options in
TurboIMAGE/XL. For more information regarding dynamic roll-back recovery,
Intrinsic Level Recovery (ILR), roll-forward recovery and roll-back
recovery refer to chapter 7, "Logging and Recovery," and chapter 8,
"Using the Database Utilities."
You should determine which type of recovery to use based on the size of
the database, frequency of system failures, equipment availability, and
other considerations.
Dynamic Roll-Back Recovery
* Allows dynamic transactions to be rolled back online while other
database activity is occurring. If a system failure occurs,
incomplete dynamic transactions will be rolled back at the first
call to DBOPEN for the database after the system is restarted.
* Uses DBXBEGIN, DBXEND, and DBXUNDO intrinsics.
[REV BEG]
* Requires strong locking. Calling DBUNLOCK after a call to DBPUT,
DBDELETE or DBUPDATE within a dynamic transaction will return an
error because the call to DBUNLOCK must occur after the call to
DBXEND. If necessary locks are not acquired before calling
DBXBEGIN, covering locks must be used on the intrinsic calls
within the transaction, or the intrinsic will return an error.
* Requires checking of the status condition before proceeding
further after a modification using DBPUT, DBDELETE, DBUPDATE, or
after DBUNLOCK, or DBCLOSE in mode 2. If an error is returned
indicating the failure of the intrinsic, the choices are:
* Call DBXEND. The successful modifications completed within
this dynamic transaction will not be rolled back.
* Call DBXUNDO to roll back the entire transaction. Even
successful modifications completed within this dynamic
transaction will be rolled back.
* Continue with the remainder of the dynamic transaction even
though this intrinsic failed. Be very cautious in your
design when taking this option as the final result can be
unpredictable.
[REV END]
* Cannot use deferred output (AUTODEFER). This ensures the
structural integrity of the database.
* Can use user logging for roll-forward recovery purposes in the
event of a disk media failure.
* Can be used with remote databases.
Intrinsic Level Recovery (ILR)
* Should only be used to force flushing to disk after a call to
DBPUT or DBDELETE.
* Not required with TurboIMAGE/XL, because physical integrity is
automatic and transparent to the user. The same physical
integrity is available through Transaction Management (XM) on
MPE/iX without enabling ILR. Using XM instead of ILR requires less
overhead.
* Guarantees that at most one DBPUT and DBDELETE call per process
will be lost. The database is recovered automatically if recovery
is needed the next time the system is rebooted.
* Cannot use deferred output (AUTODEFER). This ensures the
structural integrity of the database.
* Cannot defer writing modifications to the database because
deferred output cannot be used.
* Is intrinsic driven; transaction locking is not necessary.
* Incurs some overhead on DBPUTs and DBDELETEs due to the request to
flush Transaction Management (XM) log file pages to disk at the
end of each completed DBPUT and DBDELETE.
* Can be used with user logging.
Roll-Forward Recovery
* Provides recovery of a database, both structurally and logically,
to a likeness of its state at the time of a hard system failure.
* Uses DBSTORE and DBRESTOR to restore the database to a consistent
state.
* Requires logging be enabled. During recovery all log files since
the last database backup copy must be applied.
* TurboIMAGE/XL logging depends upon exact correspondence between
the stored backup database copy and the working database on disk
at the time logging was interrupted. The DBSTORE flag and log
file time stamp will enforce this condition.
* Logging provides recovery of both intrinsics and transactions
following a system failure.
* Is initiated with the >RECOVER command of DBRECOV. The database
must be purged and restored before recovery is initiated.
* During a start recovery operation all transactions in the memory
buffer will be lost.
* Does not require logical transaction locking; however, it is
recommended.
* When the roll-forward process finishes, the RESTART option in user
logging can be used or a new logging cycle can be started.
Remember to purge the log file before starting the new logging
cycle.
* May not recover all transactions. If using DBEND mode 2,
transactions will be flushed to the log file at DBEND time;
therefore, transactions will not be lost.
* You should consider how often to store the database. The more
frequent the DBSTORE, the smaller the log files will be, thus
cutting the time required for recovery.
Roll-Forward Flag Settings.
The recommended settings for TurboIMAGE/XL flags used for roll-forward
recovery are shown in the following table. Note that the flags change
depending on whether you are storing a database, running in production,
or initiating a database recovery.
Table G-1. Roll-Forward Flag Settings
------------------------------------------------------------------------------------------------
| | | | |
| Flags | DBSTORE | Production | DBRECOV |
| | | | |
------------------------------------------------------------------------------------------------
| | | | |
| Access | Disabled | Enabled | Disabled |
| | | | |
| AUTODEFER | Disabled | Disabled/Enabled | Disabled |
| | | | |
| Dumping | Disabled | Disabled | Disabled |
| | | | |
| ILR | Disabled | Disabled | Disabled |
| | | | |
| Logging | Enabled | Enabled | Enabled |
| | | | |
| Recovery | Enabled | Disabled | Enabled |
| | | | |
| Roll-back | Disabled | Disabled | Disabled |
| | | | |
------------------------------------------------------------------------------------------------
Roll-Back Recovery
* Provides rapid recovery of database integrity following a soft
system crash and restores the database to a consistent state,
physically and logically, by backing out any incomplete
transactions.
* Requires logging. However only the current log file is required
to restore database integrity. DBSTORE is recommended but not
required. (Logging is automatically enabled when roll-back is
enabled.)
* If logging to disk, requires that the database and the user log
file be on the same volume set.
* If logging to tape, requires that the database be on the system
volume set.
* Is initiated with the >ROLLBACK command of DBRECOV.
* When disabled, logging must be manually disabled using DBUTIL.
* Requires all multiple-intrinsic database transactions to execute
independently, using logical transaction locking.
* Uses the time stamp during recovery to verify the correct log file
for each database being recovered. The time stamp is updated when
the database is first opened and is logged to the log file and the
root file.
* Should not be disabled if roll-back recovery must be used later
because it will reset the logging time stamp, therefore recovery
cannot be performed. The database will be considered correct and
cannot be rolled back.
* Transactions are not lost during a start recovery operation
because they are not held in the memory buffer. (A start recovery
operation must be performed after a system failure.)
* When the roll-back process finishes, the RESTART option in user
logging can be used or a new logging cycle can be started.
Remember to purge the log file before starting the new logging
cycle.
Roll-Back Flag Settings.
The recommended settings for TurboIMAGE/XL flags used for roll-back
recovery are shown in the following table. Note that the flags change
depending on whether you are storing a database, running in production,
or initiating a database recovery.
Table G-2. Roll-Back Flag Settings
------------------------------------------------------------------------------------------------
| | | | |
| Flags | DBSTORE | Production | DBRECOV |
| | | | |
------------------------------------------------------------------------------------------------
| | | | |
| Access | Disabled | Enabled | Disabled |
| | | | |
| AUTODEFER | Disabled | Disabled | Disabled |
| | | | |
| Dumping | Disabled | Disabled | Disabled |
| | | | |
| ILR | Disabled | Disabled | Disabled |
| | | | |
| Logging | Enabled | Enabled | Enabled |
| | | | |
| Recovery | Enabled | Disabled | Enabled |
| | | | |
| Roll-back | Enabled | Enabled | Enabled |
| | | | |
------------------------------------------------------------------------------------------------
Recovery
* Without a database backup copy, recovery can be performed using
DBUNLOAD (chained) and DBLOAD to salvage all or most of a
database.
MPE/iX 5.0 Documentation