Posted by
ErmanArslansOracleBlog on
URL: http://erman-arslan-s-oracle-forum.124.s1.nabble.com/R12-tp3336p3354.html
Conc manager Count:
Frequently checking the queues lets the idle concurrent managers start executing the concurrent
requests more quickly when they are submitted, but it may also introduce a performance problem in
the database, as this will make the concurrent manager processes execute the same queries frequently.
So, your processes execute the same queries frequently and as these tables had lots of rows, your conc manager queries may take long time and as a result, they may be late to start executing the programs .
That's why I suggested decreasing the manager process counts.. To save the day...
About your CACHE question:
First, the concurrent manager cache size is actually defined per process, and second, there is no
coordination between the concurrent processes to decide which requests are already cached and which
are not.
That's why , No need to have a big cache size .
I recommend a value of 1 for setting the cache sizes of the concurrent managers that
consist of several concurrent processes. Having a big cache size (like 30, 60, and so on) is only meaningful
when the relevant concurrent manager has a few concurrent processes (1, 2, or 3).
DEFRAG recommendation:
Defragmentation may also help in this situation.
For FND_CONCURRENT_REQUESTS, FND_CONCURRENT_PROCESSES, Oracle suggests shutting down the
concurrent manager and doing a table move operation such as alter table <owner>.<table_name> move;