Re: instrumentation

prunoki wrote:

> So far so good, this can be fairly generally written and added to the
> existing code base. I am also thinking about a second option to log the
> parameters and the returned values too. I would like to implement this
> with the minimum difficulty, particularly I do not wish to "hand-code"
> a logging call for every existing procedure and function. Any ideas?

I have my own custom rolled log API. It uses autonomous transactions to log against a log table. It runs within a superuser schema (using authid definer). Thus it can access system level tables and views.

It provides a very basic interface to log error, critical errors, warnings, info messages, debug messages and so on - and has an adjustable log level.

All messages written to the applog table has the PL/SQL stack included (nested table column). This makes it very useful in tracing errors as you have the PL/SQL call stack and source code line numbers at the time of the error.

With critical or normal errors, the code can also access v$session and other tables to dump open cursors, session stats and so on - or even write critical errors to the alert log. It provides a lot of flexibility when troubleshooting runtime errors as a single core piece of code is called when a runtime error occurs. I.e. I always, but always, use it log exceptions, even if it is only something like:

exception when OTHERS then
  log critical error (which means I have the PL/SQL stack and whatever else recorded)
  raise;
end;

I had a look at Log4PLSQL before I did my own thing, but found it too complex and heavy for my needs.

As for recording actual parameter values.. that is too much of an intereference and overhead to consider IMO. Keep it simple. Simple stuff that provides results gets used without having to resort to lead piping.

--
Billy