Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Scalable parallel (?) read instances and one write instance in a dot-com environment...

Re: Scalable parallel (?) read instances and one write instance in a dot-com environment...

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Tue, 23 Nov 1999 17:58:25 -0000
Message-ID: <943384595.7909.1.nnrp-08.9e984b29@news.demon.co.uk>

I've just come across this one, so hope I'm not too late to contribute.

>3. all POST actions, from all java app servers, goto a SINGLE write-only
>instance, which does NOT run OPS.

Just to be clear, you do mean that this is a separate database entirely, and the rest of the instances run on a single
database.

Presumably the idea is to reduce the
block invalidation load on all the OPS
instances by batching up changes on
the second database and then replicating them into one OPS instance in bulk.

It seems to me that this will not eliminate any bottleneck, only move it whilst introducing another bottleneck at the single updatable database ( with 30,000 connections (?).

If it works at all, I think it would work without the second database - simply allocate one instance as the writing instance and put that on a very high powered multiple CPU box (using 8.1 of course).

Before chasing this kind of direction though I would look out for options for a completely artificial partition mechanism to allow multiple instances to be involved in completely independent activity.

Q1 - yes OPS is raw disk only (apart from VMS). Q2 - yes it has to be (equivalent to) shared disk clusters

The n-way replication sounds a lot worse.

However I think Oracle Corp. would claim that with the right kit they could do the 30,000 concurrent connections quite happily on a single instance anyway - perhaps with a few nodes around the edges running the connection manager to handle connection pooling and reduce CPU loss due to cycling around job queues.

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

Todd and Mary Ryder wrote in message ...
>Have what I think is a neat idea for an N-tier scalable (read) database
>architecture for a high volume (10M users, 30K simultaneous connects) Web
>site:
>
>1.middle-tier java app servers have "affinity" for specific Oracle
instances
>(search, sort, fetch) for all GET/QUERY form actions - i.e. all GET and
>QUERY acts are distributed (perhaps by modulus against connected uid)
>equally across N "read only" servers - the read only part is logical - i.e.
>we wouldn't use read only tablespaces or anything - you'll see why in a
>minute
>
>2. all (above) GET/QUERY instances, each run on a separate Unix host, but
>mount just one database between them, in parallel, using Oracle 8.0.x or
>8.1.x Parallel Server Option
>
>
>4. setup one of the parallel GET/QUERY instances as a replication slave of
>the all-write (POST) master DB so that all the GET/QUERY instances
>periodically synchronize themselves, albeit with some (acceptable) latency
>resulting from periodic (as opposed to row-level) replication refreshes
>
>Questions:
>
>1. Having experience with the replication, but not OPS, I am operating
under
>the following assumptions, derived from researching usenet:
>
>- OPS can only use raw file systems under Unix (the DB hosts will be
Solaris
>or Linux - we are leaning toward Solaris for stability - anecdotal evidence
>indicates that Oracle is simply too new on Linux right now for big-time
>production DBs)
>
>- OPS can only run under shared-disk clusters - i.e. I can't have parallel
>instances on separate Unix hosts mount the same database (datafiles) from,
>for example, a NetApp Filer (a Filer also precludes the use of raw disk as
>well - a Filer is fundamentally a cooked filesystem)
>
Received on Tue Nov 23 1999 - 11:58:25 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US