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:
- Exception Log-Level
All Exceptions, which will be handled by LEHS by calling PKG_LEHS.log_exception
(without giving a Log-Level)
will be logged with this Log-Level.
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>')
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 )
|
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:
%a
Name of the Log-Application
%d[opt. Format]
Log-Time with an optional Format. If the Format is omitted the Default-Format FMDD.MMFM.RRRR FMHH24FM:MI:SS:FF6
will be taken.
%M
producing Method
%p
used Log-Level
%T
Log-Topic
%t
Log-Transaction
%m
Log-Message
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:
- 6 alphanmeric Log-Levels (Recommendation by LOG4J)
These 6 Log-Levels are (in Severity Order)
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)
ERROR
All Errors, which causes the Application to be stopped will use this Log-Level
(for Instance a missing mandatory Parameter)
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)
INFO
An Information by the Application (for Instance a basic Calculation Step)
DEBUG
An Information for the Developer for debugging the Application (for Instance the Value of a Variable)
TRACE
A Trace Information for the Developer for debugging the Application (for Instance the Position within a Calculation)
- 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
- positional Reference
PKG_LEHS_SYSTEM.add_log_level ('<Log Application>', '<Log Level>', <Position>)
- 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.
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:
- read/write Permissions
The privileged User/Role is able to create Log Messages and to read the created Log Messages and Log Transactions at the Log-Table
(by the Views LEHS_LOGS
and LEHS_TRANSACTIONS
)
- read only Permissions
The privileged User/Role is only able to read the created Log Messages and Log Transactions at the Log-Table#
(by the Views LEHS_LOGS
and LEHS_TRANSACTIONS
)
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:
- Create the Log-Application
- Define the Log-Levels
- Set the programmable Log-Levels
- Set the Log-Appenders with all its Parameters
- Set the Privileges
Also the Developers can change the Meta-Information on the Log-Application:
- Add new or modify existing Exception Messages
- Add new or modify existing Log Topics
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.