Informix and RAID

#1 (**permalink**) 04-20-2008, 08:13 AM

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?
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,
________________________________________
Domingo Fern=E1ndez
Servicio de Inform=E1tica
Universidad de Cantabria
Tfno: 942201084
Fax: 942201083
e-mail: Domingo.Fernandez@gestion.unican.es

------_=_NextPart_001_01C4DEB7.274200F8
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6603.0">
<TITLE>Informix and RAID</TITLE>
</HEAD>
<BODY>

 

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? 

Kinds regards,

 ___________________________________ _____

 Domingo Fern=E1ndez

 Servicio de Inform=E1tica

 Universidad de Cantabria

 Tfno: 942201084

 Fax: 942201083

 e-mail: =
Domingo.Fernandez@gestion.unican.es


</BODY>
</HTML>
------_=_NextPart_001_01C4DEB7.274200F8--
sending to informix-list

#2 (**permalink**) 04-20-2008, 08:13 AM

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

#3 (**permalink**) 04-20-2008, 08:13 AM

In article <1102689507.780115a3c1139c370adf08eac9c2039f@teran ews>,
"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

#4 (**permalink**) 04-20-2008, 08:13 AM

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.

#5 (**permalink**) 04-20-2008, 08:13 AM

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

#6 (**permalink**) 04-20-2008, 08:13 AM

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,

#7 (**permalink**) 04-20-2008, 08:13 AM

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,

#8 (**permalink**) 04-20-2008, 08:13 AM

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,

#9 (**permalink**) 04-20-2008, 08:13 AM

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

#10 (**permalink**) 04-20-2008, 08:13 AM

Everybody duck, Art is heading this way :-))

Maybe he's mellowed with age:-)

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.
>

--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode