Re: advanced queuing

Thank you for the information, I'll be saving this.

Dave
On Sat, Aug 04, 2001 at 10:53:31AM -0700, A. Bardeen wrote:
> 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: 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).