Re: Best Practice: pinning objects

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 <ajay_1ajay_at_yahoo.com> 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 <sacrophyte_at_gmail.com>* 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. <http://us.rd.yahoo.com/evt=49936/*http://videogames.yahoo.com>
>
>

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l