|
|
|
A collision in a replicated database occurs when changes are made to the same record in different databases participating in the same CDDS. In a collision condition, Ingres Replicator cannot synchronize the databases without destroying information. The Replicator Servers can detect this collision condition when the data is transmitted between the two databases. For more information, see Collision Design.
|
|
|
Suspected collisions in the Ingres Replicator system can be detected from these sources:
|
|
|
Because of the overhead involved, the Replicator Server by default does not look for collisions or attempt to resolve them. You can control collision detection and resolution through CDDS collision modes. If a collision does occur, the Replicator Server identifies the condition as an error. For example, the server issues errors such as:
The target record cannot be found in the target database or
or
A primary key was already in the target database for an insert transaction.
If you find these types of errors in the replicat.log file, this indicates a collision condition.
|
|
|
If you suspect that a collision has occurred, run the Queue Collision Report available through Visual DBA or the Resolver option of Replicator Manager. This option looks at the distribution queue of the source database to see if any collision conditions exist. The report displays problems that exist in the current distribution queue and its target databases. For more information, see Viewing Collision Conflicts in online help or Queue Collision Report.
|
|
|
There are two ways to handle collisions—automatic or manual. Each method has advantages and disadvantages. Automatic resolution (using the Ingres Replicator collision mode settings) takes less time but can produce unexpected results. Manual resolution gives you more control and, in some cases, is the only way to resolve a conflict.
To resolve the condition, you must restore consistency to the base tables of the source and target database as well as to the replicated transaction keys in the shadow tables. Replication operations (insert, update, delete) that caused the collision must also be removed from the distribution queue.
|
|
|
You can resolve collisions manually in the following ways:
Visual DBA: You can resolve collisions manually by expanding the Replication branch and expanding the branch of the desired database and clicking the Collisions tab. For more information, see the online help topic Resolving Collisions Manually. 
Command Line: To resolve a collision manually, follow these steps:
The key that you select must be the replicated transaction key of one of the records in collision.
Note: This disables the Change Recorder for your session only.
|
|
|
With automatic resolution, when two records collide, one record prevails over the other. If the operation was an insert or an update, a record survives a collision by overwriting the record in the target database (the target row is deleted and the prevailing source row is inserted in its place). If the transaction was a delete, the record in the target database is deleted. If a record does not survive a collision, its replication operation (insert, update, or delete) for that target is removed from the distribution queue.
Note: Automatic resolution overwrites the entire record and can overwrite columns that have correct information with columns that do not have correct information. You must not use automatic resolution if the information contained in the losing record is important. For example, if your database contains documents that are continually updated with new information, you can lose information with automatic resolution.