Re: Disk Layout recommendation

zdavek wrote: > We have a small ~4GB database and are switching machines and I thought > this would be a good time to reorganize the disk layout I inherited. > If anyone would like to give me recommendations, I'd appreciate it. > Our current informix dbspace looks like the following. These are > symlinks to the actual dev files. > > 77218 1 1 0 204800 103697 PO- /opt/informix/dev/root.1 > 772f8 1 1 0 204800 0 MO- /opt/informix/dev/root.1-m > 77cd8 2 2 0 655360 732 PO- /opt/informix/dev/dbs0.1 > 78598 2 2 0 655360 0 MO- /opt/informix/dev/dbs0.1-m > 77db8 3 3 0 153600 152823 PO- /opt/informix/dev/temp1.1 > 77e98 4 4 0 153600 152639 PO- /opt/informix/dev/temp2.1 > 77f78 5 5 0 524288 8235 PO- /opt/informix/dev/logs.1 > 78678 5 5 0 524288 0 MO- /opt/informix/dev/logs.1-m > 78058 6 2 0 655360 743 PO- /opt/informix/dev/dbs0.2 > 78758 6 2 0 655360 0 MO- /opt/informix/dev/dbs0.2-m > 78138 7 2 0 655360 18671 PO- /opt/informix/dev/dbs0.3 > 78838 7 2 0 655360 0 MO- /opt/informix/dev/dbs0.3-m > 78218 8 2 0 655360 513972 PO- /opt/informix/dev/dbs0.4 > 78918 8 2 0 655360 0 MO- /opt/informix/dev/dbs0.4-m > > root.1 is on one disk, temp1.1 and logs.1 on a second, and the dbs0.x > spaces are striped across those same pair. > The xxx-m (informix mirror spaces) and temp2.1 have the same layout on > a second pair of disks. (4 disks total) > > The new machine has 6 4GB disks that can be used for dbspaces. > One thing I thought I'd do is use 2GB dbspaces for the dbs0.x instead > of 1.25GB and allocate a total of 6GB. > I'm open to any suggestions. > Thanks. I've not seen any responses, so I'll chip in some thoughts... First off, you've been blessed with a more coherently organized disk layout than most. Please be careful not to wreck the careful work done by your predecessor! You don't mention which version of IDS you are using (nor which platform), but I assume it is not 9.40. If it were, then I'd recommend using large chunks for dbs0 (the main dbspace). Ideally, you want the root dbspace and the logs on separate (and mirrored) disks - and for maximum performance, you want both of those separate from the main data dbspace. One of the disadvantages of the new big disks is that it is harder to achieve that separation. In your circumstances, I'd probably put the logs and the root dbspace on one pair of disks (and I might not even have a separate log dbspace given that it is all on the same spindle), and I'd place the other dbspaces on the other four disks. Yes, by all means increase the size of the chunks. If you've got IDS 9.40, you can create single chunks on the disks -- failing that, use 2 GB chunks rather than smaller ones. You said dbs0.x spaces are striped across a pair of disks? So you have a logical volume manager at work? That complicates the issue in some respects, or it makes your work at the Informix level less relevant. You can either rely on the LVM to balance the load, or you can use Informix to balance the load, but having both at work is likely to be counter-productive. Also, your LVM might handle the mirroring better for you -- or it might not (depends on the LVM and the platform where it is running). My view, not substantiated by recent experience, is that you should use the lowest available level of mirroring, provided that you monitor it for error reports. If the hardware provides mirroring, use that; else if the o/s or LVM provides mirroring, use that; only if nothing else does mirroring should you use the Informix mirroring. There are those who would argue vehemently the other way -- use Informix mirroring for everything. Even with KAIO and the like, there should be no way for Informix mirroring to outperform the o/s or hardware level mirroring. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:3ED303A6.5070908@earthlink.net... > You don't mention which version of IDS you are using (nor which > platform), but I assume it is not 9.40. If it were, then I'd > recommend using large chunks for dbs0 (the main dbspace). Why? Just for ease of administration?