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.

But all is not lost. Based on specified criteria, DBMS_MONITOR is able to gather performance information for groups or classes of activity. For example, when speaking with a user on the phone, suppose he says that querying basic customer information is painfully slow. Perhaps, for any number of reasons, you cannot easily identify his client or server process. However, when you look at v$session, you discover the application developers instrumented the application using DBMS_APPLICATION, setting both the module and action. You also discover that the application module apcustquery is being run when a customer's basic information is being queried. Here's the key: If the problem is related to what the user (or another user doing a similar task) is doing, not about the specific end user, then DBMS_MONITOR can capture both SQL and performance statistics when a customer's basic information is queried. Said another way, if it's beneficial to capture apcustquery performance information regardless of which users run the module, DBMS_MONITOR can help. But as you'll see, DBMS_MONITOR may be able to identify just the end user's activity. Classifying the activity of interest can be done in a surprisingly large number of ways-not just by an application's module and action.