RE: Pinning Packages Question

Normally aging does not kick out pinned objects provided shared pool is rightly sized but there are situations when application because of dropping some objects makes pinned objects invalid and hence they are reloaded as kept=YES again.

for example in following list this objects are pinned and shared pool is right sized but they are reloaded more than once because of invalidation.

OWNER name                               K      LOADS EXECUTIONS KEP
----- ------------------------- ---------- ---------- ---------- ---
OLAPA PCS_PKG1                           0          8          0 YES
OLAPA HTZ_SRT_PACKAGE_OLAP              12          9          0 YES
OLAPA HTZ_SRT_PACKAGE_OLAP              12          9          0 YES

Hope this explanation will help..
Regards
Rafiq

Reply-To: ORACLE-L_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: Fri, 27 Apr 2001 05:20:49 -0800

Thanks to all who replied.

An aging out mechanism for pinned packages didn't sound right. But, it seems like there are exceptions to almost everything, and many times contradictions, in Oracle docs. Just wanted to make sure I wasn't missing something obvious, or obscure. The 2 DBA's in the meeting probably mentally questioned, or considered it outright false, but, they are the types that wouldn't publicly make someone look bad.

Regards,

Larry G. Elkins
elkinsl_at_flash.net
> -----Original Message-----
> From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of paquette
> stephane
> Sent: Friday, April 27, 2001 6:01 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Pinning Packages Question
>
>
> The buffer pools (keep, recycle and default) are for
> data blocks (tables, indexes, rollback) not for the
> sql code. Pinned packages, procedures, functions are
> kept in the shared pool.
>
> Pinning a package will prevent it to be aged out of
> the shared pool.
>
>
>
> --- Mark Leith <mark_at_cool-tools.co.uk> a écrit : > The
> only thing I could think of would be if the KEEP
> > buffer pool was not
> > sized correctly. If the pool were too small to hold
> > all pinned objects then
> > I should think the LRU algorithim would come in to
> > play.
> >
> > What you have to look at is the size of all objects
> > pinned against the size
> > of the KEEP buffer pool, by analyzing all pinned
> > objects and adding together
> > their size.
> >
> > HTH
> >
> > Mark
> >
> > -----Original Message-----
> > elkinsl_at_flash.net
> > Sent: Friday, April 27, 2001 01:41
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Listers,
> >
> > I was involved in a meeting today, strictly as a
> > listener (no pun intended).
> > A consultant made the statement that pinned packages
> > are subject to being
> > aged out of the shared pool, using an LRU type of
> > mechanism. My
> > understanding is that if you pin a package, it stays
> > pinned (except maybe if
> > it gets invalidated? - not sure on that).
> >
> > From the Oracle documentation on
> > DBMS_SHARED_POOL.KEEP:
> >
> > This procedure keeps an object in the shared pool.
> > Once an object has been
> > kept in the shared pool, it is not subject to aging
> > out of the pool.
> >
> > The above statement from the doc's seems to
> > contradict what the consultant
> > said.
> >
> > I am asking this because I am *not* a DBA. I've
> > always been a developer,
> > and, was a DBA for a few years a very long time ago.
> > The DBA's I work with
> > are kind enough to involve me in meetings and
> > discussions on DBA topics --
> > they know that I like to at least try to be somewhat
> > in touch with the DBA
> > side of things (even if a little knowledge is more
> > dangerous than none). It
> > allows us to work better together. But, I know to
> > not ask questions in
> > meetings -- those questions can wait for later. I
> > don't need to get a
> > meeting sidetracked. So, I didn't ask about the
> > consultant's statement that
> > pinned packages can get aged out, especially in
> > front of him. And, I never
> > had the chance the ask about this with the DBA's
> > after the meeting.
> >
> > Anyone want to clarify this point? The doc's seem
> > pretty clear, but, I could
> > be missing some of the subtle things that aren't in
> > documents and that only
> > seasoned DBA's know.
> >
> > Regards,
> >
> > Larry G. Elkins
> > elkinsl_at_flash.net

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
   INET: elkinsl_at_flash.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mohammad Rafiq
  INET: rafiq9857_at_hotmail.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).