RE: two databases in a server

>
> The way that I've always seen it is:
>
> PRODUCTION - One server, one database. Right size the server to the
> database. Easy to implement one set of policies and procedures that
meet
> the production requirements. Server/database downtime is easier to
> schedule.

It's tried and true, agreed, but is based upon the old notion that servers and database license costs are minimal considering the sponsors revenue and profitability.

This would be considered the "Prince" methodology. Do it this way, and you'll be partying like its 1999.

>
> DEVELOPMENT/TEST/TRAINING - Stick them all on one box in different
> databases. Much more flexibility in policies and procedures. For
> downtime - just tell them it'll be down. They'll complain but the
> business won't suffer.

Agreed.

> Make sure that your have an SGA/Disk Csar who is
> responsible for allocating computer resources.
>
> I've never had any real problems with that.

But what happens if YOU'RE THAT GUY? In my shop, we have operations/systems staff, but they only spec out the box as we tell them. The best thing to do is to always oversize and still leave room for growth, where possible. This gives the flexibility to rescale as needed.

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