READ ME Before you decide to use IKM Oracle Multi-Insert in ODI 12c

Question

Ok, I've decided to write this to help out others who may be heading down this twisted mess and hope they can benefit from my pain.
If using a sequence, do not use this IKM.
The primary reason is Oracle's INSERT ALL statement is NOT atomic.  This means it WILL eventually give "ORA-02291: integrity constraint (XXX) violated - parent key not found" when it attempts to insert rows into the child table first.  To make it work, the constraint(s) in question must be disabled or set to deferred.  However, if either is done, there is no need to use the INSERT ALL because the multiple inserts can now be done in any order without error as long as everything is kosher at the time the constraint is enabled or set to immediate.  So the very fix for the IKM makes its use unnecessary.
The second reason is it burns sequence numbers.  The IKM has a tendency of grabbing the filter (no matter how buried) right before it and putting it in the WHEN statement of the INSERT ALL.  This will burn sequence numbers because the rows are not filtered prior to being feed into the insert.  Not an issue for small rowsets, but for large rowsets or frequently run mappings the burn can be quite substantial.  This can be fixed by manipulating hints and/or the physical tab, but may result in poorer performance than just using a different IKM that doesn't burn sequence numbers.
If you are doing anything else besides the multi-insert in the same mapping, beware!  This IKM does not allow ODI to respect the Target Load Order specified on the mapping.  I've found that it usually puts the multi-insert last in sequence.  It can be fixed by working on the physical tab, and making multiple targets but it also crashed several times when I was using it.  Additionally it resisted doing what seemed like simple tasks (like dragging multiple items at a time or trying to drag items off to the right of the execution units).  As I've said elsewhere, I think this is a bug and it will probably be fixed in the future.
So my advice is avoid using this IKM at all costs.  Just disable or defer your constraints and use the other IKMs.
BTW, if you want to defer the constraints, I've found you can set the On Connect command of the Physical topology to:
ALTER SESSION SET CONSTRAINTS = DEFERRED
and then select all the transactions in the list.  Trying it in the Begin Mapping Command of the mapping does not appear to work.
Please let me know if I got anything wrong,
Scott

Answer 1

This is not the first instance of KM load strategy that has had the nasty side effect of burning sequence numbers - see the following:
ODI Oracle Merge Incremental Update burns sequence values - jason's hyperion blog
However, at least this one does now seem to have been modified to try and address this issue.