Optimize After_Journal
Optimizes a backed up after-image journal (.aij) file for
database recovery (rollforward) operations by eliminating
unneeded and duplicate journal records, and by ordering
journal records. An optimized .aij (.oaij) file created by the
RMU Optimize After_Journal command provides better recovery
performance for your database than an .aij file. A benefit of
this improved recovery performance is that the database is made
available to users sooner.
The RMU Optimize After_Journal command is used to read a backed
up .aij file on disk and write the .oaij file to tape or disk.
1 – Description
The RMU Optimize After_Journal command performs the following
optimizations to backed up .aij files:
o The .aij records from transactions that rolled back are
eliminated.
Because transactions that are rolled back in an .aij file are
not needed in a recovery operation, they are not part of an
optimized .aij file.
o Duplicate .aij records are eliminated.
Duplicate .aij records are .aij records that update the same
database record. During the rollforward of an .aij file,
duplicate .aij records cause a database record to be updated
multiple times. Each update supersedes the previous update,
meaning only the last update is relevant. Therefore, all but
the last update to a database record can be eliminated from an
.aij file.
o The .aij records are ordered by physical database key (dbkey).
Ordering .aij records by physical dbkey improves I/O
performance at recovery time.
See the Oracle Rdb Guide to Database Maintenance for further
description of optimizing .aij files.
The RMU Optimize After_Journal command has the following
restrictions:
o You can only optimize quiet-point .aij backup files.
o You cannot optimize a current .aij file.
o You cannot optimize an .oaij file.
NOTE
Because an .oaij file is not functionally equivalent to
the original .aij file, the original .aij file should not
be discarded after it has been optimized.
o You cannot use .oaij files with the following types of
recovery operations:
- By-area recovery operations (recovery operations that use
the RMU Recover command with the Areas qualifier).
- By-page recovery operations (recovery operations that use
the RMU Recover command with the Just_Corrupt qualifier).
- RMU Recover commands with the Until qualifier. The .oaij
file does not retain enough of the information from the
original .aij file for such an operation.
- Recovery operation where the database or any storage areas
(or both) are inconsistent with the .oaij file. A database
or storage area will be inconsistent with the .oaij file if
the transaction sequence number (TSN) of the last committed
transaction of the database or storage area is not equal
to the TSN of the last committed transaction in the open
record of the .aij file. The last committed TSN in the
.oaij file represents the last transaction committed to the
database at the time the original .aij file was created.
As a workaround for these restrictions against using .oaij
files in these recovery operations, use the original,
unoptimized .aij files in these recovery operations instead.
o Any .aij file that possibly contains incomplete transactions
cannot be optimized. Incomplete transactions can occur in an
.aij file under the following circumstances:
- The .aij file is backed up with a no-quiet-point backup
operation (because transactions can span .aij files)
Note that transactions in a fixed-size journal
configuration may span .aij files. Thus, if each journal
in a fixed-size journal configuration has been backed up on
a per-journal basis, the resulting files are equivalent to
a no-quiet-point .aij backup operation. These .aij backup
files cannot be optimized unless you perform a manual
quiet-point backup operation first. A quiet-point backup
operation forces a switch-over to another available .aij
file which ensures that no transaction spans two journal
files.
- The previous .aij file was backed up with a no-quiet-point
backup operation
- The .aij file has unresolved distributed transactions
There are no workarounds to these restrictions against
optimizing .aij files with incomplete transactions.
2 – Format
(B)0[mRMU/Optimize/After_Journal aij-file optimized-aij-file
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Accept_Label x /Noaccept_Label
/Active_IO=max-writes x /Active_IO=3
/Block_Size=integer x See description
/Crc[=Autodin_II] x See description
/Crc=Checksum x See description
/Nocrc x See description
/Density=density-value[,[No]Compaction]x See description
/Encrypt=({Value=|Name=}[,Algorithm=]) x See description
/Format={Old_File|New_Tape} x /Format=Old_File
/[No]Group_Size=interval x See description
/Label=(label-name-list) x See description
/Librarian[=options] x None
/[No]Log x Current DCL verify value
/[No]Media_Loader x See description
/Owner=user-id x See description
/Protection[=openvms-file-protection] x See description
3 – Parameters
3.1 – aij-file
The name of the .aij file that you want to optimize. It cannot be
a current .aij file.
The default file extension is .aij.
3.2 – optimized-aij-file
The name of the optimized .oaij file to be produced by the RMU
Optimize After_Journal command.
The default file extension is .oaij.
4 – Command Qualifiers
4.1 – Accept Label
Accept_Label
Specifies that Oracle RMU should keep the current tape label it
finds on a tape during an optimize-to-tape operation even if that
label does not match the default label or that specified with
the Label qualifier. Operator notification does not occur unless
the tape's protection, owner, or expiration date prohibit writing
to the tape. However, a message is logged (assuming logging is
enabled) to indicate that a label is being preserved and which
drive currently holds that tape.
This qualifier is particularly useful when your optimize-to-tape
operation employs numerous previously used (and thus labeled)
tapes and you want to preserve the labels currently on the tapes.
If you do not specify this qualifier, the default behavior
of Oracle RMU is to notify the operator each time it finds a
mismatch between the current label on the tape and the default
label (or the label you specify with the Label qualifier).
See the description of the Labels qualifier under this command
for information on default labels. See How Tapes are Relabeled
During a Backup Operation in the Usage_Notes help entry under
the Backup Database help entry for a summary of which labels are
applied under a variety of circumstances.
4.2 – Active IO
Active_IO=max-writes
Specifies the maximum number of write operations to the .oaij
file device that the RMU Optimize After_Journal command will
attempt simultaneously. This is not the maximum number of write
operations in progress; that value is the product of active
system I/O operations and the number of devices being written
to simultaneously.
The value of the Active_IO qualifier can range from 1 to 5. The
default value
is 3. Values larger than 3 might improve performance with some
tape drives.
4.3 – Block Size
Block_Size=integer
Specifies the maximum record size for the optimized .oaij file.
The size can vary between 2048 and 65,024 bytes. The default
value is device dependent. The appropriate block size is a
compromise between tape capacity and error rate. The block size
you specify must be larger than the largest page length in the
database.
4.4 – Crc[=Autodin II]
Crc[=Autodin_II]
Uses the AUTODIN-II polynomial for the 32-bit cyclic redundancy
check (CRC) calculation and provides the most reliable end-
to-end error detection. This is the default for NRZ/PE
(800/1600 bits/inch) tape drives.
Typing the Crc qualifier is sufficient to select the Crc=Autodin_
II option. It is not necessary to type the entire qualifier.
4.5 – Crc=Checksum
Crc=Checksum
Uses one's complement addition, which is the same computation
used to do a checksum of the AIJ data on disk. This is the
default for GCR (6250 bits/inch) tape drives and for TA78, TA79,
and TA81 drives.
The Crc=Checksum qualifier allows detection of data errors.
4.6 – Nocrc
Nocrc
Disables end-to-end error detection. This is the default for TA90
(IBM 3480 class) drives.
NOTE
The overall effect of the Crc=Autodin_II, Crc=Checksum, and
Nocrc defaults is to make tape reliability equal to that
of a disk. If you retain your tapes longer than 1 year,
the Nocrc default might not be adequate. For tapes retained
longer than 1 year, use the Crc=Checksum qualifier.
If you retain your tapes longer than 3 years, you should
always use the Crc=Autodin_II qualifier.
Tapes retained longer than 5 years could be deteriorating
and should be copied to fresh media.
See the Oracle Rdb Guide to Database Maintenance for details
on using the Crc qualifiers to avoid underrun errors.
4.7 – Density
Density=density-value[,[No]Compaction]
Specifies the density at which the output volume is to be
written. The default value is the format of the first volume (the
first tape you mount). You do not need to specify this qualifier
unless your tape drives support data compression or more than one
recording density.
The Density qualifier is applicable only to tape drives. Oracle
RMU returns an error message if this qualifier is used and the
target device is not a tape drive.
If your systems are running OpenVMS versions prior to 7.2-1,
specify the Density qualifier as follows:
o For TA90E, TA91, and TA92 tape drives, specify the number in
bits per inch as follows:
- Density = 70000 to initialize and write tapes in the
compacted format
- Density = 39872 or Density = 40000 for the noncompacted
format
o For SCSI (Small Computer System Interface) tape drives,
specify Density = 1 to initialize and write tapes, using the
drive's hardware data compression scheme.
o For other types of tape drives, you can specify a supported
Density value between 800 and 160,000 bits per inch.
o For all tape drives, specify Density = 0 to initialize and
write tapes at the drive's standard density.
Do not use the Compaction or NoCompaction keyword for systems
running OpenVMS versions prior to 7.2-1. On these systems,
compression is determined by the density value and cannot be
specified.
Oracle RMU supports the OpenVMS tape density and compression
values introduced in OpenVMS Version 7.2-1. The following table
lists the added density values supported by Oracle RMU.
DEFAULT 800 833 1600
6250 3480 3490E TK50
TK70 TK85 TK86 TK87
TK88 TK89 QIC 8200
8500 8900 DLT8000
SDLT SDLT320 SDLT600
DDS1 DDS2 DDS3 DDS4
AIT1 AIT2 AIT3 AIT4
LTO2 LTO3 COMPACTION NOCOMPACTION
If the OpenVMS Version 7.2-1 density values and the previous
density values are the same (for example, 800, 833, 1600, 6250),
the specified value is interpreted as an OpenVMS Version 7.2-1
value if the tape device driver accepts them, and as a previous
value if the tape device driver accepts previous values only.
For the OpenVMS Version 7.2-1 values that accept tape compression
you can use the following syntax:
/DENSITY = (new_density_value,[No]Compaction)
In order to use the Compaction or NoCompaction keyword, you must
use one of the following density values that accepts compression:
DEFAULT 3480 3490E 8200
8500 8900 TK87 TK88
TK89 DLT8000 SDLT SDLT320
AIT1 AIT2 AIT3 AIT4
DDS1 DDS2 DDS3 DDS4
SDLT600 LTO2 LTO3
Refer to the OpenVMS documentation for more information about
density values.
4.8 – Encrypt
Encrypt=({Value=|Name=}[,Algorithm=])
The Encrypt qualifier decrypts the backup file of the optimized
after-image journal file.
Specify a key value as a string or, the name of a predefined
key. If no algorithm name is specified the default is DESCBC.
For details on the Value, Name and Algorithm parameters see HELP
ENCRYPT.
This feature requires the OpenVMS Encrypt product to be installed
and licensed on this system.
This feature only works for a newer format backup file which has
been created using the Format=New_Tape qualifier. Therefore you
have to specify the Format=New_Tape qualifier with this command
if you also use the Encrypt qualifier.
Synonymous with the Format=Old_File and Format=New_Tape
qualifiers. See the description of those qualifiers.
4.9 – Format
Format=Old_File
Format=New_Tape
The Format qualifier allows you to specify the format of the
files written by the RMU Optimize After_Journal command.
If you specify the default, Format=Old_File, the RMU Optimize
After_Journal command writes files in RMS format. This format is
provided for compatibility with prior versions of Oracle Rdb. If
you specify Format=Old_File, you must mount the media by using
the DCL MOUNT command before you issue the RMU Optimize After_
Journal command. Because the RMU Optimize After_Journal command
will use RMS to write to the tape, the tape must be mounted as
an OpenVMS volume (that is, do not specify the /FOREIGN qualifier
with the MOUNT command).
If you specify FOREIGN access although your backup file was
created using the Format=Old_File qualifier, you will not receive
an error message. The tape will be considered unlabeled, and
thus the operation will process whatever data is at the current
position of the tape (labels, data, or something else). A
failure will occur, but what will fail and how it will fail is
unpredictable because the type of information that will be read
is unknown. The result is an unlabeled tape that can be difficult
to use for recovery operations.
If you specify Format=New_Tape, the RMU Optimize After_Journal
command writes .aij files in a format similar to that used by
an RMU Backup command. If you specify Format=New_Tape, you must
mount the media by using the DCL MOUNT command before you issue
the RMU Optimize After_Journal command. The tape must be mounted
as a FOREIGN volume.
The following tape qualifiers have meaning only when used in
conjunction with the Format=New_Tape qualifier:
Active_IO
Block_Size
Crc
Group_Size
Density
Label
Owner_Uic
Protection
Rewind
Tape_Expiration
Follow these steps when you optimize an .aij file to tape:
1. Use the RMU Backup After_Journal command with the Format=Old_
File qualifier to back up the .aij file to disk.
2. Use the RMU Optimize After_Journal command with the
Format=New_Tape qualifier to optimize the backed up .aij file
to tape.
3. Use the DCL BACKUP command to create a copy of the backed up
.aij file as insurance.
If you enter the RMU Optimize After_Journal command with no
Format qualifier, the default is Format=Old_File.
4.10 – Group Size
Group_Size=interval
Nogroup_Size
Specifies the frequency at which XOR recovery blocks are written
to tape. The group size can vary from 0 to 100. Specifying a
group size of zero or specifying the Nogroup_Size qualifier
results in no XOR recovery blocks being written. The Group_Size
qualifier is applicable only to tape, and its default value is
device dependent. Oracle RMU returns an error message if this
qualifier is used and the target device is not a tape device.
4.11 – Label
Label=(label-name-list)
Specifies the 1- to 6-character string with which the volumes
of the .oaij file are to be labeled. The Label qualifier is
applicable only to tape volumes. You must specify one or more
label names when you use the Label qualifier.
You can specify a list of tape labels for multiple tapes. If you
list multiple tape label names, separate the names with commas,
and enclose the list of names within parentheses.
Use the label that you specify for the RMU Optimize After_Journal
command when you issue the RMU Recover command.
The Label qualifier can be used with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.12 – Librarian
Librarian[=options]
Use the Librarian qualifier to back up files to data archiving
software applications that support the Oracle Media Management
interface. The backup file name specified on the command line
identifies the stream of data to be stored in the Librarian
utility. If you supply a device specification or a version number
it will be ignored.
The Librarian qualifier accepts the following options:
o Trace_file=file-specification
The Librarian utility writes trace data to the specified file.
o Level_Trace=n
Use this option as a debugging tool to specify the level of
trace data written by the Librarian utility. You can use a
pre-determined value of 0, 1, or 2, or a higher value defined
by the Librarian utility. The pre-determined values are :
- Level 0 traces all error conditions. This is the default.
- Level 1 traces the entry and exit from each Librarian
function.
- Level 2 traces the entry and exit from each Librarian
function, the value of all function parameters, and the
first 32 bytes of each read/write buffer, in hexadecimal.
o Logical_Names=(logical_name=equivalence-value,...)
You can use this option to specify a list of process logical
names that the Librarian utility can use to specify catalogs
or archives where Oracle Rdb backup files are stored,
Librarian debug logical names, and so on. See the specific
Librarian documentation for the definition of logical names.
The list of process logical names is defined by Oracle RMU
prior to the start of any Oracle RMU command that accesses the
Librarian utility.
The following OpenVMS logical names must be defined for use with
a Librarian utility before you execute an Oracle RMU backup or
restore operation. Do not use the Logical_Names option provided
with the Librarian qualifier to define these logical names.
o RMU$LIBRARIAN_PATH
This logical name must be defined so that the shareable
Librarian image can be loaded and called by Oracle RMU backup
and restore operations. The translation must include the file
type (for example, .exe), and must not include a version
number. The shareable Librarian image must be an installed
(known) image. See the Librarian utility documentation for
the name and location of this image and how it should be
installed.
o RMU$DEBUG_SBT
This logical name is not required. If it is defined, Oracle
RMU will display debug tracing information messages from
modules that make calls to the Librarian shareable image.
You cannot use device specific qualifiers such as Rewind,
Density, or Label with the Librarian qualifier because the
Librarian utility handles the storage meda, not Oracle RMU.
4.13 – Log
Log
Nolog
Specifies that the optimization of the .aij file be reported to
SYS$OUTPUT. When optimization activity is logged, the output from
the Log qualifier provides the number of transactions committed
and rolled back. You can specify the Trace qualifier with the
Log qualifier. The default is the setting of the DCL VERIFY flag,
which is controlled by the DCL SET VERIFY command.
4.14 – Media Loader
Media_Loader
Nomedia_Loader
Use the Media_Loader qualifier to specify that the tape device
receiving the backup file has a loader or stacker. Use the
Nomedia_Loader qualifier to specify that the tape device does
not have a loader or stacker.
By default, if a tape device has a loader or stacker, Oracle
RMU should recognize this fact. However, occasionally Oracle RMU
does not recognize that a tape device has a loader or stacker.
Therefore, when the first backup tape fills, Oracle RMU issues a
request to the operator for the next tape, instead of requesting
the next tape from the loader or stacker. Similarly, sometimes
Oracle RMU behaves as though a tape device has a loader or
stacker when actually it does not.
If you find that Oracle RMU is not recognizing that your tape
device has a loader or stacker, specify the Media_Loader
qualifier. If you find that Oracle RMU expects a loader or
stacker when it should not, specify the Nomedia_Loader qualifier.
Synonymous with the Owner qualifier. See the description of the
Owner qualifier.
4.15 – Owner
Owner=user-id
Specifies the owner of the tape volume set. The owner is the user
who will be permitted to recover (roll forward) the database. The
user-id parameter must be one of the following types of OpenVMS
identifier:
o A user identification code (UIC) in [group-name,member-name]
alphanumeric format
o A UIC in [group-number,member-number] numeric format
o A general identifier, such as SECRETARIES
o A system-defined identifier, such as DIALUP
When used with tapes, the Owner qualifier applies to all
continuation volumes. The Owner qualifier applies to the first
volume only if the Rewind qualifier is also specified. If the
Rewind qualifier is not specified, the optimization operation
appends the file to a previously labeled tape, so the first
volume can have a different protection than the continuation
volumes.
4.16 – Protection
Protection[=openvms-file-protection]
Specifies the system file protection for the .oaij file produced
by the RMU Optimize After_Journal command.
The default file protection varies, depending on whether you
write the .oaij file to disk or tape. This is because tapes
do not allow delete or execute access and the SYSTEM account
always has both read and write access to tapes. In addition, a
more restrictive class accumulates the access rights of the less
restrictive classes.
If you do not specify the Protection qualifier, the default
protection is as follows:
o S:RWED,O:RE,G,W if the .oaij file is written to disk
o S:RW,O:R,G,W if the .oaij file is written to tape
If you specify the Protection qualifier explicitly, the
differences in protection applied for backups to tape or disk
as noted in the preceding paragraph are applied. Thus, if you
specify Protection=(S,O,G:W,W:R), that protection on tape becomes
(S:RW,O:RW,G:RW,W:R).
4.17 – Recovery Method
Recovery_Method=Sequential
Recovery_Method=Scatter
Specifies how .aij records are to be ordered. You can specify one
of two possible order types:
o Sequential-.aij records are ordered by physical dbkey in an
area:page:line sequence. This order type is the default.
o Scatter-.aij records are ordered by a sort key of
page:area:line (page number, area number, and line number).
This order can allow the RMU Recover command to perform more
effective I/O prefetching and writing to multiple storage
areas simultaneously, typically where storage areas of the
database are distributed among multiple disk devices.
Scatter ordering allows more disk devices to be active during
the recovery process. This helps reduce idle CPU time and allows
the recovery to complete in less time. However, because database
configurations vary widely, Oracle recommends that you perform
tests with both Scatter and Sequential ordering of the optimized
after-image journals to determine which method produces the best
results for your system.
4.18 – Rewind
Rewind
Norewind
Specifies that the tape that will contain the .oaij file be
rewound before processing begins. The tape will be initialized
according to the Label qualifier. The Norewind qualifier is
the default and causes the optimized .oaij file to be written
starting at the current logical end-of-tape (EOT).
The Norewind and Rewind qualifiers are applicable only to tape
devices. Oracle RMU returns an error message if these qualifiers
are used and the target device is not a tape device.
4.19 – Tape Expiration
Tape_Expiration=date-time
Specifies the expiration date of the .oaij file on tape. Note
that when Oracle RMU reads a tape, it looks at the expiration
date in the file header of the first file on the tape and assumes
the date it finds in that file header is the expiration date
for the entire tape. Therefore, if you are writing an .oaij
file to tape, specifying the Tape_Expiration qualifier only has
meaning if the .oaij file is the first file on the tape. You can
guarantee that the .oaij file will be the first file on the tape
by specifying the Rewind qualifier and overwriting any existing
files on the tape.
When the first file on the tape contains an expiration date
in the file header, you cannot overwrite the tape before the
expiration date unless you have the OpenVMS SYSPRV or BYPASS
privilege.
Similarly, when you attempt to perform a recover operation with
an .oaij file on tape, you cannot perform the recover operation
after the expiration date recorded in the first file on the tape
unless you have the OpenVMS SYSPRV or BYPASS privilege
By default, no expiration date is written to the .oaij file
header. In this case, if the .oaij file is the first file on
the tape, the tape can be overwritten immediately. If the .oaij
file is not the first file on the tape, the ability to overwrite
the tape is determined by the expiration date in the file header
of the first file on the tape.
You cannot explicitly set a tape expiration date for an entire
volume. The volume expiration date is always determined by
the expiration date of the first file on the tape. The Tape_
Expiration qualifier cannot be used with a backup operation to
disk.
4.20 – Trace
Trace
Notrace
Specifies that the optimization of the .aij file be traced. The
default is the Notrace qualifier, where optimization is not
traced. When optimization is traced, the output from the Trace
qualifier identifies transactions in the .aij file by transaction
sequence numbers (TSNs) and describes what Oracle RMU did with
each transaction during the optimization process. You can specify
the Log qualifier with the Trace qualifier.
5 – Usage Notes
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.
6 – Examples
Example 1
The following command creates an .oaij file named mf_
personnel.oaij from the .aij file named mf_personnel.aij:
$ RMU/OPTIMIZE/AFTER_JOURNAL MF_PERSONNEL.AIJ MF_PERSONNEL.OAIJ
Example 2
The following example uses a density value with compression:
RMU/OPTIMIZE/AFTER_JOURNAL /DENSITY=(TK89,COMPACTION)/REWIND -
/LABEL=(LABEL1,LABEL2) MF_PERSONNEL.AIJ TAPE1:MF_PERSONNEL.OAIJ, TAPE2: