Re: Maxextents unlimited on LMT ?

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:02:43 CDT