Disk layout for two instance servers

We are in the process of upgrading hardware for a small, long-lived OLTP Oracle 9.2 database. I'm looking for some pointers on where to focus my analysis of our existing system to ensure the best possible configuration for the new hardware. Specifically, I'm looking for advice on how to best allocate disk drives for two instances on one server.

I'm not an Oracle guru by any stretch, so I'm looking toward the masters here for any crumbs of advice to be given.

We are looking 2 each of:
* IBM X3650

• 9GB RAM
• 2 dual-core Xeon 5150 (2.66)
• 4 internal drives 15K drives (72GB)
• Redhat RHEL4

And one
* StoreVault s500 w/ 12 disks

These machines will replace two Sun ES450/Solaris 8 servers pushing 8 years of service (bought, I believe, used) with 4GB RAM, 4 processors, and 20 9-gb hard drives (on production, test has 12 drives). Actually, we've disabled two of the processors to be compliant with our 2-CPU license for Oracle Standard Edition.

This would all be more straight forward (and overkill) if we weren't running two instances of Oracle.

The primary application is an in-house developed app with 40 users in moderate-volume registration process (8,000 people/year). The second application is RaisersEdge 7, with a custom batch script to synch the data from the in-house application. This application has only 8-10 users and sees mostly CRM type read/write activity as people develop contacts for donations. Eventually we hope to unify these applications (and therefore instances), but we're stuck with the two-instance requirement for the next several years.

Currently, we consume about 50GB of disk space for everything--OS, binaries, datafiles, redo files, archive logs, kruft. About 15GB of that is for datafiles, split roughly in half between the two instances. Log files (3 members @ 1MB) rotate about every 20-30 minutes on the custom application (this setup will probably change as we occasionally choke in some nightly batch operations).

My main concern is how to layout the disks. Obviously we're dealing with a tiny storage requirement, but the dual instance drives up our need for spindles (at least in my understanding of Oracle performance**).

Obviously, we're gonna test all this, but I was hoping to start with a good system and make it better rather than make a few big mistakes and have to restart.

1. It seems to me that having set of redo logs on the CPU and a set on the s500 makes sense (to avert some kind of network event or filer mishap). With 4 drives on the CPU I am thinking of two Raid-1 pairs. Should we be concerned with disk contention among the OS, Oracle binaries, and redo logs? I would have one set of redo logs for each instance on each raid stripe.
2. Will there be an issue in archiving the redo logs from the server drives to the filer drives?
3. Our storage requirements are minimal; we could easily sacrifice disk space on the s500 to a series of Raid-1 pairs. Assuming we have 1 set of each instance's redo logs on the server drives, I was thinking we could layout the filer's 12 disks as such:

2 disks (no Raid) for redo logs (1 for each instance) 2 disks in Raid-1 for archived redo
1 disk for hot-swap

and either
1 disk for whatever and
3 Raid 1 pairs for datafiles

or
5 disks for datafiles, two for Raid-DP (If I understand the NetApp literature correctly).

I"v read enough BAARF to be leery of Raid-5 (to which Raid-DP seems to solve only the issues with double-drive failure), but I'm unclear as to how the issues with Raid-5 would compare to having more datafiles on the same spindles.

Do most folks use filers in Raid-DP setups? Does our two-instance situation take us out of "the norm?"

I realize the answers are "It depends," but I am looking for some pointers on where to focus my research of our existing system and some real-world experience of putting two instances on one CPU (something I have not seen much of in the literature or archives).

Thanks
--Steve Smith

• We're a small non-profit organization in rural Wyoming. Our IT department, after being fairly stable for 10 years, has recently turned over 6 of the 7 employees (the remaining employee having nothing to do with the Sun/Oracle setup). We no longer have any in-house experience with Solaris, hence the change in OS as well (not that our Linux experience is spectacular).

Tangential to this point is that hiring for our organization generally requires us to hire "generalists" and train them. Hence my lack of deep Oracle knowledge and asking of broad questions. I'm fairly new to the position and don't have great deal of experience with Solaris/Veritas or our general data usage patterns.

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