If the apply was paused due to a conflict, or it is retrying in a loop the same SQL again and again, you can instruct it about what to do next using the command:
RESOLVE CONFLICT id AS resolution
The conflict id is the number shown in the status bar, the resolution can be one of the following:
IGNORE | Skip the change (the conflicting statement is rolled back) |
FORCE | Skip the change (the conflicting statement is kept applied) - this is different from IGNORE only if the statement acutally did change something, i.e. only if it updated/deleted more than one row. (For any other conlict: either Oracle rolls the statement back automatically due to an ORA- error or the conflict was 0 rows updated - thus no change was actually done.) |
OVERWRITE | Try again, not checking old values in the where clause |
RETRY | Try again |
ABORT | Abort the apply whole process |
RESTART | Rollback and restart the transaction |
ROLLBACK | Rollbacks the transaction |
IGNOREALL | The current and future conflicts in the same transaction will be resolved as ignore |
To see the SQL and other details of the transaction that is causing the conflict:
dbvrep> LIST CONFLICT
or by specifying the actual conflict id
dbvrep> LIST CONFLICT 345
It is also possible to obtain the conflict information directly from the Dbvisit Replicate schema. Logon to the apply (target database) as the Dbvisit Replicate schema owner (dbvrep) and query table:
DBRSAPPLY_CONFLICT_LOG
This lists all the conflicts encountered, including failing SQL.
Global default conflict handler
The default global setting for conflicts is "retry". This means that the operation will keep trying the operation until a manual change is made on the target to resolve the conflict. The default global setting for a conflict can be changed with the SET_CONFLICT_HANDLERS FOR DEFAULT command. See the Command Reference or use HELP SET_CONFLICT_HANDLERS for the exact syntax.