Here's a very simple yet crystal-clear example. When a SQL statement reads 1,000 blocks from disk, is it because the SQL statement is not tuned, the buffer cache is too small for the table, or other SQL statements replaced cached blocks with other blocks our SQL is not interested in? The answer is possibly, possibly, and possibly.

To think that a single SQL statement is unaffected by everything else on the system goes against the very essence of why Oracle is an awesome database and why operating systems were invented. Both Oracle and operating systems exist, in part, to share scarce resources. Somehow, the technology is supposed to cause balance and fairness for all the requests for computing resources. But when we look at a profiled session, we start forgetting all of this and begin to think in isolation.

Fortunately, there is a very simple solution. Sure, you should profile the session, as this is valuable and helps identify where the performance issue resides. But also profile the entire Oracle system and include an operating system analysis. Essentially, in addition to profiling the session, perform an OraPub 3-circle analysis and make sure you also perform a system-level ORTA. This will enable you to understand the relationship that exists between the profiled session and the rest of the computing environment. It will also allow you to better understand the impact, both from a session and system-wide perspective, of any changes you may decide to make.