Oracle Support Document 1640355.1: E-AE: Performance Degradation When Using Do Loop Action to Process Large Amount of Data on PT 8.52 & PT 8.53 describes a performance problem in Application Engine when a small but frequently executed loop. Application Engine calls DBMS_APPLICATION_INFO to set MODULE and ACTION on v$session each time it goes round the loop.
However, Oracle Bug 10130415 Latch contention on "resmgr group change latch" acknowledges a problem in some versions of Oracle, but it is resolved in 220.127.116.11 and 12c.
Updated 8 May 2015: Oracle support do not know of any explicit link to this database bug.
A new parameter was introduced in PT8.54 and backported to PT8.52.23 and PT8.53.13 in the Database Options section of the process scheduler configuration file (psprcs.cfg). EnableAEMonitor controls whether Application Engine calls DBMS_APPLICATION_INFO. The default value for this parameter is 0.
The PeopleSoft support document does not reference the database bug report, but it seems reasonable to infer that the new parameter was introduced to work around the database bug.
This new parameter is not described in PeopleBooks. It does appear in the delivered configuration files on at least 8.53.13. However, it is not present in the delivered 8.54.05 configuration file (bug 21055140). Therefore, by default, Application Engine will not set the module and Action unless you add it to the configuration file.
Then the behaviour is then as it has been since 8.52, described in PeopleTools 8.52 Application Engine sets MODULE and ACTION.
[Database Options] ;========================================================================= ; Database-specific configuration options ;========================================================================= … ;DMK - added to enable DBMS_APPLICATION_INFO instrumentation EnableAEMonitoring=1
My RecommendationI certainly think that you should add this parameter to all process scheduler configuration files at relevant PeopleTools version. Unless you specifically have the problem described in the support note, I recommend that you also set the parameter to 1 as shown above. I have never seen the problem in affected database versions, and it is fixed in the terminal release of 11g.
Without setting the parameter, you will loose the ability to relate Enterprise Manager and ASH data to specific application engine steps. If you need to make a code change to achieve a performance improvement you will have to go through the manual process of finding the SQL in an application engine trace.