SQL Tuning Workshop

Last week I had the pleasure of delivering a five-part SQL Tuning Workshop for my local Oracle User Group –  Northern California Oracle User Group. The workshop explains the fundamentals of the cost-based optimizer, the statistics that feed it, the hints that influence it and key tools you need to exam executions plans.

The workshop also provides a methodology for diagnosing and resolving the most common SQL execution performance problems. Given the volume of interest in this content, I want to share all of the material from the workshop here and give you links to additional material on each of the 5 topics.

Part 1 Understanding the Optimizer
The first part of the workshop covers the history of the Oracle Optimizer and explains the first thing the Optimizer does when it begins to optimize a query – query transformation.

Query transformations or the rewriting of the SQL statement into a semantically equivalent statement allows the Optimizer to consider alternative methods of processing or executing that query, which are often more efficient than the original SQL statement would allow. the majority of Oracle’s query transactions are now cost based, which means the Optimizer will cost the plan with and with the query transformation and pick the plan with the lowest cost. With the help of the Optimizer development team, I’ve already blogged about a number of these transformations including:

 

Part 2 Best Practices for Managing Optimizer Statistics
Part 2 of the workshop focuses on Optimizer Statistics and the best practices for managing them, including when and how to gather statistics, including fixed object statistics.

It also covers what additional information you may need to give the Optimizer such as histograms, extended statistics, as well as all of the techniques you can use to speed up statistics gathering including taking advantage of Incremental statistics, parallelism and concurrency. Finally we look at some guidance on when not to gather statistics. A lot of the topics covered in this presentation are discussed in details in the following two white papers:

 

Part 3 Explain the Explain Plan
Part 3 of the workshop examines the different aspects of an execution plan, from cardinality estimates to parallel execution and explains what information you should be gleaming from the plan and how it affects the execution. It offers insight into what caused the Optimizer to make the decision it did as well as a set of corrective measures that can be used to improve each aspect of the plan.

More information on displaying and reading execution plans can be found in my previous blog posts on DBMS_XPLAN.DISPLAY_CURSOR and using SQL Monitor. Or in the white paper Explain the Explain Plan.

 

Part 4 Influencing Execution Plans with Optimizer Hints
Part 4 is called “Harnessing the power of optimizer hints”. Although I am not a strong supporter of adding hints to SQL statements for a whole host of reasons, from time to time, it may become necessary to influence the plan the Optimizer chooses. The most powerful way to alter the plan chosen is via Optimizer hints. But knowing when and how to use Optimizer hints correctly is somewhat of a dark art. This session explains how Optimizer hints are interpreted, when and where they should be used, and why they sometimes appear to be ignored.

Part 5 SQL Tuning Tips and Tricks
The final part of the SQL Tuning workshop focuses on applying the techniques discussed in the previous sections to help diagnose and correct a number of problematic SQL statements and shows how you can use SQL Plan Management  or a SQL Patch to influence an execution plan.

Hope you find the materials useful!

3 thoughts on “SQL Tuning Workshop”

  1. Maria : Thanks for the great post on sql tuning . Is there a known limitation with pulling a runtime execution plan using dbms_xplan.display_cursor when one tables in the SQL goes to a read only standby database via a db_link ?
    I get an error that sql not found in cursor , Try v$sqlplan,

    Thanks

    1. Hi Kumar,

      DBMS_XPLAN.DISPLAY_CURSOR can only show an execution plan for a SQL statement that has a cursor in the CURSOR CACHE inside the SHARED_POOL on the local system. If the SQL statement in question is executed remotely via DBLink, then the cursor for that statement will actually be in the CURSOR CACHE inside the SHARED_POOL on the remote system and hence the error.
      Thanks,
      Maria

Leave a Reply

Your email address will not be published. Required fields are marked *