RE: 20 Instances 1 Machine

Although in this situation you would need separate file systems for each database to avoid those issues

But I do agree that for providing databases to different customers I would never like to share an instance between customers. You are more prone to issues arising out of security mistakes or bugs like the one in 91r1 relating to the visibility of all objects.

You could also consider HP's Superdome type architecture to partition each customer effectively to individual subsystems Each customer effectively has its own server.

Cheers

--
=================================================
Peter McLarty               E-mail: Peter.Mclarty_at_mincom.com
Technical Consultant        WWW: http://www.mincom.com
APAC Technical Services     Phone: +61 (0)7 3303 3461
Brisbane,  Australia        Mobile: +61 (0)402 094 238
                            Facsimile: +61 (0)7 3303 3048
=================================================
A great pleasure in life is doing what people say you cannot do.

    - Walter Bagehot (1826-1877 British Economist)
=================================================
Mincom "The People, The Experience, The Vision"

=================================================

This transmission is for the intended addressee only and is confidential 
information. If you have received this transmission in error, please 
delete it and notify the sender. The contents of this e-mail are the 
opinion of the writer only and are not endorsed by the Mincom Group of 
companies unless expressly stated otherwise. 






"Fink, Dan" <Dan.Fink_at_mdx.com>
Sent by: root_at_fatcity.com
02-08-2002 09:13 AM
Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Fax to: 
        Subject:        RE: 20 Instances 1 Machine


Ethan,
                 The points you make are valid. There will be some 
resource wastage
due to the overhead of each instance and database, but the potential
downside may make it worthwhile. Suppose customerA's application has a bug
generates a ton of redo, overflowing the archive_dump_dest. This means 
that
customerB's (and all others) data is unavailable and applications will 
begin
to malfunction. Imagine telling irate CustomerB that they are down because
of CustomerA! This also simplifies backup and recovery requirements that
differ between customers.
                 There will be some performance penalties, but a 
sufficiently
powerful machine should be able to mask them.


-----Original Message-----
Sent: Thursday, August 01, 2002 4:44 PM
To: Multiple recipients of list ORACLE-L


I am going to reply to this myself before I get flamed.  I found a recent
discussion on usenet regarding this topic.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3d1091af
%240%2428006%24afc38c87%40news.optusnet.com.au&rnum=15&prev=/groups%3Fq%3Dto
o%2Bmany%2Binstances%2Bgroup:comp.databases.oracle.server%26hl%3Den%26lr%3D%
26ie%3DUTF-8%26oe%3DUTF-8%26start%3D10%26sa%3DN

Basically everyone is against this idea.  However no actual technical
details are provided to explain why this could not be done in a production
environment with the right sized machine.  The scenario presented in which
one would want 20 instances on a machine is in a class room setting.
However, my scenario would be acting as an ASP.  Each instance would 
support
a different customer.  My fear with splitting customers up into different
schemas on the same instance is that I don't want to interupt other
customers if recovery is required.  This would have to be a tablespace 
point
in time reco since we would only want to reco one customers data.  Perhaps
this isn't as big an issue if we go with RMAN? 

Ethan Post


(972) 577-6552 

Ethan.Post_at_ps.net
perotdba (AIM), epost1 (Yahoo)
--------------------------------------------------------------------


-----Original Message-----
Sent: Thursday, August 01, 2002 4:58 PM
To: Multiple recipients of list ORACLE-L


I got a request to spec out a machine that could handle 20 separate Oracle
instances on a single UNIX server.  SGA should total about 500 MB per
instance.  We have some hosts here with 6-8 instances but never tried 20
before.  Wondering what types of things I should be worried about, 
obviously
having enough memory but are there any other limitations I can expect?
Anyone had to do this?

Thanks,
Ethan
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Post, Ethan
  INET: Ethan.Post_at_ps.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Post, Ethan
  INET: Ethan.Post_at_ps.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Fink, Dan
  INET: Dan.Fink_at_mdx.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).



-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Peter.McLarty_at_mincom.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).