# Fix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests

> Source: https://netray.co/erp-help/ebs-ora-01555-snapshot-too-old-concurrent-request-fix
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

ORA-01555 in a concurrent request means the program tried to read data from undo that has already been overwritten, usually because the report or custom PL/SQL ran long enough, or committed often enough mid-cursor, that the undo tablespace could not retain the needed read-consistent image. Increase UNDO_RETENTION and undo tablespace size first, then review the program for commits inside open cursor loops.

## Kind

error

## System

oracle-ebs

## Erp

Oracle E-Business Suite (EBS)

## Module

Database / Concurrent Processing

## Query

ORA-01555: snapshot too old in EBS concurrent request

## Alternate Queries

- ORA-01555 rollback segment too small EBS report
- concurrent program fails with snapshot too old
- ORA-01555 EBS custom PL/SQL long running report
- increase UNDO_RETENTION EBS ORA-01555

## Applies To

EBS 11i, 12.1, and 12.2 on Oracle Database 11g, 12c, or 19c

## Steps

### How to fix ORA-01555 in a concurrent request

**Items:**

Read the request log fully - ORA-01555 usually appears with rollback segment too small or names the undo segment; note which SQL statement in the program actually failed.

Check current UNDO_RETENTION and undo tablespace size with SELECT tablespace_name, value FROM v$parameter WHERE name = 'undo_retention'; and confirm the undo tablespace has autoextend on with enough headroom.

If the program is a long-running report against volatile tables with high DML during the run, increase UNDO_RETENTION and the undo tablespace size so older read-consistent images survive longer.

Review the program itself - if it is custom PL/SQL, look for COMMIT statements executed while a cursor opened earlier in the same procedure is still being fetched; this is the single most common root cause of ORA-01555 outside of undersized undo.

Where possible, restructure the loop to BULK COLLECT the needed rows first, then commit in batches after the fetch completes, rather than committing between fetches on an open cursor.

Check whether the concurrent program is scheduled to overlap with heavy batch updates, for example running during month-end postings, and consider rescheduling it to a quieter window.

If the error is intermittent and only under heavy load, consider Guaranteed Undo Retention only after confirming the undo tablespace is sized to absorb it, since it can cause DML failures (ORA-30036) if undo space runs out.

## Sections

### What ORA-01555 actually means

**Body:**

Oracle's read consistency model reconstructs the state of a row as of the start of a query using undo data. If enough time passes, or enough other transactions commit and reuse that undo space, the information needed to rebuild the old image is gone, and the database raises ORA-01555 rather than return wrong results. It is a protective error, not corruption.

In EBS this shows up most often in long-running standard reports, custom PL/SQL concurrent programs, and interfaces that process large batches of records while the same base tables are also being actively updated by other users, other concurrent requests, or a background job running in parallel on the same schema, which is exactly the condition the undo mechanism was never meant to survive indefinitely.

### The undersized-undo cause

**Body:**

If UNDO_RETENTION is set too low, or the undo tablespace is too small and not set to autoextend, busy transactions on other objects recycle undo space quickly, and a long-running concurrent program simply outlives the undo it needs. Raising UNDO_RETENTION and giving the undo tablespace more room, ideally with autoextend enabled, resolves the majority of ORA-01555 cases that are not caused by application code.

This cause is more common in busy multi-org EBS environments where dozens of concurrent requests and interactive sessions all share the same single undo tablespace, since a sudden spike in unrelated DML from a completely different module, such as a large order import, can flush undo blocks that a slower, unrelated report elsewhere in the system still needs to read for its own consistent view.

**Code:**

- ALTER SYSTEM SET undo_retention = 10800 SCOPE=BOTH;
- SELECT tablespace_name, autoextensible, bytes/1024/1024 mb FROM dba_data_files WHERE tablespace_name = (SELECT value FROM v$parameter WHERE name = 'undo_tablespace');

### The commit-inside-cursor-loop cause

**Body:**

The other very common cause, particularly in custom EBS interfaces, is a PL/SQL loop that opens a cursor and then commits inside the loop body while still fetching from that same cursor. Once a commit happens, Oracle can reuse the undo the open cursor still needs for its read-consistent view, and the very next fetch can raise ORA-01555, independent of how large the undo tablespace is.

The fix is structural, not a database setting: fetch what you need with BULK COLLECT into a PL/SQL collection first, close the cursor cleanly, and only then commit in controlled batches sized to the workload. Never commit while a cursor opened earlier in the same transaction is still open and being fetched, no matter how tempting it is to commit early to keep a long-running job responsive.

## Pitfalls

- Increasing UNDO_RETENTION without also sizing the undo tablespace to support it - retention alone does nothing if the tablespace fills up.
- Assuming ORA-01555 is a database bug and reopening a Service Request before checking for commit-inside-cursor-loop patterns in custom code.
- Enabling Guaranteed Undo Retention without headroom, which trades ORA-01555 for ORA-30036 (out of space in undo tablespace) under heavy DML.
- Scheduling a large custom report to run during month-end or year-end posting windows, when undo turnover is at its highest.
- Fixing the symptom by simply re-running the failed request repeatedly instead of addressing the undersized undo or the code pattern causing it.

## Ai Angle

ERPray grounded on the EBS database can correlate a failed concurrent request's log against UNDO_RETENTION history and the actual SQL text of custom programs, flagging commit-inside-cursor-loop patterns automatically - turning what is normally an hour of log reading and code review into a direct pointer at the offending procedure and line.

## Faq

### Is ORA-01555 caused by too little undo, or bad code, or both?

**Answer:** Either can cause it, and both are worth checking rather than assuming one. Undersized undo is the more common root cause behind ORA-01555 in standard EBS reports and interfaces; a commit-inside-cursor-loop pattern is the more common cause in custom PL/SQL. Start with UNDO_RETENTION and undo tablespace size, then review the code.

### Will simply resubmitting the concurrent request fix ORA-01555?

**Answer:** Sometimes, if the failure was caused by a one-off spike in unrelated DML activity elsewhere on the database, but resubmitting the same request does nothing to fix the underlying cause. If the same request fails again with ORA-01555, treat it as an undo sizing problem or a code review task, not a transient glitch worth ignoring.

### What does Guaranteed Undo Retention do and should I turn it on?

**Answer:** It forces the database to retain undo for the configured retention period even if it means failing new DML transactions instead of overwriting undo. Only enable it after confirming the undo tablespace has enough space to absorb the guarantee, or you trade ORA-01555 for ORA-30036.

### Can BI Publisher or Discoverer reports trigger ORA-01555 too?

**Answer:** Yes - any long-running read against actively changing EBS tables can trigger it, not just concurrent programs run through the standard request set. BI Publisher data models, Discoverer workbooks, ad hoc SQL run from a client tool, and even a long report bound to a form are all subject to the same undo retention limits.

## Search terms

ORA-01555 EBS, snapshot too old concurrent request, ORA-01555 rollback segment too small, UNDO_RETENTION EBS fix, undo tablespace concurrent program, ORA-01555 custom PL/SQL cursor, EBS report ORA-01555, commit inside cursor loop ORA-01555, Guaranteed Undo Retention EBS, concurrent request fails ORA-01555

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json