o To use the RMU Recover command for a database, you must have
the RMU$RESTORE privilege in the root file access control
list (ACL) for the database or the OpenVMS SYSPRV or BYPASS
privilege.
o You can use the RMU Backup After_Journal command to copy an
extensible .aij file to tape and truncate the original .aij
file without shutting down your database.
o Transactions are applied to the restored copy of your database
in the order indicated by their commit sequence number and the
commit record in the .aij file; timestamps are not used for
this purpose. Therefore, you need not be concerned over time
changes made to the system (for example, resetting the time
for United States daylight saving time) or inconsistencies
in the system time on different nodes in a cluster. The only
occasion when timestamps are considered in the application of
.aij files is when you specify the Until qualifier. In this
case, the timestamp is used only as the point at which to stop
the recovery, not as a means to serialize the order in which
transactions are applied. See the description of the Until
qualifier for more information.
o You can redirect the AIJ rollforward temporary work files
and the database recovery (DBR) redo temporary work files
to a different disk and directory location than the default
(SYS$DISK) by assigning a different directory to the RDM$BIND_
AIJ_WORK_FILE logical in the LNM$FILE_DEV name table and a
different directory to the RDM$BIND_DBR_WORK_FILE logical in
the LNM$SYSTEM_TABLE, respectively.
This can be helpful in alleviating I/O bottlenecks that might
be occurring in the default location.
o In a normal recovery operation, the Format and Label
qualifiers you specify with the RMU Recover command should
be the same Format and Label qualifiers you specified with the
RMU Backup After_Journal command to back up your .aij files or
with the RMU Optimize After_Journal command to optimize your
.aij files.
For more information on the type of access to specify when
mounting tapes, see the description of the Format=Old_File and
Format=New_Tape qualifiers in the Format section.
o The following restrictions apply to using optimized .aij files
with recovery operations:
- Optimized .aij files cannot be used as part of by-area
recovery operations (recovery operations that use the RMU
Recover command with the Area qualifier).
- Optimized .aij files cannot be used as part of by-page
recovery operations (recovery operations that use the RMU
Recover command with the Just_Corrupt qualifier).
- Optimized .aij files cannot be specified for an RMU Recover
command that includes the Until qualifier. The optimized
.aij file does not retain enough of the information from
the original .aij file for such an operation.
- Optimized .aij files cannot be used with a recovery
operation if the database has been modified since the .aij
file was optimized.
The workaround for these restrictions against using optimized
.aij files in recovery operations is to use the original,
unoptimized .aij file in the recovery operation instead.
o You can read your database between recovery steps, but you
must not perform additional updates if you want to perform
more recovery steps.
o If a system failure causes a recovery step to abort, you can
simply issue the RMU Recover command again. Oracle RMU scans
the .aij file until it finds the first transaction that has
not yet been applied to your restored database. Oracle RMU
begins recovery at that point.
o You can use the RMU Recover command to apply the contents of
an .aij file to a restored copy of your database. Oracle RMU
will roll forward the transactions in the .aij file into the
restored copy of the database. You can use this feature to
maintain an up-to-date copy of your database for fast recovery
after a failure. To do this, use the RMU Recover command to
periodically apply your .aij files to a separate copy of the
database.
When you employ this procedure for fast recovery, you must
be absolutely certain that no one will execute an update
transaction on the database copy. Should someone execute an
update transaction, it might result in the inability to apply
the .aij files correctly.
o See the Oracle Rdb Guide to Database Maintenance for
information on the steps Oracle RMU follows in tape label
checking.
o When you use an optimized after-image journal for recovery,
the optimal number of buffers specified with the Aij_Buffers
qualifier depends on the number of active storage areas
being recovered. For those journals optimized with Recover_
Method=Sequential, a buffer count of 250 to 500 is usually
sufficient.
When you use journals optimized with Recover_Method=Scatter,
reasonable performance can usually be attained with a buffer
count of about five times the number of active storage areas
being recovered (with a minimum of about 250 to 500 buffers).
o The number of asynchronous prefetch (APF) buffers is also a
performance factor during recovery. For recovery operations
of optimized after-image journals, the RMU Recover command
sets the number of APF buffers (also known as the APF depth)
based on the values of the process quotas ASTLM, BYTLM, and
the specified AIJ_Buffers value. The APF depth is set to the
maximum of:
- 50% of the ASTLM process quota
- 50% of the DIOLM process quota
- 25% of the specified AIJ_Buffers value
The accounts and processes that perform RMU Recover operations
should be reviewed to ensure that various quotas are set to
ensure high levels of I/O performance. The following table
lists suggested quota values for recovery performance.
Quota Setting
DIOLM Equal to or greater than half of the count of
database buffers specified by the AIJ_Buffers
qualifier. Miminum of 250.
BIOLM Equal to or greater than the setting of DIOLM.
ASTLM Equal to or greater than 50 more than the setting of
DIOLM.
BYTLM Equal to or greater than 512 times the database
buffer size times one half the value of database
buffers specified by the AIJ_Buffers qualifier.
Based on a 12-block buffer size and the desire
to have 100 asynchronous I/O requests outstanding
(either reading or writing), the minimum suggested
value is 614,400 for a buffer count of 200.
WSQUOTA Large enough to avoid excessive page faulting.
WSEXTENT
FILLM 50 more than the count of database storage areas and
snapshot storage areas.