-- "CHAN Chor Ling Catherine (CSC)" <[EMAIL PROTECTED]>
> Correct me if I am wrong. I thought though I use Raid 5 but with different
> mount points, I will not have contention problems
> For example
> One mount point for data files
> Another mount point for index files.
Makes sense. Also helpful to keep rollback and log files on a
separate phyiscal path for speed. Main problem is Oracle's flakey
file layout. Either you get the supported method w/ several layers
of meaningless direcrories or you get something that people can read...
If your RAID5 systems are striped sanly (read: in O/S page size)
then they will look and act pretty much like disk drives. You can
push the whole issue onto the storage system by striping the logical
volumes across multiple RAID5 devices. This leaves you with multiple
mount points that all use all of the disks all of the time. If the
database is fairly active this can be usable since it spreads the I/O
out pretty thoroughly.
The issue of being inable to isolate the I/O to speicfic devices means
less with high-end RAID systems than it used to with disks. The
RAID toys (e.g., Storage Works, EMC) and disks have enough cache and
brains to sort, burst and pre-fetch I/O in a workable fashion. More
people screw themselves with single-backplane computers or single-
controller RAID systems than by grouping disks from what I've seen
cleaning the things up.
Best way to start is watch the I/O to things you'd like to group
together (e.g., rollback, logs, index, data) and see which ones
on your system get what kinds of load. OLTP usually looks more
like the death 1000 cuts from inserts w/a broadsword to the next
during bulk extracts; OLAP is the reverse, with a daily belch of
data from the nightly load and a constant stream of queries. You
have to decide which one needs to have the best performance and
layout the file system to manage that kind of I/O most effectively.
Things with serious peaks probably belong on their own data paths
to whatever extent possible (e.g., rollbacks); nice, steady flows
with a mix of input and output can likely be grouped onto devices
that can gracefully handle the average flow.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steven Lembark
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
