Re: How much instances per server?

On Wed, 23 May 2001 02:57:27 GMT, "Jim Kennedy" <kennedy-family_at_home.com> wrote:

>Proper init.ora parameters and configuration you can eliminate rollback
>contention. Done it on sites with 3,000 users not very difficult.

True ... my point was that by definition, more users in one instance = more contention ... even if things are tuned so that there's little or no perceptable impact. I'm not saying there will be problems, just that the chances increase.

>You are going to have something similar to redo contention with multiple
>instances since you have to put the redo somewhere. The disk IO will be
>flooded no matter which scheme you use. Of course, if you put enough disks
>together in either case you can reduce contention.

True again, but see above.

>Not sure what independent backup and restore has to do with anything. If
>the instances or schemas are seperate then I don't see how that is
>applicable. Certainly if you want another instance as a backup I see no
>problem with that. Multiple instances is not a bad thing unless you do too
>much of it.

The big problem multiple schemas mimicing DBs introduces with independent backup and restore is changing an object's definition. This then makes independent backup and restore next-to-impossible. Because mulitple schemas share one system catalog, the only way to restore a consistent version of an object to a previous incarnation that has had it's definition changed is to also restore the system catalog ... and hey presto! you've just clobbered every other schema that may have had changes. (and let's not kid ourselves that import/export is a backup option :-) ).

>Actually, you can have priviledges apply on a per schema mode. Sure someone
>is "root" somewhere, but that is true in multpile instances you just have a
>"root" for each instance. The users and privledges should not be given dba
>privledges anyway.
>
>Not sure what you mean by commercial packages using prescriptive schemas.

In shops that only use custom apps, or well-written commercial ones, there are no problems. Man commercial packages dictate the names of schemas (i.e they're hard-coded) and the privileges required. Yes this is poor design, but that's tough - the commercial package is usually far more important to an organisation that the gripes of we poor DBAs. And this means you can't just use multiple schemas to mimic DBs if you wanted a production, test, and development version of one of these apps. What's even worse is when they say "the userid BOB must have DBA privilege". Once again poor design, but would you want this userid let loose in your single instance? I didn't think so.

Ciao
Fuzzy
:-) Received on Wed May 23 2001 - 18:35:29 CDT