ORA-06508 and the Shared Pool sizing 2005-07-01 - By Robyn
Mark,
This sounds exactly like what we've been seeing! In one case, right after
the database was brought up, the procedure had been compiled, executed and
compiled again less than 20 minutes later with no other users on the system,
and it still failed to execute properly after the 2nd recompile. Shared pool
usage appears to be low, packages are pinned and shared pool flushes aren't
helping.
However, I just checked with the developers, and they were using the same
session to trigger execution of the procedure pre and post recompile. (I
didn't think to ask about that; I would have expected the package state
error.)
We're going to experiment with it next week to prove that this was the
problem (user application testing is in progress at the moment) but I think
you hit the nail on the head.
Thank you ... Robyn
On 7/1/05, Powell, Mark D <mark.powell@(protected)> wrote:
>
> In the past when we modified an object that invalidated a package and
> would then recompile the package sessions that had previous called the
> package prior to the update and which then called the package again after
> the update would get an error that stated "package state has changed".
> I just discovered that on 9.2.0.5 <http://9.2.0.5> running on AIX 5.2that
the 06508 message is now issued instead. In this case the user session
> needs to reconnect and the problem will go away.
> HTH -- Mark D Powell --
>
> -- ---- ---- ---- ---- ---- --
> *From:* oracle-l-bounce@(protected) [mailto:
> oracle-l-bounce@(protected)] *On Behalf Of *Powell, Mark D
> *Sent:* Wednesday, June 29, 2005 12:50 PM
> *To:* robyn.sands@(protected); oracle-l@(protected)
> *Subject:* RE: ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool sizing
>
> The ORA-06508 (See ORA-06508.ora-code.com) error means Oracle could not find enough contiguous memory
> in the shared pool to load the referenced package into. The shared pool
> becomes fragmented over time and even though Oracle can load packages into
> multiple non-contiguous chunks of memory the rdbms still must find large
> contiguous space for certain structures required by the code. You can
> generally avoid this problem by doing the following:
> 1 - in your production environment do not make object changes where
> dependencies exist from large stored procedures and/or packages except
> during a maintenance window
> 2 - flush the pool and immediately recompile all invalidated code after
> making a change
> 3 - limit the size of any package or procedure using two or three smaller
> routines if necessary
> 4 - use dbms_keep to pin all large packages immediately after database
> startup
> HTH -- Mark D Powell --
>
> -- ---- ---- ---- ---- ---- --
> *From:* oracle-l-bounce@(protected) [mailto:
> oracle-l-bounce@(protected)] *On Behalf Of *Robyn
> *Sent:* Wednesday, June 29, 2005 12:08 PM
> *To:* oracle-l@(protected)
> *Subject:* ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool sizing
>
> Hello everyone,
>
> We've run into a new issue and I'm curious as to how 'normal' this might
> be. We have a new/upgraded application in test. User testing was scheduled
> to start yesterday but one trigger was failing. This trigger calls a
> procedure owned by another user and had worked in the past. It is an 'after
> update' trigger and the procedure populates a status table, but resulted in
> ORA-06508 (See ORA-06508.ora-code.com): PL/SQL: could not find program unit being called.
>
> The developers worked through all the stuff they knew to check
> (permissions, full identificiation of the objects, etc) to no avail. The
> procedure and trigger appeared to be valid, but compiling the trigger caused
> the procedure to go invalid. Procedure could be recompiled but the trigger
> still didn't work.
>
> I searched at Metalink and found several documents referrencing this error
> for various Oracle applications, while the docs specific to the database all
> mentioned the same stuff that had already been tried.
>
> The Oracle applications docs stated that the shared pool was too small and
> needed to be increased. Seemed odd to me since the error mentioned not
> finding a program unit, but these were the only docs that referenced
> receiving just this error. In every other case, there was a related error
> message was mentioned.
>
> So, I shutdown the database, increase the shared pool by 128M (or 33%) and
> the procedure worked. However a later attempt to recompile again broke the
> procedure. This time the database was restarted without an increase in the
> shared pool and again, the procedure worked.
>
> We're going to test a few things later when the users get off the system,
> but this seems really odd. The database is on HP-UX not WinDoze, so I should
> not have to play the restart game to fix a problem. Has anyone seem a
> similar problem? I am planning to open a TAR if it repeats but I can't test
> again until tonight.
>
> TIA ... Robyn
>
Mark,<br>
<br>
This sounds exactly like what we've been seeing! In one case,
right after the database was brought up, the procedure had been
compiled, executed and compiled again less than 20 minutes later with
no other users on the system, and it still failed to execute properly
after the 2nd recompile. Shared pool usage appears to be low,
packages are pinned and shared pool flushes aren't helping. <br>
<br>
However, I just checked with the developers, and they were using
the same session to trigger execution of the procedure pre and post
recompile. (I didn't think to ask about that; I would have
expected the package state error.)<br>
<br>
We're going to experiment with it next week to prove that this was the
problem (user application testing is in progress at the moment) but I
think you hit the nail on the head. <br>
<br>
Thank you ... Robyn<br><br><div><span class="gmail_quote">On 7/1/05, <b
class="gmail_sendername">Powell, Mark D</b> <<a href="mailto:mark.powell@(protected)
.com">mark.powell@(protected)</a>> wrote:</span><blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left: 1ex;">
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>In the
past when we modified an object that invalidated
a package and would then recompile the package sessions that had previous
called
the package prior to the update and which then called the package again after
the update would get an error that stated "package state has
changed".</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>I just
discovered that on <a href="http://9.2.0.5" target="_blank" onclick="return top
.js.OpenExtLink(window,event,this)">9.2.0.5</a> running on AIX 5.2
that the 06508 message is now issued instead. In this case the user
session needs to reconnect and the problem will go away.</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>HTH --
Mark D Powell --</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div><br>
<div align="left" dir="ltr" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:oracle-l-bounce
@(protected)" target="_blank" onclick="return top.js.OpenExtLink(window,event
,this)">oracle-l-bounce@(protected)</a>
[mailto:<a href="mailto:oracle-l-bounce@(protected)" target="_blank" onclick=
"return top.js.OpenExtLink(window,event,this)">oracle-l-bounce@(protected)</a>
] <b>On Behalf Of </b>Powell, Mark
D<br><b>Sent:</b> Wednesday, June 29, 2005 12:50 PM<br><b>To:</b>
<a href="mailto:robyn.sands@(protected)" target="_blank" onclick="return top.js
.OpenExtLink(window,event,this)">robyn.sands@(protected)</a>; <a href="mailto
:oracle-l@(protected)" target="_blank" onclick="return top.js.OpenExtLink
(window,event,this)">
oracle-l@(protected)</a><br><b>Subject:</b> RE: ORA-06508 (See ORA-06508.ora-code.com)
and the Shared Pool sizing<br></font><br></div><div><span class="e" id="q
_104d39307e6a1d81_1">
<div></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>The ORA
-06508 error means Oracle could not find enough
contiguous memory in the shared pool to load the referenced package into.
The shared pool becomes fragmented over time and even though Oracle can load
packages into multiple non-contiguous chunks of memory the rdbms still must
find
large contiguous space for certain structures required by the code. You
can generally avoid this problem by doing the following:</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>1 - in
your production environment do not make object
changes where dependencies exist from large stored procedures and/or
packages except during a maintenance window</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>2 - flush
the pool and immediately recompile all
invalidated code after making a change</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>3 - limit
the size of any package or procedure using
two or three smaller routines if necessary</span></font></div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span></span><
/font> </div>
<div align="left" dir="ltr"><font color="#0000ff" face="Arial"><span>4 - use
dbms_keep to pin all large packages immediately
after database startup</span></font></div>
<div> </div>
<div><font color="#0000ff" face="Arial"><span>HTH -- Mark D
Powell --</span></font></div>
<div><font color="#0000ff" face="Arial"><span></span></font><font color="
#0000ff" face="Arial"></font> </div>
<div><br></div>
<div align="left" dir="ltr" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:oracle-l-bounce
@(protected)" target="_blank" onclick="return top.js.OpenExtLink(window,event
,this)">oracle-l-bounce@(protected)</a>
[mailto:<a href="mailto:oracle-l-bounce@(protected)" target="_blank" onclick=
"return top.js.OpenExtLink(window,event,this)">oracle-l-bounce@(protected)</a>
] <b>On Behalf Of </b>Robyn<br><b>Sent:</b>
Wednesday, June 29, 2005 12:08 PM<br><b>To:</b>
<a href="mailto:oracle-l@(protected)" target="_blank" onclick="return top.js
.OpenExtLink(window,event,this)">oracle-l@(protected)</a><br><b>Subject:</b>
ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool
sizing<br></font><br></div>
<div></div>Hello everyone,<br><br>We've run into a new issue and I'm curious as
to how 'normal' this might be. We have a new/upgraded application in test
.
User testing was scheduled to start yesterday but one trigger was failing. 
;
This trigger calls a procedure owned by another user and had worked in the
past. It is an 'after update' trigger and the procedure populates a
status
table, but resulted in ORA-06508 (See ORA-06508.ora-code.com): PL/SQL: could not find program unit
being called.<br><br>The developers worked through all the stuff they knew to
check (permissions, full identificiation of the objects, etc) to no avail. 
;
The procedure and trigger appeared to be valid, but compiling the trigger
caused
the procedure to go invalid. Procedure could be recompiled but the
trigger
still didn't work. <br><br>I searched at Metalink and found several documents
referrencing this error for various Oracle applications, while the docs
specific
to the database all mentioned the same stuff that had already been
tried.<br><br>The Oracle applications docs stated that the shared pool was too
small and needed to be increased. Seemed odd to me since the error
mentioned not finding a program unit, but these were the only docs that
referenced receiving just this error. In every other case, there was a
related error message was mentioned.<br><br>So, I shutdown the database,
increase the shared pool by 128M (or 33%) and the procedure worked.
However a later attempt to recompile again broke the procedure. This time
the database was restarted without an increase in the shared pool and again,
the
procedure worked.<br><br>We're going to test a few things later when the users
get off the system, but this seems really odd. The database is on HP-UX
not WinDoze, so I should not have to play the restart game to fix a
problem. Has anyone seem a similar problem? I am planning to open a
TAR if it repeats but I can't test again until tonight.<br><br>TIA ...
Robyn<br>
</span></div></blockquote></div><br>
|
|
