Re: Would you recommend having multiple instances on the same box?

Daniel Morgan wrote:

> My understanding is as follows:
>
> 1. It is a common practice.

Yes. In my area, it is extremely common, especially with organizatyions that have a separate group for Sys Admin vs DB Admin. Frequently the DBAs get 'special' priviledges (eg: install) only on a few boxes, so that's where they go.

And some organizations put multiple instances on 1 machine to save licensing fees. (Check your license agreements before jumping on this bandwagon!)

And it's accepted, as long as you don't get into swap/page issues. Mind you, I recently ran into a situation where the DBA started up the 11th 8.0 instance on an old machine with 512M memory ... CIO was very concerned about performance and other issues.

[first rant] ... Amusingly, I find organizations [ab]use this tactic (frequently based on non-Oracle vendor recommendation), and end up suggesting that Oracle can't cope with the performance needs ... "see, when you compare xyz-db on this shiny new machine to the 87th Oracle instance on this '486, you get better performance from xyz" - Duh

> 2. Oracle make's no specific recommendation.

Oracle's official recommendation to any sizing question - and this is fundementally a sizing question - always seems to be "try and see - just don't publish" <g>

> 3. Hardware vendors absolutely recommend it ... because they sell more boxes.

AFAIK, lately DELL is the only one gaining here though. With Oracle's RAC, you no longer need bigger and more to handle the load.

> 4. The decision is purely financial. In an ideal world ... one box ... one
> database.

With RAC, I see this moving to 'one box, one instance' and 'one database - multiple instances'.

[second rant] probably much more important is ensuring that the application code does not reside on the same box as the database. As far as I'm concerned, the failure to do this is one of the bigger reasons why Oracle is considered expensive - end up needing to get multiple CPU licenses to handle a 1-CPU load. Received on Fri Apr 18 2003 - 10:28:32 CDT