SERVERERROR trigger

Question

One of the things I have come up against a lot in triggers is resetting state if an error occurs. For example, to get around the mutating table issue, I find quite often I do stuff like this :
[Before {event} statement trigger]
Initialisation
[Before {event} for each row trigger]
Add current row ID to PL/SQL table
[After {event} statement trigger]
Iterate over array and process (free from mutating table restrictions)
We have an instance SERVERERROR trigger that logs database errors and contextual information in a table. This works really well and is very useful for diagnosing problems - particularly because we have multiple applications sharing the same DB instance and it allows us to centralise the error handling (at least as far as this goes).
It occurred to me that it would be nice to allow a trigger to register an on-error cleanup handler. This would simplify the trigger error handling logic considerably because you wouldn't need multiple EXCEPTION handlers. One of the problems with defining EXCEPTION handlers at a high level is that you lose the context of the error (i.e. where the error actually occurred). So, I was hoping to do something like this :
[Before {event} statement trigger]
Register cleanup function
Initialisation
[Before {event} for each row trigger]
Add current row ID to PL/SQL table
[After {event} statement trigger]
Iterate over array and process (free from mutating table restrictions)
Deregister cleanup function
and then in the SERVERERROR trigger ...
if cleanup function registered
execute cleanup function (using execute immediate)
end if;
The problem is that the SERVERERROR trigger seems to execute using DEFINER rights, so it doesn't see the cleanup function, which exists in the callers schema. Is there any way to have a SERVERERROR trigger execute with AUTHID CURRENT_USER, or alternatively another way to achieve my goal?
Thanks for any suggestions.

Answer 1

You can try oracle's builtin auditing feature to take care of this particular requirement. It's a simple three step process.
1- Set audit_trail = true in parameter file
2- Run this command while connected to a privileged user
    audit session whenever not successful;
3- Query data dictionary view to see failed logins
SQL> SELECT os_username,
  2     username,
  3     terminal,
  4     returncode
  5  FROM dba_audit_trail
  6  /
OS_USERNAME                    USERNAME        TERMINAL        RETURNCODE
DATABASE_IT\Administrator      ANWAR           DATABASE_IT           1017-------
Anwar