Another option would be to disable the trigger (ALTER TRIGGER trigger_name DISABLE;) instead of dropping it. This way it is available if you need it in the future. Depending on your organization's production policies, it may be easier to enable/disable an existing trigger instead of creating/dropping it.
Also remember that a login trigger is a stored program unit, so any privileges need to be granted directly to the user. For example, I use tracing login triggers and I make certain that ALTER SESSION or EXECUTE on dbms_monitor are granted directly to the user logging in.
-- Daniel Fink OptimalDBA.com - Oracle Performance, Diagnosis, Data Recovery and Training OptimalDBA http://www.optimaldba.com Oracle Blog http://optimaldba.blogspot.com Lost Data? http://www.ora600.be/ Jared Still wrote:
On Wed, Mar 18, 2009 at 2:39 AM, Yechiel Adar <adar666@xxxxxxxxxxxx
<mailto:adar666@xxxxxxxxxxxx>> wrote:
To tell the truth, I did not think of login trigger
and now I realized that I could create 2 jobs, one to activate and
one to stop the trace.
That is why I am on the list, to learn and get help from all you
good people.
If you use logon triggers, be sure to drop them when you are done.
Easy to forget, and can cause all kinds of problems later.
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
