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.