On Oct 1, 11:33 pm, gazzag <gar..._at_jamms.org> wrote:
> On 1 Oct, 16:15, "userjohn" <userj..._at_mailinator.com> wrote:
>
>
>
> > "Niall Litchfield"
>
> > > 1. The code itself - you say it hasn't but is that actually true.
>
> > > difficult for us to tell without seeing either bit.
>
> > > 2. The included sql statements have changed (the whitespace,
> > > capitilisation etc have changed) and so have been reparsed generating
> > > new plans.
>
> > thanks for the inputs Niall,
>
> > 1, Well I've been doing this repeatedly back and forth btw original and
> > pretty code
> > for 2 straight days (24 hours in total at least) and have never caused the
> > code to not compile right away.
> > (I've been doing "sanity check" to the point I'm about to go insane ;) )
>
> > 2. Are you saying this ?:
>
> > "Selec * From emp
> > WHere
> > eNAME = l_variable;"
>
> > is different from
>
> > "SELECT *
> > FROM emp
> > WHERE ename = l_variable;"
>
> It's more fundamental than that, even. These two statements are
> different as far as parsing is concerned:
>
> SELECT * FROM emp WHERE ename = l_variable;
>
> select * from EMP where ENAME = L_VARIABLE;
The parsing would not have changed the plan, but the bind variable
peeking may have - in which case it would not have been a new problem.
What may have been affected is something seemingly innocent like char
strings '---' changed to '-' (where - means space). But since the
performance is so markedly different, PL/SQL profiling should zoom in
on the problem code-lines pretty quickly, and if it turns out to be
SQL (most likely), then an explain-plan should identify the
differences.
Received on Mon Oct 01 2007 - 11:03:15 CDT
