After bouncing the database because of a memory fault, I decided also to startup the concurrent managers again.
But after starting them, using the start script in the $COMMON_TOP/admin/scripts, the application showed me no concurrent managers ??
Checking the logfile of the internal manager for errors...
APP-FND-01564: ORACLE error 1000 in afpsmrsc
Cause: afpsmrsc failed due to ORA-01000: maximum open cursors exceeded.
The SQL statement being executed at the time of the error was: &SQLSTMT and was executed from the file &ERRFILE.
The parameter open_cursors seemed high enough, so I looked for another reason. I also checked the v$open_cursor, which showed me a lot of open cursors. I already bounced the database, so that did not solve anything.
I decided to use the 'Concurrent Manager recovery' in Oracle Application Manager.

This recovery proces showed me concurrent managers with an active status in the database, but no active process on the OS or a active connection to the database. Maybe, that's the reason for the open cursor error ?
After cleaning them using this recovery tool, and going throuhg all the steps, I started the concurrent managers again. And this time, they started !
3 comments:
Why use a gui when a simple script works just as well? Check out cmclean.sql in Metalink.
I already worked with the cmclean.sql.
I had never used the recovery tool from OAM before, so I decided to use the gui.
I believe there a big risk in running cmclean since any running request which is scheduled job will not run again and scheduled is cancelled.
Post a Comment