RE: two databases in a server

> 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.

--
http://www.freelists.org/webpage/oracle-l