HP 3000 Manuals HP 3000 Manuals
Dynamic Roll-Back Recovery
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 while other users are accessing a database.
Using XM, uncommitted logical transactions can be rolled back dynamically
(online) while other database activity is occurring. This is
accomplished through the use of three intrinsics: DBXBEGIN, DBXEND, and
DBXUNDO.
[REV BEG]
DBXBEGIN and DBXEND mark the beginning and end of the dynamic transaction
which can be for one or multiple databases. The dynamic transaction can
be rolled back in the following ways:[REV END]
* Programmatically with a call to DBXUNDO.
* Automatically when the application aborts or a system failure
occurs within the transaction.
In any case, those transactions begun after the call to DBXBEGIN that do
not have a corresponding call to DBXEND will be rolled back. When you
use DBXUNDO, your program logic must ensure that it does not call DBXEND
subsequently; otherwise, you will get an error.
Use the following sequence of operations when modifying a database with
dynamic transactions:
[REV BEG]
1. Call DBLOCK for each database to be included in the dynamic
transaction to lock all data that must not be changed by other
processes during the transaction. This includes data to be read
and data to be modified.
2. If you wish, read data using DBFIND and DBGET to determine the
necessary modifications.
3. If this is a multiple database transaction, ensure that DBCONTROL
mode 7 is done at least once for each of the databases before
including in the dynamic transaction.
[REV END]
4. Call DBXBEGIN to declare the beginning of modifications.
5. Make modifications using DBPUT, DBDELETE, or DBUPDATE.
For every DBPUT, DBDELETE, or DBUPDATE, the status must be checked
before proceeding further. If an error is returned indicating the
failure of the intrinsic, the choices are:
a. Call DBXEND. The successful modifications completed within
this dynamic transaction will not be rolled back.[REV BEG]
b. Call DBXUNDO to roll back the entire transaction. Even
successful modifications completed within one or more
databases included in this dynamic transaction will be
rolled back. That is, for DMDBX, DBXUNDO affects all
databases included in the DBXBEGIN call.
c. Continue with the remainder of the dynamic transaction even
though this intrinsic failed. As the application designer,
you should be very cautious when taking this option as the
modification to the database in this intrinsic did not take
place.
6. Call DBXEND to declare the end of the modifications. If DBXUNDO
was used in step 4 to roll back a transaction, your program logic
should ensure that the subsequent call to DBXEND is not
processed.[REV END]
7. Call DBUNLOCK to release all of the locks.
Dynamic roll-back requires strong locking as discussed previously under
"Locking and Dynamic Transactions." 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 dynamic transaction,
otherwise an error will be returned.
It is essential that you check the status after each intrinsic. If a
database intrinsic fails, you may end the transaction by calling DBXEND
or roll back the entire transaction by calling DBXUNDO. You may be able
to continue with the transaction despite the intrinsic failure, however,
you must account for the intrinsic failure. The outcome varies based on
your application design.
Do not use DBCLOSE mode 1 (close the database) inside an active dynamic
transaction. This use of DBCLOSE will cause your dynamic transaction to
be rolled back, the locks will be released, the database will be closed,
and subsequent use of DBXEND or DBXUNDO will return an error.
If your dynamic transaction is very long causing XM to reach its limit of
the log buffer space allowed per process, it will become a stalled
transaction, and you cannot continue any further. This stalled
transaction will be rolled back and the process is terminated.
If the system aborts or TurboIMAGE/XL encounters an internal error, the
active memo records are saved in a file. All of the unrecovered memo
records for a particular database are held in the dbname00 file. It
resides in the same group and account as the database, and each database
has only one dbname00 file. The first DBOPEN of an unrecovered database
initiates the recovery using the dbname00 file.
User logging (discussed later in this chapter) is not required for
dynamic roll-back recovery, but it is recommended to guard against a
media failure.