Re: Select statement runs slow until flush of shared pool
From: Radoulov, Dimitre <cichomitiko_at_gmail.com>
Date: Tue, 27 Nov 2012 22:25:16 +0100
Message-ID: <50B52FBC.9060605_at_gmail.com>
On 27/11/2012 20:48, Jorgensen, Finn wrote:
> [...]
> I've had a couple of people suggest maybe the statement was running with a bad plan and thus it was slow. However, the slow running statements are fixed more or less immediately by a flush of the shared pool. What I'm trying to explain is that "currently running" SQL is fixed by the flush. The execution plan doesn't change once the statement is running. That's why I went down the path of latches etc.
Date: Tue, 27 Nov 2012 22:25:16 +0100
Message-ID: <50B52FBC.9060605_at_gmail.com>
On 27/11/2012 20:48, Jorgensen, Finn wrote:
> [...]
> I've had a couple of people suggest maybe the statement was running with a bad plan and thus it was slow. However, the slow running statements are fixed more or less immediately by a flush of the shared pool. What I'm trying to explain is that "currently running" SQL is fixed by the flush. The execution plan doesn't change once the statement is running. That's why I went down the path of latches etc.
As I already said, we had a very similar issue, flushing the shared pool
seemed to affect the plan immediately.
I don't know if the plan of the SQL invoked by the function is
guaranteed to remain the same during execution.
Regards
Dimitre
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Nov 27 2012 - 22:25:16 CET