Unfortunately, when many DBAs hear profiling, they think of tracing an Oracle session and categorizing the time. However, based on the industry-accepted definition of profiling, analyses based on an Oracle trace, an operating system trace, Oracle's performance views, and sampling directly from the SGA are all profiling. So there are many ways to profile an Oracle system, an individual session, or a group of Oracle sessions.

ORTA, which is also profiling, was initially injected into the Oracle community back in 2001 when I published a paper on the subject and started presenting it at Oracle conferences and internally within Oracle. I can still remember my presentation on the subject at a Computer Measurement Group (CMG) conference. It created quite a stir because most of the attendees had no idea we could gather and classify Oracle time. All this to say, profiling is indeed useful and practical, but let's keep the definition as it is defined by the larger IT community and get on with it.

The session profiling or session-level response time analysis7 trap is insidious. It works likes this. First we profile a session and a report is produced. The report classifies time wonderfully by providing a breakdown of response time and various levels of classification. We may also see the SQL executed during the profile. Then we make the fatal assumption that the response time and its components are based entirely on the SQL executed during the profile. Doesn't that sound correct? But it is not correct.