Re: Rollback segments minextents

It is a little odd, and you (and the manual) are both right that in general each extent can support multiple transactions.

The feature only applies to the very special case where a transaction STARTS in one extent and continues into the next extent, then no other transaction is (was) allowed to start in the next extent unless the first transaction committed.

Presumably this made sense in the days of small (5.1) databases when the strategy may have been -

    if a transaction crosses an extent boundary then     it may be big, so we'll give it the chance to use     the whole extent and keeps all its rollback contiguous.

I can't think of a good reason for the strategy, and I have to say that I haven't yet checked it on v8 so it may no longer be true.

If a pre-existing 2nd transaction needs another block I think it will try to allocate a new extent. If you want to test it, get a database with only one rbs online, and shrink it down to 2 extents, then do lots of 'update one row, commit', checking the UBA information in the v$transaction view until you can see that you are close to the end of one extent, then do a bigger update to cross the extent. (As you can see, it's a bit of a pain to set up tests for it).

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

markp7832_at_my-deja.com wrote in message <7rtg9j$7t2$1_at_nnrp1.deja.com>...
>>
>Jonathan, could you expand a little more on this. The manual says that
>multiple transactions can share an extent but that only one transaction
>writes to a rbs block within the extent. How does one transaction
>needing another block which is allocated from the next extent make that
>extent unusable, and for how long? If a second transaction in the
>segment needs another block does it go into a different extent or does
>it go into a wait state until some event?
Received on Fri Sep 17 1999 - 08:57:36 CDT