Replication Independence

Replication is the ability of a database to create copies of a master database at remote sites. These copies are sometimes called snapshots and may contain the whole database or any subcomponent of the database.
For example, in a relational database, a CUSTOMER table may be snapped to many remote sites for read-only query.
Subsets of the CUSTOMER table may be specified, requesting only specific rows and columns, and these replications are refreshed on a periodic basis.

The Publish/Subscribe Model for Oracle Replication is a more flexible method for replication than was the Oracle7 snapshot replication.Oracle advanced queuing has initiated a new replication model dubbed "publish/subscribe" that differ from the traditional replication model in a very important way.

The sender of the replicated data (called the "publisher"), does not have to know anything about what's-up on the receiver-side (called the "subscriber"). With replication independence we no longer have to complex feed and verify procedures and the dbms_aq package allows some interesting replication functions: listen Procedure The new dbms_aq.listen procedure allows you to "listen" for incoming messages (rows), just as-if you were the registered subscriber. The listen procedure has a newer input parm method, agent_list) which is a Oracle abstract data type (ADT):

agent_list IN AQ$_AGENT_LIST_T,
wait IN BINARY_INTEGER DEFAULT DBMS_AQ.FOREVER, 
agent OUT SYS.AQ$_AGENT);

In order to meet the replication independence objective, a distributed system must provide a means of maintaining copies of the same data (i.e., tables) at multiple sites. The reasons to replicate include performance gains and failover capability, to name a few. The challenge with providing replication independence is that when data is changed, the change must propagate to all replicas, as soon as possible. Users and applications should not be concerned with how their changes to a replicated table are propagated or whether their version of the table is up to date. Technically, replication independence requires that changes be propagated to all sites and committed as a single transaction using the two-phase commit protocol. However, enforcement of this stipulation can defeat the purpose of replicating in the first place since the additional communication required impacts performance and since processing is halted if any site is unavailable.