So while DBMS_MONITOR still attaches to a server process, it will only collect performance data based on the defined criteria. If you can make the mental shift from end user to end user classification, combined with a little creativity in identification criteria, then DBMS_MONITOR will serve you well! The next section focuses on strategies to identify a session or a group of sessions.

This is probably the most unique aspect of using DBMS_MONITOR. Because you have many session identification options, you're likely to find a way to identify session(s) of interest. Sessions can be identified by their Oracle instance, session identifier (v$session.sid), client identifier (v$session.client_identifier), service name (v$session.service_name), module (v$session.module), program (v$session.program), and various combinations.

Once the session is attached, data collection starts and will continue until the session qualifications are no longer met. For example, if the DBMS_MONITOR were set to trace all sessions with a program name of arpost, once a session's program name became arpost, a trace file associated with the running server process would be created and tracing details written. But once the session either disconnected or the program name changed, the tracing would stop. Then if the session's program were reset to arpost, the tracing information would once again start flowing. The power lies in the fact that it makes no difference which server process or client process the session is associated with at the time. If two different server processes are involved with a single or even multiple sessions with their program set to arpost, then two trace files will be created. This allows for connection pooling, Oracle's multithreaded shared server capability, and various other architectures to benefit.