Update-anywhere replication is the replication of changed data from either a replication source table or a replica target table defined in a replication subscription. Unlike one-way replication, the target table (the replica) can be updated and the Capture program at the target server captures the changes and the Apply program pushes the changes back to the replication source at the source server. Updates to all of the replicas in a replication subscription are replicated together.
With the Capture program running at both the source and target servers, changes against the original user table (the replication source object) and its updateable copy (replica) can both be captured, and the Apply program then replicates these changes from one server to the other to maintain data currency. This is also true for a one-to-many configuration (one source table to many replicas); changes to the replication source table can be copied to all of its replicas, and changes to any of the replicas can be copied to the replication source table. The changes are then copied to all other replicas.
Figure 12 shows a basic update-anywhere replication model. Changes are originated at both the source and replica tables.
Figure 12. Update-Anywhere Replication. Update-anywhere replication is used to replicate changes from both the source and target servers.
Assessing the suitability of update-anywhere replication for your application is not so much a matter of looking for replication features as it is deciding what sort of anomalies are tolerable to your applications. Is it acceptable that sometimes updates are lost? If so, then you can turn off conflict detection and save processing cycles. Is it acceptable that occasionally a transaction is rejected and automatically compensated? These are the questions you need to ask, and include in your application design process.
The same-row conflict check done by the Apply program is only as good as the information provided. Updates that have not been captured are unknown to the Apply program, escaping the conflict check. Because the Capture program is asynchronous from the user transactions, there is a cost/risk decision that must be made. The cost is the availability of the table for update. The only way for the Capture program to synchronize with your updating applications is to block your updating applications until it has captured all outstanding updates. Taking table level locks on production tables has a negative impact on your production system.
The alternative to synchronizing with the application is to look at the risk of a conflicting update occurring during the Capture program latency window, and at the risk of losing the occasional update. Some customers say that losing some updates is not a problem (For example, one application was a hotel reservations system where rooms are over booked as routine practice), and others design their update cycle so that there is no possibility of conflict.
The Apply program detects update conflicts, after they occur, during the subscription cycle. When transactions are rejected, the Apply program compensates the transactions at the replica.
The replication source is considered the primary, or global table. It can receive updates from replicas, but if there is a conflict, the replication source wins and the replicas' conflicting transactions are rejected. An update conflict occurs when an application and one or more replicas try to update the same version of a row in a table at different locations or when constraints are violated. Direct row conflicts are detected by comparing the key values in the CD tables with the source and target tables. If any match is found, the replica unit of work is marked as rejected in the UOW table and the transaction is compensated.
Conflict detection cannot detect read-dependencies. If, for example, an application reads information that is subsequently removed by compensation, the dependency cannot be detected.
Conflict detection is provided at three levels: no detection, standard detection, and enhanced detection. Each level has a numerical value and is stored in the CONFLICT_LEVEL column of the register control table. You must decide, based on your tolerance for lost or rejected transactions and performance requirements, which type of detection to use.
By using rejection codes provided in the UOW table, you can identify the before and after row values in the change data table for each rejected transaction. When the Apply program compensates the rejected transactions, you must decide how to handle the rejected transactions. The ASNDONE user exit notifies you when the subscription cycle is completed, regardless of whether there are conflicts or rejected transactions. You can have your application handle the rejected transactions and have the Apply program run your application logic in the ASNDONE user exit. See the Capture and Apply chapter in this book for your platform for more information on the Apply program ASNDONE exit. You can choose to handle the rejections in batch; the change data rows and UOW control table rows for rejected transactions are exempt from normal pruning. They are subject only to RETENTION_LIMIT pruning.
The following suggestions for handling the rejected transactions have not been tested in user environments and should be used as suggestions:
Because update-anywhere replication requires referential integrity, CCD tables are not used in update-anywhere replication. CCD tables stage data and transactions are condensed. In update-anywhere replication, every transaction update should be replicated to the target server in the original order it occurred, which does not occur with CCD staging tables. Additionally, there may be triggers defined which rely on reading each update. Because you want to synchronize the source and target servers as up-to-the-minute as possible to detect update conflicts, you want to prevent the delays imposed by CCD staging. If you defined an internal CCD at the source server, it is ignored by the Apply program when processing a subscription with a replica as a target.
To reduce the risks of conflicts and cost of rejected conflicting transactions, use update-anywhere replication under the following conditions:
The following list describes restrictions for update-anywhere replication:
If referential constraints that exist among the source tables are omitted from the corresponding set of replicas, an update made to a replica could result in an RI violation when replicating the update to a source table.