Re: How to store a table on multiple datafiles (one tablespace of course) ??
Date: 1995/12/20
Message-ID: <819500747snz_at_jlcomp.demon.co.uk>#1/1
In article <4b659q$8vj_at_www.acay.com.au> nsouto_at_acay.com.au writes:
: If you can "stripe" a logical disk over various physical disks at the OS level,
: then do so and use the resulting area as your database file for that
: tablespace.
I know I'm drifting away from the original post, but I do wonder whether O/S striping is such a good idea compared to Oracle striping. I have had two thought that suggest that O/S striping could reduce the efficiency of a good setup, and would appreciate any comments based on actual experience.
Point 1:
Parallel Query Option: Say you create a tablespace over 5 discs to hold nothing but a table of 5 extents, and you give the table a degree of 5 for parallel queries. When you push a large query at the table, Oracle can set off 5 processes to scan the table and, because of the design, end up running one process against each disc.
By comparison, if you have simply striped the 5 discs at the O/S level then attempting to run 5 parallel processes against it would probably result in a significant level of contention.
Any thoughts ?
Point 2:
Unix systems and I-nodes: If I have 5 discs each set up as a file system, and 10 Oracle files on each, then the i-node updates are spread evenly across the discs.
If I stripe the discs then (for a single logical volume) I will almost certainly end up with all i-nodes in a single block, i.e. on a single disc. Even if I stripe the discs and set them up as 5 logical volumes I could get most of the i-nodes on the same physical device.
I _think_ (and Unix experts please correct me) that i-nodes get updated whenever a file is written to.
If I stripe, won't I introduce a skewed I/O distribution because of i-node concentration ?
Note: this hypothesis is based on reports I have had from a couple of people who striped some (data) discs and still found that 80% of the I/O took place against one physical device.
-- Jonathan LewisReceived on Wed Dec 20 1995 - 00:00:00 CET