Re: rollback maxextents

Charles J. Fisher wrote:

> On Thu, 9 Oct 2003, Howard J. Rogers wrote:
>
>> So the question remains: why do you feel the need to set maxextents?
>
> Because if someone starts a large transaction, I would like them to have
> the foresight to select r_large. The ORA-1555 is helpful to me in this
> case.

Re-iterating the bit that was snipped: maxextents was there to prevent the acquisition of huge numbers of extents, because huge numbers of extents were a performance problem when all we had were DMTs. With LMTs, the number of extents is practically of no consequence, and hence the decision to abolish maxextents.

Given that, what you are saying here is that you are using maxextents to control users that are otherwise uncontrollable. And on that basis, you think the abolition of maxextents to be a mistake.

I would rather think that its the uncontrollability of your users that's the mistake. If you have an application that permits users to fire off frequent, ad hoc, massive DML transactions, then that sounds like poor application design.

>
> It seems that the only way to enable this functionality is to either a)
> place r_large in a different tablespace or b) convert a DMT with the
> previously mentioned hack.

You realise that if you ever migrate to automatic undo, (a) won't even be an option? And (b) seems a curious path to take, since with no autoextend you already have a limit on the amount that a rollback segment can grow.

>
> MAXEXTENTS was a useful tool in being certain that a runaway object
> couldn't consume an entire tablespace.

Well, it seems a rum sort of database that has much of a tablespace sitting there empty, just in case. Tablespaces are *there* to be consumed!

But in any case, it's cart before horse time again: you real problem is runaway objects... and why they are running away... and why your users are able to let them run away.

>The loss of it in LMTs is a
> mistake.

I happen not to agree, though I know Richard Foote will. But whatever: it's the way things are, so you either accept that or try for some hokey workaround, which will be a short-term "fix" with unknown consequences, and no future when (if) migration time comes around.

Good luck, whatever approach you go for.

Regards
HJR

-- 
--------------------------------------------
See my brand new website, soon to be full of 
new articles: www.dizwell.com.
Nothing much there yet, but give it time!!
--------------------------------------------