Informix and RAID
A DBA moving an IDS installation from mirrored chunks spread across individual disks to a RAID5 array asked whether it still makes sense to separate critical, non-critical and temporary data into different chunks. Respondents strongly advised against RAID5 for databases (citing the write penalty and other issues, pointing to Art Kagel's RAID5 rant and baarf.com); one dissenter argued a controller with write-back cache makes RAID5 acceptable for small/medium systems, which Kagel rejected. On the actual question, the advice was yes: keep a sensible logical layout with separate dbspaces/chunks (temp, smart blobs, not everything in rootdbs) for fragmentation, fragment elimination and better onstat monitoring, even though physical placement matters less on RAID. No single agreed outcome from the original poster is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DEB7.274200F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am an administrator of IDS. Up till now we have stored data in different chunks distributed betwen = different disks to obtain a better performance in read-write operations. We had the chunks distributed and mirrored in different disks. We are going to change the hosts and in the new one we are going to have = a storage system with RAID5. Is it reasonable to build different chunks to store critical, = non-critical, temporary, etc...... data?
Fernandez Garcia, Domingo wrote:
> This is a multi-part message in MIME format.
>
Please don't.
>
> Hi,
> I am an administrator of IDS.
> Up till now we have stored data in different chunks distributed betwen
> different disks to obtain a better performance in read-write operations.
> We had the chunks distributed and mirrored in different disks.
> We are going to change the hosts and in the new one we are going to have
> a storage system with RAID5.
RAID 5 is a *really* *bad* *idea* for databases. Wait for Art's rant.
> Is it reasonable to build different chunks to store critical,
> non-critical, temporary, etc...... data?
Yes, of course. You'll want some marked as temporary, you might want
some marked as smart-blobs. You really don't want everything in one
huge rootdbs.
> From the viewpoint to improve the performance don't think so, we could
> store all data in one only big chunk
The physical placement of chunks on a raid doesn't matter as much as it
does in a jbod. That's no excuse for not getting the logical layout
right, though.
> but could we have other reasons to
> build different chunks to store data?
Tables can be fragmented, fragments can be eliminated, better numbers
from onstat.
--
rh
In article <1102689507.780115a3c1139c370adf08eac9c2039f@teranews>, "Fernandez Garcia, Domingo" <domingo.fernandez@gestion.unican.es> wrote: > Up till now we have stored data in different chunks distributed betwen = > different disks to obtain a better performance in read-write operations. > We had the chunks distributed and mirrored in different disks. > We are going to change the hosts and in the new one we are going to have = > a storage system with RAID5. Ah, so you have wearied of sitting around, watching Informix run, and you now want to cause some REAL performance problems for yourself? Unless this is a very nearly read-only database, and I bet it isn't, RAID-5 will cause your performance to suck mightily. Some of the more recent arrays with heroic amounts of cache manage to get RAID-5 to shamble along at an OK pace, but one has to marvel at the waste of effort and resources. Karl
I think that as long as the RAID 5 controller has a reasonable write-back cache memory ( 256Mb seems to be the standard now) and you are talking about a small to medium size Informix installation, RAID-5 is a OK solution. Without a write-back cache is a bad choice indeed. Just my 2 cents.
dbsolution@gmail.com wrote: > I think that as long as the RAID 5 controller has a reasonable > write-back cache memory ( 256Mb seems to be the standard now) and you > are talking about a small to medium size Informix installation, RAID-5 > is a OK solution. Without a write-back cache is a bad choice indeed. > Just my 2 cents. > WRONG! Period. Even if the performance hit were the only major problem with RAID5 you'd be wrong. Test it. No amount of cache can make up for a 50% write performance penalty. Not possible. But performance while the most obvious problem, and nothing to ignore, is the LEAST of the problems with RAID5. You can read my RAID5 Rant and the testimonies of MANY other pundits, including system engineers at the big O, on the BAARF (Battle Against Any RAID Five/Four/Free): www.baarf.com Art S. Kagel
Fernandez Garcia, Domingo wrote: NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! See my RAID5 Rant and those of many others on the BAARF web site: www.baarf.com Art S. Kagel > Hi, > I am an administrator of IDS. > Up till now we have stored data in different chunks distributed betwen = > different disks to obtain a better performance in read-write operations. > We had the chunks distributed and mirrored in different disks. > We are going to change the hosts and in the new one we are going to have = > a storage system with RAID5. > Is it reasonable to build different chunks to store critical, = > non-critical, temporary, etc...... data? > From the viewpoint to improve the performance don't think so, we could = > store all data in one only big chunk, but could we have other reasons to = > build different chunks to store data?=20 > Kinds regards,
Fernandez Garcia, Domingo wrote: NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! See my RAID5 Rant and those of many others on the BAARF web site: www.baarf.com Art S. Kagel > Hi, > I am an administrator of IDS. > Up till now we have stored data in different chunks distributed betwen = > different disks to obtain a better performance in read-write operations. > We had the chunks distributed and mirrored in different disks. > We are going to change the hosts and in the new one we are going to have = > a storage system with RAID5. > Is it reasonable to build different chunks to store critical, = > non-critical, temporary, etc...... data? > From the viewpoint to improve the performance don't think so, we could = > store all data in one only big chunk, but could we have other reasons to = > build different chunks to store data?=20 > Kinds regards,
Fernandez Garcia, Domingo wrote: NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! NO RAID5!! See my RAID5 Rant and those of many others on the BAARF web site: www.baarf.com Art S. Kagel > Hi, > I am an administrator of IDS. > Up till now we have stored data in different chunks distributed betwen = > different disks to obtain a better performance in read-write operations. > We had the chunks distributed and mirrored in different disks. > We are going to change the hosts and in the new one we are going to have = > a storage system with RAID5. > Is it reasonable to build different chunks to store critical, = > non-critical, temporary, etc...... data? > From the viewpoint to improve the performance don't think so, we could = > store all data in one only big chunk, but could we have other reasons to = > build different chunks to store data?=20 > Kinds regards,
dbsolution@gmail.com wrote: > I think that as long as the RAID 5 controller has a reasonable > write-back cache memory ( 256Mb seems to be the standard now) and you > are talking about a small to medium size Informix installation, RAID-5 > is a OK solution. Without a write-back cache is a bad choice indeed. > Just my 2 cents. > WRONG! Period. Even if the performance hit were the only major problem with RAID5 you'd be wrong. Test it. No amount of cache can make up for a 50% write performance penalty. Not possible. But performance while the most obvious problem, and nothing to ignore, is the LEAST of the problems with RAID5. You can read my RAID5 Rant and the testimonies of MANY other pundits, including system engineers at the big O, on the BAARF (Battle Against Any RAID Five/Four/Free): www.baarf.com Art S. Kagel