Defer_Index_Updates
    Nodefer_Index_Updates

    The Defer_Index_Updates qualifier specifies that non-unique
    indexes (other than those that define the placement information
    for data in a storage area) will not be rebuilt until commit
    time.

    Use of this qualifier results in less I/O and fewer lock
    conflicts than when index builds are not deferred, but results
    in a total failure of a load operation if any lock conflicts
    are encountered. In such a case, the entire load operation is
    rolled back to the previous commit and you must repeat the load
    operation. (Record insertion recommences at the beginning of
    the input file). For this reason, you should only use the Defer_
    Index_Updates qualifier when all of the following are true:

    o  You specify the Noconstraints qualifier (or you have dropped
       constraints, or no constraints are defined on the table).

    o  You have dropped triggers from the table (or triggers are not
       defined for the table).

    o  No other users are accessing the table being loaded.

    Also be aware that required virtual memory can be quite large
    when you defer index updates. Required virtual memory is directly
    proportional to the following:

    o  The length of the Ikeys in the indexes being deferred

    o  The number of indexes being deferred

    o  The value for n specified with the Commit_Every qualifier

    You can estimate the amount of virtual memory required for each
    deferred index using the following formula, where:

    o  n = the value specified with the Commit_Every qualifier

    o  I = (length of the Ikey + 50)

    n * (I * number_defered_ikeys)

    The Nodefer_Index_Updates qualifier is the default. When you
    specify the Nodefer_Index_Updates qualifier (or accept the
    default), both the indexes that define the placement information
    for data in a storage area and any other indexes defined on the
    table being loaded are rebuilt at verb time.

    This can result in a managed deadlock situation when the Parallel
    qualifier is specified. The following describes such a scenario:

    o  Executor_1 locks index node A in exclusive mode

    o  Executor_2 locks index node B in exclusive mode

    o  Executor_1 requests a lock on index node B

    o  Executor_2 requests a lock on index node A

    In such a situation, Oracle Rdb resolves the deadlock by
    directing one of the executors to commit the data it has already
    stored. This resolves the deadlock situation and the load
    operation continues.