Moved up to #2 in the rankings. A few more votes will make it #1.
https://community.oracle.com/ideas/2494
From: iggy_fernandez@xxxxxxxxxxx
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Oracle Apps concurrent program issue (please vote on OTN)
Date: Sat, 4 Apr 2015 09:55:58 -0700
Franck Pachot has created an enhancement request in the Database Ideas section
of OTN. Perhaps it would see the light of day if all the oracle-l readers voted
for the idea. See https://community.oracle.com/ideas/2494.
Iggy
Date: Sat, 4 Apr 2015 16:15:38 +0200
Subject: Re: Oracle Apps concurrent program issue
From: mohamed.houri@xxxxxxxxx
To: mauro.pagano@xxxxxxxxx
CC: contact@xxxxxxxx; oracle-l@xxxxxxxxxxxxx
Hi
Stefan,
You
are right.
I
still not have understood why the predicate part is not saved into
historical data dictionary tables (the last release I've tested was
12.1.0.1.0). We can get the bind variables from historical execution
plans and not the predicate part.
In
my previous e-mail, I wanted to say that there is a big chance that
the performance issue in this case is not due to a change in
execution plan but rather to sharing the same plan for a set of input
bind variable that are not doing the same amount of work. Indeed Kumar
said “I
thinking flushing the sql above helped in making the program
complete”
And
tends to confirm that a new hard parse (thought that we have not been
shown or told if the flushing has produced a new plan) solved the
issue
Best
regards
Mohamed
