There is a lot to glean from Figure 5-20. First, remember that if the application uses a TP monitor or Oracle connections are persistent, then this approach is not likely to work. The first time the persistent connection is made, its client identifier will be set and cannot be reset by a logon trigger. Perhaps somewhere else in the application, or through your methods, the client identifier will be reset, but obviously the logon trigger is fired only once for each session.

Pay close attention to the use of the sys_context function. This function can produce a wide variety of user-identifying information, such as the host from where the client process connected, instance name, language and territory, module, network protocol, operating system username of the client initiating the connection, service name, session identifier, and terminal. With this many options, it is highly likely you can identify the user or at least a group of users, and then set their server process's client identifier, enabling DBMS_MONITOR to gather the requested performance data!

Based on how server process activity is identified, the best DBMS_MONITOR procedure will become apparent. Tracing and statistics collection are independently switched on and off by their own procedures; that is, if you want to trace and collect instance statistics, two procedures will be called to turn on the collection, and then two different procedures must be called to turn off the collection. A simple describe of DBMS_MONITOR will produce a couple pages of options. If you want to gather all actions for a specific module, you can use the dbms_monitor.all_actions procedure as an argument. Table 5-1 is sorted by turning collection on or off, and then tracing or statistics collection.