Dave,
Benchmarking is very difficult with replication as
it's very dependent on the data involved and since
every db is different it makes it very hard to compare
apples to apples. Tx propagation rates are pretty
useless as all tx's are not equal. Is the data
involved in a tx that adds a new customer the same as
a tx that changes the quantity for one line item in an
order? Put a different way, a single transaction can
affect one row or a million rows, so all transactions
are not equal.
The best thing to look at is the number of calls
propagated as a transaction that affects 100 rows will
result in 100 calls. Even then all calls are not
equal as it depends on the structure of the tables
involved.
I'm pretty sure a couple of the sites I've worked with
were achieving close to 1000 calls per minute, but I'm
going from memory so I'll see if I can find my notes
when I'm in the office and post them later.
It all boils down to a matter of proper design,
configuration, and tuning. IMHO the ratios should be
60% planning and design; 30% setup, configuration, and
testing; and 10% maintenance. People who don't do
enough work in the first two phases, inevitably pay
for it in terms of administration problems and poor
performance.
Some specific issues needing to be considered for
performance in a replication environment (in no
particular order) are:
- The design of the application is especially crucial
to achieving good performance. The amount of data
replicated needs to be kept to the absolute minimum
and this often entails altering the structure of the
replicated tables and hence the application.
- Conflict avoidance and resolution. Conflicts are
an extremely expensive operation to perform so to
achieve good performance you need to design the
application so that conflict is avoided (i.e. so that
in most, if not all, cases DML on a given row is
performed at only one site). If a conflict cannot be
avoided, then it should be resolved automatically so
that subsequent transactions dependent on this one do
not fail. Designing for conflict avoidance and
resolution requires a very thorough understanding of
the business rules governing the data.
- High transaction rates mean a lot of activity in
the deferred transaction queues so they should be
relocated into their own tablespace to minimize I/O
contention.
- The judicious use of connection qualifiers allows
transactions affecting different replication groups to
be pushed to the same site at different intervals.
- Adequate physical resources are needed. The
network needs to support the increased load without
latency or failures. Enough CPU power must be
available to allow greater levels of parallel
propagation.
- When replicating lobs, piecewise lob updates should
be done to avoid replicating the entire lob.
- Column groups need to be properly defined so that
optimal use of the "min communication" and "send and
compare" features minimizes the amount of data being
replicated. As with conflict avoidance and
resolution, this requires a thorough understanding of
the business rules.
- Change control needs to be tightly tested and
controlled. Something as simple as adding a single
column to a replicated table can drastically affect
the replication environment.
These are only a few things that come to mind, but
this should give you a good idea. Perhaps others
running replication can contribute their experiences.
HTH,
- Anita
- David Turner <turner_at_tellme.com> wrote:
> Thanks, yes I spoke with a guy that said they were
> replicating 250 transactions a second
> using AQ, which sounded fishy. I have heard of 800
> transactions per minute on Oracle as
> being high.
>
> Dave
> On Fri, Aug 03, 2001 at 03:36:01PM -0700, A. Bardeen
> wrote:
> > Dave,
> >
> > Oracle's Advanced Replication uses AQ as the
> > propagation mechanism for asynchronous parallel
> > propagation (serial and synchronous use the
> two-phase
> > commit process). Or are you asking if anyone has
> > written their own custom replication using AQ?
> >
> > HTH,
> >
> > -- Anita
> >
> > --- David Turner <turner_at_tellme.com> wrote:
> > > Is anyone out there using advanced queuing for
> > > replication?
> > >
> > > Dave
> > > --
> > > Please see the official ORACLE-L FAQ:
> > > http://www.orafaq.com
> > > --
> > > Author: David Turner
> > > INET: turner_at_tellme.com
> > >
> > > Fat City Network Services -- (858) 538-5051
> FAX:
> > > (858) 538-5051
> > > San Diego, California -- Public Internet
> > > access / Mailing Lists
> > >
> >
>
> > > To REMOVE yourself from this mailing list, send
> an
> > > E-Mail message
> > > to: ListGuru_at_fatcity.com (note EXACT spelling of
> > > 'ListGuru') and in
> > > the message BODY, include a line containing:
> UNSUB
> > > ORACLE-L
> > > (or the name of mailing list you want to be
> removed
> > > from). You may
> > > also send the HELP command for other information
> > > (like subscribing).
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute
> with Yahoo! Messenger
> > http://phonecard.yahoo.com/
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: A. Bardeen
INET: abardeen1_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Sat Aug 04 2001 - 13:07:48 CDT
