Re: Multiple hosts - shared SAN - ASM ?

Mark Bole wrote:

> My point was that it's not a straight line relationship, as you claimed.
> 15 1GB temp tablespaces do not take up 15 times the disk space of a
> single 15GB temp tablespace.

The assumption that 15 distinct 1GB TEMP spaces have the same ability as a single 15GB TEMP space is seriously flawed. And that is what the relationship is about - not just total physical size or disk footprint (which is the case when dealing the Oracle system process footprint per instance), but the capability and scalability of the resource.

A 15GB TEMP space is more than 15 times able than a 1GB TEMP space. It cannot just handle all the query sorts and temp LOBs and what not than those 15 TEMP spaces, it can handle significantly more complex and bigger queries and temp LOBS and what not.

Simple example of the ability to used shared resources to scale far above and beyond the ability of dedicated non-shared resources. HP L-class 4 CPU machine with 4GB of memory. Only able to accecpt just over a 120 JBOSS connections. Dell desktop PC with 256MB of memory. Able to accept over a 1000 JBOSS connections. The difference? Dedicated Server versus Shared Server.

> But it can be done, and if done reasonably, it does not incur 15 times
> the administrative and hardware overhead. This is where we disagree.

Of course it does! Instead of a single backup, you now have to deal with 15 backups. Instead of performance issues in a single instance, you now have to deal with 15 instances. Instead of a single pfile/spfile, you now have 15.

Worse, you need to juggle the system resources between these 15 instances. What happens when instance 5 shows that the bottleneck is its 32MB buffer cache and there is insufficient memory to increase it? What other instance's db cache do you now downsize? Ditto for running into TEMP space issues with no more free diskspace available. Etc.

> Your statement in all caps is easy to disprove with a counter-example.
> Let's say I have a server with a database used for QA and user
> acceptance testing of an application prior to final release (not R&D).
> For business reasons, this server is also a secondary disaster recovery
> location, and as such has a physical standby database running. (Note I
> said "secondary" -- as in, Murphy has taken out both my primary and my
> dedicated standby).

There are always exceptions. Granted. And if the heavens fall we will all wear blue hats. ;-)

I have run multiple instances on production platforms myself. Most recent one being 2 instances (8i and 9i) on the same production machine during an app port and upgrade.

The fact however is that these exceptions are just that. And if you are still running multiple instances on a production platform after that exception has past... that's is simply put (and IMO), either extreme ignorance or utter stupidity.

A single physical Oracle database can contain any number of distinctly seperate logical databases. The very core of Oracle supports this - from physical seperation of logical databases to providing specific resource management and security and auditing for each logical database.

> Your final paragraph says it all. I'm not trying to provide "bs [...]
> to prop up the argument for having multiple instances". Even you
> acknowledge there are exceptions to your own "inviolate" rule. I'm
> (spending too much effort) quibbling over the way you make your point
> (exclusively in terms of scalability), not the point itself.

Mark, I made a statement that there is NO *technical* merrit in running multiple instances per platform. This can also be extended to administration merit (it makes it just more complex) and costs (think licensing).

At the same time I said that there are always exceptions - especially in the R&D environment and on the very high-end server platforms. There is also the case where the you buy shrinkwrap software that comes with a bundled Oracle database, where the licensing and support agreement forces you to have a dedicated instance for that application. Thus you are forced into having multiple Oracle instances on your production platform.

However, none of these exceptions disproves the statement that I made that running multiple instances per platform has no technical merrit and severely limits the scalability of Oracle on that platform.

--
Billy