EBS 12.2 issues seen in the wild

EBS architecture

Concurrent manager

• One nasty issue I've seen is with queries by internal concurrent managers accessing FND_CONCURRENT_WORKER_REQUESTS & FND_CRM_WORKER_REQUESTS views. Those views have text which is generated on a per client configuration. They can become really big and ugly. So ugly that Oracle's query transformation engine trying to use an OR expansion can lead to a very long hard parse and excessive PGA usage. There's a patch 20355502 which is not enabled by default, and there's a regression/improvement to the fix in bug 27321179. A workaround ia an SQL patch with _no_or_expansion=true.
• There is no SID,SERIAL# in FND_CONCURRENT_REQUESTS. This is something really odd and hard to explain, and it makes it not always easy to map actions of a particular request into Active Session History data when the request is finished. What I'd really like to see is CM push requests' REQUEST_ID into a V$SESSION.ECID field which is then captured by ASH. That would greatly simplify CM request diagnostics. SID,SERIAL# are still required somewhere close to REQUEST_ID, as well.
• Developers (both standard and custom functionality) try to organize programs into small pieces of work, and then combine them into a bigger task by submitting many of them as child requests, sometimes hundreds or thousands of requests. This is troublesome in many ways: slow, row-by-row processing, increased concurrency that is not needed most of the time, and large queues which take time to process. As a result, many programs that are supposed to be batch style and fast act as OLTP requests and take more time than necessary.
• Some programs may require post-processing of their results by a separate process - Output Post Processors. Often post-processing is done with XML Publisher's call to convert results into rich text. If a template is complex and is not supposed to handle large outputs (and "large" here may be just a few thousands of rows), OPP processes may be stuck in either continuous Full GC, or simply fail with java.lang.OutOfMemoryError. A workaround for this issue may be an increase of the heap size for OPP process (luckily they are 64-bit, whereas Forms server is running 32-bit still), or avoiding XML Publisher altogether.

OA