The response to a conflict can be configured before the conflict occurs. This is done with conflict handlers. The configuration can be specified for each replicated table and for each operation type separately, and for the special case ("data" divergence) when zero or more than one row are affected. The Dbvisit Replicate command to set conflict handlers is SET_CONFLICT_HANDLERS.
The options for conflict handles are as follows:
Operations | "NO_DATA" and "TOO_MANY" handlers | "Error" handler |
---|---|---|
Update | discard | force | retry | overwrite | pause | abort | newer | older | plsql | sql | error | discard | retry | overwrite | pause | abort | plsql | sql | error |
Delete | discard | force | retry | overwrite | pause | abort | newer | older | plsql | sql |error | discard | retry | overwrite | pause | abort | plsql | sql | error |
Insert | n/a | discard | retry | overwrite | pause | abort | plsql | sql | error |
Transaction | n/a | discard | retry | overwrite | pause | abort | plsql | sql | error |
The transaction handler is used for errors in DDL and during commit/rollback.
The update handler also covers LOB operations.
The "NO_DATA" and "TOO_MANY" handler is used only once for a conflict – if using this handler leads to a conflict again, "Error" handler is used for the next attempt. For the next change SQL, the Data conflict will be used again.
Additionally, logging may be specified:
- log: the conflict is logged, and a error plog is created with the offending statement
- nolog: the conflict is not logged
- fast_nolog: the conflict is not logged and it may be omitted from conflict counters altogether
- log_transaction: the conflict is logged, and a error plog is created with the offending transaction
- default: same as log
See the Command Reference or use HELP SET_CONFLICT_HANDLERS for the exact syntax.
Use SHOW_CONFLICT_HANDLERS to query current settings of handlers.
dbvrep> SET_CONFLICT_HANDLERS FOR TABLE SCOTT.AVI_OBJECTS FOR UPDATE ON NO_DATA TO OVERWRITE
Source tablename is used while setting conflict handlers.
To show what the conflict handler has been set to:
dbvrep> show_conflict_handlers for table scott.avi_objects
The table called SCOTT.AVI_OBJECTS on source is handled on apply as follows:
UPDATE (error): handler: RETRY logging: LOG
UPDATE (no_data): handler: OVERWRITE logging: LOG
UPDATE (too_many): handler: OVERWRITE logging: LOG
DELETE (error): handler: RETRY logging: LOG
DELETE (no_data): handler: RETRY logging: LOG
DELETE (too_many): handler: RETRY logging: LOG
INSERT (error): handler: RETRY logging: LOG
TRANSACTION (error): handler: RETRY logging: LOG
Note that previous versions used the DATA handler instead of NO_DATA and TOO_MANY. For compatibility reasons, this is still supported - specifying DATA handler sets both NO_DATA and TOO_MANY handlers.
For 2.3.18 and before: Note that the handler is executed AFTER the conflicting statement was run and thus any changes done by the statement are still in effect. This is important to consider especially for TOO_MANY handler.
For 2.3.20 and later: For TOO_MANY error, the conflicting statement is rolled back before retry etc. This brings a new conflict resolution: FORCE. While FORCE keeps the effect of the conflicted statement (multiple rows changed), IGNORE/DISCARD rolls the statament back and thus no change is applied.