Conceptually, all database activity flows through DBMS_MONITOR, and if any activity meets certain specific criteria, the activity is captured. So instead of focusing on a specific user (which you can do), you focus on defining the criteria of interest. Oracle introduced DBMS_MONITOR in Oracle Database 10g, and unlike other diagnostic features, it does not require an additional license.

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.