Re: best Hardware for 8i

I'd recommend that you start with only one or two of the fastest processors you can afford, and add more processors later, ONLY if a careful analysis determines that cpu is the bottleneck on the system.

One item that is going to have a significant impact on the overall performance of your database is the i/o subsystem. Without a doubt, the more disks and the more controllers you have, and the faster they are, the better your performance is going to be.

If you absolutely must "stripe" your datafiles, then you must resist the temptation to stripe everything across all of the disks. For some applications, that may be a good approach, but not for an Oracle database.

IMHO, you are much better off carefully distributing the i/o between each of the available disks and controllers, which will give you a much better chance of tuning the i/o subsystem. in addition, it makes recovery after a disk failure much simpler and faster. if you still have 'hotspots', i would relocate the active table to its own tablespace and its own disk drive. if acceptable performance was still not achived, i would then consider "striping" that datafile across multiple disk drives.

The selection of a RAID solution is really going to depend on your uptime requirements: i.e. how long can you afford to have the database down when you lose a disk drive? If you need to minimize downtime, or the ability to stay up when (not if) you lose a disk drive or a controller, then you should look at RAID-1 (mirroring) as an elegant, cost effective solution.

NOTE: From personal experience, I have seen that adding processors to a system does not always improve performance. On a system where the i/o subsystem is the bottleneck, adding more cpu's can exacerbate the problem by putting a larger load onto the i/o subsystem. Case in point: we had an oracle instance on a multi processor hp-ux system that was not performing up to par. The dba carefully analyzed the problem and recommended (1) an additional controller and additional disk drives be allocated to the database (only one controller and eight disk drives) and (2) more memory be made available to our oracle instance (only 150MB was allocated to the SGA). The capacity planners (in the infinite wisdom that capacity planners can sometimes exhibit) re-analyzed the problem and decided that since (1) some of the disk drives were not "full" and since (2) the system wasn't swapping, the right way to "correct" the problem was really to (3) increase the number of CPU's on the system. After the so-called "upgrade", the performance of our database was significantly worse than before... to restore performance, they actually had to "disable" the cpus that had been added. What was really needed was to reduce contention on the disks, either by (1) distributing the i/o over more disks and controllers, or (2) generating fewer i/o requests (by increasing the number of buffers, and holding more actively used data in the SGA). Adding more cpus resulted in even more i/o requests and more disk contention to the already overburdened i/o subsystem.

"Kay Liesenfeld" <kliesenfeld_at_databecker.de> wrote in message news:8dmv1g$mo0$1_at_crusher.de.colt.net...
> Hi,
>
> we want to use Oracle 8i (Standard) on a Linux-Server, what is
 the ideal
> hardware for our environment?
>
> There are about 50 concurrent users (number will dramatically
 increase the
> next months) and we think about an Intel-based HP-Server with
 2 PIII-733, 2
> GB RAM, 100 GB Harddisks (RAID 0).
>
> Is it more profitable for a database system...
>
> ...to use MORE CPUs than FASTER ones (unless we don't have
 Oracle EE with
> parallel querying, do make more than 2 CPUs any sense)?
>
> ...to use more RAM than more CPUs?
>
> Thank you for help,
>
> Kay.
>
>
>
>
Received on Sat Apr 22 2000 - 00:00:00 CDT