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.