Re: Symmetric Replication

Phil Melendez wrote:
>
> All,
>
> I have recently been tasked to implement a Symmetric Replication
> environment for a client. I have attended the 5-day SymRep
> course provided by Oracle and have just finished reading Oracles
> white paper on "Strategies and Techniques for Using Oracle7
> Replication". I had a couple of questions and was hoping someone could
> provide answers/opinions or direct me to the appropriate sources.
>
> o What are the potential issues/"gotchas" involved with the
> following
> configuration.
>
> - One (1) master site (Corporate Site) and 50-75 updatable
> snapshot sites (Remote
> Stores)
> - OLTP environment
> - Different timezones
> - 56K - T1 network connections to Corporate site
>
> o I noticed on page 25 of Oracles white paper "Strategies and
> Techniques for Using Oracle7 Replication" references to
> to a snapshot administrator and to grant_admin_repschma
> and was wondering if thesewere still the way to go if
> I was using Oracle 7.3.2.2. If not was is the correct
> usage.
>
> o Is there more information available on Symmetric Replication
> in general and Symmetric Replication implementation issues
> specifically.
>
> Thank you for your time in answer these questions.
>
> Regards,
>
> Phil Melendez

Phil,

I can elaborate on my recent experiences configuring and implementing Oracle's symmetric replication in a world-wide OLTP application.

Issues which need to be addressed are:

1. N-Way master configuration versus updateable snapshots

We initially started the project utilizing 7.1.3 and with the intent to implement a hybrid configuration with 2 master sites and 5 updateable snapshot sites. We experienced many problems with the updateable snapshot environment, including on-line instantiation of the updateable snapshots. Our snapshots were very large and our communication lines proved less than adequate (fractional T-1). The initialization of the updateable snapshots involved a complete refresh from the associated master site. This proved both unrealistic and given the snapshot sizes and communication reliability impossible. Additional areas of concern are refresh rates associated with each snapshot, initially we had configured the snapshots to be refreshed every 30 seconds, once again, unrealistic and impossible. We also noted a very large amount of redo being generated because of Oracle internal "housekeeping" procedures. We have since implemented an N-Way master configuration with 7 master sites, which asynchronously replicate the majority of our deferred transactions with a scheduled execution interval of 2 minutes.

2. OLTP applications/throughput/transactions/size of transactions:

Replication works well with small transactions, fast and reliable communication throughput, and applications which are query intensive versus update intensive. This is especially true with delete transactions. The conflict resolution routines rely on a combination of latest/earliest timestamp and site priority when utilizing an N-Way configuration to guarantee convergence. Deletes need to be handled by the application as Oracle does not provide a COTS package for delete conflict resolution.

3. Disaster recovery - This provides a large challenge to the database administrator, involving synchronization of global databases and the timing involved for recovery of a single site. All deferred transactions are queued for 2PC to the remote maste site in an N-Way configuration. The amount of time to resolve/converge all data is again dependent upon the number of transactions and given throughput and the state of the entire system. In an updateable snapshot scenario, changes are queued into the snapshot log at the master site and the updateable snapshot site would be refreshed when the site became available.

As you can see, I could spend a great deal of time documenting our experiences and recommendations; hopefully, Oracle can provide you with additional insight into the envioronments.

We are currently operational under 7.3.2.2/ Solaris 2.4.

Any additional questions please E-Mail me directly: mclaughl_at_disagate.tinker.af.mil

Jim McLaughlin Received on Mon Mar 03 1997 - 00:00:00 CET