Re: Distributing Oracle using parallel server...

Comments inline.

Pete

Todd and Mary Ryder wrote:

> Mr. Peter Sharman, I need some Oracle Parallel Server advice, if I can
> get it. 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
> For the number of users you're looking at, I'd recommend going lower
> level than Java if you want to get some performance out of the
> system. It may be just my bad experiences, but everything I have that
> requires loading of Java runs like a dog, and that's on a laptop with
> 256 Mb of physical memory. Maybe OCI or similar would be a better
> option, but that would obviously depend on what you're trying to do at
> this middle layer.
> 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
>
> This would need to be on an absolute mother of a machine. I wouldn't
> recommend relying on one box for a system this big. All it would take
> is a water leak in the computer room and your entire system is dead.
> If latency is acceptable as you discuss below, I'd be more inclined to
> use multiple machines with distributed databases, rather than OPS. I
> don't really see what you gain from using OPS, other than machine
> failover (see comments below about performance). 3. all POST actions,
> from all java app servers, goto a SINGLE write-only instance, which
> does NOT run OPS.
>
> Same comment as point two. 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
>
> Row level replication can be periodic. I've seen clients set
> replication up for anything from 5 minute refreshes to weekly
> refreshes. It just depends on your business needs. 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)
>
> Yes, this is a limitation of Unix and NT (not VMS). OPS isn't
> available on Linux yet (they're just starting to get some cluster
> support now).
> - 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 - I think a Filer is fundamentally a
> cooked filesystem)
>
> Correct.
> Would appreciate any/all feedback regarding my plan/assumptions or
> even the validity of partitioning reads (but not writes) across N
> Oracle instances, for scalable performance under massive load in a
> dot-com environment Worst case, I could bag the whole OPS idea, and
> run stand-alone databases for each of the N, get/query instances, but
> that would require each to participate in Advanced Replication (as
> slave) to refresh itself from the lone, all-write master. This would
> still be acceptable (but more hassle to setup/maintain) I think,
> because the snapshot refreshes could be restricted at each slave to
> include only data for logged-in (affinity) users. Thus, total
> replication network/disk IOs would remain X, where X represents ALL
> writes to the master, instead of N * X, where N is the number of
> GET/QUERY slaves. Does that make sense? I think it does, as long as
> each GET/QUERY slave keeps a log table containing uid's of each
> connection it is supporting.
>
> I still wouldn't go for a single write master. I would go for
> mutli-master to spread the load.
> Sorry for being so wordy, but I just want you, should you consider
> responding, to really understand my questions/concerns. Any feedback
> is greatly appreciated. Please respond directly as well as to
> comp.databases.oracle.
> Thanks in advance.
> Todd Ryder
> tryder_at_captech.com
> tryder2_at_home.com
> tryder_at_best.com

Received on Mon Nov 08 1999 - 11:33:32 CST