1  –  process_attaches_field

    This field displays the total number of database attaches on
    the current node. If a single process attaches to the database
    multiple times, this statistic is incremented by the actual
    number of attaches.

2  –  process_failures_field

    This field displays the total number of processes that abnormally
    terminated and required database recovery.

    In the case of some other node failure, this statistic might
    indicate process failure on the other node that was actually
    recovered on this node.

3  –  DB freeze len x100 field

    This field displays the total database freeze duration, expressed
    in hundredths of a second. During the database freeze, no
    database activity is permitted; the database is "frozen". The
    longer the duration, the more database performance bottlenecks
    may result.

4  –  Tx REDO count field

    This field displays the total number of transactions that needed
    to be "redone".

    Transaction redo occurs when fast commit transaction processing
    is enabled. The fast commit feature contains several parameters
    that can be modified to control the overall redo duration, but at
    the expense of runtime performance.

    Transaction redo requires reading the AIJ journal from the failed
    process' checkpoint location and re-applying all subsequent
    committed database modifications for that process. This usually
    involves re-applying many committed transactions.

    The number of transactions redone is not as important as the
    amount of work required per transaction. In other words, a single
    long transaction requires the same redo processing as many short
    transactions.

    Transactions that are densely packed into a minimum AIJ interval
    are more efficiently redone than a transaction whose data
    spans a long range of AIJ blocks. In other words, long-running
    transactions that do only occasional infrequent database updates
    may be redone more efficiently as several short transactions.
    This is an application issue. However, total application
    throughput also affects this redo performance.

    Transaction redo is normally the longest portion of the process
    recovery operation.

5  –  __redo_time_x100_field

    This field displays the total time (in hundredths of a second)
    required for transactions that needed to be "redone".

6  –  Tx UNDO count field

    This field displays the total number of transactions that needed
    to be "undone".

    Transaction undo requires reading the RUJ journal approximately
    twice, once forwards to determine the end of the current
    transaction, and then backwards from that location to the
    beginning of the RUJ file.

    Transaction undo is performed only on the transaction that was
    currently active, if any, at the time of process failure.

7  –  __undo_time_x100_field

    This field displays the total time (in hundredths of a second)
    required for transactions that needed to be "undone".

8  –  no_undo_needed_field

    This field displays the total number of transactions that did
    not need to be "undone". Occasionally, the failed process did
    not have any active transactions, thereby allowing the database
    recovery (DBR) process to avoid having to manually determine if a
    transaction needs being "undone".

9  –  Tx committed field

    This field displays the total number of transactions that were
    committed during the transaction undo phase. This normally
    occurs during the resolution phase of an in-progress distributed
    transaction. However, this event can also occur if an optimistic
    commit record was found in the AIJ journal that was not yet
    recorded in the process' recovery information.

10  –  Tx rolled back field

    This field displays the total number of transactions that were
    rolled back during the transaction undo phase. This is the normal
    result of transaction undo.

11  –  No resolve needed field

    This field displays the total number of transactions that did not
    need to be either committed or rolled back during the transaction
    undo phase. This normally occurs when fast commit transaction
    processing is enabled, where the RUJ file is examined to locate
    an active transaction, but none can be found.

12  –  AIJ recover x100 field

    This field displays the total time (in hundredths of a second)
    required to recover the in-progress AIJ flush operation, if any.
    This is normally a very fast operation.

13  –  GB recover x100 field

    This field displays the total time (in hundredths of a second)
    required to recover the global buffer information, if applicable.
    This is normally a very fast operation.

14  –  Cache recover x100 field

    This field displays the total time (in hundredths of a second)
    required to recover the row cache following RCS failure or node
    failure.

    Depending on the number and sizes of the active row caches, this
    can be a lengthy operation.

15  –  RUJ file reads field

    This field displays the total number of read I/O operations
    performed on the RUJ journal during the transaction undo phase.
    The RUJ file is never written by the database recovery (DBR)
    process.

16  –  AIJ file reads field

    This field displays the total number of read I/O operations
    performed on the AIJ journal during both the transaction redo
    and undo phases. If, during the transaction undo phase, the in-
    progress transaction is rolled back, a rollback record will be
    written to the AIJ journal.