We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G Sun
3310 RAID for Informix 9.4. It will be used exclusively as a database
server for our agency's main application, which I would characterize as a
low volume OLTP app. It doesn't really have a lot of data by current
standards (the dbexport is only a few GB), but it has over 1000 tables and
SPs.

I have recently discovered the Oracle "SAME" paper (
http://www.oracle.com/technology/dep...w2000_same.pdf ).

Since, for our purposes, absolute top performance is not as important as
ease of administration, the SAME idea seems to make sense. There are also
other related papers from HP and IBM, which also support the same (SAME)
:-) idea. It seems to be "catching".

We're going to try it.

The RAID will be configured as a raw RAID10 (striped across 6 mirrored
pairs). [One weakness (with respect to the paper's recommendations) in our
implementation will be that the Sun 3310 RAID restricts stripe depth to
128K, rather than the 1M suggested in the paper.]

I'm currently planning on just one big, "whole enchilada" dbspace. Actually
a single chunk. Going to put everything (data, indexes, logs, etc.) in
rootdbs, and leave the whole load balancing thing to the RAID. I'm also
planing to leave all the logs in rootdbs, too. Since they RAID is the only
storage (except for internal system drives, which will be mirrored and used
for the cooked file system), I can't really see any certain benefit in
cannibalizing the RAID to get a single (mirrored pair) spindle for the logs.
Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient, we'll
see.

The application, written by a consultant, does not use table fragmentation,
so no reason from that perspective to create multiple dbspaces.

I guess it might also be a reasonable to make a separate small space for
rootdbs, and then a second, "enchilada_dbs", for everything else, but am not
currently leaning in this direction.

So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all the
storage, are there reasons NOT to use a single dbspace for everything?

DG



--
David Grove

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"I think not," said Descartes, and disappeared.

On Tue, 14 Sep 2004 13:52:47 -0400, David E. Grove wrote:

Sounds good to me. SOO refreshing to finally have lots of influential on my
band wagon. ;-)

Art S. Kagel

> We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G Sun
> 3310 RAID for Informix 9.4. It will be used exclusively as a database
> server for our agency's main application, which I would characterize as a
> low volume OLTP app. It doesn't really have a lot of data by current
> standards (the dbexport is only a few GB), but it has over 1000 tables and
> SPs.
>
> I have recently discovered the Oracle "SAME" paper (
> http://www.oracle.com/technology/dep...w2000_same.pdf ).
>
> Since, for our purposes, absolute top performance is not as important as
> ease of administration, the SAME idea seems to make sense. There are also
> other related papers from HP and IBM, which also support the same (SAME) :-)
> idea. It seems to be "catching".
>
> We're going to try it.
>
> The RAID will be configured as a raw RAID10 (striped across 6 mirrored
> pairs). [One weakness (with respect to the paper's recommendations) in our
> implementation will be that the Sun 3310 RAID restricts stripe depth to
> 128K, rather than the 1M suggested in the paper.]
>
> I'm currently planning on just one big, "whole enchilada" dbspace. Actually
> a single chunk. Going to put everything (data, indexes, logs, etc.) in
> rootdbs, and leave the whole load balancing thing to the RAID. I'm also
> planing to leave all the logs in rootdbs, too. Since they RAID is the only
> storage (except for internal system drives, which will be mirrored and used
> for the cooked file system), I can't really see any certain benefit in
> cannibalizing the RAID to get a single (mirrored pair) spindle for the logs.
> Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient, we'll
> see.
>
> The application, written by a consultant, does not use table fragmentation,
> so no reason from that perspective to create multiple dbspaces.
>
> I guess it might also be a reasonable to make a separate small space for
> rootdbs, and then a second, "enchilada_dbs", for everything else, but am not
> currently leaning in this direction.
>
> So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all the
> storage, are there reasons NOT to use a single dbspace for everything?
>
> DG
>
>
>

Thank you for commenting, Art.

In my shop, I tell folks that if <whatever-we're-discussing> has Art's
imprimatur, just do it. :-)

Regards,

DG


"Art S. Kagel" <kagel@bloomberg.net> wrote in message
newsan.2004.09.14.15.17.19.219562.1355@bloomberg .net...
> On Tue, 14 Sep 2004 13:52:47 -0400, David E. Grove wrote:
>
> Sounds good to me. SOO refreshing to finally have lots of influential on
my
> band wagon. ;-)
>
> Art S. Kagel
>
> > We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G
Sun
> > 3310 RAID for Informix 9.4. It will be used exclusively as a database
> > server for our agency's main application, which I would characterize as
a
> > low volume OLTP app. It doesn't really have a lot of data by current
> > standards (the dbexport is only a few GB), but it has over 1000 tables
and
> > SPs.
> >
> > I have recently discovered the Oracle "SAME" paper (
> >
http://www.oracle.com/technology/dep...w2000_same.pdf ).
> >
> > Since, for our purposes, absolute top performance is not as important as
> > ease of administration, the SAME idea seems to make sense. There are
also
> > other related papers from HP and IBM, which also support the same (SAME)
:-)
> > idea. It seems to be "catching".
> >
> > We're going to try it.
> >
> > The RAID will be configured as a raw RAID10 (striped across 6 mirrored
> > pairs). [One weakness (with respect to the paper's recommendations) in
our
> > implementation will be that the Sun 3310 RAID restricts stripe depth to
> > 128K, rather than the 1M suggested in the paper.]
> >
> > I'm currently planning on just one big, "whole enchilada" dbspace.
Actually
> > a single chunk. Going to put everything (data, indexes, logs, etc.) in
> > rootdbs, and leave the whole load balancing thing to the RAID. I'm also
> > planing to leave all the logs in rootdbs, too. Since they RAID is the
only
> > storage (except for internal system drives, which will be mirrored and
used
> > for the cooked file system), I can't really see any certain benefit in
> > cannibalizing the RAID to get a single (mirrored pair) spindle for the
logs.
> > Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient,
we'll
> > see.
> >
> > The application, written by a consultant, does not use table
fragmentation,
> > so no reason from that perspective to create multiple dbspaces.
> >
> > I guess it might also be a reasonable to make a separate small space for
> > rootdbs, and then a second, "enchilada_dbs", for everything else, but am
not
> > currently leaning in this direction.
> >
> > So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all
the
> > storage, are there reasons NOT to use a single dbspace for everything?
> >
> > DG
> >
> >
> >

Just want to clarify--

I didn't mean to suggest that the O paper was the source of the RAID10 idea.
I have read your periodic rants for a long time.

I was just trying to zero in on the one-dbspace-for-all thing.

DG




"Art S. Kagel" <kagel@bloomberg.net> wrote in message
newsan.2004.09.14.15.17.19.219562.1355@bloomberg .net...
> On Tue, 14 Sep 2004 13:52:47 -0400, David E. Grove wrote:
>
> Sounds good to me. SOO refreshing to finally have lots of influential on
my
> band wagon. ;-)
>
> Art S. Kagel
>
> > We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G
Sun
> > 3310 RAID for Informix 9.4. It will be used exclusively as a database
> > server for our agency's main application, which I would characterize as
a
> > low volume OLTP app. It doesn't really have a lot of data by current
> > standards (the dbexport is only a few GB), but it has over 1000 tables
and
> > SPs.
> >
> > I have recently discovered the Oracle "SAME" paper (
> >
http://www.oracle.com/technology/dep...w2000_same.pdf ).
> >
> > Since, for our purposes, absolute top performance is not as important as
> > ease of administration, the SAME idea seems to make sense. There are
also
> > other related papers from HP and IBM, which also support the same (SAME)
:-)
> > idea. It seems to be "catching".
> >
> > We're going to try it.
> >
> > The RAID will be configured as a raw RAID10 (striped across 6 mirrored
> > pairs). [One weakness (with respect to the paper's recommendations) in
our
> > implementation will be that the Sun 3310 RAID restricts stripe depth to
> > 128K, rather than the 1M suggested in the paper.]
> >
> > I'm currently planning on just one big, "whole enchilada" dbspace.
Actually
> > a single chunk. Going to put everything (data, indexes, logs, etc.) in
> > rootdbs, and leave the whole load balancing thing to the RAID. I'm also
> > planing to leave all the logs in rootdbs, too. Since they RAID is the
only
> > storage (except for internal system drives, which will be mirrored and
used
> > for the cooked file system), I can't really see any certain benefit in
> > cannibalizing the RAID to get a single (mirrored pair) spindle for the
logs.
> > Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient,
we'll
> > see.
> >
> > The application, written by a consultant, does not use table
fragmentation,
> > so no reason from that perspective to create multiple dbspaces.
> >
> > I guess it might also be a reasonable to make a separate small space for
> > rootdbs, and then a second, "enchilada_dbs", for everything else, but am
not
> > currently leaning in this direction.
> >
> > So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all
the
> > storage, are there reasons NOT to use a single dbspace for everything?
> >
> > DG
> >
> >
> >

On Tue, 14 Sep 2004 16:11:41 -0400, David E. Grove wrote:

> Just want to clarify--
>
> I didn't mean to suggest that the O paper was the source of the RAID10 idea.
> I have read your periodic rants for a long time.
>
> I was just trying to zero in on the one-dbspace-for-all thing.

Wasn;t taking umbridge(SP?). Just enjoying the support. Actually I'd seen
that Oracle dos about a year ago, just thought it had been buried.

Art S. Kagel

> DG
>
>
>
>
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> newsan.2004.09.14.15.17.19.219562.1355@bloomberg .net...
>> On Tue, 14 Sep 2004 13:52:47 -0400, David E. Grove wrote:
>>
>> Sounds good to me. SOO refreshing to finally have lots of influential on
> my
>> band wagon. ;-)
>>
>> Art S. Kagel
>>
>> > We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G
> Sun
>> > 3310 RAID for Informix 9.4. It will be used exclusively as a database
>> > server for our agency's main application, which I would characterize as
> a
>> > low volume OLTP app. It doesn't really have a lot of data by current
>> > standards (the dbexport is only a few GB), but it has over 1000 tables
> and
>> > SPs.
>> >
>> > I have recently discovered the Oracle "SAME" paper (
>> >
> http://www.oracle.com/technology/dep...w2000_same.pdf ).
>> >
>> > Since, for our purposes, absolute top performance is not as important as
>> > ease of administration, the SAME idea seems to make sense. There are
> also
>> > other related papers from HP and IBM, which also support the same (SAME)
> :-)
>> > idea. It seems to be "catching".
>> >
>> > We're going to try it.
>> >
>> > The RAID will be configured as a raw RAID10 (striped across 6 mirrored
>> > pairs). [One weakness (with respect to the paper's recommendations) in
> our
>> > implementation will be that the Sun 3310 RAID restricts stripe depth to
>> > 128K, rather than the 1M suggested in the paper.]
>> >
>> > I'm currently planning on just one big, "whole enchilada" dbspace.
> Actually
>> > a single chunk. Going to put everything (data, indexes, logs, etc.) in
>> > rootdbs, and leave the whole load balancing thing to the RAID. I'm also
>> > planing to leave all the logs in rootdbs, too. Since they RAID is the
> only
>> > storage (except for internal system drives, which will be mirrored and
> used
>> > for the cooked file system), I can't really see any certain benefit in
>> > cannibalizing the RAID to get a single (mirrored pair) spindle for the
> logs.
>> > Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient,
> we'll
>> > see.
>> >
>> > The application, written by a consultant, does not use table
> fragmentation,
>> > so no reason from that perspective to create multiple dbspaces.
>> >
>> > I guess it might also be a reasonable to make a separate small space for
>> > rootdbs, and then a second, "enchilada_dbs", for everything else, but am
> not
>> > currently leaning in this direction.
>> >
>> > So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all
> the
>> > storage, are there reasons NOT to use a single dbspace for everything?
>> >
>> > DG
>> >
>> >
>> >

On Tue, 14 Sep 2004 15:56:26 -0400, David E. Grove wrote:

> Thank you for commenting, Art.
>
> In my shop, I tell folks that if <whatever-we're-discussing> has Art's
> imprimatur, just do it. :-)

Now, I'm blushing. Thanks for the ... whatever it is. But watch me, I throw
a zinger every once in a while. 8-0

Art S. Kagel

> Regards,
>
> DG
>
>
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> newsan.2004.09.14.15.17.19.219562.1355@bloomberg .net...
>> On Tue, 14 Sep 2004 13:52:47 -0400, David E. Grove wrote:
>>
>> Sounds good to me. SOO refreshing to finally have lots of influential on
> my
>> band wagon. ;-)
>>
>> Art S. Kagel
>>
>> > We are building a brand new system: 2 CPU, 16G, Sun V480 with 12 x 72G
> Sun
>> > 3310 RAID for Informix 9.4. It will be used exclusively as a database
>> > server for our agency's main application, which I would characterize as
> a
>> > low volume OLTP app. It doesn't really have a lot of data by current
>> > standards (the dbexport is only a few GB), but it has over 1000 tables
> and
>> > SPs.
>> >
>> > I have recently discovered the Oracle "SAME" paper (
>> >
> http://www.oracle.com/technology/dep...w2000_same.pdf ).
>> >
>> > Since, for our purposes, absolute top performance is not as important as
>> > ease of administration, the SAME idea seems to make sense. There are
> also
>> > other related papers from HP and IBM, which also support the same (SAME)
> :-)
>> > idea. It seems to be "catching".
>> >
>> > We're going to try it.
>> >
>> > The RAID will be configured as a raw RAID10 (striped across 6 mirrored
>> > pairs). [One weakness (with respect to the paper's recommendations) in
> our
>> > implementation will be that the Sun 3310 RAID restricts stripe depth to
>> > 128K, rather than the 1M suggested in the paper.]
>> >
>> > I'm currently planning on just one big, "whole enchilada" dbspace.
> Actually
>> > a single chunk. Going to put everything (data, indexes, logs, etc.) in
>> > rootdbs, and leave the whole load balancing thing to the RAID. I'm also
>> > planing to leave all the logs in rootdbs, too. Since they RAID is the
> only
>> > storage (except for internal system drives, which will be mirrored and
> used
>> > for the cooked file system), I can't really see any certain benefit in
>> > cannibalizing the RAID to get a single (mirrored pair) spindle for the
> logs.
>> > Am I wrong, here? Anyway, we hope 6 logical spindles is sufficient,
> we'll
>> > see.
>> >
>> > The application, written by a consultant, does not use table
> fragmentation,
>> > so no reason from that perspective to create multiple dbspaces.
>> >
>> > I guess it might also be a reasonable to make a separate small space for
>> > rootdbs, and then a second, "enchilada_dbs", for everything else, but am
> not
>> > currently leaning in this direction.
>> >
>> > So (finally), the QUESTION: In our context, with a 6x2 RAID10 for all
> the
>> > storage, are there reasons NOT to use a single dbspace for everything?
>> >
>> > DG
>> >
>> >
>> >

"David E. Grove" <david_grove@correct.state.ak.us> wrote in message
news:10kej7ohosp5j65@corp.supernews.com...
> Thank you for commenting, Art.
>
> In my shop, I tell folks that if <whatever-we're-discussing> has Art's
> imprimatur, just do it. :-)
>
> Regards,
>
> DG

We *sort* of do the same thing with our clients, except that we present his
ideas and analysis as our own and get all the credit!

David E. Grove wrote:
> Thank you for commenting, Art.
>
> In my shop, I tell folks that if <whatever-we're-discussing> has Art's
> imprimatur, just do it. :-)

On issues of RAID, in particular, I would agree.

> "Art S. Kagel" <kagel@bloomberg.net> wrote :
>> Sounds good to me. SOO refreshing to finally have lots of
>> influential on my band wagon. ;-)
>>
>>David Grove wrote:
>>>We are building a brand new system: [...]
>>>
>>> So (finally), the QUESTION: are there reasons NOT to use a
>>> single dbspace for everything?

The only mild reason for being concerned about a single dbspace is if
any of the tables in your (still relatively small) database is
encroaching on the limits of what will fit in a single partition. If
you do have a large table, you will have to fragment it to keep it as
a single table, and in released code, you have to each fragment in a
separate dbspace. (There are plans to change that, but that is not
available yet.) So, if you have any big tables that might outgrow
their single fragment, you will need more dbspaces (or an upgrade to
IDS that isn't available yet).

Otherwise, it is perfectly reasonable to use a single dbspace for
everything, basically for the reasons outlined.

The ultra-purist might want to argue that the physical log on on
mirrored disk and the logical log on another mirrored disk might give
better performance, but you'd probably be wasting space for neglible
performance benefit and extra complexity in the setup.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Art S. Kagel wrote:

> Actually I'd seen
> that Oracle dos about a year ago, just thought it had been buried.


Not buried at all. In fact, in 10g, we build in and automate the
striping and mirroring (and rebalancing on disk addition/removal) with
Automatic Storage Management (ASM) -
http://www.oracle.com/technology/pro...asm/index.html

Thank you, Jonathan. We always appreciate your comments-- another resource
we can "take to the bank."

> The only mild reason for being concerned about a single dbspace is if
> any of the tables in your (still relatively small) database is
> encroaching on the limits of what will fit in a single partition

I had been planning on a single 72G dbspace (a single chunk, actually [on
the RAID]). That's over 10 times the size of the whole database, and should
allow for >8 years of growth.

I expect to create the dbspace and import a test database, today. I guess
I'll find out soon enough, but I am expecting 9.4 to permit such a single
large chunk. Even if not a single chunk, I can always create a bunch of 2G
chunks, right? (I never fully understood the absolute demands for >2G
chunks, since you can just create however many you need.)

Anyway, I am presuming your caution about encroaching upon the limits of a
single dbspace was just to emphasize proper planning for space, and not any
kind of hint that there is any difficulty with large chunks in 9.4.

Regards,

DG



"Jonathan Leffler" <jleffler@earthlink.net> wrote in message
news:4147D563.5070306@earthlink.net...
> David E. Grove wrote:
> > Thank you for commenting, Art.
> >
> > In my shop, I tell folks that if <whatever-we're-discussing> has Art's
> > imprimatur, just do it. :-)
>
> On issues of RAID, in particular, I would agree.
>
> > "Art S. Kagel" <kagel@bloomberg.net> wrote :
> >> Sounds good to me. SOO refreshing to finally have lots of
> >> influential on my band wagon. ;-)
> >>
> >>David Grove wrote:
> >>>We are building a brand new system: [...]
> >>>
> >>> So (finally), the QUESTION: are there reasons NOT to use a
> >>> single dbspace for everything?
>
> The only mild reason for being concerned about a single dbspace is if
> any of the tables in your (still relatively small) database is
> encroaching on the limits of what will fit in a single partition. If
> you do have a large table, you will have to fragment it to keep it as
> a single table, and in released code, you have to each fragment in a
> separate dbspace. (There are plans to change that, but that is not
> available yet.) So, if you have any big tables that might outgrow
> their single fragment, you will need more dbspaces (or an upgrade to
> IDS that isn't available yet).
>
> Otherwise, it is perfectly reasonable to use a single dbspace for
> everything, basically for the reasons outlined.
>
> The ultra-purist might want to argue that the physical log on on
> mirrored disk and the logical log on another mirrored disk might give
> better performance, but you'd probably be wasting space for neglible
> performance benefit and extra complexity in the setup.
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/