P.S. And I have already written my own (to be true, it’s a logging package which can be used for instrumentation).

However, with Hotsos ILO, look at some of the things that now you don’t have to do:

- Keep your own stack of dbms_application_info history so that you can instrument task hierarchies, not just tasks at a single level. (A lot of people who bother to learn about and use dbms_application_info don’t tidy up after themselves; when their instrumented task ends, the relic data of the instrumented task persists in v$session until either the session ends, or some other code replaces the module/action info.)

- Figure out how to separate the act of instrumenting code (done by a developer at compile-time) from the act of activating or deactivating that instrumentation (done by a DBA at run-time).

- Figure out a consistent, application-wide policy for how to use dbms_application_info, dbms_session, dbms_support or dbms_monitor (there’s an Oracle version dependency there that you don’t want developers having to deal with), or dbms_system.ksdddt and -.ksdwrt. For example, should you nest module/action name changes within timestamps, or vice versa? What kind of format should anything you write to the trace data be in.

- Have your developers learn about dbms_support/monitor, dbms_application_info, dbms_session, etc. in the first place.

- Come up with your own security scheme to protect from public abuse of potentially dangerous packages like dbms_system.

- Worry about performance-tuning your instrumentation.

We made Hotsos ILO free and open-source, so whether you use it or not, you can see for yourself exactly what’s in there. Our hope is that you’ll find it well-written enough that you won’t bother to write your own.

Testing

Testing

abc test