Managing Undo Data
What undo does
Undo holds before-images used for rollback, read consistency and instance recovery. Each transaction writes to one undo segment inside the undo tablespace. With automatic undo management (UNDO_MANAGEMENT=AUTO, the default since 11g) Oracle creates and sizes segments for you; manual mode with rollback segments is legacy. Only one undo tablespace is active per instance, changed with ALTER SYSTEM SET UNDO_TABLESPACE.
Retention and extent states
Extents in the undo tablespace are active (needed by a running transaction), unexpired (not needed but retained to honour UNDO_RETENTION) or expired (reusable). Inspect them in DBA_UNDO_EXTENTS and watch consumption in V$UNDOSTAT and the Undo Advisor.
UNDO_RETENTION is a lower bound, not a promise: when space runs short, unexpired extents are reused. ALTER TABLESPACE undotbs1 RETENTION GUARANTEE makes retention mandatory - at the cost of transactions failing with ORA-30036 when the tablespace cannot grow.
ORA-01555 "snapshot too old" means a long query needed a before-image that has been overwritten. Remedies: a larger undo tablespace with AUTOEXTEND, a longer retention, fewer commits inside the long-running process, and query tuning.
Undo also underpins flashback query, versions query, transaction query and flashback table; flashback database instead uses flashback logs in the FRA.
Rule of thumb: set UNDO_RETENTION to at least the runtime of your longest query, then size the undo tablespace so peak concurrent DML plus that retention fits with room to spare.