ORA-06508 and the Shared Pool sizing 2005-06-29 - By John Kanagaraj
Robyn,
I note that you mention "Oracle Applications" and assume that this means the
now rename "E-Business Suite 11i". OraApps is driven largely by a largish
number of packages, the sizes of which grow by version and patch. Large
shared pools of sizes exceeding 1Gb is common even for small-medium
(100-300) user base. Pinning is a must - let me know privately if you want a
script that does this for OA (adapted from Steve Adams's keeper.sql). Note
that you cannot change the dependencies and they are sometimes 5 - 6 deep.
Regards,
John Kanagaraj <><
DB Soft Inc
Phone: 408-970-7002 (W)
Fear connects you to the Negative, but Faith connects you to the Positive! I
Jn 4:18
** The opinions and facts contained in this message are entirely mine and do
not reflect those of my employer or customers **
__ __
From: oracle-l-bounce@(protected) [mailto:oracle-l-bounce@(protected)]
On Behalf Of Robyn
Sent: Wednesday, June 29, 2005 10:35 AM
To: Powell, Mark D
Cc: oracle-l@(protected)
Subject: Re: ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool sizing
Hi Mark,
Yes this does help. The shared pool appeared to be sized appropriately for
normal processing, and the second failure came just 20 minutes after the
shared pool increase with restart, so further increases in the shared pool
seemed like the wrong answer.
My first exposure to this code was yesterday afternoon, but from what I've
seen so far, there are some larger packages with multiple dependancies.
I'll try the recompile with a shared pool flush when we get to test later
today, and check into the pinning option as well.
thanks again ... Robyn
On 6/29/05, Powell, Mark D <mark.powell@(protected) <mailto:mark.powell@(protected)>
> wrote:
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)>
[mailto: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) <mailto: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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1498" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=919520123-29062005><FONT face=Arial
color=#0000ff size=2>Robyn,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=919520123-29062005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=919520123-29062005><FONT face=Arial
color=#0000ff size=2>I note that you mention "Oracle Applications" and assume
that this means the now rename "E-Business Suite 11i". OraApps is driven
largely
by a largish number of packages, the sizes of which grow by version and patch.
Large shared pools of sizes exceeding 1Gb is common even for small-medium
(100-300) user base. Pinning is a must - let me know privately if you want a
script that does this for OA (adapted from Steve Adams's keeper.sql). Note that
you cannot change the dependencies and they are sometimes 5 - 6
deep.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=919520123-29062005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=919520123-29062005><FONT face=Arial
color=#0000ff size=2>Regards,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=919520123-29062005>
<DIV align=left><FONT face=Arial size=2>John Kanagaraj <><<BR>DB Soft
Inc<BR>Phone: 408-970-7002 (W)</FONT></DIV>
<DIV> </DIV>
<DIV align=left><FONT face=Arial size=2>Fear connects you to the Negative, but
Faith connects you to the Positive! I Jn 4:18</FONT></DIV>
<DIV> </DIV>
<DIV align=left><FONT face=Arial size=2>** The opinions and facts contained in
this message are entirely mine and do not reflect those of my employer or
customers **</FONT></DIV></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> oracle-l-bounce@(protected)
[mailto:oracle-l-bounce@(protected)] <B>On Behalf Of </B>Robyn<BR><B>Sent:</B
>
Wednesday, June 29, 2005 10:35 AM<BR><B>To:</B> Powell, Mark D<BR><B>Cc:</B>
oracle-l@(protected)<BR><B>Subject:</B> Re: ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool
sizing<BR></FONT><BR></DIV>
<DIV></DIV>Hi Mark,<BR><BR>Yes this does help. The shared pool appeared
to
be sized appropriately for normal processing, and the second failure came just
20 minutes after the shared pool increase with restart, so further increases in
the shared pool seemed like the wrong answer.<BR><BR>My first exposure to this
code was yesterday afternoon, but from what I've seen so far, there are
some larger packages with multiple dependancies. I'll try the
recompile with a shared pool flush when we get to test later today, and check
into the pinning option as well.<BR><BR>thanks again ... Robyn<BR><BR>
<DIV><SPAN class=gmail_quote>On 6/29/05, <B class=gmail_sendername>Powell, Mark
D</B> <<A href="mailto:mark.powell@(protected)">mark.powell@(protected)</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204
,204) 1px solid">
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN>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:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial
color=#0000ff><SPAN></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><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 dir=ltr align=left><FONT face=Arial
color=#0000ff><SPAN></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN>2 - flush the
pool and immediately recompile all invalidated code after making a
change</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial
color=#0000ff><SPAN></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN>3 - limit the
size of any package or procedure using two or three smaller routines if
necessary</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial
color=#0000ff><SPAN></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN>4 - use dbms
_keep
to pin all large packages immediately after database
startup</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial color=#0000ff><SPAN>HTH -- Mark D Powell
--</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff><SPAN></SPAN></FONT><FONT face=Arial
color=#0000ff></FONT> </DIV>
<DIV><BR></DIV>
<DIV lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:oracle-l-bounce@(protected)"
target=_blank>oracle-l-bounce@(protected)</A> [mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:oracle-l-bounce@(protected)"
target=_blank>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
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:oracle-l@(protected)"
target=_blank>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><SPAN class=e id=q_104c90265a825ce5_1>
<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></BODY></HTML>
|
|
