I highly recommend Tyler Muth's logger.
OraLog FAQ
Frequently Asked Questions for OraLog
FAQ 1.
What is OraLog?.
OraLog is a logging framework for Oracle database developers. The main idea of the project was to create an extensible logging framework, easy to understand and easy to adapt to each project logging needs. Another important requirement which was taken into consideration was the need to change the logging properties on the fly so that the logging destination to be easily re-configured without any code changes.
FAQ 2.
How much does it cost?.
OraLog is free. You can have a look here to see its license.
FAQ 3.
I want to add my own appender. What is the recommended way to add it?
First of all, you have to create a package which MUST have a public procedure with
the following signature:
procedure log(pi_header log_header_typ,
pi_message varchar2,
pi_params varchar2);
The pi_header parameter contains log header information, the pi_message
is the effective log message and the pi_params contains additional info automatically sent
by the OL CORE when the appender is invoked. In the end the appender must be registered into the OraLog platform
and to be configured to subscribe to various "interesting" logs. Additional details may be
found here.
FAQ 4.
I don't like the header of each log entry I receive in "Table Appender" monitor. Are there any ways to change it?
YES. Provide your log template as a valid SQL expression (see the "Template" field form "Table Appender" window).
FAQ 5.
It seems that some logs are not shown into the OraLog Monitor. Why?
You must check if you have configured a corresponding log profile/subscription. The log profile tells what messages to log and to which appender they have to be routed. In addition, double check:
- is the log profile enabled?
- is the "Debug When" condition properly defined?
- are there any errors reported by the target log appender? Check the "Last error" field and the "Log alert".
FAQ 6.
I want to build the DEBUG_WHEN condition based on some log header information. What is the best way to do it?
If the DEBUG_WHEN condition relies to log header information then it is advisable to build the
DEBUG_WHEN condition based on the g_header global variable defined within the OL package. This
variable is initialized with log header information after every log entry is issued and
only after that the DEBUG_WHEN condition is evaluated. So, do not build the DEBUG_WHEN condition
using the SYS_CONTEXT function if the information you need is already in the log header. Use
OL.g_header global variable instead, avoiding by this an additional expensive call to the SYS_CONTEXT function.