Learn about the issues that must be considered when using an Oracle replicate data server.
In ECDA Option for Oracle version 12.0 or later, an additional trace flag allows the replicate Replication Server to control transaction commit boundaries when applying transactions to an Oracle replicate database.
Setting the value of the ECDA autocommit trace flag to 0 (zero) in the ECDA Option for Oracle configuration file allows Replication Server to control when a COMMIT command should be sent to Oracle. When the value of the autocommit trace flag is not set, ECDA Option for Oracle commits each individual operation (INSERT, UPDATE, and DELETE) sent by the replicate Replication Server.
Having ECDA commit each operation causes a problem at the replicate database if an error occurs in the middle of a multiple operation transaction. The replicate Replication Server may attempt to re-send the entire transaction, while ECDA has already committed each individual operation. To avoid this problem, set the value of the ECDA autocommit trace flag to 0 (zero).
In ECDA Option for Oracle 15.0 ESD#3, set the rep_sparse_parse configuration parameter to 1. This prevents SQL statements in Oracle syntax, sent from Replication Server directly to Oracle, from being parsed by ECDA Option for Oracle. This not only improves performance but is also required for using the flashback replication feature.
When rep_sparse_parse parameter is set to 0, some of the DDL and DML SQL statements sent by Replication Server are parsed and changed by ECDA Option for Oracle. For example, when ECDA Option for Oracle receives a DDL statement drop table <table_name> from Replication Server, the DDL statement is parsed by ECDA Option for Oracle and changed to drop table <table_name> purge. This change should not take place if you want the replicate database recycle bin to be synchronized with the primary database recycle bin. This issue can be avoided by setting the value of rep_sparse_parse to 1.