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@xxxxxxxxx> 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.