Figure 5-18 is in some ways misleading because it implies a one-to-one relationship from the end user to the server process. In addition to accounting for a specific client's activity on a shared server, with application servers, web server, connection pooling of all kinds and at various layers, the task of associating an end user's activity to part of a server processing is nearly impossible. This created not only a performance analyst problem, but at a basic level, also a support issue. Suppose an end user calls her support department with an issue. How does the support department know what the end user is truly doing? Many times this is not possible, so the support technician must make inferences. To truly understand what the user is doing, the user's activity must be isolated in a controlled environment. But what if the problem is the result of noncontrolled environment issues? Now diagnosing user experience issues is no longer just muddy, it's nearly impossible to isolate with satisfactory clarity.

As I mentioned, application software vendors anxious to avoid being blamed for poor performance stepped in to help identify a user's activity. Additionally, other companies introduced tools to help profile a user's activity in this messy environment. From an IT management perspective, it's complicated, many people are involved, and it's expensive. This boils down to increased risk, and that's a word no IT manager wants to hear. I believe this has motivated Oracle to take some leadership and work on providing at least a partial solution. This partial solution is indeed a big step, and it is called DBMS_MONITOR.

Figure 5-18. Many factors-such as cost, maintenance, security, the end users' experience and location, and computing system capacity-helped push Oracle to embrace a web-based architecture. This is a highly simplified drawing highlighting the key Oracle architectural components: browser, Oracle client process, Oracle server process, and the Oracle SGA.