Figure 5-20. This actual working logon trigger can be used as a template to set a session's client identifier based on an amazing array of possibilities.

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!