| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Distributing Oracle using parallel server...
Pete Sharman <psharman_at_us.oracle.com> wrote in message =
news:3827096C.92E59257_at_us.oracle.com...
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.
A MOTHER of a Unix cluster - i.e. separate nodes, one shared = disk-pack/array. Ideally, I would like the disk-pack to be a NetApp = Filer (simplest administration for backup/restore/mirror I have EVER = seen) but didn't believe that to be possible, under OPS. Now, thanks to = your sage advice, I KNOW it not to be possible.
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) =
I think of row-level-replication as two-phase-commit. Whereas, a = periodic refresh of a replication slave, based on entries in a refresh = log, connotes table-level or set-level replication, to me. Maybe I = don't have the terminology right. But, in practice, have done it = successfully with Oracle under HPUX.
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).
BooHoo - I have deep and abiding affinity for the stupid-simplicity = of the NetApp filer (stupid being my side of the equation).
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.
But the distribution is likely to be 85-90% read vs 15-10% write. = Why add write overhead to the Nth instances. Ideally, I want this = stupid-simple, like plugging in another Web server host and adding an IP = entry to my round-robin DNS or Big/IP routing table... I want it = plug-and-play scalable, plug-and-play simple to administer, and more = importantly, manage long term. I want to work myself out of a job, by = making the correct decisions upfront.
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
And thanks, Pete.
Todd Ryder Received on Tue Nov 09 1999 - 07:14:21 CST
 |
 |