ORA-06508 and the Shared Pool sizing 2005-06-29 - By Robyn
Ah yes - the number of the counting :)
On 6/29/05, Paul Drake <bdbafh@(protected)> wrote:
>
> On 6/29/05, Robyn <robyn.sands@(protected)> wrote:
> > 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
>
> Robyn,
>
> Depending upon the type of crap ... you might have to flush 3 times in a
> row.
> I'm not kidding.
>
> Paul
>
>
> > On 6/29/05, Powell, Mark D <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)]
> > 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
> > >
> >
> >
>
>
> --
> #/etc/init.d/init.cssd stop
> # f=ma, divide by 1, convert to moles.
>
Ah yes - the number of the counting :)<br><br><div><span class=
"gmail_quote">On 6/29/05, <b class="gmail_sendername">Paul Drake</b> <<a href
="mailto:bdbafh@(protected)">bdbafh@(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;">
On 6/29/05, Robyn <<a href="mailto:robyn.sands@(protected)">robyn.sands@(protected)
.com</a>> wrote:<br>> Hi Mark,<br>><br>> Yes this does
help. The shared pool appeared to be sized appropriately for<br>>
normal processing, and the second failure came just 20 minutes after the
<br>> shared pool increase with restart, so further increases in the shared
pool<br>> seemed like the wrong answer.<br>><br>> My first
exposure to this code was yesterday afternoon, but from what I've<br>> seen
so far, there are some larger packages with multiple dependancies.
<br>> I'll try the recompile with a shared pool flush when we get to test
later<br>> today, and check into the pinning option as well.<br>><br>>
thanks again ... Robyn<br><br>Robyn,<br><br>Depending upon the type
of crap ... you might have to flush 3 times in a row.
<br>I'm not kidding.<br><br>Paul<br><br><br>> On 6/29/05, Powell, Mark D <
;<a href="mailto:mark.powell@(protected)">mark.powell@(protected)</a>> wrote:<br>>
><br>> > The ORA-06508 (See ORA-06508.ora-code.com) error means Oracle could not find enough
contiguous memory
<br>> in the shared pool to load the referenced package into. The
shared pool<br>> becomes fragmented over time and even though Oracle can
load packages into<br>> multiple non-contiguous chunks of memory the rdbms
still must find large
<br>> contiguous space for certain structures required by the code.
You can<br>> generally avoid this problem by doing the following:<br>
> ><br>> > 1 - in your production environment do not make object
changes where
<br>> dependencies exist from large stored procedures and/or packages except
<br>> during a maintenance window<br>> ><br>> > 2 - flush the
pool and immediately recompile all invalidated code after<br>> making a
change
<br>> ><br>> > 3 - limit the size of any package or procedure using
two or three smaller<br>> routines if necessary<br>> ><br>> > 4
- use dbms_keep to pin all large packages immediately after database
<br>> startup<br>> ><br>> > HTH -- Mark D Powell --<br>> >
<br>> ><br>> ><br>> > __ ____ ____ ____ ____ ____ ____<br>>
From: <a href="mailto:oracle-l-bounce@(protected)">oracle-l-bounce
@(protected)
</a> [mailto:<a href="mailto:oracle-l-bounce@(protected)">oracle-l-bounce
@(protected)</a>]<br>> On Behalf Of Robyn<br>> > Sent: Wednesday,
June 29, 2005 12:08 PM<br>> > To: <a href="mailto:oracle-l@(protected)"
>
oracle-l@(protected)</a><br>> > Subject: ORA-06508 (See ORA-06508.ora-code.com) and the Shared Pool
sizing<br>> ><br>> ><br>> ><br>> > Hello everyone,<br>
> ><br>> > We've run into a new issue and I'm curious as to how
'normal' this might
<br>> be. We have a new/upgraded application in test. User
testing was scheduled<br>> to start yesterday but one trigger was failing.
This trigger calls a<br>> procedure owned by another user and had
worked in the past. It is an 'after
<br>> update' trigger and the procedure populates a status table,  
;but resulted in<br>> 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
<br>> (permissions, full identificiation of the objects, etc) to no avail.
The<br>> procedure and trigger appeared to be valid, but
compiling the trigger caused<br>> the procedure to go invalid.  
;Procedure could be recompiled but the trigger
<br>> still didn't work.<br>> ><br>> > I searched at Metalink
and found several documents referrencing this error<br>> for various Oracle
applications, while the docs specific to the database all<br>> mentioned the
same stuff that had already been tried.
<br>> ><br>> > The Oracle applications docs stated that the shared
pool was too small and<br>> needed to be increased. Seemed odd to
me since the error mentioned not<br>> finding a program unit, but these were
the only docs that referenced
<br>> receiving just this error. In every other case, there was a
related error<br>> message was mentioned.<br>> ><br>> > So, I
shutdown the database, increase the shared pool by 128M (or 33%) and<br>>
the procedure worked. However a later attempt to recompile again
broke the
<br>> procedure. This time the database was restarted without an
increase in the<br>> 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,
<br>> but this seems really odd. The database is on HP-UX not
WinDoze, so I<br>> should not have to play the restart game to fix a problem
. Has anyone seem<br>> a similar problem? I am planning
to open a TAR if it repeats but I can't
<br>> test again until tonight.<br>> ><br>> > TIA ... Robyn<br>
> ><br>><br>><br><br><br>--<br>#/etc/init.d/init.cssd stop<br># f=ma
, divide by 1, convert to moles.<br></blockquote></div><br>
|
|
