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.

The trap begins when we hold the report in our hands and we think we hold both the cause and effect before us. We start believing that the SQL was run in isolation and is unaffected by anything and everything else occurring on the system. For this to be true, the database server would need to be completely dedicated to that specific SQL. All other database server activity and operating system activity would need to halt while your SQL ran.