Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Maxextents unlimited on LMT ?

Re: Maxextents unlimited on LMT ?

From: Howard J. Rogers <dba_at_hjrdba.com>
Date: Wed, 10 Jul 2002 12:31:34 +1000
Message-ID: <agg694$61n$1@lust.ihug.co.nz>


Certifiable, more like

Said in love and with affectionate cooing tones! HJR "Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:0NMW8.31671$Hj3.95713_at_newsfeeds.bigpond.com...
> Hi Nuno,
>
> I completely agree, that's my point. Control for maxextents is (was) a
> capacity management aid. I have no problem with the default behaviour
being
> changed to unlimited, but *only* unlimited ?
>
> I am certified. It hurt a little but after a few Panadols was soon over it
> :)
>
> Regards
>
> Richard
> "Nuno Souto" <nsouto_at_optushome.com.au> wrote in message
> news:dd5cc559.0207091802.541898a0_at_posting.google.com...
> > Pete Sharman <peter.sharman_at_oracle.com> wrote in message
> news:<agcts10d0h_at_drn.newsguy.com>...
> >
> > PMFJI, but this one cannot be let alone...
> >
> > The
> > > number of extents in a locally managed tablespace has absolutely none
> (very
> > > negligible in the worst of cases) impact on performance. As such there
> is no
> > > need to set this parameter which puts an artificial limit on the size
of
> an
> > > object and hence, requires additional manual intervention.
> >
> >
> > This is so very wrong! Logic: number of extents of an
> > object has no impact on performance, therefore no need
> > to control its maximum size.
> >
> > Hellloooooooooo??????
> > Can anyone NOT spot the completely wrong logical inference?
> >
> >
> > > What exactly is your client not convinced about? Do they find the
> argument of
> > > number of extent having no performance impact unacceptable or do they
> have a
> > > need to control the object size?"
> > >
> >
> > I'd dare say at a minimum, that MAXEXTENTS was never a performance
> > control parameter. It was in fact a capacity management one.
Therefore,
> > it shouldn't have been removed as part of a performance control
exercise?
> >
> > Anyways, it might make its way back as a quota control system
> > managed by another DBMS_**** package?
> >
> > BTW, another gripe: replacing the complexity of storage management
> > parameters by the complexity of multiple DBMS_**** packages is
> > not my idea of simplifying DBA tasks. The number of these packages
> > in the last few versions has grown exponentially. Not good.
> >
> > But then again, what do I know about "DBAing"? I'm not even
certified...
> >
> > Cheers
> > Nuno Souto
> > nsouto_at_optushome.com.au
>
>
Received on Tue Jul 09 2002 - 21:31:34 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US