Re: DB2 HADB

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:4387c614$0$12479$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...
> I'm not so sure about those advantages. Basically, it's good
> old vsam multi-key indexing. Used to be called MSAM by Univac,
> for example. (Christ, that's how old the technique is!)
>
> The disadvantage of course is the overflow (stored as you say
> somewhere else). Which requires periodic reorgs IF the table
> is accessed by sequence of key as a significant portion of its
> use.
>
> Mind you, Oracle can be pretty nasty with their row-chaining
> and row-relocation (essentially another manifestation of a
> similar problem). I believe there is something now in 10gr2
> to address this problem. Online as well, ie: no downtime.
> I wonder how well that will work with ASSM...
>
> But from what I see the reorg in db2 is a bit of a problem given
> there are warnings and limitations about it all over the place.
> Maybe IBM should add a note to the doco that reorgs are only
> needed WHEN using clustered tables?
>
> Because to someone on the outside it can look like it's an
> essential part of life, if they don't also read the specifics
> of table clustering. When like you said: it doesn't need to be.
>
> --
> Cheers
> Nuno Souto

I am not sure what warning and limitations you are referring to. Before version 8 was released in 2003, DB2 reorgs had to be done offline (except for some limited online reorg capability of indexes), but that is no longer the case.

Clearly, there are a lot of DBA's (DB2 and Oracle) who don't know what they are doing, but I don't think you can blame the vendors for that.

Even without clustering, indexes needed to be re-orged in DB2 or Oracle. You can call it reorg or rebuild, but it is the same thing since indexes are always in the correct order and page splits may have occurred that need attention. In DB2 version 8, the reorg table is a different command than reorg index. Received on Fri Nov 25 2005 - 20:28:38 CST