Re: Why put logs away from rootdbs?

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

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