Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

Note

To view the conflicts, please see Viewing the conflicts

 

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:

No Format
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
actually did change something, i.e. only if it updated/deleted more than one row. (For any other
conlict
conflict: either Oracle rolls the statement back automatically due to an ORA- error or the conflict was 0 rows
updated -
updated – thus no change was actually done.)
OVERWRITE

Try again, not checking the old (source) values in the where clause. This overwrites the target database with the values from the source database.

The OVERWRITE handler is used for conflicts with UPDATE statements.

OVERWRITE works by using only Primary Key (PK) columns in the where clause. If the record to be updated is still not found on the target (by using only the PK columns in the where clause), the UPDATE cannot proceed and OVERWRITE will have no effect.

RETRY
Try again.
ABORT
Abort the
apply
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

Listing of the conflict with the LIST CONFLICT command

To see the SQL and other details of the transaction that is causing the conflict:

Section
Column
width5%

 

Column
width95
Panel
bgColorCCC

dbvrep> LIST CONFLICT

or by specifying the actual conflict id

Section
Column
width5%

 

Column
width95
Panel
bgColorCCC

dbvrep> LIST CONFLICT 345

...

.

...

DBRSAPPLY_CONFLICT_LOG

This lists all the conflicts encountered, including failing SQL.

The column SQL_TEXT contains the actual SQL statement that is run against the target database and includes the bind variables. 

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.

2-Way Replication

By default all commands in the Dbvisit Replicate console work with the default processes MINE and APPLY. The choose CHOOSE replication command is useful when working with 2-way replication where there are multiple processes such as MINE, APPLY, MINE1 and APPLY1. Note that the

Note

The CHOOSE REPLICATION command selects all processes for the indicated replication (so both

...

MINE and

...

APPLY processes).

 

Example:

Panelnoformat
bgColorCCC
dbvrep>dbvrep> CHOOSE REPLICATION MINE1

 The above command will choose the replication pair that is associated with MINE1. Typically this is MINE1->APPLY1. Note that the CHOOSE REPLICATION


Note

The CHOOSE REPLICATION command is needed prior to issuing commands to display, resolve and set conflicts for the APPLY1 process.