Fix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
ORA-01555: snapshot too old in EBS concurrent request
Also searched as
- 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
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.
Applies to: EBS 11i, 12.1, and 12.2 on Oracle Database 11g, 12c, or 19c
How to fix ORA-01555 in a concurrent request
- 1Read 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.
- 2Check 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.
- 3If 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.
- 4Review 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.
- 5Where 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.
- 6Check 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.
- 7If 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.
What ORA-01555 actually means
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
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.
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Is ORA-01555 caused by too little undo, or bad code, or both?
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?
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?
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?
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.
Related
Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.
Error fixOracle EBS Concurrent Manager Will Not Start: How to Fix It
A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh.
Error fixFix Oracle EBS Workflow Notification Mailer Not Sending Emails
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
Error fixFix adop phase=prepare Failures in EBS 12.2 Online Patching
An adop prepare phase failure in EBS 12.2 almost always means the patch edition (patch file system) and the run edition are out of sync, or a previous cutover or cleanup did not complete cleanly. Read adop.log for the specific worker error, resync the file systems with adop phase=fs_clone if needed, and never start a new patch cycle on top of an unfinished one.
How-toHow to Import AP Invoices in Oracle EBS with Payables Open Interface Import
Load invoice header and line data into AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then run the Payables Open Interface Import concurrent program to create standard invoices in Oracle Payables. Rows that fail validation land in AP_INTERFACE_REJECTIONS with a specific reject reason you can query directly, without opening the Invoice Workbench.
How-toHow to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)
Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI-assisted data migration for ERP implementations
AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.
Stuck on Oracle E-Business Suite (EBS)?
Talk to engineers who work inside Oracle E-Business Suite (EBS) every week, and who build private AI that answers these questions from your own ERP data.