Buffered queues were introduced in 10.1 so that’s one of the places I would expect a change. These were used by Streams but some part(-s) of the new code path could have end up for user enqueued messages as well.

Unfortunately, even with a new codepath, the Apply server remained on a row-by-row processing. It’ll be interesting to see whether this approach provided a better return as opposed to, say, introducing bulk processing which is something that Oracle GoldenGate can do already.

On a side note… Something similar happened to AQ as well. At the beginning the operartions used to insert/delete entries from a queue were based on regular SQL statements. At some point in time (don’t remember the version…) some of the operations were replaced by other code paths that were no longer using SQL statements. As you correctly pointed out, performance are better but profiling is no longer that easy…

Cheers,
Chris

this Metalink Note explains the feature where the Capture process can communicate directly with the Apply process (most probably through an IPC calls). This is relevant as far as data transport is concerned (i.e. you do not stage LCRs in the queue) but doesn’t really (or have to) affect the way the Apply server executes the LCRs. Indeed, the combined capture and apply appeared in 11.1.0.6 but Apply in this version still used the “classic” codepath for LCRs executions.

I’ve seen a note on the MOS called “Combined Capture and apply” (463820.1) – though it’s for 11gR1 maybe this is what you’ve discovered.