Synchronous (Real-Time) Data Propagation
Asynchronous data propagation is the normal configuration for advanced 
replication environments. However, Oracle also supports synchronous data 
propagation for applications with special requirements. Synchronous data 
propagation occurs when an application updates a local replica of a table, and 
within the same transaction also updates all other replicas of the same table. 
Consequently, synchronous data replication is also called real-time data 
replication. Use synchronous replication only when applications require that 
replicated sites remain continuously synchronized. 


Note: A replication system using real-time propagation of replication data is highly
 dependent on system and network availability because it can function only when 
all system sites are concurrently available. 


Figure  1 - 12  Synchronous Data Replication Mechanisms
 
As Figure  1 - 12  shows, Oracle uses the same system of internal database triggers
 to generate RPCs that replicate data-level changes to other replication sites to 
support synchronous, row-level data replication. However, Oracle does not defer 
the execution of such RPCs. Instead, data replication RPCs execute within the 
boundary of the same transaction that modifies the local replica. Consequently, a 
data-level change must be possible at all sites that manage a replicated table or 
else a transaction rollback occurs. 

You can create a replicated environment with some sites propagating changes 
synchronously while others use asynchronous propagation (deferred transactions). 

Replication Conflicts and Synchronous Data Replication

When a shared ownership system replicates all changes synchronously (real-time 
replication), replication conflicts are cannot occur. With real-time replication, 
applications use distributed transactions to update all replicas of a table at the 
same time. As is the case in nondistributed database environments, Oracle 
automatically locks rows on behalf of each distributed transaction to prevent all 
types of destructive interference among transactions. Real-time replication 
systems can prevent replication conflicts. However, this type of system is highly 
dependent on system and network availability because it can function only when 
all system sites are available. 

When a shared ownership system replicates all changes synchronously (real-time 
replication), replication conflicts are cannot occur. With real-time replication, 
applications use distributed transactions to update all replicas of a table at the 
same time. As is the case in nondistributed database environments, Oracle 
automatically locks rows on behalf of each distributed transaction to prevent all 
types of destructive interference among transactions. Real-time replication 
systems can prevent replication conflicts. 

 1 ) Есть база банка БД1 в г. Москве и БД2 в г.Питере. Базы находятся в 
асинхронной репликации. Рассотрим таблицу счетов. Скажем у клиента 
Иванова на счету лежит реально  600 , 000 . 00  рублей. Эти данные есть в обеих 
БД.
 2 ) Упал канал в 15ч00мин на  2  часа
 3 ) В Москве в 15ч05мин приходит г.Иванов и получает  600 , 000 .00р. На счету у 
г.Иванова в БД1 0р. 
 4 ) В Питере в 15ч08мин приходит человек с доверенностью от г.Иванова на 
получение денег. Кассир честно лезет в БД2 и выдаёт человеку  600 , 000 .00р.
 5 ) В 17ч.00мин связь восстанавливается. В результате после перекачки 
отложенных транзакций получаем В БД1 и в БД2 на счету - 600 , 000 .00р или 
если программа умная скажет что неверная операция.
 6 ) Счастливые и довольные г.Иванов и его подельник едут отдыхать на Канары
 7 ) DBA по имени Сергей Минюров вызывает директор банка и молча кладёт 
пистолет на стол и выходит из кабинета.
 8 ) Конец