LEHS - Log- and Exception-Handling System for ORACLE®

Who am I?

Who will be able to configure LEHS? During Installation there has been created a Role named LEHS_ADMIN. Every User who has been granted this Role is able to configure LEHS by the Package PKG_LEHS_SYSTEM (which in fact is a public Synonym to the Package PKG_LEHS_SYSTEM).

Concepts

Tasks done by the LEHS Admins
  • Create a new Log-Application /
    Manage existing Log-Applications
  • Register Log-Appenders and set the appropriate Parameters
  • Define Log-Levels and the programable Log-Levels
  • Set the Privileges to the Log-Applications
Tasks done by the Developers
  • Log Messages by the Application
  • Log Exceptions by the Application
  • Define Exception Messages
  • Define Topics
  • Create Log-Transactions and Search-Keywords to these Log-Transactions

Log Application

As you can see on the Image above the main Artefact is the Log Application. So the first step is to define a new Log Application.

This can be done by calling

	PKG_LOG_SYSTEM.add_application ('<Log Application>', TRUE)

There is an optional Attribute a Log-Application will get:

Look at the Section of Log Levels to get a nearer Description about Log-Levels.

This Attribute (Exception Log-Level) can be changed by calling

	PKG_LOG_SYSTEM.change_application ('<Log Application>', TRUE, '<Exception Log-Level>')

Log Appender

Where should all these Logs produced by the Developers be displayed or stored? This in fact is the task of the Log Appenders. For the Definition of an Appender Package and the usage look at LEHS Appender Packages

LEHS provides you 5 predefined Appender Packages you can use with your Log-Application:
Appender Package Description
PKG_LEHS_ALERT_LOG_APPENDER Writes the Log-Message to the Alert-Log of the Database
PKG_LEHS_APP_INFO_APPENDER Writes Parts of a Log-Message to the View V$SESSION by the Package DBMS_APPLICATION
PKG_LEHS_DBMS_OUTPUT_APPENDER Writes the Log-Message to the Console by the Package DBMS_OUTPUT. Be aware of setting the Log-Buffer of this Package just before you start your Application (on SQL*Plus by calling SET SERVEROUTPUT ON SIZE UNLIMITED).
PKG_LEHS_TABLE_APPENDER Writes the Log-Message to the Table LEHS_LOG_TABLE_BASIC which a User can query by the View LEHS_LOGS (in accordance to its Privileges of the Log-Application)
PKG_LEHS_TRACE_FILE_APPENDER Writes the Log-Message to the Trace-File of the actual Session
In fact, these 5 Log Appenders relate to old Log Destinations of LEHS Version 1.3. With the new Open Appender Architecture (look at LEHS Appender Packages) you are able to write your own Appender Package and registers it as an Appender to your Log-Application.

Please refer to the Configuration Phase of the Log-Appenders to see, how to register and configure Appenders.

Appender Parameters

Here's a List of Parameters you can define for the 5 predefined Appender Packages (provided by LEHS):
Package Name Parameter Datatype possible Values Description
PKG_LEHS_ALERT_LOG_APPENDER LOG_FORMAT CLOB Default (when NULL): %d [%a:%T:%p] %M[TX=%t]: %m Format String (look at Log Format)
PKG_LEHS_APP_INFO_APPENDER MIN_LOG_LEVEL CLOB all available Log-Levels of the Log-Application
Default: same as the maximum Log-Level of the Appender
the minimum Log-Level of the Log-Message. If a Log-Message has a Log-Level below this minimum Log-Level the Log-Message will not be logged by this Appender
ACTION CLOB
APPLICATION The Name of the Log-Application
TOPIC the Topic of the Log-Message
TRANSACTION the Log-Transaction of the Log-Message
CALLER the Caller of the Log-Message (Format: Owner.Method[Line#])
MESSAGE the Log-Message itself
prints the given Part of the Log-Message (see possible Values) to the Field V$SESSION.action (truncated to 32 Characters)
MODULE CLOB
APPLICATION The Name of the Log-Application
TOPIC the Topic of the Log-Message
TRANSACTION the Log-Transaction of the Log-Message
CALLER the Caller of the Log-Message (Format: Owner.Method[Line#])
MESSAGE the Log-Message itself
prints the given Part of the Log-Message (see possible Values) to the Field V$SESSION.module (truncated to 48 Characters)
CLIENT_INFO CLOB
APPLICATION The Name of the Log-Application
TOPIC the Topic of the Log-Message
TRANSACTION the Log-Transaction of the Log-Message
CALLER the Caller of the Log-Message (Format: Owner.Method[Line#])
MESSAGE the Log-Message itself
prints the given Part of the Log-Message (see possible Values) to the Field V$SESSION.client_info (truncated to 64 Characters)
PKG_LEHS_DBMS_OUTPUT_APPENDER LOG_FORMAT CLOB Default (when NULL): %d [%a:%T:%p] %M[TX=%t]: %m Format String (look at Log Format)
PKG_LEHS_TABLE_APPENDER RETENTION_TIME NUMBER 0 - 99999
0 = infinite Retention Time (Default)
Retention Time (in Minutes) for the Log-Entries
REMOVE_UNUSED_TRANSACTIONS CLOB
TRUE Remove unused Transactions
FALSE Don't remove unused Transactions (Default)
Should unused Transactions be removed (regardless of the Retention Time) (Default: FALSE).
REMOVE_LOGS_IN_OPEN_TRX CLOB
TRUE Remove Logs whose Transaction is already opened
FALSE Don't remove Logs whose Transaction is open (Default)
Should Log-Entries with open Transactions be removed by the Cleanup-Procedure (Default: FALSE)
PKG_LEHS_TRACE_FILE_APPENDER LOG_FORMAT CLOB Default (when NULL): %d [%a:%T:%p] %M[TX=%t]: %m Format String (look at Log Format)

Log Format

By defining a Log-Format you can define, how Log-Messages would be written by the Log-Destinations DBMS_OUTPUT, ALERT_LOG and TRACE_FILE. The Format follows the Rules defined by LOG4J:

Log Levels

Log-Levels are important for the severity of a Log-Message. A Error-Message is always more important than just a Info-Message. You can define the Severity of the Log-Levels for every Log-Application. The're existing 2 general Recommendations for the Usage of Log-Levels:
  1. 6 alphanmeric Log-Levels (Recommendation by LOG4J)
    These 6 Log-Levels are (in Severity Order)
    1. FATAL
      All Errors, which causes the Application to be broken immediatly will use this Log-Level to be logged (if possible) (for Instance a faulted Memory Structure)
    2. ERROR
      All Errors, which causes the Application to be stopped will use this Log-Level (for Instance a missing mandatory Parameter)
    3. WARN
      All Errors, which causes the Application not to be stoppend immediatly will use this Log-Level (for Instance a Web-Service, which can't be obtained)
    4. INFO
      An Information by the Application (for Instance a basic Calculation Step)
    5. DEBUG
      An Information for the Developer for debugging the Application (for Instance the Value of a Variable)
    6. TRACE
      A Trace Information for the Developer for debugging the Application (for Instance the Position within a Calculation)
  2. 100 numeric Log-Levels (Recommendation by Apache)
    The Log-Levels are numeric from 0 to 99 which describes the Severity (0 ... fatal Exception; 99 ... only a trace message)
You can choose any Recommendation you like for your Log-Application. But you always have to set the Severity by yourself.
You can define a new Log-Level by
  1. positional Reference
    	PKG_LEHS_SYSTEM.add_log_level ('<Log Application>', '<Log Level>', <Position>)
  2. predecessing Reference
    	PKG_LEHS_SYSTEM.add_log_level ('<Log Application>', '<Log Level>' '<predecessing Log Level>')
    	(the first Log-Level of a Hierarchy will be addressed by a NULL-Predecessor)
In any Way you define a Log-Level Hierarchy (in fact it's only a linked List). Look the Image below

This Hierarchy takes effect when you define the maximum Log-Level of a Log-Appender. When you define a maximum Log-Level of ERROR, only Messages with the Log-Level FATAL and ERROR will be logged by this Log-Appender. All other Messages with a Log-Level higher than ERROR will be rejected.

On the other Hand, if you define a maximum Log-Level of DEBUG all Log Messages with the Log-Level FATAL, ERROR, WARN, INFO and DEBUG will be logged. The Messages with the Log-Level TRACE will be rejected.

Programmable Log Levels

As you can see above at the Log Levels there exists a simple to use Recommendation by 6 alphanumeric Log-Levels. This Recommendation has been implemented by LEHS to simplify the usage of the Log-Procedures. These 6 alphanumeric Log-Levels will be called "programmable Log-Levels". You can set any of these programmable Log-Levels to an existing Log-Level. See Image below:

For any of these 6 Log-Levels there exists a programmatic Interface which can be used by the Developers:
programmable
Log-Level
Interface Setter Unsetter
FATAL PKG_LEHS.fatal PKG_LEHS_SYSTEM.set_log_level_fatal PKG_LEHS_SYSTEM.unset_log_level_fatal
ERROR PKG_LEHS.error PKG_LEHS_SYSTEM.set_log_level_error PKG_LEHS_SYSTEM.unset_log_level_error
WARN PKG_LEHS.warn PKG_LEHS_SYSTEM.set_log_level_warn PKG_LEHS_SYSTEM.unset_log_level_warn
INFO PKG_LEHS.info PKG_LEHS_SYSTEM.set_log_level_info PKG_LEHS_SYSTEM.unset_log_level_info
DEBUG PKG_LEHS.debug PKG_LEHS_SYSTEM.set_log_level_debug PKG_LEHS_SYSTEM.unset_log_level_debug
TRACE PKG_LEHS.trace PKG_LEHS_SYSTEM.set_log_level_trace PKG_LEHS_SYSTEM.unset_log_level_trace
This Method is much simplier to use than the general Implementation PKG_LEHS.log, where you have to set the Log-Level manually. Another advantage is the flexibilty. A Log-Administrator can reset the assigned Log-Level fluently.

Log Privileges

Following the Principle of the least Privilege a newly created Log-Application isn't available for any Database User. This is a big difference to the Releases 1.2 and 1.3 of LEHS where a newly created Log-Application was available to all Database Users. So since Release 2.0 a Log-Application needs to be granted to Grantees. A Log-Application can be granted to any of these Grantees: User, Role or PUBLIC.

There exists at least 2 Security Privileges:

The read/write Permission rules over the read only Permission. Following Example
CREATE USER a_user IDENTIFIED BY a_user;
CREATE ROLE a_role;
GRANT a_role TO a_user;

exec LEHS.PKG_LEHS_SYSTEM.grant_privs ('LOG_APPLICATION', 'A_USER', TRUE);
exec LEHS.PKG_LEHS_SYSTEM.grant_privs ('LOG_APPLICATION', 'A_ROLE', FALSE);
exec LEHS.PKG_LEHS_SYSTEM.grant_privs ('LOG_APPLICATION', 'PUBLIC', TRUE);
Because the Role A_ROLE has been granted the read/write Permissions the User A_USER is able to write Log-Messages regardless of the User Permissions (which will be read only).

A Privilege can be granted by calling:

	PKG_LEHS_SYSTEM.grant_privs ('<Log Application>', '<User/Role>', <read/write (FALSE) or read-only (TRUE)>);

A granted Privilege can be revoked by calling:

	PKG_LEHS_SYSTEM.revoke_privs ('<Log Application>', '<User/Role>');

Get the Metadata Information

If you want to create a Log-Application you have plenty of work to do: Also the Developers can change the Meta-Information on the Log-Application: All these Informations are important for the Log-Application. If you want to copy these Informations of a Log-Application to another System running LEHS you can get all these Meta-Information by calling:
	SELECT * FROM TABLE(PKG_LEHS_SYSTEM.get_metadata('<Log Application>'[,'<include Log Topics (Y/N)>'[,'<include Exception Messages (Y/N)>']]));
which gives you the Registration of such Log-Application in the correct order to create this Log-Application on another Database running LEHS.