Re: Running application and database on same hardware?

If it ain't broken, don't fix it.
Generally you should separate db and app servers.. but if the machine can handle the load why not.. As for network issues, you should be able to derive from db how much data is send in/out and see if you can accomodate such demands.

Separating the two would also help figuring out where the problems are (if any) especially if both db and app use the same disks.

You're also underutilizing your Oracle licenes, or you bought too many.

On Wed, 31 Mar 2004 22:50:59 +0200, Stefan Rupp <st.rupp_at_t-online.de> wrote:

>Good evening,
>
>althought I thought this to be a FAQ, I didn't manage to find anything
>about it on the Co-operative FAQ. Maybe you can help me:
>
>We have an application spread across a couple of processes, some with
>high I/O, some with high CPU, but all with high (> 100 MB) memory needs.
>So far, we have a couple of installations for different customers where
>the underlying Oracle database is running on the same physical hardware
>as the application processes (mostly Sun/Solaris, some HP/PA-RISC,
>DEC/Alpha and Intel/i386 architectures).
>
>Although our application usualy spreads its processes on multiple
>machines, which have multiple CPUs and loads of memory, I am wondering
>if it might be better to have a dedicated database server running on a
>dedicated hardware which only serves as the database for all application
>processes such that the application needs not compete with Oracle for
>system resources. This of course puts additional load on the network
>and requires additional hardware to be purchased. Is it worth? If not
>- would it be better to have the oracle server share the hardware with
>the more CPU intense processes or with the I/O intense ones?
>
>Thank you for your advice!
>
>Regards,
>Stefan

.......
We use Oracle 8.1.7.4 on Solaris 2.7 boxes remove NSPAM to email Received on Wed Mar 31 2004 - 16:15:36 CST