How to purge concurrent requests and manager data in Oracle EBS
How to run Purge Concurrent Request and/or Manager Data in Oracle EBS
Also searched as
- FND_CONCURRENT_REQUESTS table too large purge
- purge concurrent requests parameters entity mode age
- Purge Obsolete Workflow Runtime Data schedule
- EBS applcsf log out files filling disk
Short answer
Run the standard program Purge Concurrent Request and/or Manager Data (executable FNDCPPUR) on a schedule, with Entity set to ALL and Mode set to Age with a value in days. It removes old rows from FND_CONCURRENT_REQUESTS and related tables and deletes the matching log and output files on disk.
Applies to: Oracle E-Business Suite 11i, R12.1 and R12.2
Schedule the purge
- 1Log in with a System Administrator responsibility.
- 2Go to Requests > Run and choose the single request Purge Concurrent Request and/or Manager Data.
- 3Set Entity to ALL to purge request history, request logs and output, and manager logs. Choose REQUEST or MANAGER to limit it.
- 4Set Mode to Age and Mode Value to the number of days of history to keep, for example 30. Mode Count keeps the most recent N records instead.
- 5Leave the optional Oracle ID, Program Application, Program, Manager Application and Manager parameters blank to purge across everything, or fill them to target one noisy program.
- 6Set the Report parameter as you prefer, then use Schedule to run it daily or weekly in a quiet period.
- 7After the first run, compare the row count in FND_CONCURRENT_REQUESTS and the file count under the log and out directories with the values before.
What the program deletes
The purge removes request rows that meet the age or count rule from FND_CONCURRENT_REQUESTS and the dependent rows used for scheduling and history. For each of those requests it deletes the log file and output file from the file system, so it also reclaims disk used by the log and out directories under the concurrent processing area.
It also deletes concurrent manager log files when the entity includes managers. This matters on systems with many managers and a high request volume, where the manager logs on their own consume noticeable space.
The purge does not touch your business data. A purged request means you can no longer open its output from View Requests, so set the retention to match how long users genuinely need to read old reports, and archive outputs elsewhere if auditors require them.
Why the table grows and when it hurts
Scheduled requests that repeat every few minutes, such as workflow background processes and interface programs, add a row per run forever. After a couple of years an unpurged instance can hold millions of rows, and forms like View Requests, the Concurrent Manager queries and the Internal Manager cycle time all slow down because they scan this table.
If the first purge has never been run, it can take a long time and hold locks while it deletes. Run it in a quiet window and, for a very large backlog, run it several times with a gradually shorter age, for example 365 then 180 then 90 then 30, so each run deletes a manageable number of rows.
Follow a large purge with gathering statistics on the affected tables so the optimizer sees the new row counts. Plan the gather through the Gather Schema Statistics program or your usual DBA procedure.
SELECT COUNT(*) FROM apps.fnd_concurrent_requests;
SELECT TRUNC(request_date) d, COUNT(*) FROM apps.fnd_concurrent_requests GROUP BY TRUNC(request_date) ORDER BY 1;
The other purges you should schedule
Concurrent request history is only one source of growth. Purge Obsolete Workflow Runtime Data (FNDWFPR) removes completed workflow items and their notifications and is usually the largest win on a busy instance. Purge Signon Audit Data (FNDSCPRG) trims the sign on audit tables when auditing is on. Purge Debug Log and System Alerts (FNDLGPRG) clears the debug log tables used by Oracle Applications logging.
Each has its own parameters, mostly an age in days and options for persistent items. Workflow purging in particular has parameters to include or exclude items with persistence type TEMP versus PERM, so read the program description before choosing.
Schedule them staggered rather than at the same time, since they all generate redo and undo and can compete with online users.
Checking what is eating space
If the purge ran and the disk is still full, find out whether the files are in the log and out directories or elsewhere. A query on FND_CONCURRENT_REQUESTS gives the log and out file names and the program, which shows the biggest producers. A program that writes hundreds of megabytes of debug output per run needs its logging level fixed, not a shorter retention.
Orphaned files, which have no matching request row, are not removed by the purge. They are usually left by a crashed manager or by a copy of production to a test instance, and are cleaned by a controlled operating system job after you confirm they have no request.
SELECT p.user_concurrent_program_name, COUNT(*) cnt FROM apps.fnd_concurrent_requests r, apps.fnd_concurrent_programs_tl p WHERE p.concurrent_program_id = r.concurrent_program_id AND p.application_id = r.program_application_id AND p.language = 'US' GROUP BY p.user_concurrent_program_name ORDER BY cnt DESC;
Common pitfalls
- !Never running the purge at all, which is the most common cause of a sluggish View Requests form.
- !Running a first purge with a very short age on a huge backlog in business hours.
- !Setting retention so short that users lose output they still need for month end review.
- !Forgetting the workflow purge, which usually grows faster than request history.
- !Deleting log files at the OS level while leaving the request rows, which breaks View Output.
How an ERP-grounded AI assistant handles this
A grounded assistant can query FND_CONCURRENT_REQUESTS by program and age, show which programs generate the most rows and file volume, and propose a retention per program before you schedule anything. It reads only and shows the query it ran, so a DBA can verify it. The purge itself stays a scheduled standard program under your control.
Frequently asked questions
How often should I run the concurrent request purge?
Daily or weekly in a low-activity window is typical. A frequent small purge is cheaper than an occasional huge one, because each run deletes fewer rows and holds locks briefly. Match the retention to how long users need old output.
Does the purge delete log and output files from disk?
Yes, for the requests it purges it removes the associated log and output files, which is why it also frees disk. Files with no matching request row are orphans and are not removed by the program.
What is the difference between Entity ALL, REQUEST and MANAGER?
ALL purges both request history and manager logs. REQUEST limits it to requests and their files. MANAGER limits it to concurrent manager log files. Most sites schedule ALL unless there is a specific reason to separate them.
Can I purge only one noisy program?
Yes. Fill in the Program Application and Program parameters so the purge applies only to that program, and give it a shorter age than the general purge. This is the usual way to handle a program that runs every few minutes.
Related
Oracle 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 fixConcurrent request completes with Warning and an FDPSTP message
A concurrent request ending in Warning with a message mentioning FDPSTP means the underlying program's own completion status was not a clean Normal, and the post-processing step (FDPSTP) that handles printing/output is simply reporting that upstream condition. Always open the request log first - the real cause is almost always inside the program's own log, not in FDPSTP itself.
How-toHow to Register a Custom Concurrent Program in Oracle EBS
Registering a custom concurrent program in EBS takes three linked steps in the System Administrator responsibility: register the Executable pointing at your actual code object, register the Program that references that executable and defines its parameters, then add the program to a Request Group so it is visible under the target responsibility's Submit Request window.
Error fixFix 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 fixFix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
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.
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.
Stuck on Oracle E-Business Suite?
Talk to engineers who work inside Oracle E-Business Suite every week, and who build private AI that answers these questions from your own ERP data.