GithubHelp home page GithubHelp logo

oraopensource / logger Goto Github PK

View Code? Open in Web Editor NEW

This project forked from tmuth/logger---a-pl-sql-logging-utility

308.0 76.0 118.0 2.34 MB

Logger is used by Oracle developers to instrument their PL/SQL code

Home Page: http://www.oraopensource.com/logger/

License: MIT License

Shell 4.25% PLSQL 95.75%

logger's Introduction

Donate to Logger

What is Logger?

Logger is a PL/SQL logging and debugging framework. The goal of logger is to be as simple as possible to install and use. The primary use cases for this utility include:

  • Debugging: It's often difficult to track down the source of an error without some form of debugging instrumentation. This is particularly true in multi-tier, stateless architectures such as Application Express.
  • Error Logging: While most experts agree that it's important not to mask errors, it's also nice to have a persistent record of them.
  • Timing: Logger has a very simple timing framework built-in that makes it easy to benchmark sections of code.
  • Instrumentation: Because it's easy to "turn-off" logger globally with virtually no performance impact, it's easy to get in the habit of leaving debug calls in production code. Now, when something does go wrong, you simply flip the switch and logger is enabled making it much quicker to debug errors.

Feedback/Issues

Please submit any feedback, suggestions, or issues on the project's issue page.

Demo

exec logger.log('hello world');

select * from logger_logs;
-- This will display all the logged logs

See the [Logger API](docs/Logger API.md) documentation for complete set of procedures.

Documentation

In order to keep this page relatively small and for ease of use, the documentation has been moved to the Logger Docs. In there you you will find the following sections:

Download

It is recommended that you download a certified release (from the releases folder). The files in the current repository are for the next release and should be considered unstable.

Change Log

The [Change Logs](docs/Change Logs.md) contain all the major updates for each release. Complete set of issues can be found on Milestones page.

History

Logger was originally created by Tyler Muth and is now maintained by OraOpenSource.

License

This project is uses the MIT license.

logger's People

Contributors

alexnuijten avatar frankschmitt avatar gilcrest avatar iancarpenter avatar martindsouza avatar philippsalvisberg avatar shakerlxxv avatar tmuth avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

logger's Issues

Issue setting client level with same session multiple times.

From @martindsouza on August 25, 2013 18:54

The following raises an error:

exec dbms_session.set_identifier('martin_session');

exec logger.set_level('DEBUG', 'martin_session');

PL/SQL procedure successfully completed.

exec logger.set_level('DEBUG', 'martin_session');

*
ERROR at line 1:
ORA-20000: l_include_call_stack must be TRUE or FALSE DEBUG
ORA-06512: at "GIFFY.LOGGER", line 97
ORA-06512: at "GIFFY.LOGGER", line 1345
ORA-06512: at line 1

The issue is in get_pref as it only looks at logger_level for sessions where client_id is defined.

Copied from original issue: tmuth#39

logger_no_op.sql has mismatch of spec and body definitions for some procedures

From @rimblas on September 13, 2013 18:49

In v2.1.2 the spec declaration for log_permanent,log_warning,log_information and log doesn't match the body.

For example in the spec:
procedure log_permanent(
p_text in varchar2,
p_scope in varchar2 default null,
p_extra in clob default null,
p_params in tab_param default logger.gc_empty_tab_param);

The body is missing p_params:
procedure log_permanent(p_text in varchar2,
p_scope in varchar2 default null,
p_extra in clob default null)

Copied from original issue: tmuth#44

select privilege against logger_logs table

From @hkpatv on August 7, 2013 7:20

In the sample code, scope is defined by accessing using logger_logs.scope%TYPE. To be able to access this, then user has to be given SELECT privilege against logger_logs table. If this is the case, then that user can see all logs for other users.
Not sure if there is a way to encapsulate the scope data-type into the logger package, that way user doesn't need to be given access to read log tables unless we decide to grant it. I can't think of a neat way to do this.
It may be a partial solution, although maybe complicated, to perform row-level-security against the logger_logs table, so that non-priviledged users can only see logs that they have created.

Copied from original issue: tmuth#35

Install - "Call Home" Feature

From @martindsouza on July 2, 2013 16:19

Create a Call Home feature which will send a simple request to a server to let the Logger team know how many people are installing Logger. Users should have the ability to disable this option but should be on by default.

When sending the call home request, include a unique number based on the users instance. This way if we implement a "check for updates" feature we can know unique databases that use it.

No tracking information should be stored (i.e. db name etc). Just a random generated tag so we know how many unique databases Logger is installed on.

Copied from original issue: tmuth#23

Allow for large text in the "TEXT" field and auto move it to "EXTRA" if necessary

From @martindsouza on April 18, 2013 5:23

From Juergen:

The other enhancement I made was our developers don't have to know if the message they want to log are > 4K, so logger.error(my_variable); looks if my_variable is > 4K and automatically stores it in the extra column together with a short hint in the text column that the text is too long and can be found in the extra column

Note: We already do something similar for the log_params functionality.

Copied from original issue: tmuth#17

logger.status

From @martindsouza on August 31, 2013 11:34

Received the following error when viewing logger status in SQL*Plus when a client identifier has been set.

SQL> exec logger.status;
BEGIN logger.status; END;

                                         *
ERROR at line 1:
ORA-01830: date format picture ends before converting entire input string
ORA-06512: at "LOGGER", line 1310
ORA-06512: at line 1

Copied from original issue: tmuth#41

Remove levels Timing, Debug, and Context

From @martindsouza on September 29, 2013 0:47

I think these levels are making things a bit more complicated than they need to be. Though I understand why they were initially implemented it's too many options that may restrict people from using them.

The work around is to re-write these procedures so that the level of logging can be applied to them. For example log_apex_items would take in an additional parameter for level. If the current level matches then the apex items would be logged. This is not a final decision as to how it should be implemented, rather a suggestion.

It is important to ensure that backwards compatibility is enabled for this functions so as not to remove existing functionality.

Copied from original issue: tmuth#49

select privilege against logger_logs table

From @hkpatv on August 7, 2013 7:20

In the sample code, scope is defined by accessing using logger_logs.scope%TYPE. To be able to access this, then user has to be given SELECT privilege against logger_logs table. If this is the case, then that user can see all logs for other users.
Not sure if there is a way to encapsulate the scope data-type into the logger package, that way user doesn't need to be given access to read log tables unless we decide to grant it. I can't think of a neat way to do this.
It may be a partial solution, although maybe complicated, to perform row-level-security against the logger_logs table, so that non-priviledged users can only see logs that they have created.

Copied from original issue: tmuth#35

Change default schema

From @tmuth on January 15, 2013 23:13

Default install schema is "logger". I believe there is a name resolution issue when you call logger.logg.log... Will change the default schema to logger_user.

Copied from original issue: tmuth#3

log_error does not lower p_scope

From @markwagoner on April 18, 2013 18:26

The insert statement in the log_error procedure does not perform a lower(p_scope) like log_internal does. This leads to inconsistent values in the scope column.

Copied from original issue: tmuth#19

Log CURRENT_SCHEMA

From @hkpatv on August 6, 2013 8:9

For some scheduled tasks we use external authentication to call the same stored procedure defined on multiple schemas (ie phtutl.purge_pkg.purge, thtutl.purge_pkg.purge).
For current logging version, it is not easy to see which of the stored procedures is being called, because the username field is populated with the external username, OS$ORACLE, only.
I think it may be useful to have an additional field (schema_name?) which is populated with the value of "SYS_CONTEXT ('USERENV', 'CURRENT_SCHEMA')".
Note not a huge deal for us, as we have configured the dbms_application_info action field in our calling process, and also can infer from the UNIT_NAME field.

Copied from original issue: tmuth#34

Reference to BI_LOGGER_LOGS

From @casajarm on August 12, 2013 13:0

In the script LOGGER_INSTALL.SQL the trigger BI_LOGGER_LOGS is dropped but then in the procedure LOGGER_CONFIGURE it is compiled resulting in an error:

Calling logger_configure begin * ERROR at line 1: ORA-04080: trigger 'BI_LOGGER_LOGS' does not exist ORA-06512: at "LOGGER_USER.LOGGER_CONFIGURE", line 108 ORA-06512: at line 2

Copied from original issue: tmuth#36

Open ok_to_log as public

From @martindsouza on July 10, 2013 13:56

There may be times where developers need to log a set of data that may be expensive to obtain (i.e. need to loop through and parse a bunch of text etc). They only want to run that block of code if logging will occur, rather than computing the data then going to log only to find out logging was off.

Suggested fix is create a ok_to_log function where p_level is a varchar2. Internally it will call ok_to_log(p_level number).

In documentation should stress how this is to be used (i.e. should not write a bunch of "if ok_to_log" then blocks. Only for costly areas.

Copied from original issue: tmuth#24

Oracle bug 5733472 “WRONG OUTPUT IN APEX WHEN USING GLOBAL CONTEXT.”

From @tmuth on April 5, 2013 13:34

Mark Wagoner posted this on my blog here: http://tylermuth.wordpress.com/2011/11/09/logger-project-moved-temporarilly/#comment-3565

Not sure if it's really an issue and what versions of logger and APEX are impacted, but it sounds troublesome.

I was also having issues regarding Oracle bug 5733472 “WRONG OUTPUT IN APEX WHEN USING GLOBAL CONTEXT.” I noticed the values were not coming from the context when accessed through APEX, although it worked fine using SQL*Plus or SQL Developer. Have you seen this issue as well? We are on an old version of Apex (4.0) so it could be due to that.
<

Copied from original issue: tmuth#15

Global Constants for Logger Level Names

From @martindsouza on August 31, 2013 11:58

Instead of using 'DEBUG', 'WARNING', etc. use gc variables for them
Note: Can't change code that expects those values since backwards compatibility issues. Need to always support them and this should be documented in the code.

Copied from original issue: tmuth#43

Plugins/Hooks for Logger

From @martindsouza on September 15, 2013 22:26

Allow certain locations in the code to accept dynamic code execution. One clear example of this is for error handling. Whenever a logger.log_error is called some client specific code may need to be executed (ex: email notifying dev team that error has occurred).

Since this is organization specific Logger can't be expected to know each use-case however it should support the ability for organizations to add their own hooks into the code without having to modify the base code.

High level structure would look like this:

  • Table to store plugin locations and dynamic code
  • Types for plugin architecture to use so that data can be passed in easily
  • Modify current logger code to call these if they exist. Performance implications need to be considered (store the object names in sys_contexts?).

Copied from original issue: tmuth#45

Standardize support for Names vs Numbers for Levels

From @martindsouza on September 15, 2013 23:0

Some of the code takes in numbers and other parts take in names for level references. Overload all code like this so one standard is across the board and have a common option for all code on a go forward basis so it's consistent.

Copied from original issue: tmuth#47

Remove Trigger on LOGGER_LOGS

From @martindsouza on August 2, 2013 5:7

Remove the trigger on LOGGER_LOGS for both performance issues and to resolve #17. Still need to create a public API to insert into LOGGER_LOGS in case any external code inserted into it.

Copied from original issue: tmuth#31

Return logger_id

From @martindsouza on March 26, 2013 19:24

For APEX Error handler it would be nice to return the logger_id when logging an error so that we can reference the ID in the error message and search quickly on it.

Copied from original issue: tmuth#14

Substitution Strings

From @martindsouza on August 5, 2013 15:45

Thanks to John Scott for this idea.

Would like the ability to support substitution strings. For example: "Updated %num_rows% in table out of %total_rows%".

John and I discussed possible implementation options. For now here's what is purposed:

  • Add a new parameter call p_do_substitutions default false
  • If user sets p_do_substitutions to true then it will leverage the p_params option for substitution switching rather than logging paramers

Ex:

logger.append_param(l_params, 'p_empno', p_empno);
logger.log('Employee %P_EMPNO%', p_params => l_params, p_do_substitutions => true)

Alternatively, instead of p_do_substitutions we can us p_param_type with 'DEFAULT'/'PARAMS' and 'SUBSTITUTION' (or something like that). We can create global constants to manage. This may be the better option.

Copied from original issue: tmuth#32

Browser to Server logging

From @martindsouza on August 5, 2013 16:11

Thanks to John Scott for this request.

Create an APEX plugin to support client to server logging. Note: we realize that this will not be a performant feature.

Here are some things that would be nice to have in this request:

  • Support console.log (i.e. read into it so developers wouldn't need to change their code)
  • Direct tie into logger settings so that only logs at the Logger levels
  • Store logs in local browser DB first then submit periodically to DB? (on time, #entries, page submit etc)
  • Also look at perhaps leveraging the new APEX5 apex.debug JS namespaces to bundle in with that? Would need to look at creating prototype to add on and also overwrite the existing framework to then write (via a DA or something) to the Db.
  • See https://github.com/hkirat/notification-logger for example of how to overload console

Copied from original issue: tmuth#33

Logger over DBLink

From @martindsouza on May 2, 2013 19:25

Had the following issue:

...
l_x := my_function@dblink;

In my_function over the dblink

begin
logger.log('START');
...

This throws the following error (in v 1.4.0):
ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML
ORA-06512: at "XXRA_LOGGER.LOGGER", line 84
ORA-06512: at "XXRA_LOGGER.LOGGER", line 156
ORA-06512: at "XXRA_LOGGER.LOGGER", line 381

I've isolated it to the fact that it logger will try to set the context (in save_global_context).

Copied from original issue: tmuth#21

APEX Error Handling Procedure

From @martindsouza on September 15, 2013 22:27

Default procedure for the APEX Error Handler code. This may be integrated with #46.

Consider this as a low priority as we may need to start handling various version of APEX etc.

Copied from original issue: tmuth#46

Include Wiki documents in release

From @martindsouza on July 26, 2013 21:22

Since the wiki is in a different repository than the code it doesn't get versioned the same. Make sure the wiki documents are part of the release as the documentation will change for each release.

Copied from original issue: tmuth#28

Error compiling in 10g due to trigger > sequence.nextval

From @martindsouza on July 26, 2013 13:37

Submitted by Patrick Jolliffe: http://www.talkapex.com/2013/06/logger-200-released.html - it does not currently compile on 10g database (cannot use SEQUENCE.NEXTVAL directly in trigger, have to insert into a local variable).

Update: .nextval is only available in PL/SQL starting with 11gR2 onwards: http://docs.oracle.com/cd/B28359_01/server.111/b28279/chapter1.htm#FEATURENO07450

Copied from original issue: tmuth#26

Issue with logger.ok_to_log and result_cache?

From @martindsouza on January 26, 2013 15:39

In logger.ok_to_log in order for result_cache to occur must have $$RAC_LT_11_2 in order for result_cache to be enabled. What about systems that are greater than 10.2 (and support result_cache) but are not cluster databases?

Copied from original issue: tmuth#5

Allow for Other Logger Features to supply level

From @martindsouza on July 27, 2013 1:10

The "[Other Logger Functions]https://github.com/tmuth/Logger---A-PL-SQL-Logging-Utility/wiki/Logger-API#wiki-other-logger-procedures) don't allow for the level to log them at.

This can be an issue in certain situations. For example log_apex_items will only be logged when the current level is set to "APEX" (or 128). Developers may want this functionality when an error occurs in production (which usually runs using the "ERROR" logger level).

Implementation ideas: Not exactly sure how to implement this but odds are a new parameter, p_level (optional) will allow developers to call with a custom level. If defined, it will ignore the default settings and log based on the level.

Deprecate the following levels (everything below DEBUG), and automatically set to DEBUG:

  • TIMING
  • SYS_CONTEXT
  • APEX

Note: these will still exist as objects will be inserted into Logger with that level to show that they're specific to APEX, timing, etc

Allow for setting the level for the following functions:

  • log_apex_items
  • log_userenv
  • log_cgi_env
  • log_character_codes

Note: Timing was not modified since they're multiple functions and need to rethink how to enable/disable for more detailed approach

Currently (3.0.0) these procedures all use DEBUG as the level.

Copied from original issue: tmuth#29

ORA-14000 when using log_apex_items

From @davidkyanek on August 29, 2013 16:4

Hello,

I think that there is a bug in log_internal function, last parameter, when this function call ins_logger_logs function, the po_id, should be assigned to global variable g_log_id, not to the local variable l_id.

With regards.

David

Copied from original issue: tmuth#40

Timing should have it's own column

From @tmuth on January 15, 2013 23:11

Need to add a new column to the logger_logs table to hold timing results. "text" column is not the right place, tough to compute times.

Copied from original issue: tmuth#1

Expand the TEXT column to 32767 characters for 12c instances

From @martindsouza on July 27, 2013 1:59

As a result for issue #17 A current workaround for large text entries in p_text is to move it to the EXTRA column. In 12c this may not be required since it supports varchar2 columns of 32767 characters.

Look at modifying the text column to 32767 for 12c or greater instances. Also need to check that the large text fields don't depend on a parameter configuration in the database. If so, need to verify that parameter.

If this issue goes in, then the check in log_internal doesn't need to happen (but will still need to be supported for older versions.

Need to check for parameter and version number: http://dbasolved.com/2013/06/26/change-varchar2-to-32k-12c-edition/

select *
from v$parameter
where name = 'max_string_size'

As part of Issue #17 already have a new compilation parameter LARGE_TEXT_COLUMN which will remove the need for #17 (and thus a slight performance boost since not checking text size anymore).

Copied from original issue: tmuth#30

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.