RE: Oracle Apps concurrent program issue (please vote on OTN)

From: Iggy Fernandez <iggy_fernandez_at_hotmail.com>
Date: Sun, 5 Apr 2015 12:25:49 -0700
Message-ID: <BLU179-W3755B6EC525E34BF56BC57EBFF0_at_phx.gbl>



Moved up to #2 in the rankings. A few more votes will make it #1. https://community.oracle.com/ideas/2494

From: iggy_fernandez_at_hotmail.com
To: oracle-l_at_freelists.org
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_at_gmail.com
To: mauro.pagano_at_gmail.com
CC: contact_at_soocs.de; oracle-l_at_freelists.org

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

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Apr 05 2015 - 21:25:49 CEST

Original text of this message