I read through about half of the O document and for
the most part got sold on the idea of SAME. However
there are some Informix specific maintanence issues
that spring to mind:
1) Table and index reorgs
2) Is this a viable option for log files?
3) Should you let the root dbspace also be the temp
dbspace?
I would imagine that since Art gave an okay to Davids
suggestion that he didn't see any glaring problems
with the one large dbspace idea, but I would like to
see some discussion to the points and any others that
can be thought of.
DL Redden
"David E. Grove" <david_grove@correct.state.ak.us>
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.
DG
"Art S. Kagel" wrote in message
news
an.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
> >
> >
> >
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
sending to informix-list