This content has been marked as final. Show 1 reply
What is happening here is that the two optimizations are canceling each other out. DB_TXN_NOSYNC optimizes by not waiting for the logs to be flushed to disk before continuing processing. DB_TXN_BULK works by not logging the data that is inserting into new pages in the database, but instead flushing the data files at commit time to ensure durability. Usually database pages are not flushed at commit time, because they can be recreated from the logs that were flushed if there is an application failure. The extra cost of flushing the pages at the end is usually made up by the savings in not having to flush so many logs to disk, but since you are using DB_TXN_NOSYNC, the logs are not flushed synchronously anyway, so you loss the savings.
When populating a new database, DB_TXN_BULK does provide a lot of savings because it does not log the data that is inserted into the pages added to the database (although it still has to log that the page was created). In long transactions flushing the new data pages instead of logging all the insertions is faster. Data added to existing pages in the database still has to be logged, so the flag is not very useful for lots of updates of existing records.
On a related note, have you tried the Bulk API (http://docs.oracle.com/cd/E17076_02/html/programmer_reference/am_misc_bulk.html) to speed up populating the database?