o To use the RMU Backup After_Journal command for a database,
you must have the RMU$BACKUP privilege in the root file access
control list (ACL) for the database or the OpenVMS SYSPRV or
BYPASS privilege.
o See the Oracle Rdb7 Guide to Database Performance and Tuning
for information on how to enhance the performance of the RMU
Backup After_Journal command.
NOTE
When fast commit is enabled and an extensible .aij file
configuration is used, the after-image journal backup
process compresses and retains some fraction of the
original .aij file (in a new version of the current .aij
file). This fraction can approach 100% of the original
size. Therefore, be sure to reserve enough space to
duplicate the maximum size .aij file before backing it
up.
Oracle Corporation recommends that you schedule .aij
backup operations with sufficient frequency and check the
free space and journal file size periodically; you need
to know when you are approaching a critical situation in
terms of free space. (This is good practice whether or
not you have fast commit enabled.)
However, if you issue the RMU Backup After_Journal
command with fast commit enabled and find that you
have insufficient space for the .aij file, you have the
following options:
o Delete unneeded files to create sufficient space on
the disk where the .aij file is located.
o Temporarily disable fast commit and back up the .aij
file.
o Close the database, disable after-image journaling,
enable a new after-image journal file, and perform a
backup operation. (The database can be opened either
before or after the backup operation.)
o Close the database. Create a bound volume set or
stripe set that is large enough for the .aij file
and copy the .aij file there. Use the RMU Set After_
Journal command to change the .aij file name (or
redefine the logical name if one was used to locate
the journal), and then open the database again.
o Note the following issues and problems you can encounter when
you specify the Format=Old_File qualifier for an .aij backup
operation to tape or the Format=New_Tape qualifier for an .aij
backup operation to disk:
- If you use the Format=Old_File qualifier for an .aij
backup operation to tape and the tape is mounted as a
FOREIGN volume, the result is an unlabeled tape that can
be difficult to use for recovery operations.
Therefore, if you use the Format=Old_File qualifier with
an .aij backup operation to tape, you must mount the tape
as an OpenVMS volume (that is, do not specify the /FOREIGN
qualifier with the DCL MOUNT command).
- You must remember (or record) the format you use when you
back up your .aij file and specify that same format when
you issue an RMU Dump After_Journal, RMU Optimize After_
Journal, or RMU Recover command for the .aij backup file.
If you always follow the guidelines of specifying
Format=New_Tape for tape backups and Format=Old_File for
disk backups, you do not need to track the format you
specified for the .aij backup operation for future use
with the other Oracle RMU .aij commands.
- If you specify Format=Old_File for a backup operation
to tape and the .aij spans tape volumes, you might have
problems recovering the .aij file.
o You can use the RMU Backup After_Journal command to save disk
space by spooling the .aij file to tape.
o When you use extensible .aij files, note that although a new
version of the .aij file might be created when the after-image
backup operation begins, the old .aij file continues to be
active and growing. Until the switch occurs (which could be
several hours after the creation of the new version of the
.aij file), the old .aij file is still being accessed. For
this and other reasons, you should never use the DCL DELETE or
DCL PURGE on .aij files (or any database files).
o The following list provides usage information for the Quiet_
Point and Noquiet_Point qualifiers:
- If the backup operation stalls when you attempt a quiet-
point Oracle RMU backup operation, it may be because
another user is holding the quiet-point lock. In some
cases, there is no way to avoid this stall. However, you
may find the stall is caused by a user who has previously
issued and completed a read-write transaction, and is
currently running a read-only transaction. When this user
started the read-write transaction his or her process
acquired the quiet-point lock. Ordinarily, such a process
retains this lock until it detaches from the database.
You can set the RDM$BIND_SNAP_QUIET_POINT logical name to
control whether or not such a process retains the quiet-
point lock. Set the value of the logical name to "1" to
allow such a process to hold the quiet-point lock until
they detach from the database. Set the value of the logical
name to "0", to ensure that the process releases the quiet-
point lock prior to starting a read-only transaction.
- When devising your backup strategy for both the database
and the after-image journal files, keep in mind the trade-
offs between performing quiet-point backup operations and
noquiet-point backup operations. A noquiet-point backup
operation is quicker than a quiet-point backup operation,
but usually results in a longer recovery operation. Because
transactions can span .aij files when you perform noquiet-
point .aij backup operations, you might have to apply
numerous .aij files to recover the database. In a worst-
case scenario, this could extend back to your last quiet-
point .aij or database backup operation. If you rarely
perform quiet-point backup operations, recovery time could
be excessive.
One method you can use to balance these trade-offs is
to perform regularly scheduled quiet-point .aij backup
operations followed by noquiet-point database backup
operations. (You could do the converse, but a quiet-
point backup of the .aij file improves the performance
of the recovery operation should such an operation become
necessary.) Periodically performing a quiet-point .aij
backup operation helps to ensure that your recovery time
will not be excessive.
- You cannot specify the Noquiet_Point qualifier with the
Format=New_Tape qualifier because an .aij file created with
the Noquiet_Point qualifier does not end on a quiet point.
Some transactions can bridge several backup files. When
you recover from these backup files you frequently must
apply several backup files in the same RMU Recover command.
However, the RMU Recover command with the Format=New_Tape
qualifier can only process one backup file at a time, so it
cannot support backup files created with the Noquiet_Point
qualifier.
o Oracle RMU tape operations do not automatically allocate the
tape drives used. In an environment where many users compete
for a few tape drives, it is possible for another user to
seize a drive while Oracle RMU is waiting for you to load the
next tape volume.
To prevent this, issue a DCL ALLOCATE command for the drives
you will be using before you issue the Oracle RMU command,
and then issue a DCL DEALLOCATE command after you complete the
Oracle RMU command.
o The Label qualifier can be used with indirect file
reference. See the Indirect-Command-Files help entry for more
information.
o If an .aij backup process fails or is terminated prematurely,
the user might discard the resultant .aij backup file because
the backup operation was not completed. However, all .aij
backup files, including those produced by a failed backup
process, are necessary to recover a database. If an .aij
backup file of a failed backup process is discarded, the
database is not recoverable from that point forward. This
is especially important if you use magnetic tapes as the .aij
backup media; in this case, preserve this magnetic tape and do
not reuse it.
o When an .aij backup process, especially one running in
continuous (Continuous) mode, writes to the .aij backup file,
it is possible for the transferred data to be deleted from the
database .aij file. If the backup process subsequently fails
or is prematurely terminated (for example with Ctrl/Y or the
DCL STOP command), it might not be possible to retransfer the
data to the subsequent .aij backup file because the data was
deleted from the active database .aij file.
Therefore, it is extremely important that you preserve all
.aij backup files, even those produced by failed or terminated
backup processes. If the resultant .aij backup file is
discarded, the next .aij backup file could contain a "gap"
in transactions, so that no transactions would ever be rolled
forward from that point on.
This problem is more severe when backing up directly to tape.
Therefore, when backing up to tape, you should back up one
journal at a time, rather than using an open-ended or long-
duration backup operation.
NOTE
If this problem occurs, the database is not inconsistent
or corrupt. Rather, the database cannot be rolled forward
past the discarded .aij backup file.
The solution to this problem is to preserve all .aij backup
files to ensure that a database can be completely recovered.
If you have discarded an .aij backup file, perform a full and
complete database backup operation immediately to ensure that
the database can be restored up to the current transaction.
o When an AIJ backup operation completes, the after-image
journal files are initialized with a pattern of -1 (hex
FF) bytes. This initialization is designed to be as fast as
possible. It fully utilizes the I/O subsystem by performing
many large asynchronous I/O operations at once. However, this
speed can come at the cost of a high load on I/O components
during the initialization. This load could slow down other I/O
operations on the system.
You can use two logical names to control the relative I/O load
that the AIJ initialization operation places on the system.
If you define these logical names in the system logical
name table, they are translated each time an AIJ file is
initialized.
The RDM$BIND_AIJ_INITIALIZE_IO_COUNT logical name specifies
the number of asynchronous I/O operations that are queued at
once to the AIJ file. If the logical name is not defined, the
default value is 15, the minimum value is 1, and the maximum
value is 32.
The RDM$BIND_AIJ_INITIALIZE_IO_SIZE logical name controls
the number of 512-byte disk blocks to be written per I/O
operation. If the logical name is not defined, the default
value is 127, the minimum value is 4, and the maximum value is
127.
Reducing the value of either logical will probably increase
the amount of time needed to initialize the AIJ file after a
backup. However, it may also reduce load on the I/O subsystem.
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 When you use the RMU Backup After_Journal command with the
Log qualifier, the DCL global symbol RDM$AIJ_LAST_OUTPUT_FILE
is automatically created. The value of the symbol is the full
output backup AIJ file specification.
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.
o The system logical RDM$BIND_AIJBCK_CHECKPOINT_TIMEOUT can
be configured to control the checkpoint stall duration
independent of the AIJ shutdown parameter. This logical works
for both the AIJ backup and Automatic Backup Server (ABS)
utilities.