In my years of Oracle DBA work, I’ve seen these two errors confused more times than I can count. Both involve undo. Both appear during long-running operations. Both are blamed on “undo tablespace too small.” But they have fundamentally different root causes, different diagnostic paths, and different fixes. If you treat ORA-01628 like ORA-01555, you’ll spend hours tuning undo retention while the real problem sits untouched.

What Each Error Actually Means

ORA-01555: snapshot too old: rollback segment number X
           with name "..." too small
ORA-01628: max # extents (32765) reached for rollback segment ...

ORA-01555 means Oracle couldn’t reconstruct a consistent read snapshot because the undo data was overwritten before a query finished reading. The undo existed — then got recycled too soon.

ORA-01628 means an undo segment tried to extend beyond its maximum extent count. This is a hard architectural limit. The undo segment literally cannot grow any further. It has nothing to do with retention — it’s about extent management and undo tablespace configuration.

The fact that both errors appear in the context of undo leads DBAs to conflate them. Don’t.

Diagnosing ORA-01628 — Start With Undo Segment Structure

-- Check the undo segment that's hitting the limit
SELECT segment_name, status, extents, max_extents,
       blocks, initial_extent, next_extent,
       min_extents
FROM dba_rollback_segs
WHERE segment_name = '_SYSSMU&your_segment_number$'
ORDER BY extents DESC;
-- Check all undo segments approaching limits
SELECT segment_name, extents, max_extents,
       ROUND(extents/max_extents * 100, 1) pct_used
FROM dba_rollback_segs
WHERE status != 'OFFLINE'
ORDER BY pct_used DESC;

If extents equals max_extents, you’ve hit the wall. The segment cannot extend further. Any transaction requiring more undo space from this segment will fail with ORA-01628.

Why does a segment reach max extents?

Two scenarios:

Scenario 1: Tiny extent sizes

If your undo tablespace was created with very small UNIFORM SIZE or the extent size was inherited from an old default, each extent is tiny. A large transaction generates thousands of extents to accumulate enough undo space, eventually hitting the maximum.

-- Check undo tablespace extent configuration
SELECT tablespace_name, allocation_type,
       initial_extent, next_extent,
       min_extents, max_extents,
       extent_management, segment_space_management
FROM dba_tablespaces
WHERE contents = 'UNDO';

If allocation_type is SYSTEM and extents are very small (under 1MB), this is likely your problem.

Scenario 2: A single enormous transaction

A batch job that updates tens of millions of rows in a single transaction generates undo for every row. If the undo segment’s extent size is reasonable but the transaction is massive, the segment still runs out of room at max_extents.

The Fix for ORA-01628

The correct fix is not increasing UNDO_RETENTION. That parameter controls how long unexpired undo is kept — it doesn’t affect extent limits.

The fix is recreating the undo tablespace with a larger uniform extent size:

-- Create new undo tablespace with larger extent size
CREATE UNDO TABLESPACE undotbs2
    DATAFILE '/oradata/undotbs2_01.dbf' SIZE 10G AUTOEXTEND ON
    RETENTION GUARANTEE
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128M;
    -- 128M extents = max 32765 * 128M = ~4TB of undo capacity
-- Switch to new undo tablespace
ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS2 SCOPE=BOTH;
-- Wait for old segments to go offline, then drop old tablespace
-- Check no active segments remain on old tablespace:
SELECT segment_name, status FROM dba_rollback_segs
WHERE tablespace_name = 'UNDOTBS1'
AND status = 'ONLINE';
-- When empty:
DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;

With 128MB extents, your undo segments can grow up to approximately 4TB before hitting the 32,765 extent limit — far beyond what any realistic transaction requires.

When Both Errors Appear Together

I’ve investigated cases where ORA-01555 and ORA-01628 appear in the same alert log window, from the same workload. This is not coincidental — it’s telling you that your undo architecture is fundamentally broken in two directions simultaneously.

The pattern: a batch job is generating enormous undo (causing ORA-01628 when undo segments max out), while simultaneously a long-running report is losing its read consistent snapshot because the undo it needs is being recycled to make room for the batch job’s undo (causing ORA-01555).

The diagnosis:

-- Find concurrent workload at time of errors
SELECT sample_time, session_id, session_serial#,
       event, sql_id, session_state,
       undo_segusn, undo_slot
FROM v$active_session_history
WHERE sample_time BETWEEN TIMESTAMP '2026-04-19 02:00:00'
                      AND TIMESTAMP '2026-04-19 04:00:00'
  AND session_state = 'WAITING'
ORDER BY sample_time;
-- Check undo usage at peak
SELECT begin_time, end_time,
       maxquerylen,     -- longest query (snapshot age needed)
       maxquerysqlid,   -- which query
       undoblks,        -- undo blocks generated
       ssolderrcnt,     -- ORA-01555 count
       nospaceerrcnt    -- ORA-01628 count
FROM v$undostat
WHERE begin_time > SYSDATE - 1
ORDER BY begin_time DESC;

Both ssolderrcnt and nospaceerrcnt elevated in the same time windows confirms concurrent undo starvation. The solution requires addressing both: larger extent size (for ORA-01628) AND larger undo tablespace with retention guarantee (for ORA-01555).

The RETENTION GUARANTEE Option — Use It Carefully!!!

-- Enable retention guarantee
ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
-- Check current setting
SELECT tablespace_name, retention FROM dba_tablespaces
WHERE contents = 'UNDO';

RETENTION GUARANTEE tells Oracle to never overwrite unexpired undo, even if the undo tablespace is full. This eliminates ORA-01555 caused by premature undo recycling. But it introduces a new risk: if the undo tablespace fills with guaranteed unexpired undo and a new transaction needs undo space, that transaction fails with ORA-30036 (“unable to extend segment in undo tablespace”).

Use RETENTION GUARANTEE only when:

• Your undo tablespace is large enough to hold the full workload’s undo for the configured retention period
• You’ve calculated the required undo tablespace size using v$undostat data
• You have autoextend enabled as a safety net

Without sufficient space, RETENTION GUARANTEE trades ORA-01555 errors for ORA-30036 errors — different error, same operational problem.