Document ID:	    33516.1
Subject:            Overview of Asynchronous Replication
Last Revision Date: 13 May       1996
Author:             toscroft


SYMMETRIC REPLICATION
---------------------

The example used will be for symmetric replication set up between
two databases:

MASTERDEF - DB1: This is where all administration activity has to be
                 performed eg: altering replicated tables, adding new
                 objects.

MASTER - DB2:    This site will have changes on its replicated tables 
                 propagated to DB1 but no administration of replicated
                 objects can be performed from this site.

Replication Support
-------------------

When a table is registered for replication (usingdbms_repcat.create_
master_repobject/dbms_repcat.generate_replication_support) a trigger is created 
on the table and two packages are generated. One  of these packages is used to 
generate the information necessary to create a remote procedure call. The other 
handles conflict resolution (necessary when updates are made to the same row 
from different sites).

Once all replicated objects have been created and the replicated schema has
a status of 'NORMAL' in dba_repcat then replication of transactions against
replicated table can start taking place.

Sequence of Events
------------------

An insert, update or delete from a replicated table will fire a trigger
which extracts and stores the information necessary to create a remote      
procedure at the remote site. The table, defcall, will hold the transaction id, 
the callno (ie: the statement within the transaction) and the compressed 
arguments as well as the names of the originating and destination databases (to 
prevent the statement being replicated back). There will be an entry for each 
statement within the transaction.

The arguments which are stored in defcall can be extracted by using the
packages dbms_defer_query.get_arg_type followed by dbms_defer_query.get_ 
<datatype>_arg.

Replicating Transactions
------------------------

Transactions are pushed to the remote site by the package 
dbms_defer_sys.execute(), which takes the fully qualified database name of
the remote site (eg: DB2.WORLD) as an argument. 

By default, the entire contents of defcall will be pushed to the remote site. 
It is possible to configure dbms_defer_sys.execute to scan only part of defcall 
by telling it to send only a certain number of transactions or to only scan a 
certain number of bytes of the table.

Automatic replication takes place using the job queue mechanism. Executing
dbms_defer_sys.schedule_execution (with the same arguments as dbms_defer_sys.
execute plus an interval) will put the job in the job queue. The job queue 
processes (job_queue_processes 7.2 onwards, snapshot_refresh_ processes before) 
will wake up at the pre-configured interval to check whether there are any jobs 
which need executing. Any which do need executing will be ordered according to 
the time at which they should be executed. 

A remote procedure call is built which will apply the transactions sent to
the remote site in transaction order. If one transaction fails, an error will 
be written to deferror at the remote site, with full details so that it can be 
reexecuted when the problem is resolved, and the others will be applied.

If the remote site is down, the job will try to execute 16 times and then be 
marked broken; the transactions will be queued at the local site. When the 
remote site is accessible again, the job should be marked unbroken and the 
queued transactions will be pushed over.

Conflict Resolution
-------------------

If, replication applies the change remotely and finds that the content of the 
row is not what is expected then a conflict has occurred. Rows are located by 
the primary key:

1. Update - the old values of the local update do not match the remote     
   values.

   ORA 1403 is signalled.
   - a unique key is updated to the same value as an existing key.    

2. Insert - the key value of the new row already exists.
            
Conflicts are handled in one of three ways:

1. An error is written to the deferror table and the conflict is resolved 
   manually.
2. An ORACLE-provided conflict resolution routine is called to allow for 
   eg: the latest transaction to win.
3. A user-written conflict resolution routine is called.