Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Best Practice: pinning objects

Re: Best Practice: pinning objects

From: Charles Schultz <>
Date: Mon, 5 Mar 2007 10:24:54 -0600
Message-ID: <>

  1. It is not so much an argument against pinning (afterall, we have objects that we require to be pinned), but rather an argument of method.
  2. A trigger must fire something, whether it be the pl/sql embedded within the body of the trigger, or a call to a store procedure. Given that we occasionally, change the list of objects to be pinned, that list (wherever it is sourced) must be managed. That is the meat of what I meant by "managing the trigger".
  3. Yes, we are thinking of putting the list of objects in a different table, but it is much easier to keep the list maintained externally (ie, a flat file). We are discussing the pros and cons in our group.

However, the main question remains; what are the Best Practices for pinning objects? Specifically, is there a good reason to avoid doing pinning objects directly after system startup?

On 3/5/07, Ajay <> wrote:
> What are the valid points against pinning?
> What do you mean by managing the trigger?
> You can put the objects to pin in a database table and join it with
> dba_objects and pin the appropriate ones. You only change the table to
> add/remove objects and leave the trigger code alone. Thanks
> *Charles Schultz <>* wrote:
> Good day, list,
> My colleagues and I were debating the merits of having a startup trigger
> pin objects. I am in favor of this method, but the others bring some valid
> points to the table. It basically comes down to managing the trigger and the
> objects that are pinned. We experimented with a shutdown trigger in the
> past, which was responsible for gathering stats and collecting info about
> "current' objects, but that broke rather quickly. So we are thinking of
> providing a list of objects from an external source (ie, flat file), which
> would be consistent and extremely visible. The alternative to using a
> trigger would be a cron job that checks every-so-often.
> I tried to find supporting documentation online, but I did not get any
> useful hits for "best practice[s]" and "pin object[s]". Anyone want to weigh
> in on either side? One way or another, we want various application objects
> to be pinned right after the database is started, with minimal amount of
> hassle and overhead. From my point of view, the whole purpose of a startup
> trigger is to run something when the database starts. Yes, one could use a
> glorified startup script, but we want to steer away from such conventions.
> One key question is "Is there ever a time when you do not want to
> automatically pin objects?"
> I have also been looking for information about whether or not a startup
> trigger would fire for "STARTUP UPGRADE" when patching.
> PS - I have an example I am using from M.Gralike, 2003-10-10
> --
> Charles Schultz
> ------------------------------
> Be a PS3 game guru.
> Get your game face on with the latest PS3 news and previews at Yahoo!
> Games. <*>

Charles Schultz

Received on Mon Mar 05 2007 - 10:24:54 CST

Original text of this message