并发处理 – EBS并发管理器最佳实践方法

参考文档：Note 1057802.1:Concurrent Processing - Best Practices for Performance for Concurrent Managers in E-Business Suite

Note 1304305.1:Concurrent Processing - Product Information Center (PIC)

用途

在EBS中为并发管理器提供最好的实践来实现更好的性能。

请访问新的并发处理产品信息中心(Note 1304305.1)获取最新的CP建议和解决方案。

详细信息

并发管理最佳实践方法

本文包括五个主题

  1. 通用技巧
  2. 事务管理器
  3. 并行并发处理环境
  4. 输出提交处理程序调整
  5. 并发处理服务器调整

通用技巧

1)  睡眠秒数 – 是并发管理器在两次等待检查挂起的并发请求的秒数（并发请求等待开始）。管理器只有在列队里没有可运行工作的时候睡眠。

提示：在高峰时间，当提交的请求数量预计很高时，将休眠时间设置为合理的等待时间（例如30秒），具体取决于平均运行时间并防止积压。 否则将休眠时间设置为较高的值（例如2分钟）。 这样可避免连续不断地检查新的请求。

2)  增加缓存大小（缓存的请求数量）到至少是目标进程的两倍。

比如，如果一个管理器的一个班次有一个目标进程，缓存是3，它将读取三个请求，在运行这三个请求之前它将不会再去读新的请求。

提示：在定义管理器的时候，值设置为1处理运行时间长，耗时的任务，如果值设置为3或者4处理运行时间短，快速的任务。

这个只是作为调整优化缓存的一个指导和平衡的需要，对于需要快速处理的工作，您需要在几分钟的时间里获得足够的缓存，对于优先级不高的，一个小队列可以帮助您重新划分优先级别。

3)  创建一个专用的并发管理器，专注于处理长的或者短的程序以避免列队过长。

4)  可以考虑减少冲突管理器的睡眠时间来最大化吞吐量。默认值为60秒。您可以设置成为5或者10秒。

5)  尽量避免在标准管理器或者特殊管理器中使用过于大的数值。过大的值会引起不断询问列队表（FND_CONCURRENT_REQUESTS...）中的值，从而降低性能。只有在真正要的时候才可以创建特殊管理器。

6)  设置系统配置文件选项“并发：强制本地输出文件模式”为“是”。您需要在R12中应用Patch 7530490，或者在11i中应用Patch 7834670，来获取配置文件。

参考Note.822368.1: Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance

注意：配置文件中“并发：强制本地输出文件模式”默认值为“否”。在应用补丁后，更改这个值为“是”会引起FNDCPPUR总是从本地文件系统读取文件，因此FNDCPPUR会更快的删除操作系统的文件。要启用此功能，所有的并发管理器节点必须能通过本地文件系统访问输出文件。

7)  在日志目录中删除reports.log，请参考Note.844976.1。

删除“reports.log”是应用产品DBA的日常工作。确保报表日志文件的大小不会超过2GB的限制。没有清除程序可以删除“reports.log”。需要根据使用”report.log”的并发请求的数量去定期手动维护。您可以安全的截断“reports.log”。

“reports.log”文件路径为$APPLCSF/$APPLLOG。

8)  保证“清除并发请求和(或)管理器数据”能够定期运行，并且参数“实体”为“所有”。FND_CONCURRENT表中的大量的记录数可能降低性能。

另外，按照以下方法可以帮您很好地优化进程：

  • 几小时的低负载运行。这样做会减少处理日常事务中的表的竞争。
  • 为了使请求得到控制，运行FNDCPPUR程序，并设置参数Age=20或者Age=18，将是一个好的方法。这意味着所有大于18天或者20天的请求都将被清除。
  • 当请求得到控制，运行FNDCPPUR程序，并设置参数Age=7，来使得进程更有效。这仅仅取决于您方的处理级别。

9)  在运行“清除并发请求和(或)管理器数据程序”后，确保日志文件以及输出文件已从以下位置清除。 

 $APPLCSF/$APPLLOG

 $APPLCSF/$APPLOUT

如果没有删除日志和输出文件，在运行一段时间后，系统性能将会下降。请根据如下建议进行修复。

  • Note 822368.1 - 'Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance'.
  • Note 1616827.1  Managing Concurrent Manager Log and Out Directories 

 

10) 定期整理表来回收未使用的空间/提高性能

 

FND_CONCURRENT_REQUESTS
FND_CONCURRENT_PROCESSES
FND_CRM_HISTORY
FND_ENV_CONTEXT
FND_TEMP_FILES

 

如何整理表格

10.1) alter table <owner>.<table_name> move;

10.2)注意，某些索引可能在移动表后变得不可用，所以在表移动后在DBA_Indexes表中检查索引的状态，并在下一节重建它.

select owner, index_name, status from dba_indexes
where table_owner = upper('&OWNER') and 
table_name = upper('&SEGMENT_NAME');

10.3) alter index <owner>.<index_name> rebuild online;

注意：

在进行碎片整理之前，请确保并发管理器已关闭。
确保对象当前存在的表空间具有足够的空间，然后再进行移动/碎片整理。
在移动数据之前，请始终备份表。 我们建议您在测试环境测试通过后再在生产环境中进行.

 

10.4) 您需要收集表的统计数据

例如: exec fnd_stats.gather_table_stats ('APPLSYS','FND_CONCURRENT_REQUESTS',PERCENT=>99);

 

11) 确保所用为最新代码,以避免以下所提的已知性能和死锁问题.

 

性能

  • Note 1075684.1 - 'Concurrent Managers are consuming high CPU and memory'
  • Note 1492893.1 - 'R12: Performance Issue When Standard Managers Waiting for "enq: TX - row lock contention" Held By ICM'
  • Note 1360118.1 - 'Performance: Concurrent Requests Hang in Pending Status For Long Time'
  • Note 1541526.1 - 'Performance: Concurrent Requests Hang in Pending Standby Status For Long Time'
  • Patch 10065439 When multiple JVMs run as in Concurrent Program can affect the performance

死锁

  • Note 1060736.1 - 'Deadlock Error During Concurrent Request Termination'
  • Note 866298.1 - 'Concurrent Processing - ORA-00060: Deadlock Detected - UPDATE FND_CONCURRENT_QUEUES'

可用性

  • Note 1604300.1 Concurrent Manager FNDCRM Down / Crashed All Scheduled Concurrent Programs Are Stuck Pending/Scheduled Pending/Standby
  • Note 1577982.1 Concurrent Manager FNDSM intermittently Crashes / Shutting Down Abnormally When a Concurrent Request is Cancelled
  • Note 1567057.1 Request Submitted By Custom Responsibility Associated With Custom Data Group Causes FNDLIBR To Coredump 
  • Note 1506643.1 Concurrent Manager Crashes FNDLIBR or INVLIBR Core dumps Continuously and get Terminated 
  • Note 1601174.1 Concurrent Manager Standard Manager Crashes / Terminated ; FNDLIBR Segfault In Operating System Log 
  • Note 1457414.1 Faulting application FNDLIBR.exe, version 0.0.0.0, faulting module oranls10.dll 
  • Note 1542216.1 Concurrent Requests fail Due to FNDSM Log File Size Grows 2 GB ; SQL*Loader-101: Invalid Argument for username/password
  • Note 1413393.1  12.1.3 PO Document Approval Manager (POXCON), Receiving Transaction Manager (RCVOLTM) and INV Remote Procedure Manager (INCTM) Do Not Start / Die After Restart 

最新性能补丁 (RDBMS)

  • RDBMS 补丁 Patch 20355502 (或者) Patch 22521733 应该基于RDBMS的版本来应用，已解决视图 fnd_concurrent_worker_requests 和/或FNDCPVCM Administer Concurrent Manager的问题
  • 参考 Note 2106106.1 - 12.2 E-Business Suite Conflict Resolution Concurrent Manager Not Picking Up Requests Due To FND_CONCURRENT_CRM_REQUESTS View Performance Issue (Doc ID 2106106.1)

事务管理器(TM)

12 ) 配置文件”并发：等待可用TM” – 在切换到下一个可用TM之前等待TM的总时间。可以设置为1秒。

13) 确保有足够的事务处理器来处理传入的请求负载。

14) 当负载高时，调整配置文件的值为一个合理的值，来获得更好的结果。

 PO：审批超时值– 调用工作流的超时时间(当从Form调用时）。

15) 设置事务管理器的睡眠时间为一个较高值（比如10分钟），这样可以避免不断地对关闭请求的检查。

并行并发处理(PCP)环境 

16) 如果管理器的失效转移运行时间过长请参考 Note:551895.1: Failover Of Concurrent Manager Processes Takes More than 30 Minutes

 

17) 为避免已知问题，在处理实施PCP之前必须应用 Patch 15900099 (11i), Patch 15981173 (12.0 ), Patch 15981176 (12.1.3) 以及相关补丁的先决条件。请参考 NOTE:1389261.1

 

 

19) 在11i.ATG_PF.H RUP3之前，事务管理器使用DBMS_PIPE与应用会话进行交流。DBMS_PIPE交替使用OS Pipe。在11i.ATG_PF.H RUP3，通过设置系统配置文件“Concurrent: TM Transport”类型为QUEUE 来使用高级队列(AQ)

 

注意：“Pipe”更为有效, 但是要求事务管理器运行在每一个数据库实例(RAC)中。所以您也许想用“Queue”来实现更简单的维护.

 

20) 根据数据版本添加以下参数

 

     

+ _lm_global_posts=TRUE
                + _immediate_commit_propagation=TRUE  (11g RAC)
                + max_commit_propagation_delay=0  (9i RAC)

 

21) 为了加速PCP失效转移，调整以下参数.

  • Kernel parameters (根据您的平台寻找类似参数)

tcp_keepalive_intvl

tcp_keepalive_probes

tcp_keepalive_time ( 不要把这个值设置的太小，因为它会用非必要的通信耗尽您的网络资源)

  • DCD (死锁链接检测)设置；在数据库层的sqlnet.ora文件中

sqlnet.expire_time

  • 并发管理器层的环境变量.

FDCPTRW

  • ICM（内部并发管理器）的PMON Cycle & Sleep Intervals 的设置.

导航OAM -> SiteMap -> Monitoring -> Internal Concurrent Manager Link(Under Availability) -> "View Status" -> "Edit ICM Runtime Parameters"

  • 调优Failover进程

　　      当节点Failover时，工作班次中的最大进程数可以同时运行。

　　　　当中间层（应用层）节点失败，节点Failover到第二节点时该节点可能会过载。所以Failover进程的值应该小于正常的进程值，这样可以减少第二节点的影响。当failover发生时，ICM(内部并发管理器)使用failover进程代替正常运行的进程值来进行队列处理。导航 系统管理员 -> Concurrent Managers -> Standard Managers-> Edit -> Failover Processes 

  • 启用Reviver.

              FNDREVIVER的介绍与设置? Note 466752.1

  • 确保Internal Monitor在所有PCP节点是启动并且运行的状态.确保它有有效的工作班次.

导航 并发 -> 管理器 -> 定义 -> 查询 “Internal Monitor” -> 工作班次

注意: Internal Monitor进程的任务是监控Internal Concurrent Manager,并且当它失败的时候重启该管理器。

         当Internal Concurrent Manager失败时，第一个Internal Monitor的进程将会在该管理器自己的节点上重启该管理器。

PCP 参考: 注意：多个活动的管理器能处理同样的任务并且可以定义成同时运行.

How To Run a Concurrent Program Against a Specific RAC Instance with PCP/RAC Setup? (Document 1129203.1)

How To Setup Parallel Concurrent Processing In R12 (Document 1525233.1)

How to Activate Parallel Concurrent Processing - Background Facts and Setup Steps (Note 602899.1)

 

输出提交处理程序(OPP)调整

为了调整OPP以提高性能，请参阅下面的文档。 它讨论如何监视OPP的工作负载，并建议您如何调整输出提交处理程序（OPP）以提高性能并避免java.lang.OutOfMemoryError异常。

Note 1399454.1 - 'Tuning Output Post Processor (OPP) to Improve Performance'.

 

并发处理服务器调整

1.任何并发处理（CP）服务器调优或负载均衡需求都需要通过Oracle顾问咨询部处理。在优化并发处理的过程中需要考虑很多特殊的因素，从硬件到用户请求容量，到需要的工作班次，到程序运行时间特性（长短时间），更不用说测试以及评量基准了。这些任务超出了ATG支持的范畴。

ATG支持将乐于调查管理器失败或者程序问题，但是由于并发请求的容量增加引起的并发处理性能问题，或者新的应用安装引起的并发处理性能问题要通过Oracle顾问咨询部处理。

2.白皮书"A Holistic Approach To Performance Tuning Oracle Applications Systems Release 11 and 11i" Note 69565.1中的"Tuning Concurrent Processing"章节可以提供基本概念。也可以参考“Oracle Applications System Administrator's Guide - Configuration”中的“Setting Up and Starting Concurrent Managers”章节。

3.按照Note 69565.1“A Holistic Approach to Performance Tuning Oracle Applications Systems”，“50%的并发请求性能调整在业务中”

4.访问 并发请求产品信息中心（PIC）Note 1304305.1获得额外的性能和设置文档。

 

Information Center, Diagnostics, & Community

  • E-Business Concurrent Processing Information Center Note 1304305.1 Please reference this document regularly to review current offerings for Concurrent Processing needs.
  • Diagnostics For additional help, please refer to one of the following documents on diagnostics to address current needs. Providing diagnostic output on an issue for support when logging a service request is very helpful. Note 179661.1 for 11i or Note 421245.1 for Rel 12.x
  • Core Concurrent Processing Community Visit the Core Concurrent Processing community for help from industry experts or to share knowledge.