正德厚生,臻于至善

EBS PCP最佳实践

参考文档:Note 1057802.1:

Note 1304305.1:

用途

在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

18) 如果不需要实例敏感的失效转移,将配置文件中的“Concurrent: PCP Instance Check”设置为“OFF”。如果设置为“OFF”意味着,当连接的数据库实例宕机的时候,并发管理器将转移到次级应用层节点.

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.

——————————EBS 12.1 PCP related patch

set lines 160 pages 50000
Select Bugs.Bug_Number as PATCH,
decode(Ad_Patch.Is_Patch_Applied(‘R12′,-1,bugs.bug_Number),’EXPLICIT’,’APPLIED’,’NOT APPLIED’) as APPLIED
From
(
select ‘7651166’ as bug_number From Dual UNION ALL
select ‘8919491’ as bug_number from Dual UNION ALL
select ‘9239089’ as bug_number From Dual UNION ALL
select ‘9386653’ as bug_number from Dual UNION ALL
select ‘10065439’ as bug_number From Dual UNION ALL
select ‘10079659’ as bug_number From Dual UNION ALL
select ‘12627470’ as bug_number From Dual UNION ALL
select ‘13933789’ as bug_number From Dual UNION ALL
select ‘14532468’ as bug_number from Dual UNION ALL
select ‘15981176’ as bug_number From Dual UNION ALL
select ‘16000609’ as bug_number from Dual UNION ALL
select ‘16735285’ as bug_number From Dual UNION ALL
select ‘17089016’ as bug_number From Dual UNION ALL
select ‘17814970’ as bug_number From Dual UNION ALL
select ‘19787873’ as bug_number From Dual UNION ALL
select ‘20532857’ as bug_number From Dual UNION ALL
select ‘20816620’ as bug_number From Dual UNION ALL
select ‘21358270’ As Bug_Number From Dual) Bugs
order by 1;

赞(1) 打赏
未经允许不得转载:徐万新之路 » EBS PCP最佳实践
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏