Parallel[=(options)]

    Specifies a parallel load operation. A parallel load operation is
    especially effective when you have large partitioned tables that
    do not contain segmented strings and for which no constraints or
    triggers are defined.

    If you specify the Parallel qualifier without any options, your
    load operation is assigned one executor and four communications
    buffers for that executor. A communications buffer is used for
    communications between your process and the executors.

    If you want to assign additional executors or communications
    buffers, or both, use one or both of the following options:

    o  Buffer_Count=n

       Allows you to specify the number of communications buffers
       assigned to each executor in a parallel load operation.

       Do not confuse this with the Buffers=n qualifier. The
       Buffers=n qualifier specifies the number of database buffers
       to use during the load operation.

    o  Executor_Count=n

       Allows you to specify the number of worker processes to
       be assigned to the load operation. Ideally, the number of
       executors should be equal to the number of table partitions.
       You should not assign a greater number of executors than
       the number of table partitions. If a table is randomly or
       vertically partitioned, Oracle RMU creates only one executor,
       regardless of the number you specify.

       If the user account's MAXDETACH UAF value is greater than 0,
       then executors are created as detached processes. If there
       is no MAXDETACH value set, then executors are created as
       subprocesses. (A MAXDETACH value = 0 equates to unlimited
       detached processes.)

    At the end of each load operation, Oracle RMU displays summary
    statistics for each executor in the load operation and the main
    process. Look at the "Idle time" listed in the statistics at the
    end of the job to detect data skew and look at "Early commits" to
    detect locking contention.

    If some executors have a large amount of idle time, you likely
    have data that is skewed. Ideally, data loaded with the Parallel
    qualifier should appear in random order within the .unl file.
    Data that is already in partition order when you attempt to
    perform a parallel load operation results in high idle time for
    each executor and thus defeats the advantages of a parallel load
    operation.

    The summary statistics also list the number of records read from
    the input file, the number of data records stored, and the number
    of data records rejected. In most cases, the number of data
    records rejected plus the number of data records stored equals
    the number of data read from the input file. However, under the
    following circumstances this equation does not hold:

    o  The parallel load operation aborts due to a duplicate record
       that is not allowed.

    o  You did not specify an exception file.

    Similarly if a load operation aborts due to a record in the input
    file being improperly delimited for a delimited text load, the
    records rejected plus the records stored do not equal the number
    of records read from the input file.

    You cannot use a parallel load operation to load list data
    (segmented string) records or security audit records. If you
    specify a parallel load operation and attempt to load list data
    or security audit records, Oracle RMU returns a warning and
    performs a single-process (non-parallel) load operation.