SEO

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







_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
sending to informix-list

my two 0.01

haven't played much with 9.4 however

i would use a certain number of dbspaces because of:

1: paralel dbspace backups
2: better use of PDQ ( a scan thread per dbspace )
3: (re)loading tables using hpl can be faster when having multiple dbspaces.
-- can be faster needs to be tested!!!



See you

Superboer.

BTW how hard is it to maintain a xx number of dbspaces;

On Tue, 14 Sep 2004 17:46:58 -0400, DL Redden wrote:


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

ABSOLUTELY! Let's kick this one around the block a few times. Heck, there
are so many of endless discussions of nothing here that I often expect to see
Jerry Seinfeld's sig in there somewhere. This one has an important point so
let's keep it in the air folk.

As to my agreement... OK, I definitely agree that so long as there are not
too many drives (and I would not let it get as far as the O doc does, ie into
the dozens of mirrored pairs) there's nothing wrong with using a single large
stripe. Indeed as many of you know we use a 'plaid' a stripe of 5 RAID10
sets, each made of 5 mirrored pairs, bringing 25 pairs of spindles to every
read or write. But that's my limit. I don't think I'd approve a 50 or 100
pair array as a single unit.

Keep in mind something that the O guys just glanced over - the bottleneck in a
large array is NOT the drives but the controllers. Five fast drives can
deliver data to an ULTRA320 SCSI controller faster than the controller can
cache it or deliver it to the system bus or network! Building arrays using
controllers with 16 drives on them all in the same array is going to tank on
sequential reads or large readahead (my feelings about THAT are well known as
well). So, caviat emptor!

Either way in David's configuration of 6 pairs the array size is not a problem
but I'd want to make sure there were at least 4 controllers in use, two on
each side of the mirror (plus redundancy 4 controllers of course) handling
only 3 drives each.

As to dbspaces, personally I prefer several dbspaces just for administrative
reasons, and I DO like to keep ROOT, logical logs, and physical logs on a
separate structure. I like to keep indexes and data on separate dbspaces
also, and the issue raised about fragmenting larger tables is valid whether
you are reaching the 16MM page limit or not. Again, with David's description
of their data, and his willingness, at least for now ;-), to sacrifice
performance for administrative simplicity, I don't see any major problems.

Art S. Kagel

Just trying to think through this stuff... Not sure of the results of that
process, though :-)

1.) Wouldn't the RAID give me the full bandwidth, anyway? At least for
those tables occupying multiple physical disks?

2.) Again, wouldn't the RAID read from multiple disks simultaneously, thus
being sort of like the same bandwidth as individually scanning individual
disks, but "automatically"? (At least to the extent that the controllers
can accept the I/O?)

3.) Similar thoughts. The RAID isn't JBOD, right? So, I have a firehose of
bandwidth, that's carved up into smaller I/O streams for individual drives
that I never see. And, if # drives sufficient, an additional effect is no
hot spotting.

It just doesn't seem right, at first blush, because we just (from long
practice) tend to immediately think in terms of individual spindles, etc.
It really requires "switching mental gears", at least for me. But, if we
can get 80% of the benefit of agonizing over proper placement of database
objects, but with 20% of the "agony" (metaphorically speaking), we're
interested. Our system just doesn't need the absolute highest performance;
we're not operating like Sabre, or some other huge OLTP system.

DG



"superboer" <superboer7@planet.nl> wrote in message
news:bb790a36.0409150415.70f8ad06@posting.google.c om...
> my two 0.01
>
> haven't played much with 9.4 however
>
> i would use a certain number of dbspaces because of:
>
> 1: paralel dbspace backups
> 2: better use of PDQ ( a scan thread per dbspace )
> 3: (re)loading tables using hpl can be faster when having multiple
dbspaces.
> -- can be faster needs to be tested!!!
>
>
>
> See you
>
> Superboer.
>
> BTW how hard is it to maintain a xx number of dbspaces;