Re: Informix in the SAN environment

Traveller2003 wrote: > > Hi All , > > My question is:- > > Do all the practices mentioned over the years on this new group for > disk layout's hold true still for performance on SAN's? yes _all_ of them! The only difference to keep in mind: On a SAN a volume group or RAID group (or whatever it is called next Tuesday) goes in the text wherever you read about disks (or spindle). [ I fear that you will have to find out, that this innocent sentence is in fact very sarcastic :( ] Doh! Now it is pretty clear, why this is what one can expect to see: - _heavy_ hot spotting and disk contention in the SAN - waaaay too small caches - not even half of the I/Os per second of what one naively expects (looking at the price tags) - overburdened 2Gbit links from SAN to switch, overbooked - bandwith-sharing of a thing as slow as 2 Gbit (compare: SCSI 320) sluggish switch backbones and many more nice surpises! Best is to do some testing, should you be able to! bonnie++ is quite nice (especially random seeks per second) or setup a 5 table INFORMIX db (medium size tables & 3 indexes each) then do an index reorg ..... > > I know NO RAID 5. SAN means RAID5. More than a few, which makes things even worse. The bigger the SAN, the more RAID5 boxen you have. I never saw anything else. *) One cannot expect to offer 1 GB of disk @ >10 USD *and* to motivate customer to go RAID 1+0, which puts price up as high as >20 USD/GB. Not even storage companies salespeople have that sort of guts. *) this does NOT hold for 3U/4U FC (or SCSI) to SATA RAIDs which come into market since about 6 months. But these devices are not what everybody speaks about when mentioning SAN, or I do miss something. > > No doubt you still get performance gains but at what price from the > administration perspective. I admit it is a pretty open ended You gonna need (and you will prolly not get) storage management & monitoring as a (new) technical business funcion. Did someone mention TCO? > question but the idea is to get, hopefully a discussion with a number > of views and ideas to use in the future for SAN environments if the > "old" views are different. I also ask this question as SAN's > technology is becoming more accessible ( Not to all though I know but > I am lucky enough to have worked in a number of environments where > they do have it). > > I am interested in a few that come to mind but other practices people > want to discuss would be of great benefit as well. > > 1. Detached V attached indexes yes > 2. Moving Physical Log and Logical Logs out of Rootdbs double yes, especially with 9.40 and automatic log file addition > 3. Raw devices V cooked files using Vertias raw, raw, raw, or DIRECT I/O (which is labelled as a big O product by Veritas, but does a better job as any fs I know of. But raw is better, as it does not pinn down one of your CPUs, just to get them O admins their beloved ls command showing the chunks ;) > 4. Optimal Size of chunks related to version 9.4 as the 2 gig chunk > limit has been removed. In supporting some customers running a 0.5 - 1.5 TB databases, the 2GB chunks were always only the few huge things. I like to have fragmented tables and I like to have detached indexes in their single chunk dbspaces, all way smaller then 2GB - it makes monitoring so much easier - YMMV [ ... snip ... ] My conclusio always is the same: With the help of Solid State Disks, even a SAN can perform well for a database. dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe