RE: Development projects: Multiple databases v/s multiple schemas

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Fri, 20 Jun 2003 10:40:33 -0700
Message-ID: <F001.005B66FD.20030620102026@fatcity.com>

That's why my question ... do schema cross-reference ...?

If you have schema that don't need to talk to each other, one DB is still good. If you have enough resources, then give every team on db. But that is costly in terms of administration from DBA angle. Do developers/teams startup/shutdown databases? Not here ... 
Agreed, testing should be on a separate box or instance at-least. Testing in development instance is like shooting a moving target. Rarely works as advertised.

So, it boils down you your resources, if you have, go with multiple DB, or else one DB should be fine. We have one dev/acpt/qa/release_test/dayold database per production instance. Because the codebase is different and there is some customization that really matters.

But on our development RAC we have 22 (devl/acpt/qa) instances for various groups on each machine. Production it is only 5 instances per box.

Raj
<FONT face="Courier New"

size=2>--------------------------------------------------------------------------------

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email
are strictly personal. QOTD: Any clod
can have facts, having an opinion is an art !

-----Original Message-----From: Naveen Nahata [mailto:[EMAIL PROTECTED]Sent: Friday, June 20, 2003 11:15 AMTo: Multiple recipients of list ORACLE-LSubject: RE: Development projects: Multiple databases v/s multiple schemas
Thanx Raj and Bahar,

 Raj
 I think you misunderstood my question. Or I might be misunderstanding a part of your reply :-)

 I'll
 try to make my question clearer....

 All
 the developers of a project work on the same DB(developers don't have individual DBs, project teams have). Different projects have individual servers running separate DBs on separate machines. This causes maintenance problems since currently project teams are responsible for their respective servers and they don't have the required expertize to do it.


 We
 are planning to centralize the same and have one
 high-end machine running different versions of Oracle. My question is, for multiple projects which plan development on the same version of oracle, should I have 1 DB per project or within one DB multiple schemas for different projects?

 The
 project teams want separate DBs because they think they can shutdown and startup the DB as per their wish. For them if something gets stuck, the best way is to restart the DB :-). But my point is that starting and shutting down a DB is not required at all, since most of the things can be dynamically changed.

 The
 only thing is that certain init.ora parameters which cannot be changed dynamically. But since there is not too much of benchmarking done by the project teams the need to change init.ora parameters is not there.


 If
 required this can be done in a separate test DB which will be allotted for testing and taken back once load testing/benchmarking is over.

 The
 only problem I envisage with having multiple schemas is the name conflict between applications(projects) (2 applications might want to have schema with the same name).

I
 think the "stats" referred by Bahar are system level statistics like CPU utilization, waits etc. which I think are most relevant when doing tuning during load testing / benchmarking which as mentioned above can be done on a separate test DB specifically allotted for the same on a short term basis.

Regards
Naveen

********************************************************************This e-mail

message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank

you.*********************************************************************2

Received on Fri Jun 20 2003 - 12:40:33 CDT