Re: Maxextents unlimited on LMT ?

In article <dd5cc559.0207091802.541898a0_at_posting.google.com>, nsouto_at_optushome.com.au says...
>
>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.

No that's not the logic, at least not completely. You need to add in how do we minimize the amount of management for the database. As you're undoubtedly aware, there are so many times when you need to balance one need against another - performance against availability is one that springs to mind fairly quickly. I think this is just another one of those cases. Now you might argue against which is more important, but that's another discussion.

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

I don't think it was. It was removed as part of a manageability exercise. Again, you might argue it shouldn't be so, but to me MAXEXTENTS is the wrong thing to do capacity management with anyway. The as yet undocumented MAXSIZE parameter I mentioned in another reply might be better. Of course the fact that it doesn't exist might explain why it's not documented :)
>
>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.

You want the functionality or not? ;)

My personal viewpoint is that you'll see these packages used by Oracle itself to "self-manage". Doesn't it then make sense that you as an experienced DBA might find them useful too?
>
>But then again, what do I know about "DBAing"? I'm not even certified...
>

Ahah! I take back my "experienced DBA" comment! ;)
>Cheers
>Nuno Souto
>nsouto_at_optushome.com.au

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Wed Jul 10 2002 - 00:12:15 CDT