Re: How to store a table on multiple datafiles (one tablespace of course) ??

Hi Jonathan:

Point 1:

Parallel Query is a totally different can of workms than vanilla ORACLE. Given a simple ORACLE setup ( by simple I mean without any of the PQ or Parallel Server options added), I've found that striping at the OS level is more efficient for tables that get ad-hoc access over the ENTIRETY of its data, ie, where multiple simultaneous queries access rows covering the entire table.

Then we got the variations on disk striping at OS level: you can stripe block-by-blok, cluster the striping on a number of blocks (say, 32 blocks on disk1, 32 on next, disk, etc). The clustering factor can balance the load so that both ad-hoc and batch type access (where most of the table is read in a single SQL) can proceed at top speed.

Then there is the obvious factor that striping, ORACLE or OS, should only be used where there is an identified performance problem. Otherwise, its useless. Ie, if one has a botteleneck in access to one or more tables, then it's worth investigating striping. If not, then don't bother, you gain NOTHING...

Point2:

I don't use striping at all if I'm using file system data files. Most of the UNIX file system drivers nowadays use all sorts of algorithms to reduce I/O. It's pointless to add the striping on top of that, you just don't have enough control over the I/O process to get any significant results. Striping both at ORACLE or OS level is only worth doing if you can be sure that no other factors will affect the expected disk response, ie, only when you are using raw devices.

Which raises the age-old question of "are raw devices better than file systems?". I don't wanna get involved in that one except to say that invariably raw devices are faster than file systems, but to what extent is difficult to affirm.

Cheers Received on Fri Dec 22 1995 - 00:00:00 CET