Re: Multiple hosts - shared SAN - ASM ?

From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 01 Jun 2005 14:28:06 -0700
Message-ID: <1117661156.508451@yasure>

Mark Bole wrote:

> Billy wrote:
> 

>> Mark Bole wrote:
>>
>>
>>> While I'm not saying running 15 instances (presumbably for 15 databases)
>>> on one host is a great idea, the math here is faulty, and anyone with
>>> basic ability to use Unix tools and Oracle's OFA will most definitely
>>> NOT incur N times the overhead (either administrative or disk/memory)
>>> just because they have N small instances instead of one large one (where
>>> N is some small integer). Values of N equal to two or three are no big
>>> deal and can be easily justified in a number of situations.
>>
>>
>>
>> Mark, simply put you now have 15 distinct TEMP space areas instead of a
>> single shared TEMP space resource. Ditto for the SGA, UNDO/REDO space
>> and so on.
>>
>> A shared resource is *many* times more scalable than indvidual
>> non-shared resources. Just how small will the SGAs be when dealing with
>> 15 of them? Just how big is the risk to have parts of the SGA paged to
>> disk?
>>
>> Think of scalability in operating systems and databases. Shared and
>> virutal memory. Shared pool. Shared i/o buffers. Etc. You do not scale
>> by making things non-sharable. Just what the hell is RAC? Multiple
>> databases/instances per platform? No - the EXACT opposite. Single
>> database serviced by mutiple platforms running a single RAC instance
>> per platform.
>>
>> Not too mention on an admin basis having to deal with 15 sets of bdump,
>> udump and cdump directories and their contents on a daily basis. And
>> backups and what not...
>>
>> Yes, a good sysadm/dba (Oracle/Unix) will be able to deal with that
>> (they always do).. but nor will a good sysadm/dba ever propose such a
>> configuration.
>>
>> THERE IS NO VALID TECHNICAL REASON FOR RUNNING MULTIPLE INSTANCES ON A
>> SINGLE PLATFORM.
>>
>> The only exceptions to this is when dealing with very high-end servers
>> where you do physical machine partitioning or when you have a R&D
>> platform.
>>
>> And if anyone beg to differ, please do it with technical fact and not
>> personal fiction. (yeah, I have had this "debate" more times than I
>> care to remember and every friggen time I have to listen to bs that is
>> devoid of any technical facts and merrits to prop up the argument for
>> having multiple instances per platform).
>>
>> --
>> Billy
>>

> 
> 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.  15 100MB SGA's do not take up 15 times the 
> memory of a single 1.5GB SGA.  15 services in the listener do not 
> automatically require 15 time the network bandwidth of a single service.
> 
> As I stated up front, I don't recommend 15 instances on a single server. 
>   We seem to agree on this.
> 
> 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.
> 
> 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).
> 
> 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 Bole

Methinks you may be missing the point. Do you need 15 servers for 15 instances at one instance per server? Paying 15X the license cost to Oracle?

Do you need 15 instances with their own SGA, data dictionary, backups, patches, etc. on a single server? Sharing the Oracle licenses.

Or do you need 15 schemas in a single database, each in its own tablespace but sharing a common SGA, common catalog, common control files, common redo logs, common backup, etc. Also sharing the Oracle licenses.

There are three possibilities ... not two. And I would prefer the third unless there is a compelling reason as to why the different applications can not co-exist.

-- 
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)

Received on Wed Jun 01 2005 - 16:28:06 CDT