well, you do have to use VALID syntax:

ops$tkyte@ORA920> set transaction use rollback segment rb01;

Transaction set.

ops$tkyte@ORA920> set transaction use rollback segment=rb01;
set transaction use rollback segment=rb01
                                    *
ERROR at line 1:
ORA-02245: invalid ROLLBACK SEGMENT name



lose the "=" 

undo_retention -- you tell oracle "i'd like to keep undo for a certain period of time, say 1 hour"

what that means is, if you ran a transaction at noon -- it generated some undo (rollback data).  if undo retention was set to an hour, Oracle will try to retain that undo -- not overwrite it -- for at least an hour.  It might overwrite it -- if you are pressured for space, but it will try to keep it for an houur (in 10g, you can force it to keep it -- by making transactions that want to overwrite fail instead of overwriting it)


1) setting a high undo retention means you are saying to Oracle -- PLEASE try to keep this undo for N hours.  Oracle will extend undo segments as much as possible as it needs space in order to accomodate that request.  If it cannot extend anymore (undo tablespace is full and no autoextend is possible on the datafiles) -- it will prematurely expire the oldest undo data in that segment -- meaning the undo retention request you made will not be observed.


with undo retention -- the option to reused already allocated extents is not so simple.  You will reused an already allocated extent IF it contains no transaction data that falls in the retention period.  If you have a 1 hour retention and you find an already allocated undo extent that contains undo for a transaction performed 59 minutes ago -- Oracle will not use that extent unless *forced* to by an out of space condition.


Setting undo retention artifically high will cause undo segments to grow until there is no more space available.  If you set up a 32gig undo segment and set 

a) undo retention to 1 hour
b) undo retention to 1 day

come back in a day and tell me how much undo data you have in each case.  One would *probably* have much less than 32gig allocated (i'm assuming you generate less than 32gig of undo per hour) the other would probably have 24times or more as much undo as a) does


2) it happens like this, when another extent is needed in an undo segment then:

1. first we try to allocate a new extent using free space (or autoextend space) in the undo tablespace

2. if this fails, AUM looks at expired extents in other undo segments (extents that contain undo for transactions that happened longer ago than the undo retention period).  when it finds one, it'll "steal" it -- take it over.

3. if this fails, it looks at unexpired extents in it's own segment (the oldest extent it has) and will prematurely expire that one and reuse it (meaning we've just blown the undo retention)

4. if that fails, it'll try to steal an unexpired extent from some other undo segment

5. and finally, if we get here, well, you are "out of luck" and "out of space"



3) no -- not at all.  they are managed almost just like rollback segments using manual undo -- were you specify how many rbs's to have, how big their extents are, and how big each rbs is.  They just have the additional ability to extend because of the retention policy (manual undo will only extend in response to a transaction needing more space -- aum will extend in response to that as well as "time") and move extents around (between segments)



<b>i thought it would be vaguely interesting to see an extent "move" from segment to segment so I setup a test to do so...</b>



ops$tkyte@ORA9IR2> create undo tablespace undo_test
  2  datafile size 2m
  3  /
 
Tablespace created.
<b>starting with a small undo tablespace (undo retention is set to 10800 -- "big")</b>

 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> alter system set undo_tablespace = undo_test
  2  /
 
System altered.
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> drop table t;
 
Table dropped.
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> create table t ( x int, y char(2000) );
 
Table created.
 
ops$tkyte@ORA9IR2> insert into t values ( 1, 'x' );
 
1 row created.
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> declare
  2      l_cnt number;
  3  begin
  4      loop
  5          update t set y = substr( y, 3 ) || to_char(sysdate,'ss');
  6          commit;
  7          select sum(blocks) into l_cnt from dba_free_space where tablespace_name = 'UNDO_TEST';
  8          exit when l_cnt is null;
  9      end loop;
 10  end;
 11  /
 
PL/SQL procedure successfully completed.

<b>we fill it up -- make it allocate all of the way out to 2meg. It cannot grow anymore, no autoextend and it is full</b>
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> drop table snap;
 
Table dropped.
 
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> create table snap
  2  as
  3  select segment_name, extent_id, blocks
  4    from dba_extents
  5   where tablespace_name = 'UNDO_TEST'
  6  /
 
Table created.

<b>save the "configuration" of the undo segments -- their extents and sizes..</b>
 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> /* in another session, do something, a transaction and don't commit it */
ops$tkyte@ORA9IR2> pause

<b>here, I went off and did "update emp set ename = ename" and left it there, we just grabbed an extent in an undo segment and won't release it -- we will not be able to advance back into this one when we start doing lots of work below because of the uncommitted transaction</b>

 
ops$tkyte@ORA9IR2>
ops$tkyte@ORA9IR2> declare
  2      l_cnt number;
  3  begin
  4      for i in 1 .. 5000
  5      loop
  6          update t set y = substr( y, 3 ) || to_char(sysdate,'ss');
  7          commit;
  8      end loop;
  9  end;
 10  /
 
PL/SQL procedure successfully completed.

<b>so, we did lots of updates..</b>
 
 
ops$tkyte@ORA9IR2> column segment_name format a11
ops$tkyte@ORA9IR2> select coalesce( a.segment_name, b.segment_name ) segment_name,
  2         coalesce( a.extent_id, b.extent_id ) extent_id,
  3         a.blocks, b.blocks,
  4         case when a.segment_name is null then 'Moved Here'
  5              when b.segment_name is null then 'Moved Away'
  6          end what
  7    from snap a FULL OUTER JOIN
  8             (select *
  9                from dba_extents
 10               where tablespace_name = 'UNDO_TEST') b
 11         on (a.segment_name = b.segment_name and a.extent_id = b.extent_id)
 12   order by 1, 2
 13  /
 
SEGMENT_NAM  EXTENT_ID     BLOCKS     BLOCKS WHAT
----------- ---------- ---------- ---------- ------------------------------
_SYSSMU10$           0          7          7
_SYSSMU10$           1          8          8
_SYSSMU10$           2          8          8<b>
_SYSSMU10$           3                     8 Moved Here</b>
_SYSSMU11$           0          7          7
_SYSSMU11$           1          8          8
_SYSSMU11$           2          8          8
_SYSSMU11$           3          8          8
_SYSSMU12$           0          7          7
_SYSSMU12$           1          8          8
_SYSSMU12$           2          8          8
_SYSSMU12$           3          8          8
_SYSSMU13$           0          7          7
_SYSSMU13$           1          8          8
_SYSSMU13$           2          8          8
_SYSSMU13$           3          8          8
_SYSSMU14$           0          7          7
_SYSSMU14$           1          8          8
_SYSSMU14$           2          8          8<b>
_SYSSMU14$           3          8            Moved Away</b>
_SYSSMU15$           0          7          7
_SYSSMU15$           1          8          8
_SYSSMU15$           2          8          8
_SYSSMU15$           3          8          8
_SYSSMU16$           0          7          7
_SYSSMU16$           1          8          8
_SYSSMU16$           2          8          8
_SYSSMU16$           3          8          8
_SYSSMU9$            0          7          7
_SYSSMU9$            1          8          8
_SYSSMU9$            2          8          8
_SYSSMU9$            3          8          8
 
32 rows selected.
 

<b>and we can see that an extent (at least an extent) moved from 14 to 10...</b>


 

ok, i had to prove myself wrong :)

and I did.


setup the two meg undo tablespace.


found out my undo segment numbers (select segment_name from dba_segments where tablespace_name = 'UNDO_TEST') and did this:


drop table names;
create table names
as
select segment_name
  from dba_segments
 where tablespace_name = 'UNDO_TEST';
                                                                                


when I found out my segments were 9, 10, 11, ... 16 I ran this script

SQL> @uselast 10 16



--------------------------- uselast.sql -----------------------------
define usn=&1
define maxusn=&2
                                                                                
                                                                                
column extent_id new_val eid
                                                                                
declare
    l_eid number;
    l_xidusn number;
    l_ext number;
begin
    select max(extent_id) into l_eid
      from dba_extents
     where tablespace_name = 'UNDO_TEST'
       and segment_name =  '_SYSSMU&usn.$';
                                                                                
    loop
        update names
           set segment_name = segment_name
         where segment_name = '_SYSSMU&usn.$';
                                                                                
        select xidusn, start_uext into l_xidusn, l_ext
          from v$transaction
         where addr = ( select taddr
                          from v$session
                         where sid = (select sid
                                        from v$mystat
                                       where rownum = 1 )
                      );
        exit when ( l_xidusn = &usn and l_ext = l_eid );
        commit;
    end loop;
end;
/
                                                                                
select xidusn, start_uext
  from v$transaction
 where addr = ( select taddr
                  from v$session
                 where sid = (select sid
                                from v$mystat
                               where rownum = 1 )
                      );
                                                                                
column cmd new_val cmd
select decode( &usn,
               &maxusn, '',
               'sqlplus / @uselast ' || (&usn+1) || ' ' || &maxusn ) cmd
  from dual;
                                                                                
host &cmd
--------------------------------------------------------------

that grabed the last extent of all but the first undo segment (segment 9).


I then used:


define usn=&1
                                                                                
declare
    l_xidusn number;
    l_ext number;
begin
    loop
        update names
           set segment_name = segment_name
         where segment_name = '_SYSSMU&usn.$';
                                                                                
        select xidusn, start_uext into l_xidusn, l_ext
          from v$transaction
         where addr = ( select taddr
                          from v$session
                         where sid = (select sid
                                        from v$mystat
                                       where rownum = 1 )
                      );
        exit when ( l_xidusn = &usn and l_ext = 0 );
        commit;
    end loop;
end;
/
                                                                                
select xidusn, start_uext
  from v$transaction
 where addr = ( select taddr
                  from v$session
                 where sid = (select sid
                                from v$mystat
                               where rownum = 1 )
                      );
---------------------------------------------------------------


to use rbs 9 and issued a big update in that session (it kept the transaction active in that segment).

So now the script:
break on segment_name skip 1
select segment_name, extent_id, blocks
  from dba_extents
 where tablespace_name = 'UNDO_TEST'
 order by segment_name, extent_id
/
                                                                                
select xidusn, start_uext from v$transaction order by 1;

returns:


SEGMENT_NAME                    EXTENT_ID     BLOCKS
------------------------------ ---------- ----------
_SYSSMU10$                              0          7
                                        1          8
                                        2          8
                                        3          8
 
_SYSSMU11$                              0          7
                                        1          8
                                        2          8
                                        3          8
                                        4          8
 
_SYSSMU12$                              0          7
                                        1          8
                                        2          8
                                        3          8
 
_SYSSMU13$                              0          7
                                        1          8
                                        2          8
                                        3          8
 
_SYSSMU14$                              0          7
                                        1          8
                                        2          8
                                        3          8
 
_SYSSMU15$                              0          7
                                        1          8
                                        2          8
                                        3          8
 
_SYSSMU16$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU9$                               0          7
                                        1          8
                                        2          8
 
 
31 rows selected.
 
 
    XIDUSN START_UEXT
---------- ----------
         9          0
        10          3
        11          4
        12          3
        13          3
        14          3
        15          3
        16          2
 
8 rows selected.

showing segment 9 has three extents and we are busy using the last extent of each of the existing rbs's.

Now I issued a "big" update:


ops$tkyte@ORA9IR2> update t set object_name = lower(object_name);
update t set object_name = lower(object_name)
       *
ERROR at line 1:
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDO_TEST'
 



and reran the queries against dba_extents and v$transaction:


ops$tkyte@ORA9IR2> @test
 
SEGMENT_NAME                    EXTENT_ID     BLOCKS
------------------------------ ---------- ----------
_SYSSMU10$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU11$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU12$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU13$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU14$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU15$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU16$                              0          7
                                        1          8
                                        2          8
 
_SYSSMU9$                               0          7
                                        1          8
                                        2          8
                                        3          8
                                        4          8
                                        5          8
                                        6          8
                                        7          8
                                        8          8
                                        9          8
 
 
31 rows selected.
 
 
    XIDUSN START_UEXT
---------- ----------
         9          0
        10          2
        11          2
        12          2
        13          2
        14          2
        15          2
        16          2
 
8 rows selected.


rbs 9 now has 10 extents -- it stole all but 3 from the existing rbs's.



Perhaps, if you are interested, you could write a procedure that when you get the unable to extent -- you select this data out into plsql variables (contents of dba_extents for the undo tablespace and contents of v$transaction) for a post mortem (after you rollback, you should be able to save that data) 

ops$tkyte@ORA9IR2> update (
  2  SELECT MAS.ID new_user_m_id,  log.user_m_id
  3    FROM USER_M MAS,USER_L LOG
  4   WHERE MAS.USERID=LOG.USERID
  5     AND MAS.LOC_ID=LOG.LOC_ID
  6     and LOG.USER_M_ID is null
  7         )
  8     set user_m_id = new_user_m_id
  9  /


If user_m_id is indexed AND there are many thousands or more records planned to be modified, you might consider disabling the indexes, doing the update, and then rebuilding the indexes afterwards. 

"in seconds", you set undo retention in seconds.

documentation also says

for x in C
loop
    savepoint foo;
    begin
        do your work here....
    exception
        when whatever
             rollback to foo; -- rolls back to LAST issued savepoint
             insert into log table;
    end;
end loop;

procedure log_error( p_error_msg in varchar2 )
as
   pragma autonomous_transaction;
begin
   insert into error_log(msg) values ( p_error_msg);
   commit;
end;