The RMU Unload After_Journal command translates the binary data
    record contents of an after-image journal (.aij) file into an
    output file. Data records for the specified tables for committed
    transactions are extracted to an output stream (file, device,
    or application callback) in the order that the transactions were
    committed.

    Before you use the RMU Unload After_Journal command, you must
    enable the database for LogMiner extraction. Use the RMU Set
    Logminer command to enable the LogMiner for Rdb feature for the
    database. Before you use the RMU Unload After_Journal command
    with the Continuous qualifier, you must enable the database for
    Continuous LogMiner extraction. See Set Logminer help topic for
    more information.

    Data records extracted from the .aij file are those records that
    transactions added, modified, or deleted in base database tables.
    Index nodes, database metadata, segmented strings (BLOB), views,
    COMPUTED BY columns, system relations, and temporary tables
    cannot be unloaded from after-image journal files.

    For each transaction, only the final content of a record
    is extracted. Multiple changes to a single record within a
    transaction are condensed so that only the last revision of the
    record appears in the output stream. You cannot determine which
    columns were changed in a data record directly from the after-
    image journal file. In order to determine which columns were
    changed, you must compare the record in the after-image journal
    file with a previous record.

    The database used to create the after-image journal files being
    extracted must be available during the RMU Unload After_Journal
    command execution. The database is used to obtain metadata
    information (such as table names, column counts, record version,
    and record compression) needed to extract data records from the
    .aij file. The database is read solely to load the metadata
    and is then detached. Database metadata information can also
    be saved and used in a later session. See the Save_MetaData and
    Restore_MetaData qualifiers for more information.

    If you use the Continuous qualifier, the database must be opened
    on the node where the Continuous LogMiner process is running. The
    database is always used and must be available for both metadata
    information and for access to the online after-image journal
    files. The Save_MetaData and Restore_MetaData qualifiers are not
    permitted with the Continuous qualifier.

    When one or more .aij files and the Continuous qualifier are
    both specified on the RMU Unload After_Journal command line,
    it is important that no .aij backup operations occur until the
    Continuous LogMiner process has transitioned to online mode
    (where the active online .aij files are being extracted). If you
    are using automatic .aij backups and wish to use the Continuous
    LogMiner feature, Oracle recommends that you consider disabling
    the automatic backup feature (ABS) and use manual .aij backups
    so that you can explicitly control when .aij backup operations
    occur.

    The after-image journal file or files are processed sequentially.
    All specified tables are extracted in one pass through the
    after-image journal file.

    As each transaction commit record is processed, all modified and
    deleted records for the specified tables are sorted to remove
    duplicates. The modified and deleted records are then written
    to the output streams. Transactions that were rolled back are
    ignored. Data records for tables that are not being extracted are
    ignored. The actual order of output records within a transaction
    is not predictable.

    In the extracted output, records that were modified or added are
    returned as being modified. It is not possible to distinguish
    between inserted and updated records in the output stream.
    Deleted (erased) records are returned as being deleted. A
    transaction that modifies and deletes a record generates only
    a deleted record. A transaction that adds a new record to
    the database and then deletes it within the same transaction
    generates only a deleted record.

    The LogMiner process signals that a row has been deleted by
    placing a D in the RDB$LM_ACTION field. The contents of the
    row at the instant before the delete operation are recorded
    in the user fields of the output record. If a row was modified
    several times within a transaction before being deleted, the
    output record contains only the delete indicator and the results
    of the last modify operation. If a row is inserted and deleted
    in the same transaction, only the delete record appears in the
    output.

    Records from multiple tables can be output to the same or to
    different destination streams. Possible output destination
    streams include the following:

    o  File

    o  OpenVMS Mailbox

    o  OpenVMS Pipe

    o  Direct callback to an application through a run-time activated
       shareable image

    Refer to the Using_LogMiner_for_Rdb help topic for more
    information about using the LogMiner for Rdb feature.