I think I’d make a couple of changes to that sequence – but the important assumption I am making is that you can’t steal extents out of order.

Any short text description is going to be a little flawed, but imagine the current segment having six extents, and the small transaction started in segment three. So we have:

1, 2, 3x, 4, 5, 6

As time passes, and assuming the transactions in extents 1 and 2 have committed, new transactions can keep on going around the ring of extents – at some point we could imagine the segment looking like this:

3x, 4, 5, 6, 1, 2

The segment hasn’t extended, and extents 1 and 2 haven’t really moved, but we can imagine that the segment starts at extent 3.

My working hypothesis is that even if every transaction that started in extent 4 committed a long time ago, if Oracle needs to add a new extent to the end of the segment it cannot “steal” an extent out of order – so it cannot rearrange the extents in the order:

3x, 5, 6, 1, 2, 4

So every extent from 3 onwards is untouchable until the transaction in extent 3 commits.

I thought

1. Oracle will try to steal expired extents from the same segment
2. Oracle will then try to steal expired extents from other undo segments
3. Oracle will try to steal unexpired inactive extents from the same segment
4. Oracle will try to steal unexpired inactive extents from the other undo segments.
5. Oracle will try to extend the undo segment
6. Oracle will try to extend the tablespace (if autoextend)
7. Throw an error.

So it this case shouldn’t oracle try to steal expired/unexpired extents from the _SYSSMU4$

Or my understanding in incorrect ?

thanks

Stew,
Just one little detail for clarification – the transaction acquires a block at a time, not an extent; but the consequence, of course, is that the extent is effectively locked.

srivenu,

Unless that parameter has changed its purpose recently, it has nothing to do with the problem. It used to relate to RAC (or OPS) systems and public (manual) rollback segments, and told each instance the minimum number of segments they had to acquire on startup.

select  s.sid, s.serial#, r.segment_name
from    v$session s
join    v$transaction t on s.taddr = t.addr
join    DBA_ROLLBACK_SEGS r on r.segment_id = t.xidusn;

2) If I read Jonathan correctly, an EXTENT is allocated, not a SEGMENT. Extents can be reused or added freely at the end of the segment, but the starting point remains the same as long as the first extent is still being used.

1) How did you come to know that it was session 662 which was holding a lock?
2) When a segment is already allocated to a particular session and is not being used then why/how does Oracle allocate more and more segments into it and make it fatter and fatter until it gets obese.