Stripe and Mirror Everything?
A DBA planning a new Informix 9.4 server on a Sun V480 with a 12-disk RAID10 array asked whether, following Oracle's "SAME" (Stripe And Mirror Everything) approach, it's acceptable to put everything -- data, indexes and logical/physical logs -- into a single large rootdbs chunk on the striped/mirrored array, rather than splitting into multiple dbspaces or dedicating spindles to logs. Art Kagel simply endorsed the plan as sound, noting it matched his long-standing advice; no objections or caveats were raised, and the thread ends with that informal agreement rather than detailed technical discussion.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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/deploy/availability/pdf/oow2000_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/deploy/availability/pdf/oow2000_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
news:pan.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/deploy/availability/pdf/oow2000_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
news:pan.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/deploy/availability/pdf/oow2000_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
> news:pan.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/deploy/availability/pdf/oow2000_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
> news:pan.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/deploy/availability/pdf/oow2000_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
>> >
>> >
>> >