RE: How to organize oracle directories in Unix ?

• "CHAN Chor Ling Catherine (CSC)" <clchan_at_nie.edu.sg>

> 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 singlecontroller  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: lembark_at_wrkhors.com

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: ListGuru_at_fatcity.com (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).