Re: Disk striping and tablespaces

In article <1995Feb22.082638.1_at_cbr.hhcs.gov.au>

           Bruce.Pihlamae_at_a1.cbr.hhcs.gov.au "Bruce Pihlamae" writes:
> In article <3id2q7$2ho_at_homer.alpha.net>, nwojtal_at_earth.execpc.com (Norman
> Wojtal) writes:
> >
> > We are installing an HP system with multiple disk drives an multiple scsi
> > controllers. We plan to stripe the file systems/raw devices across disk
> > drives/controllers.
> >
> > Given that all file systems/raw devices will be striped across disks and
> > controllers is there any PERFORMANCE reason to worry about which file
> > system/raw device the tablespaces, rollback segments, etc. are on or which
> > tablespace a table or index is in?
>
> No performance reasons but you may have reliability problems.
>
> (etc)

Two points;

1. A good getaround for this is (if you have got the disk space and the OS supports this - I don't know HP) to mirror *each* spindle to another as `far away' logically as possible (i.e. on a different SCSI chain, a different SCSI controller, in a separate disk bay etc). Then when you have mirrored every whole spindle to another, stripe across the `logical drives' formed by the mirror pairs.
2. It's not entirely true to say that there are *no* performance reasons not to put everything on the same stripe set; you may still gain from having two stripe groups across different sets of disks (e.g. use 12 disks, mirror 6 to 6, and use this as one stripe set, then take another 12 disks and do this again, putting indexes on one stripe set and tables on the other). It is also important (if you've got the patience) to put the most frequently-accessed material near the centre of physical spindles.

As an afterthought, another good idea is to make your stripes equal sizes, or multiples of a common size, to make reorganisation easier. And don't forget cylinder boundaries!

Seriously, we recently took a system which had `grown' organically, and with a *lot* of help from our processor supplier, did just what I've described above. It's a bit difficult to tell exactly what performance gains if any we achieved, because we changed a number of other things at around the same time and we don't collect incredibly detailed stats always, but it's certainly easier to manage now...

-- 
Tom Cooke               tom_at_tomcooke.demon.co.uk             +44 (0)1782 748027
North Staffordshire Hospital Computer Centre, Stoke-on-Trent, Staffordshire, UK