Stephen,
Tim's statement is correct, but can be construed incorrectly if you read it and think
of TEMP segments. AUM still uses undo segments (same basic structure as rollback
segments). However, one of the space management steps is to allow an undo segment to
'steal' extents from another undo segment. This means that all extents (other than
those currently in use or extent 0 (and perhaps 1)) are available to any other segment
should it require them.
A single transaction cannot start in undo segment #1, allocate space in it and then
move to undo segment #2. However, the transaction can cause undo segment #1 to
allocate space currently allocated to #2.
I hope this clears up the disparity between the statements.
Daniel
[EMAIL PROTECTED] wrote:
>
> Daniel,
>
> I have just finished reading your document on UNdo Internals and Tims
> "Cats, Dogs and ORA-1555s".
>
> Thanks for the documents they were both great.
>
> There is something I don't understand and I am not sure about it.
>
> You have said below:
>
> "When a transaction is bound to an undo segment, it allocates a slot in the
> tx table."
>
> I thought that transactions were no longer bound to UNDO segments and
> this was one of the improvements in 9i.
>
> I have pasted an extract from Tims document:
>
> Into the future: Oracle9i UNDO tablespaces.
> As you may have observed, one of the reasons space management for rollback
> segments is so difficult is due
> to the fact that a transaction is assigned irrevocably to a single rollback
> segment.
> Each rollback segment can only handle a finite number of transactions
> (due to block-level contention for the transaction table in the header
> block),
> so there must be multiple rollback segments to handle potentially large
> numbers of transactions.
> UNDO tablespaces in Oracle9i allow an entire tablespace to become a single,
> large pool of undo blocks for use by any and all transactions.
> Instead of having available space carved up into many smaller rollback
> segments,
> a single transaction can utilize all of the space in the UNDO tablespace,
> if necessary. Many, many transactions can share that space also,
> because the controlling transaction table is no longer contained in a
> single database block,
> avoiding contention for this important resource.
>
> I guess I am jumping to the wrong assumption in Tims extract - can you
> clarify it for me.
>
> thanks, stephen
>
> Phone: 01737 27 5564
> [EMAIL PROTECTED]
begin:vcard
n:Fink;Daniel
x-mozilla-html:FALSE
org:Sun Microsystems, Inc.
adr:;;;;;;
version:2.1
title:Lead, Database Services
x-mozilla-cpt:;9168
fn:Daniel W. Fink
end:vcard
