When this attribute is set, the transaction will avoid logging the contents of insertions on newly allocated database pages. In a transaction that inserts a large number of new records, the I/O savings of choosing this option can be significant. Users of this option should be aware of several issues. When the optimization is in effect, page allocations that extend the database file are logged as usual; this allows transaction aborts to work correctly, both online and during recovery. At commit time, the database's pages are flushed to disk, eliminating the need to roll-forward the transaction during normal recovery. However, there are other recovery operations that depend on roll-forward, and care must be taken when Bulk-enabled transactions interact with them. In particular, Bulk is incompatible with replication, and is simply ignored when replication is enabled. Also, hot backup procedures must follow a particular protocol, introduced in 11gr2.5.1, to set a flag in the environment before starting to copy files. It is especially important to note that incremental hot backups can be invalidated by use of the bulk insert optimization. Please see the hot backup description in the Getting Started with Transactions Guide, and the description of the HotbackupInProgress attribute in HotbackupInProgress for further information.

The bulk insert optimization is effective only for top-level transactions.