When a transaction is committed on the source database, only new data is written to the Redo log. However for Oracle to apply these transactions on the destination database, the “before image” key values are required to identify the effected rows. This data is also placed in the trail file and used to identify the rows on the destination, using the key value the transactions are executed against them. This is a key consideration for data sizing for the trail files.

Important considerations for bi-directional replication

The customer should consider the following points in an active-active replication environment.

• Primary Key: Helps to identify conflicts and Resolve them.
• Sequences: Are not supported. The work around is use to use odd/even, range or concatenate sequences.
• Triggers: These should be disabled or suppressed to avoid using uniqueness issue
• Data Looping: This can be easily avoided using OGG itself
• LAG: This should be minimized. If a customer says that there will not be any LAG due to network or huge load, then we don’t need to deploy CRDs. But this is not the case always as there would be some LAG and these can cause conflicts.
• CDR (Conflict Detection & Resolution): OGG has built in CDRs for all kind of DMLs that can be used to detect and resolve them.
• Packaged Application: These are not supported as it may contain data types which are not support by OGG or it might not allow the application modification to work with OGG.

OGG can be installed on ACFS

No, OGG binaries are not supported on DBFS. You can however store parameter files, data files (trail files), and checkpoint files on DBFS.