Informix and HP AutoRaid

Hardware: HP 9000 / K200 class OS: HPUX 10.20 IDS: 7.30.uc7 There's talk of getting an HP AutoRaid assembly for our POS / warehousing system (using the 'other' database on a HP K570). I've come to understand that the box in question will have the ability to house our Informix data as well (accessed from the K200). While I've cut my teeth on data/disk configurations and fragmentation, this possibility sounds very different from the system I've grown to know and love <G>. I have a few questions: 1. Is this setup reasonable? 2. What are the differences from a DBA's point of view? I'm used to disk setup, data placement, fragmentation, etc. Does this setup relieve the DBA of those type of responsibilities? 3. Are there some 'gotchas'? I've heard that Informix and RAID may not mix. We're probably split 50-50 between OLTP and batch processing. 4. In relation to 2), what setup and maintenance issues exist in this environment? I'm able to tell on which disk my tables are; I know where everything is. How different is AutoRaid? 5. Anything I left out? If the return message is too long, please answer via direct EMail. Inquiring minds like mine want to know. <G> TIA John Carlson Informix DBA WHSmith USA

Also, how are reorgs, drop/creating indices, etc. ( the typical DBA stuff ) different? TIA John Carlson Informix DBA WHSmith USA Carlson@WHSmith wrote: > > Hardware: HP 9000 / K200 class > OS: HPUX 10.20 > IDS: 7.30.uc7 > > There's talk of getting an HP AutoRaid assembly for our POS / > warehousing system (using the 'other' database on a HP K570). I've come > to understand that the box in question will have the ability to house > our Informix data as well (accessed from the K200). While I've cut my > teeth on data/disk configurations and fragmentation, this possibility > sounds very different from the system I've grown to know and love <G>. > I have a few questions: > > 1. Is this setup reasonable? > 2. What are the differences from a DBA's point of view? I'm used to > disk setup, data placement, fragmentation, etc. Does this setup relieve > the DBA of those type of responsibilities? > 3. Are there some 'gotchas'? I've heard that Informix and RAID may not > mix. We're probably split 50-50 between OLTP and batch processing. > 4. In relation to 2), what setup and maintenance issues exist in this > environment? I'm able to tell on which disk my tables are; I know where > everything is. How different is AutoRaid? > 5. Anything I left out? > > If the return message is too long, please answer via direct EMail. > Inquiring minds like mine want to know. <G> > > TIA > > John Carlson > Informix DBA > WHSmith USA

In article <370BB1C2.7206E6A8@bellsouth.net>, "Carlson@WHSmith" <carlson1@bellsouth.net> writes >Hardware: HP 9000 / K200 class >OS: HPUX 10.20 >IDS: 7.30.uc7 > >There's talk of getting an HP AutoRaid assembly for our POS / >warehousing system (using the 'other' database on a HP K570). I've come >to understand that the box in question will have the ability to house >our Informix data as well (accessed from the K200). While I've cut my >teeth on data/disk configurations and fragmentation, this possibility >sounds very different from the system I've grown to know and love <G>. >I have a few questions: > >1. Is this setup reasonable? >2. What are the differences from a DBA's point of view? I'm used to >disk setup, data placement, fragmentation, etc. Does this setup relieve >the DBA of those type of responsibilities? >3. Are there some 'gotchas'? I've heard that Informix and RAID may not >mix. We're probably split 50-50 between OLTP and batch processing. >4. In relation to 2), what setup and maintenance issues exist in this >environment? I'm able to tell on which disk my tables are; I know where >everything is. How different is AutoRaid? >5. Anything I left out? > >If the return message is too long, please answer via direct EMail. >Inquiring minds like mine want to know. <G> > > > >TIA > > >John Carlson >Informix DBA >WHSmith USA Hi John, I am using HP AutoRAID on two K-class boxes (a DEV and a PROD one), for Informix OLTP application (with overnight batch) and am very pleased with them overall, their main benefit is the high availability of the data combined with good performance (for my needs). Firstly, they are extremely easy to setup and use (the term "fit and forget" springs to mind) but there are some guidelines to follow: 1. Fill all the slots with disks to give the AutoRAID the max # of spindles to internally place data over; 2. Go for the extra cache controller and populate both controllers with the full amount of cache RAM; 3. Connect the two controllers to their own HSC FWD SCSI adapter on the K-machine. (HP's PB bus is far inferior to the HSC SCSI option); 4. Leave at least 20-30% of the disk space unallocated, this will more or less guarantee that the most frequently accessed (and changed) data blocks will reside in the RAID 1/0 area; 5. Use both SCSI channels (this will require LVM experience) to spread the I/O over; 6. Use a disk as a 'hot-spare', this means the performance of the unit is only impaired during rebuild and not until you find out the disk has failed, order replacement and finally replace failed disk!). You need to spend on the extra cost options (you pays yer money...) to ensure the unit is operating in the most efficient manner. The AutoRAID will dynamically reconfigure itself (it has 'cache storage levels', RAID 1/0 levels (next best) and lastly RAID 5 levels), to ensure that data is kept in the most appropiate place according to disk usage. To HP-UX, the pool of storage can be divvy'd up using LVM commands or by the SAM interface, into 'LUNS' - which are visible as disk devices (you get two paths to the one LUN, mainly for resilience, which also enables you to place half the allocated LUNS on one channel and vice-versa to maximise the I/O bandwidth. The unit is very reliable and highly available, we had two disks fail early on and each time all we had to do was pull the failed disk out and replace with a new one, (we use hot-spare again for best performance). If you do a lot of writes then I have heard that the cache can be a bottleneck, also we don't use fragmentation yet but are planning to use the new fibre connected standalone disks for that (to locate our largest and most intensively accessed tables), leaving the bulk of the database on the AutoRAID). We've had no problems with placing the rootdbs, llogdbs and plogdbs on the AutoRAID but I'll probably move these out onto the new fibre disks when I get the chance. TTFN -- Simon Barber