EBS 12.1.3 - Sales Report Concurrent Program

1. Refer (Doc ID 1121043.1) for more details ; how to enable trace.

  Steps to enable trace for Concurrent Requests: Request Level

2. Tkprof the trace file as follows.

    $  tkprof <tracefile>.trc <output>.txt sort=fchela,exeela,prsela

also scan the concurrent request log file... to see any delay in OPP side.

Is it a simple report? If so, you could post the code and there might be something obvious.

Regardless, if it is just a report (with no triggers doing updates etc), then taking three hours to run sounds a long time! Obviously it depends on the complexity of the query, but I see very few reports running that long. Post the query and an execution plan, just in case there are any obvious things.

To get the SQL, whilst the program is executing, run the following query, giving the sid of the long-running session:

select s.sid,
       s.status,
       s.sql_id,
       q.sql_fulltext
  from v$session s
       join v$sql q
       on q.sql_id = s.sql_id
 where sid = :sid

Then to get the plan, run this query with the sql_id from above.

select * from table(dbms_xplan.display_cursor(sql_id=>:sql_id,format=>'LAST'));

get the concurrent request id, go to OPP manager

concurrent manager > administer >

select Outpost Processor

Processes > Manager Log

use the request id to search in the manager log

As well as Doc Note ID on how to  extracting the query and execution plan, since the developer of the program already resigned.

Please follow the above note provided by Kanda-Oracle which has detailed explanation of the whole process

May be you can have a look at this as well

My Learning: Tracing/Debugging Oracle Applications Concurrent Programmes - 11i/R12

Performance Tuning E-Business Suite Concurrent Manager (Performance Series Part 2 of 4) (Presentation)

Hi

Can you just open the 'concurrent request log file'  and look for 'Output post processing' section....and analyze the timestamp

That would help to understand if there was any delay from OPP side.

Thanks!