Re: Oracle Replication and Parallel Server

Thanks, Pete. I understand your confusion, but let me try to expound on the rationale being given to me....

1. The idea is that since MQSeries is not committing database transactions (per se), then it can handle the peak loads and the database transactions can be committed in due time. It is critical that the "work" be done very quickly (sub-second), but the "result" can be stored at a later time. In other words, the initial unit of work will not even update the database.
2. We must find something that can handle that kind of traffic... the platform is Solaris and we will have to scale to handle the load. I just want to validate (or reject) the proposed software architecture.
3. Thanks for the heads up on OPS. Seems like we can save some dough leaving out the clustering and parallel solutions.

Ajax

Pete Sharman <psharman_at_us.oracle.com> wrote in message news:37838072.856A6E8_at_us.oracle.com...
> Ajax
>
> There are a number of questions which arose in my mind on reading this,
and I
> can't give you a direct answer as a result. But here's some comments to
start
> out with:
>
> 1. If you're already using a messaging product (MQSeries), why even
bother
> looking at using another (which is what replication is under the covers)?
>
> 2. In any case, replication and probably MQSeries may not be able to
handle a
> load like 3 million hits per hour. Have you done any volume testing to
check
> this?
>
> 3. OPS is primarily an availability tool to my way of thinking. It can
give
> you higher performance as well, but I'd be surprised if the application
was
> designed with OPS in mind. In this case, you may end up with performance
> degradation if you're hitting OPS from multiple nodes.
>
> HTH.
>
> Pete
>
> Ajax wrote:
>
> > Looking for opinions (of which there has never been a shortage)
regarding
> > the appropriate use of Advanced Replication and Parallel Server in our
> > application architecture.
> >
> > Our database acts as the primary data store for a transactional queue
that
> > sits "above" it using MQSeries. The transactions must be written to the
> > database in a timely manner, but the queue guarantees their delivery
(just
> > go with it).
> >
> > My peers have suggested that we employ Parallel Server to allow massive
> > throughput and fast transactional capability to insure that the database
> > server can handle the 3 million transactions per hour peak volume. I
> > contend that parallel server addresses high availability via fail-over,
and
> > does little to improve the "performance" of such a system. The
performance
> > in this instance comes from the responsiveness of the queue.
> >
> > My suggestion is to use advanced replication across two or three
> > geographically separate multi-masters that can synchronize at regular
> > intervals. This addresses fail-over and disaster-recovery in a way that
is
> > not currently possible. The logged transactions must be highly
available
> > (99.9%) for query, but the high-level application must be 100%
available.
> > Non-stop hardware is less important than redundancy. Transactional
> > integrity must be maintained and the system must be able to restore data
> > lost as a result of mass media failure.
> >
> > Can I get a sanity check for this?
> >
> > Also, it looks like this is turning into a CORBA system in the front and
> > middle. Any comments on that with regard to our volume?
> >
> > Thanks!
> > Ajax
>
> --
> Regards
>
> Pete
>
>
Received on Thu Jul 08 1999 - 12:29:29 CDT