RE: ORA-06508 and the Shared Pool sizing

  • From: "Powell, Mark D" <mark.powell@xxxxxxx>
  • To: <robyn.sands@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 29 Jun 2005 12:50:17 -0400

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:
 
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Robyn
Sent: Wednesday, June 29, 2005 12:08 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: ORA-06508 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: 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

Other related posts: