Handling errors on source database, partially executed statements

Owned by Arjen Visser
Last updated: Dec 09, 2013
1 min read

The MINE (and then APPLY as well) process follow the changes as they are written to redo logs by Oracle. This also defines it's (sometime peculiar) behavior in case of errors, statement rollbacks, statement restarts etc. In general:

  • Oracle handles these cases in transaction-consistent way, and so do MINE and APPLY. Thus after a commit (and thus to any other session as well), the data is in sync with source.
  • However, Oracle writes to redo in an optimistic way – and thus in case of an partial execution followed a statement or partial rollback of a statement, the data is actually written to the redo logs and thus replicated as well.
  • This means, in consistence with usual behavior on source, triggers can execute on data that are later rolled back. See for example discussion on one way how can this happen at write "consistency" at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:11504247549852
  • One interesting case of this behavior is (primary, unique) key checking – Oracle first writes the row data, then goes on to update the index, failing on key violation, then rolls back the row change. The consequence is that APPLY also updates the row and if the key is present on APPLY database as well, it will also fail, causing a conflict. But this conflict is usually automatically resolved as the APPLY sees the change is going to be rolled back.