Disk layout for two instance servers
- From: stv <stvsmth@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 27 Apr 2007 10:25:25 -0600
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
