Update conflicts happen when two transactions that originate from different databases update the same row at nearly the same time. An example of this conflict type is when two transactions originate from two different databases, and each one inserts a row into a table with the same primary key value.Īn update conflict occurs when Replicat applies an update that conflicts with another update to the same row. Conflicts occur when the timing of simultaneous changes results in one of these out-of-sync conditions:Ī uniqueness conflict occurs when Replicat applies an insert or update operation that violates a uniqueness integrity constraint, such as a PRIMARY KEY or UNIQUE constraint. Conflicts should be identified immediately and handled with as much automation as possible however, different business applications will present their own unique set of requirements in this area.īecause Oracle GoldenGate is an asynchronous solution, conflicts can occur when modifications are made to identical sets of data on separate systems at (or almost at) the same time. Uniform conflict-resolution procedures must be in place on all systems in an active-active configuration. See Section 9.3.1.1.įor more information, see Reference for Oracle GoldenGate for Windows and UNIX. You can choose which of these to ignore when you configure Extract. You can also use the transaction name or userid of the Replicat user to identify Replicat transactions. If you are excluding multiple tags, each must have a separate TRANLOGOPTIONS EXCLUDETAG statement specified. The following shows how EXCLUDETAG can be set in the Extract parameter file:
The following shows how SETTAG can be set in the Replicat parameter file: The logmining server associated with that Extract excludes redo that is tagged with the SETTAG value. Use the TRANLOGOPTIONS parameter with the EXCLUDETAG option in the Extract parameter file. For more information about tags, see Reference for Oracle GoldenGate for Windows and UNIX. Valid values are a single TAG value consisting of hexadecimal digits. Replicat tags the transactions being applied with the specified value, which identifies those transactions in the redo stream. Use DBOPTIONS with the SETTAG option in the Replicat parameter file. When Replicat is in classic or integrated mode, you use the following parameters: There are multiple ways to identify Replicat transaction in an Oracle environment. (Note: For Oracle targets, if Replicat is in integrated mode, constraints are handled automatically without special configuration.) This reverses the logical order of a cascaded delete but is necessary so that the operations are replicated in the correct order to prevent "table not found" errors on the target. Create it as a BEFORE trigger so that the child tables are deleted before the delete operation is performed on the parent table. See Installing and Configuring Oracle GoldenGate for Oracle Database.ĭisable ON DELETE CASCADE constraints and use a trigger on the parent table to perform the required delete(s) to the child tables.
Parameter options are available for a nonintegrated Replicat for Oracle. If the target is an Oracle database, Replicat handles triggers without any additional configuration when in integrated mode. Modify triggers to ignore DML operations that are applied by Replicat.
To prevent the local DML from conflicting with the replicated DML from these operations, do the following:
Triggers and ON DELETE CASCADE constraints generate DML operations that can be replicated by Oracle GoldenGate. DDL support is available for Oracle and Teradata databases. Oracle GoldenGate supports DDL replication in an Oracle active-active configuration. Oracle GoldenGate supports active-active configurations for: Bidirectional synchronization is supported for all database types that are supported by Oracle GoldenGate. It can be used for disaster tolerance if the business applications are identical on any two peers. This configuration supports load sharing. Data captured by an Extract process on one system is propagated to the other system, where it is applied by a local Replicat process. In a bi-directional configuration, there is a complete set of active Oracle GoldenGate processes on each system. Oracle GoldenGate replicates transactional data changes from each database to the other to keep both sets of data current.ĭescription of the illustration simple_config_bidirectional.jpg Oracle GoldenGate supports an active-active bi-directional configuration, where there are two systems with identical sets of data that can be changed by application users on either system. 9.1 Overview of an Active-active Configuration