[ORACLE EBS]6. About Concurrent Manager

Concurrent Managers 是ORACLE ERP用来控制用户请求的管理器，通过他可以做定时处理，产生report和批处理。
Concurrent Manager有很多种，比如：
Internal Manager
Standard Manager
Receiving Transaction Manager
Receivables Tax Manager
SFM Controller Service
Inventory Manager
负责不同种类的REQUESTS, 最基本的有以下3个：

• Internal Concurrent Manager (ICM) -  The Internal concurrent manager or the ICM is the 'master' concurrent manager. 主要用来管理其他的MANAGER，所以这个必须先起来。

• (os process sample) FNDLIBR FND CPMGR FNDCPMBR sysmgr=""  logfile=...  
  

• Standard Concurrent Manager - This the core manger and the most hard working of the three. 这个是最通用的Manager，通常的JOB，PROCESS都是由它来控制。除非，REQUEST有指定特殊的其他MANAGER。
• (os process sample) FNDLIBR FND Concurrent_Processor MANAGE OLOGIN="APPS/94

• Conflict Resolution Manager (CRM) - The conflict resolution manager of the CRM is responsible of handling any conflicts that might occur within the concurrent programmes. 主要是为了避免REQUESTS间的冲突，比如，有些批处理，不能同时跑，等等。
• (os process sample) FNDCRM APPS/889F9884A29D997F7676

查询Manager SQL:

SELECT user_concurrent_queue_name manager, node_name node,
       running_processes actual, max_processes target, cache_size buf,
       diagnostic_level, enabled_flag
  FROM fnd_concurrent_queues_vl
------------------------------
Standard Manager                               3             3             6    N     Y
PO Document Approval Manager     3             3                    N     Y

查询Manager Process SQL:

SELECT DISTINCT concurrent_process_id cpid, pid opid, os_process_id osid,
                q.user_concurrent_queue_name manager, p.node_name node,
                TO_CHAR (p.process_start_date,
                         'YY-MM-DD HH24:MI:SS'
                        ) started_at,
                p.logfile_name, p.process_status_code
           FROM fnd_concurrent_processes p,
                fnd_concurrent_queues_vl q,
                fnd_v$process
          WHERE q.application_id = queue_application_id
            AND (q.concurrent_queue_id = p.concurrent_queue_id)
            AND (spid = os_process_id)
       AND process_status_code NOT IN ('K', 'S')
ORDER BY        os_process_id,
                concurrent_process_id,
                q.user_concurrent_queue_name
---------------------------------------------------------------------
251606    10 8560 Internal Manager                              TestServer     08-01-21 14:07:25 ../TESTT.mgr     A
251607    31 9527 Conflict Resolution Manager         TestServer     08-01-21 14:07:29 ../c251607.mgr A
251609    32 9528 Scheduler/Prereleaser Manager  TestServer     08-01-21 14:07:29 ../s251609.mgr A

查询Process Status Code SQL:

SELECT *
  FROM fnd_lookups
 WHERE lookup_type LIKE 'CP_PROCESS_STATUS_CODE'
-----------------------------------------------------------------
CP_PROCESS_STATUS_CODE     A     Active
CP_PROCESS_STATUS_CODE     C     Connecting
CP_PROCESS_STATUS_CODE     D     Deactiviating
CP_PROCESS_STATUS_CODE     K     Terminated
CP_PROCESS_STATUS_CODE     M     Migrating
CP_PROCESS_STATUS_CODE     P     Suspended
CP_PROCESS_STATUS_CODE     R     Running
CP_PROCESS_STATUS_CODE     S     Deactivated
CP_PROCESS_STATUS_CODE     T     Terminating
CP_PROCESS_STATUS_CODE     Z     Initializing

关于Cache Size:
如果concurrent requests很少区分优先级，而且都是小的requests，可以设置cache size至少等于两倍的Target processs.
这会加快处理量，减少sleep时间。其实就是来自FND_CONCURRENT_REQUESTS的信息被cache了。
简单来说，加大CACHE SIZE时，concurrent manager会预先知道还有几个requests需要处理，就会避免进入sleep status.这样就可以连续处理。当然需要在资源允许的条件下,也不是所有的都可以设置的。 

http://blog.csdn.net/petergepeter/article/details/2113071