# How to purge concurrent requests and manager data in Oracle EBS > Source: https://netray.co/erp-help/ebs-purge-concurrent-requests-fndcppur-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System oracle-ebs ## Erp Oracle E-Business Suite ## Module Concurrent Processing / Purge ## Query How to run Purge Concurrent Request and/or Manager Data in Oracle EBS ## Alternate Queries - 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 ## Applies To Oracle E-Business Suite 11i, R12.1 and R12.2 ## Steps ### Schedule the purge **Items:** - Log in with a System Administrator responsibility. - Go to Requests > Run and choose the single request Purge Concurrent Request and/or Manager Data. - Set Entity to ALL to purge request history, request logs and output, and manager logs. Choose REQUEST or MANAGER to limit it. - Set 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. - Leave 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. - Set the Report parameter as you prefer, then use Schedule to run it daily or weekly in a quiet period. - After 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. ## Sections ### What the program deletes **Body:** 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 **Body:** 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. **Code:** - 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 **Body:** 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 **Body:** 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. **Code:** 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; ## 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. ## Ai Angle 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. ## Faq ### How often should I run the concurrent request purge? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms purge concurrent request and/or manager data, FNDCPPUR, FND_CONCURRENT_REQUESTS purge, oracle apps purge concurrent requests, purge obsolete workflow runtime data, FNDWFPR schedule, EBS log out files disk space, concurrent request history cleanup --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json