ORA-01555; Snapshot tool old rollback segment number 1 with name "RB_TEMP" too small

pspera,

with Oracle Storage Manager you can only change the NEXT segment size and MAXEXTENTS. But this could be a quick solution to your request.
Anyways: To fix the rollback segment the way you like it I suggest you do remove RB_TEMP and re-create it with your desired values. Or you do a right click on the segment, then issue a "create like" and alter the values to create a similar rollback segment.

BUT - I suppose an even more relevant issue might be that your rollback tablespace could be too small to handle the snapshot your application needs. In this case, it is best practice to create a rollback segment with large extent sizes - maybe even in a different tablespace (name it RB_BIG if you like).
On the other hand, if this problem arises during everyday operation, you should consider having identical storage parameters for _every_ rollback segment. Or simply take RB_TEMP offline (or even drop it, if there's no explicit need for it).

HTH
Uwe

not sure which version of oracle you are running... ver. 7.3 and earlier were throwin this error very frequently... as Uwe said this error occurs when one transaction commits while other long running query is accessing the same data.

all you need to do is create a larger rbs and assign it to long running transaction.

from ver 9 onwards this problem is history as now there is only undo tablespace need tobe created.

checkout tom kyte's site for the detailed explanation for this error.

http://asktom.oracle.com/pls/ask/f?p=4950:8:17029152311990183433::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:275215756923,

CASE 1 - ROLLBACK OVERWRITTEN
1. Increase size of rollback segment which will reduce the likelihood of
overwriting rollback information that is needed.
2. Reduce the number of commits (same reason as 1).
3. Run the processing against a range of data rather than the whole table.
(Same reason as 1).
4. Add additional rollback segments. This will allow the updates etc. to be
spread across more rollback segments thereby reducing the chances of
overwriting required rollback information.
5. If fetching across commits, the code can be changed so that this is not
done.
6. Ensure that the outer select does not revisit the same block at different
times during the processing. This can be achieved by :
- Using a full table scan rather than an index lookup
- Introducing a dummy sort so that we retrieve all the data, sort it
and then sequentially visit these data blocks.
CASE 2 - ROLLBACK TRANSACTION SLOT OVERWRITTEN
1. Use any of the methods outlined above except for '6'. This will allow
transactions to spread their work across multiple rollback segments
therefore reducing the likelihood or rollback segment transaction table
slots being consumed.
2. If it is suspected that the block cleanout variant is the cause, then
force block cleanout to occur prior to the transaction that returns the
ORA-1555. This can be achieved by issuing the following in SQL*Plus,
SQL*DBA or Server Manager :
alter session set optimizer_goal = rule;
select count(*) from table_name;
If indexes are being accessed then the problem may be an index block and
clean out can be forced by ensuring that all the index is traversed. Eg,
if the index is on a numeric column with a minimum value of 25 then the
following query will force cleanout of the index :
select index_column from table_name where index_column > 24;