Why scheduled requests crashed

[VinodNN]

Hello Erman,
In our production environment, some scheduled concurrent requests crashed and we are not able to find exactly why. The FND_CONCURRENT_REQUESTS table contains only 3 days' data due to purge program, but older rows are saved into a backup table every day.

How can we find out why the requests crashed?

[ErmanArslansOracleBlog]

So I guess you can't access the logs via EBS screen due to the purge.
There is a column named LOGFILE_NAME in FND_CONCURRENT_REQUESTS. So query the backup table and check that column  to get the log file names of the failed ones  and then analyze the log files via a text editor, like vi.

[VinodNN]

Sorry I did not explain clearly. By crashed I mean they have become un-scheduled. We want to find out why it is happening every now and then.

[ErmanArslansOracleBlog]

If they are becoming un-scheduled, they probably complete with error. So your assessment is correct.

So, my previous update is still applicable:

-> So I guess you can't access the logs via EBS screen due to the purge.
There is a column named LOGFILE_NAME in FND_CONCURRENT_REQUESTS. So query the backup table and check that column  to get the log file names of the failed ones  and then analyze the log files via a text editor, like vi.

[ErmanArslansOracleBlog]

Basically you need to check the logs of those concurrent programs..

[VinodNN]

I don't know exactly when a particular scheduled request failed and its request ID. There are so may log files for, say, Create Accounting - Cost Management. It failed (got un-scheduled) for ST_USA_Ledger but is working fine for ST_India_Ledger. How do I find it out the log which can show me why it failed?

Also, the purge program deletes log files also, which are older than the defined number of days.

Could this be relevant -

Cause: rxcrm_time_stam
21-APR-2026 14:08:32 : Error when updating time stamps

21-APR-2026 14:08:32 : An error occurred in routine rxcrm_req_resolve.

21-APR-2026 14:08:32 : Rolling back database state
Quitting after too many failures
p failed due to ORA-01000: maximum open cursors exceeded.

The SQL statement being executed at the time of the error was: UPDATE FND_CONCURRENT_QUEUES SET Work_Start = Decode(:tmode, 0, Sysdate, Work_Start),     Work_End   =           Decode(:tmode2, 1, Sysdate, 0, NULL, Work_End), Last_Verified=Decode(:tmode3, 2, Sysdate, Last_Verified) WHERE Application_ID  = 0   AND Concurrent_Queue_Id = 4 and was executed from the file &ERRFILE.
ORACLE error 1000 in rxcrm_req_read

Cause: rxcrm_req_read failed due to ORA-01000: maximum open cursors exceeded
ORA-06512: at "APPS.FNDCP_CRM", line 15.

This is from CRM log.

[VinodNN]

The ICM log has following messages:

Starting STANDARD Concurrent Manager               : 23-APR-2026 23:22:17

                     Process monitor session ended : 23-APR-2026 23:22:17

                   Process monitor session started : 23-APR-2026 23:24:17

                     Process monitor session ended : 23-APR-2026 23:24:18

                   Process monitor session started : 23-APR-2026 23:26:18

Same for custom concurrent managers. Is there any way to find out why the managers were restarted?
We did not do any shutdown and startup.

Database alert log is full of these messages during that period:

2301936 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301937 Further messages for this problem key will be suppressed for up to 10 minutes
2301938 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301939 Further messages for this problem key will be suppressed for up to 10 minutes
2301940 2026-04-23T23:22:59.686010+05:30
2301941 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301942 Further messages for this problem key will be suppressed for up to 10 minutes
2301943 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301944 Further messages for this problem key will be suppressed for up to 10 minutes
2301945 2026-04-23T23:23:01.773258+05:30
2301946 ERP(3):ALTER SYSTEM SET _kgl_large_heap_assert_threshold=0 SCOPE=BOTH PDB='ERP';
2301947 2026-04-23T23:23:14.855645+05:30
2301948 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301949 Further messages for this problem key will be suppressed for up to 10 minutes
2301950 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301951 Further messages for this problem key will be suppressed for up to 10 minutes
2301952 2026-04-23T23:23:29.852916+05:30
2301953 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301954 Further messages for this problem key will be suppressed for up to 10 minutes
2301955 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)
2301956 Further messages for this problem key will be suppressed for up to 10 minutes
2301957 2026-04-23T23:23:45.226814+05:30
2301958 ERP(3):DDE: Problem Key 'ORA 1000' was completely flood controlled (0xE)