Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







SQL tuning and execution statistics 

Oracle Database Tips by Donald BurlesonJuly 19, 2015

One common mistake by SQL tuning people is forgetting the empirically test the speed of their query. 


When tuning SQL, many Oracle professionals only focus on the execution plans and the associated "cost" figures.  We have already discussed why the "cost" figures in a SQL execution plan do not always reflect the fastest execution plan, and that's another reason why it's critical to always "set timing on" and time your query's actual execution speed and the number of logical I/O's (consistent gets).


Many people analyze their execution plans, and choose the one that they believe has the best execution plan, without actually timing the SQL for execution speed.


If you do not check the time and the plan, you may end using expensive new features.


Consider this simple SQL by Oracle ACE Laurent Schneider (author of the bestselling Advanced Oracle SQL Programming book).  The goal is to find out the best paid employees in each department:


create table
   select * from emp;

create index lsc_i on lsc_emp(deptno,sal);


exec dbms_stats.gather_table_stats(user,'LSC_EMP',cascade=>true)


Before Oracle introduced analytic functions, one way to find the highest paid employees in a department is to use an exists subquery.  The subquery would compute the max salary and serve as the value against which the outer query measured salaries:


   lsc_emp e1
   exists (
         lsc_emp e2
      having e1.sal=max(e2.sal)


Notice here that the subquery causes us to invoke multiple index range scans inside of the full table scan of our emp table:


Execution Plan


Plan hash value: 2224773357



| Id  | Operation           | Name    | Rows  | Bytes | Cost (%CPU)| Time     |


|   0 | SELECT STATEMENT    |         |     1 |    68 |    56   (0)| 00:00:01 |

|*  1 |  FILTER             |         |       |       |            |          |

|   2 |   TABLE ACCESS FULL | LSC_EMP |   107 |  7276 |     2   (0)| 00:00:01 |

|*  3 |   FILTER            |         |       |       |            |          |

|   4 |    SORT AGGREGATE   |         |     1 |     7 |            |          |

|*  5 |     INDEX RANGE SCAN| LSC_I   |    10 |    70 |     1   (0)| 00:00:01 |



Predicate Information (identified by operation id):



   1 - filter( EXISTS (SELECT MAX("E2"."SALARY") FROM "LSC_EMP" "E2"

              WHERE "E2"."DEPARTMENT_ID"=:B1 HAVING MAX("E2"."SALARY")=:B2))

   3 - filter(MAX("E2"."SALARY")=:B1)

   5 - access("E2"."DEPARTMENT_ID"=:B1)





Finally, note that this query required 79 consistent gets:





          1  recursive calls

          0  db block gets

         79  consistent gets

          0  physical reads

          0  redo size

       1991  bytes sent via SQL*Net to client

        520  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

         11  rows processed


Next, let's run the same for of the query using the Oracle analytic functions.  In this example, we replace the exists subquery with an in-line view (a select inside the from clause), and we use the rank analytic function to determine the highest salaried employees:


      (partition by deptno order by sal desc) r
      lsc_emp e)
   deptno is NOT NULL;


Note:  While this query runs much faster than the original exists clause, it is much harder to understand, and consequently, much harder to maintain!


Let's take a closer look and see why this form of the query runs faster.  Here we see a very different execution plan with the "window sort pushed rank" execution plan operation.


Execution Plan


Plan hash value: 151729177



| Id  | Operation                | Name    | Rows  | Bytes | Cost (%CPU)| Time     |


|   0 | SELECT STATEMENT         |         |   107 | 15622 |     3  (34)| 00:00:01 |

|*  1 |  VIEW                    |         |   107 | 15622 |     3  (34)| 00:00:01 |

|*  2 |   WINDOW SORT PUSHED RANK|         |   107 |  7276 |     3  (34)| 00:00:01 |

|   3 |    TABLE ACCESS FULL     | LSC_EMP |   107 |  7276 |     2   (0)| 00:00:01 |



Predicate Information (identified by operation id):



   1 - filter("R"=1)


              INTERNAL_FUNCTION("SALARY") DESC )<=1)






But more importantly, note that the Statistics show only 4 consistent gets, as opposed to 78 consistent gets in the original query.  While a reduction in consistent gets does not always correlate to faster execution time, it's fair to say that this form of the query does 19 times less I/O to retrieve the desired rows!






          1  recursive calls

          0  db block gets

          4  consistent gets

          0  physical reads

          0  redo size

       2151  bytes sent via SQL*Net to client

        520  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          1  sorts (memory)

          0  sorts (disk)

         12  rows processed



Now, you may believe the analytic query runs faster because it scans the table only once, but even though it does less I/O, the analytics operation is quite expensive.  Remember, the best way to judge the speed of a query is to measure it, using the SQL*Plus set timing on command.


Again, always remember that your execution plans costs and consistent gets may not always tell you the fastest execution speed, and what appears to be the fastest execution plan may run slower than other alternative forms of the same query.




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.