Feature: Support for Direct Insert

[bersler]

Is your feature request related to a problem? Please describe.
When the source database contains transactions which include INSERT /+APPEND/ they are ignored by OpenLogReplicator.

Describe the solution you'd like
Such transactions could be fully supported.

Describe alternatives you've considered
Not to use Direct Insert and use regular insert instead.

Additional context
Sometimes such transactions are generated by the application. It might not be always possible to change the application source code to avoid transactions using Direct Insert.

[bersler]

This feature is complicated to implement.. If there is a demand from users more focus could be given here.

[sonnguyen-dba]

Hi Adam,
I'm waiting this feature.

Regards,
Son

[bersler]

Thanks Son for feedback. This feature is quite complex to implement. Direct load just puts fully prepared disks blocks with table data to the redo log stream. To be able to replicate such events would require to make an additional parser which I capable of parsing regular disk blocks. I personally find this very useful. Many applications just use direct load and there is no way to change the application code to switch to regular insert operations.

[marlon-costa-dc]

Reflecting further on the challenge presented by transactions using INSERT /+APPEND/ which are currently ignored by OpenLogReplicator, I suggest a targeted approach for enhancing data capture capabilities. Specifically, as I commented previously in issue #[52], this involves reading data directly from the source database. However, I recommend refining this strategy to focus exclusively on transactions that are incompatible with OpenLogReplicator's existing framework.

This refined approach would involve implementing a mechanism to identify and selectively capture only those transactions employing Direct Insert methods, which are not presently supported. By doing so, we can maintain the efficiency and performance of OpenLogReplicator for transactions that are already compatible, while extending its functionality to include previously unsupported transaction types.