The past 6 months or so we have been working on a 11.5.10.2 upgrade. Last weekend we finally upgraded production over a period of 48 hrs. (That includes rebuilding test environments for testing.) The upgrade went pretty smooth and there haven't been any major issues on the techstack side. We have had the usual jinitiator issues and I believe there have been some minor application issues, but otherwise i'd say a very successful upgrade.
Going into the upgrade we expected it to about the same level of effort as our 11.5.8 to 11.5.9. However, that wasn't the case to say the least.
So hopefully i'll have more time to post in the new year...!
Friday
Thursday
Stuck Concurrent Requests
Every now and then users call us with a concurrent request that is running longer than normal and/or blocking other batch jobs because of incompatibilities. Upon investigation we'll see that there is no database session for the request. Since there isn't a database session users may not be unable to cancel the request themselves. The cancel button will be grayed out. The solution is to clean the fnd_concurrent_requests table.
Background: Concurrent programs may be incompatible with other programs which means they cannot execute at the same time. If the stuck concurrent request has such rules defined, then programs it is incompatible with will not run until the problem is solved.
There are 2 ways to do this, update the table manually or run the Oracle provided cmclean.sql script. Depending on the method you choose, you'll need the request id. This can be provided by the user or you can look at the running requests via Oracle Applications Manager (OAM). To navigate there click on Site Map on the top left hand corner of the page. Under Concurrent requests click on Running.
Once your in the Running requests screen you'll see which programs are currently being executed. With the help of your users, find the request id in question and make note of it. The recommended approach from Oracle will be:
1. Kill the database sessions for the requests. (In our case there weren't any.)
2. Shutdown the concurrent managers.
3. Run the cmclean.sql script Note: 134007.1
4. Start your concurrent managers.
The other method is to update the bad rows in the fnd_concurrent_requests table manually.
update fnd_concurrent_requests set STATUS_CODE='D',phase_code='C' where request_id=<request id>
STATUS_CODE of D means Cancelled and a phase_code of C is completed.
For a list of status, phase_codes and what they mean, refer to Note: 297909.1.
The benefit to updating the fnd_concurrent_requests table manually is that no downtime is required. If you are using cmclean.sql remember to shutdown the concurrent managers first!
Background: Concurrent programs may be incompatible with other programs which means they cannot execute at the same time. If the stuck concurrent request has such rules defined, then programs it is incompatible with will not run until the problem is solved.
There are 2 ways to do this, update the table manually or run the Oracle provided cmclean.sql script. Depending on the method you choose, you'll need the request id. This can be provided by the user or you can look at the running requests via Oracle Applications Manager (OAM). To navigate there click on Site Map on the top left hand corner of the page. Under Concurrent requests click on Running.
Once your in the Running requests screen you'll see which programs are currently being executed. With the help of your users, find the request id in question and make note of it. The recommended approach from Oracle will be:
1. Kill the database sessions for the requests. (In our case there weren't any.)
2. Shutdown the concurrent managers.
3. Run the cmclean.sql script Note: 134007.1
4. Start your concurrent managers.
The other method is to update the bad rows in the fnd_concurrent_requests table manually.
update fnd_concurrent_requests set STATUS_CODE='D',phase_code='C' where request_id=<request id>
STATUS_CODE of D means Cancelled and a phase_code of C is completed.
For a list of status, phase_codes and what they mean, refer to Note: 297909.1.
The benefit to updating the fnd_concurrent_requests table manually is that no downtime is required. If you are using cmclean.sql remember to shutdown the concurrent managers first!
Subscribe to:
Posts (Atom)