o To use the RMU Optimize After_Journal command for a database,
you must have the RMU$BACKUP or RMU$RESTORE privilege in the
root file access control list (ACL) for the database or the
OpenVMS SYSPRV or BYPASS privilege.
o You cannot optimize an .aij file in the process of backing it
up. You must first back up the .aij file, using the RMU Backup
After_Journal command with the Format=Old_File qualifier, and
then optimize it.
o As part of the optimization process, Oracle RMU sorts journal
records by physical dbkey which improves I/O performance of
the recovery. Because AIJ file optimization uses the OpenVMS
Sort/Merge utility (SORT/MERGE) to sort journal records, you
can improve the efficiency of the sort operation by changing
the number and location of the work files used by SORT/MERGE.
The number of work files is controlled by the RDMS$BIND_SORT_
WORKFILES logical name. The allowable values are 1 through 10
inclusive, with a default value of 2. The location of these
work files can be specified with device specifications, using
the SORTWORKn logical name (where n is a number from 0 to
9). See the OpenVMS documentation set for more information
on using SORT/MERGE. See the Oracle Rdb7 Guide to Database
Performance and Tuning for more information on using these
Oracle Rdb logical names.
o Do not use the OpenVMS Alpha High Performance Sort/Merge
utility (selected by defining the logical name SORTSHR to
SYS$SHARE:HYPERSORT) when using the RMU Optimize After_Journal
command. HYPERSORT does not support several of the interfaces
the command uses. In addition, HYPERSORT does not report
errors or warnings when it is used with the RMU Optimize
After_Journal command.
Make sure that the SORTSHR logical name is not defined to
reference HYPERSORT.EXE.
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 You can optimize an inactive .aij file that results, for
example, from backing up and renaming an extensible .aij file.
Backing up and renaming an extensible .aij file creates a new
active, primary .aij file and makes the previous .aij file
inactive. After optimizing the inactive .aij file, you can
use the OpenVMS BACKUP command to back up the .oaij file. Note
that you cannot optimize an active, primary .aij file.
o The RMU Optimize After_Journal command can read an .aij file
on disk or a backed up .aij file on disk or on tape that is in
the Old_File format, and it can write the .oaij file to disk
or to tape in either Old_File or New_Tape format.
o If an RMU Optimize After_Journal command is issued from a
batch job, tape requests and problems are reported to the
tape operator. This occurs because tape requests and problems
often require manual intervention, and if the RMU Optimize
After_Journal command was issued from a batch job, the only
available person might be the operator.
o When the RMU Optimize After_Journal command is issued
interactively and a tape request or problem arises, Oracle
RMU notifies the person who issued the command through the I/O
channel assigned to the logical name SYS$COMMAND. After being
notified of the problem, the user who issued the command can
either fix the problem (if the user has access to the tape
drive) or contact the tape operator to ask the tape operator
to fix the problem. The REQUEST command can be used to notify
the tape operator, as follows:
$ REQUEST/REPLY/TO=TAPES -
_$ "Please Write Enable tape ATOZBG on drive $255$MUA6:"
o You should use the density values added in OpenVMS Version
7.2-1 for OpenVMS tape device drivers that accept them because
previously supported values may not work as expected. If
previously supported values are specified for drivers that
support the OpenVMS Version 7.2-1 density values, the older
values are translated to the Version 7.2-1 density values if
possible. If the value cannot be translated, a warning message
is generated, and the specified value is used.
If you use density values added in OpenVMS Version 7.2-1 for
tape device drivers that do not support them, the values are
translated to acceptable values if possible. If the value
cannot be translated, a warning message is generated and the
density value is translated to the existing default internal
density value (MT$K_DEFAULT).
One of the following density-related errors is generated if
there is a mismatch between the specified density value and
the values that the tape device driver accepts:
%DBO-E-DENSITY, TAPE_DEVICE:[000000]DATABASE.BCK; does not support
specified density
%DBO-E-POSITERR, error positioning TAPE_DEVICE:
%DBO-E-BADDENSITY, The specified tape density is invalid for
this device
o If you want to use an unsupported density value, use the VMS
INITIALIZE and MOUNT commands to set the tape density. Do not
use the Density qualifier.
o Because data stream names representing the database are
generated based on the backup file name specified for the
Oracle RMU backup command, you must either use a different
backup file name to store the next backup of the database
to the Librarian utility or first delete the existing data
streams generated from the backup file name before the same
backup file name can be reused.
To delete the existing data streams stored in the Librarian
utility, you can use a Librarian management utility or the
Oracle RMU Librarian/Remove command.