Re: locally managed tablespace & dictionary managed tablespace

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:UHsR9.16323$jM5.44436_at_newsfeeds.bigpond.com...
>
> > Also the bit about maxextents unlimited as an incorrect default might
> > concern some. Remember, most of the world is not on 9iR2.
>
> Well, a certain Richard Foote wrote here several months ago, arguing that
> the lack of a maxextents clause in LMT was a problem, largely (if I
remember
> correctly) because the lack of a 'brick wall' across the tracks means that
> the segment train can keep on rolling with nothing to stop it. I certainly
> remember a case where a developer of my acquaintence happened to code an
> infinite loop, and when I got back after a long weekend, discovered that
my
> table had acquired something like 178,000 extents. Having a maxextents set
> would have cured that problem (by inducing an out of space error and thus
> breaking the loop).
>

Hi Joel,

Exactly as Howard states.

It's not so much that maxextents is the default (there have been/are a lot worse defaults around), it's the fact that it can't be changed. Maxextents is not necessarily a "tuning" option but a "management" one.

If a program goes into an infinite loop as Howard says, I would like to have the option for a "brick wall". If I have a blocking transaction, I want the option to not fill necessarily fill the entire RBS tablespace. If the users were lousy at estimating the capacity requirements of a table(s), I want the option to prioritise what gets what storage. This manageability is somewhat lost without a maxextents option. If I want to control possible unexpected segment growth, I need to start looking a many more tablespaces which is a pain.

LMT are great. No maxextents is a mistake.

Cheers

Richard Received on Fri Jan 03 2003 - 23:36:14 CST