Under certain
conditions, Rdb and DBMS will bugcheck with a fatal error (DBR$RESOLVE).
This error requires a full database restore and recovery from an
earlier full database backup and the associated After Image Journal (AIJ)
file. This occurs when the database monitor believes it must recover for
a failed process, and there is an inconsistency between the contents
of the RUJ block in the root file and the corresponding (if any) Run
Unit Journal file.
This problem may occur when a process is stopped
(STOP/ID or CTRL-Y/STOP or RMU/CLOSE/ABORT=DELPRC or
DBO/CLOSE/ABORT=DELPRC) after it
has bound to the database and before it has performed any SQL
(or DML)
verbs on that database and the contents of the RUJ block in
the root file are uninitialized. This problem may be caused by RUJ
blocks in the root file being left uninitialized after increasing
the maximum number of users for the
database or when the Process Identification in the RUJ block in the
root file contains the PID of an earlier process.
In the old version of database, the RUJ file is
not created, and the contents of the RUJ block in the root file are
not initialized until a MODIFY occurs. Until the RUJ block in the
root header is initialized, it may contain an older RUJ entry. When a
process is deleted, Rdb and DBMS attempts to recover from an older or
invalid RUJ entry but is unable to do so because the Run Unit
Journal file does not exist or the PID in the RUJ block and the
existing Run Unit Journal file do not match. This problem should be
fixed in Rdb v5.1a and v6.0 and DBMS v4.3c, v5.1a and 6.0.
If you believe you have experienced this bug,
search the DBRBUGCHK.DMP file for the string "*****". You
may see something like the following:
***** Exception at 00B4A568 : DBR$RESOLVE +
00000117
The "DBR$RESOLVE + 117" indicates that
this is the problem you are experiencing. To recover, you will need
to restore your database from an earlier backup, and recover the
database using the After Image Journal. The database experts and
Software Concepts International have successfully
"patched" the database root file to initialize the errant
RUJ blocks in the root file – by using this
approach SCI avoided the significant amount of downtime that would
have been required to restore and recover the database.
Recommendations
Avoid
the use of auto-logoff utilities and implement After Image
Journaling on all Rdb and DBMS databases. The very small amount of
overhead is well worth the additional level of protection. In
addition, since version 4.3, certain optimizations can be used only
if after image journaling is enabled – possibly enhancing overall
performance if AIJs are enabled.
It is also wise to force the RUJ blocks in the
root file to be initialized by simultaneously binding
(attaching) to the database multiple times (one bind per number of
users allowed). To force the RUJ block to be initialized, each
attach to the database must READY the database, FETCH and MODIFY the
first record then ROLLBACK the transaction. Note: Multiple binds can
occur within one process by using streams – each stream represents
a separate attach to the database.
