This package combines many of the ways we have traditionally traced Oracle processes, but extends it to meet modern architecture challenges. DBMS_MONITOR allows for the creation of trace files, including bind variables, SQL, and wait event details. Additionally, it collects v$sesstat and v$sess_time_model-based statistics. DBMS_MONITOR is a very flexible and nicely designed package that eventually every DBA will use.

Overhead on the database server is always a concern during data collection. Vendors go to great lengths to reduce both the real and perceived impact of their data collection. Based on my experience, DBMS_MONITOR tracing places no more load on the database server than traditional tracing, and I have been unable to detect a noticeable load increase when gathering statistics. I suspect the no-load statistics collection is because Oracle's kernel code instrumentation and statistical sampling (see the "Active Session History" section a little later in this chapter) is already in place and working, regardless of statistics being recorded. So any additional load would simply be the statistics being updated in memory and their associated x$ tables.

When working on a very specific and well-defined performance problem, our training and our success have taught us to focus on a specific Oracle session. In fact, if you understand what led up to DBMS_MONITOR, you can see that the focus has always been on attaching to a specific end user's server process. With a complex architecture, even when using DBMS_MONITOR, this may still not be possible.