Sizing hw for small oracle database

I know that it is hard to do a general suggestion on sizing hardware but I need a starting point for recommendations to customers. I think the number of concurrent users is a one way to determine the sizing of hardware even if 2 sites with the same number of users might differ depending on how the application is used (how many users ar doing heavy data entry users or running heavy batch processes compared to users running only mall queries).

The small sites are more sensitive to cost than the larger sites (100+ users) so I have to compromise optimal configuration from a performance and availability aspect, with the cost.

The application is an OLTP (about 200 tables), small frequent select/insert/updates.

O/S: NT/Netware/Linux Lets assume o/s is NT (customers preference, not my).

In most cases 7 x 24 availability is not necessary (most use the application "9-5"), but sensitivity to down-time during regular working hours is different (some will not tolerate any longer

Processor and memory

10-20 concurrent users, 250-500 MB data

Minimum: 1 Pentium II 266 MHz or better, 128 MB RAM Recommended: 1 Pentium II/III 450 Mhz or better, 256 MB RAM

50 concurrent users, 0,5 - 2 GB data

Minimum: 1 Pentium II/III 450 Mhz or better, 256 MB RAM Recommended 2 Pentium II/III 450 Mhz or better, maybe start with 1 processor (buy a motherboard expandable to 2-4 processors), 512 MB RAM

For which load do you think it is necessary to use more than 1 processor (a general rough estimate since it is impossible to know for sure until you have analyzed the actual CPU usage).

Storage

There are two things to consider, performance and availability. "Every installation is Mission Critical but some are more Mission critical than other", i.e. for some customers it is ok that the system is down a half day or more but for some other it is unacceptable. One way to classify the sites is availability and performance, Some examples:

1. Low demand for availability. Losing some data is acceptable ("I will tolerate losing all work since the last backup")

I don't think this kind of user would need the application to run on Oracle but I include this category anyway.

Storage: 1 SCSI disk. If better performance add one or more disks (RAID0 or manually balancing load)

Use archiving if protection against instance failure is important (but no protection against media failure).

b) Fault tolerant but down-time for replacing a failed disk and recovery is acceptable, losing data is not acceptable.

• O/S, Oracle s/w and datafiles on disk 1 and 1 set of redo logs and control file (if high through-put is required, use RAID0 or manually balancing load on 2 or more disks, maybe also separating o/s and software to an own disk)
• Mirrored redo logs and control file+ archived log files on disk 2

This configuration would require at least 2 disks

c) Fault tolerant, high availability (no down-time during work-hours), small-medium througput requirements.

1. Everything on RAID5 (3 disks or more)
2. An alternative is perhaps to add two more disks (no RAID) and put Redo logs and archive logs on these (multiplexed to each disk)
3. Fault tolerant, high availability (no down-time during work-hours), high througput requirements.
4. Use RAID1+0 (4 disks or more)
5. Manually balancing load on several RAID1 arrays for data files, o/s and Oracle, separate disks (2) for redo logs/archive logs.

Any comments or recommendations? I think that for our customers will choose either alternative b) (probably using > 2 disks) or c) (RAID5 only).

I am very interested in hearing about what your configuration you are using.

BTW, have you ever installed a production site using IDE disk. My opinion is that IDE disks are not suitable for a server (either Oracle or even a file server). We have a customer who wants us to install Oracle on his existing "server" which is a PII-266, 128 RAM using 1 IDE disk. I have recommended against using this configuration (I can live with the processor and memory because it is few users, but the IDE disk is not acceptable).

Magnus Received on Mon Aug 23 1999 - 17:09:40 CDT