Re: Why put logs away from rootdbs?

I work with a SAN as well and it is very nice to not have to little worry where data lives. Originally I had to be prepared to roll off of a RAID 5 configuration if the disk access was too slow. It never happened. Now I find it best to just move them out of habit. It doesn't harm anything to move them and little if they stay. The only other point I would make is that with Dynamic Logical Logs it could make a difference if they are split off. But since I have not had to use it or read enough on it I could not say for sure. >I don't understand why having the physical log in the rootdbs increases >the >probability of the root dbspace filling. The physical log is of fixed >size, >determined at initialisation. >Personally, hen working on SANs I put very little thought into >placement, >since there is such a level of indirection between the logical view as >presented to the OS and the physicality of the storage that it's >next-to-pointless to worry about it. >> Plus if there was ever a need to move away from RAID this could be >> completed with little changes to the Informix setup. >That's a reasonable point I hadn;t thought about previously. >"Eric Rowell" <erowell@knology.net> wrote in message >news:c5126c$pdv$1@terabinaries.xmission.com... > > Tables still become fragmented at the Informix level and they become a > management issue for Informix. Also what happens if your Root space > fills. It doesn't change as much as you think. Or at least I would not > suggest handling thing any different. > > Yes under the surface it is all one disk but I would not suggest doing > anything different then one would do if it was separate disks. > > Plus if there was ever a need to move away from RAID this could be > completed with little changes to the Informix setup. > > > On Wed, 2004-04-07 at 07:35, Andy Kent wrote: > > Sure, that's the conventional wisdom, but surely RAID blows all that > > away? I can think of some reasons why you'd still have separate > > dbspaces (static vs volatile tables, temp dbspaces, critical vs. > > non-critical ... ), but what I'm at a loss to understand is why one > > would need to separate rootdbs and logs on an all-RAID box. > > > > Andy > > > > "David Williams" <djw@smooth1.fsnet.co.uk> wrote in message news:<c4uv0q$mo0$1@news6.svr.pol.co.uk>... > > > "Dirk Moolman" <DirkM@mxgroup.co.za> wrote in message > > > news:c4umft$d2$1@terabinaries.xmission.com... > > > > > > > > I think it really bores down to the physical disk spindles - if you can > > > > split your physical and logical logs off onto different disks, you will > > > > have better performance. > > > > > > and put alternate logical logs on seperate disks. Whilst ontape/onbar is > > > backup up on you can be writing to the next one without disk contention. > > > > > > Also the physical log (and also each logical log) is always a sequential > > > write > > > so put it on a seperate disk so that the disk heads don't move away from > > > where they need to be. > > > > > > > > > > These logs are used intensely, and you don't want other data to share > > > > the same disks. Well, you can share disks, but for best performance you > > > > should split and keep these logs separate. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] > > > > On Behalf Of Andy Kent > > > > Sent: Tuesday, April 06, 2004 2:19 PM > > > > To: informix-list@iiug.org > > > > Subject: Why put logs away from rootdbs? > > > > > > > > What are the reasons why Informix keeps on about moving your logical > > > > and physical logs away from rootdbs? Surely if the whole instance is > > > > going into a single RAID 1+0 array it doesn't make any difference? OK, > > > > a bit more to glean from onstat -D perhaps, but is there any other > > > > benefit? > > > > > > > > In a rare break with tradition for me, this is a REAL, IN-USE email > > > > address. > > > > > > > > Andy Kent > > > > > > > > sending to informix-list > > > > sending to informix-list sending to informix-list sending to informix-list sending to informix-list sending to informix-list sending to informix-list