We have 13 databases (and instances) of approximately 17G each on a
RISC/6000. We have 6 database/instances on a Win2K box. Two of those are
in the 17G range but the rest are smaller. But it's not the disk size
that's important, it's the SGA size.
Kean Jacinta
<jacintakean To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
@yahoo.com> cc:
Sent by: Subject: RE: Database Instance
ml-errors
12/26/2003 01:59
AM
Please respond
to ORACLE-L
Dear :All
Well we did not buy any application packages.
Currently we are using open source product ...which
is Apache and Tomcat.
By the way, have anyone ever have more than 5 database
under a single server ? I heard that the best practice
is to have 1 database n 1 application in a single
server. Is that true ?
Thank
JKean
- "Mercadante, Thomas F"
<thomas.mercadante_at_labor.state.ny.us> wrote:
> I would be very careful about doing this if you have
> purchased application
> packages. Sooner or later, you will want to upgrade
> one of the packages,
> and it will require a different release of Oracle -
> and you will be stuck.
>
>
> Tom Mercadante
> Oracle Certified Professional
>
> -----Original Message-----
> Sent: Wednesday, December 24, 2003 11:24 AM
> To: Multiple recipients of list ORACLE-L
>
>
> One other disadvantage of putting all instances
> together is if you need to
> say bounce the database (for parameter change or
> other maintenance etc)
> then all other applications will get affected.
> Whereas with separate
> instances other applications will not get affected.
>
> To some extent one application failing will not
> affect other applications.
> Except if one application does not close its
> connections then it could lead
> to maximum connections (sessions) being reached and
> affecting other
> applications.
>
> If the nature of the applications is different :
> OLTP, warehousing then you
> cannot really tune the parameters.
>
> On the positive side I think putting instances
> together will lead to some
> memory savings.
>
> I would suggest : Do not worry about who wants to
> put the instances together
> just list the advantages, disadvantages and make the
> decision.
>
> Stephen.Lee_at_DTAG.Com wrote:
>
>
> It is not necessarily true that an error in one
> application will affect all
> applications. If there is a problem with oracle
> instance or the database,
> then all applications might be affected.
>
> Multiple schemas which have the same table names can
> be a problem. If your
> applications uses public synonyms, then you might
> have a big problem.
>
> If everything is working fine now, it seems
> pointless to move things around.
> But this is philosophy. I do believe that isolating
> applications from each
> other as much as possible is usually a good thing.
> "Good fences make good neighbors." (usually)
>
> But, if your manager insists on it, you have no
> choice. Just do your best
> to keep the old stuff around in case it becomes
> apparent that the new way
> will not work and you must go back to the old way.
>
> > -----Original Message-----
> > Lately, m! y manager want me to remove all the
> databases
> > and remain a single instance. I was wondering if i
> > move everything into single database then if one
> of
> > the application fail due to oracle error , then
> all
> > other four application will fail also rite ?
> >
> > Each of our web application needs to have 2 schema
> and
> > both schema have to be transparent to each other.
> > While other application schema will be invisible
> to
> > each other. Since i have 5 web app then i will
> need 10
> > schema.One major problem is all the 10 schema will
> > contain same table name. It will be a mess putting
> so
> > much app in a single db .
> >
> > Pls correct me if i am wrong and do let me know
> what
> > are the pro and cons or maybe you can educate me
> with
> > some of the best practice to setup a proper
> production
> > server environment.
> >
> > Thank You
> >
> > Regards,
> > Jkean
> >
> > >
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> --
> Author:
> INET: Stephen.Lee_at_DTAG.Com
>
> Fat City Network Services -- 858-538-5051
> http://www.fatcity.com
> San Diego, California -- Mailing list and web
> hosting services
>
> 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).
>
>
>
> _____
>
> Do you Yahoo!?
> Free
>
<http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/>
> Pop-Up Blocker - Get it now
>
>
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Kean Jacinta
INET: jacintakean_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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.net
--
Author: Thomas Day
INET: tday6_at_csc.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
Received on Fri Dec 26 2003 - 07:44:25 CST