RE: two databases in a server
- From: "Michael Fontana" <MFontana@xxxxxxxxx>
- To: <danielwfink@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 31 Mar 2006 12:26:14 -0500
> This is one area that is just two broad to be able to say "Here is the
> right way to do it." There are just too many variables (as has already
> been noted).
This is correct, but generally speaking, you will save so much money by
consolidating (at least more than one database on each server) that even
the vendors who suffer by it still support the notion.
> * Different backup/recovery requirements
These can be easily overcome with proper planning.
> * Different support teams and how well they work together
For a long time, we had teams (and still do) who thoroughly refuse to
play in the sandbox together. When we present the cost savings to their
management, they will almost always come in line. If they can't, they
pay a heavy price.
> * How well the apps handle resource (putting a
low-business-impact,
> high-resource-hog app on the same server as a high-business-impact app
is
> going to be problematic)
Even this can be done if the hardware is allocated correctly. But it's
true that a good mix is always best.
We like to put the hogs all together in the same pen, actually. They
deserve each other. In our case, this is Siebel and BEA weblogic.
> * Security issues
If you're security administration is kept up, and policies properly
applied, this should NEVER be an issue. If you think so, provide an
example (PS - I'll be ready for this one - users who didn't want to play
in the sandbox with others tried it - we came up with a way to address
their every point - even though THEY WERE THE ONES who we'd caught
snooping at other systems before we implemented proper policy. I'd call
that ironic.
>
> Everything is a tradeoff.
To some extent, yes. But trading off a possible occasional operational
adjustment for lowered administration time and greatly lower cost seems
like a win-win to me.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
