Explain This!

A Toad for Oracle WHITE PAPER

Tuning SQL queries often seems like an art versus a science. When I ask people if or how they tune their queries, I often get empty stares or mutterings. So, are people not tuning? Well, of course people are tuning but, this topic can be extremely intimidating, and no one wants to give the wrong answer. When I ask someone if they have ever been less than satisfied with the performance of a SQL query they or someone else has written, the answer is always a definitive YES! If anything, performance of the database in general is the number one pain or topic of interest for any customer we speak to at Quest. Where does one start with tackling a performance problem? I think many people assume that they can just start at the SQL step first, but it is very possible the problem lies elsewhere. If you have a PL/SQL program, it could contain many queries and not all of them will be bad. A query can also have problems with things other than the execution step. It must be parsed, executed, and account for the data to be requested and retrieved from the database to the client. Oracle has many processes and requests to deal with (internally and externally) simultaneously ever millisecond. You may have a system resource busy and unavailable for your query to run. Investigating the root cause of the problem involves using Oracles Profiler and Tracing facilities. Thankfully the wealth of information from these tools is easily gathered and analyzed with Toad. However, it has been documented that a majority of performance problems with database applications comes down to poor Execution Plans and/or poor indexing implementations. If the plan is bad, then a user is left to re-design their query in hopes of a better plan being chosen by Oracles optimizer. Or if the query isnt available for changes, they can experiment with different indexing scenarios in hopes of influencing how the database chooses to gather the data.

Just what is a Plan, and why should I care?

Relational databases have been around in theory for almost 50 years now. Two really smart guys by the name of Boyce and Codd came up with the idea that information could be stored and retrieved based on how the data was related to itself. The Oracle database was the first commercially successful implementation of this theory with its v2 release in 1979. It supported SQL, or the Structured Query Language. What SQL made available to end users was the ability to ask for information in such a way to describe the output without much of a need to worry about just HOW the database should go about getting it. Instead of telling the database to read this information, then that information, then hash join it together, and do a sort at the very end, we can instead just say Show me the people hired in this department in the last 30 days and give it to me in hire date descending order. For a while, Oracle would showcase this functionality by doing a demo of writing queries and having them executed in SQL*Plus.

In a well tuned environment, hopefully 9 out of 10 or so of your queries will execute in a reasonable amount of time. If you end up tuning more queries than not, then its likely your problem is with the database and not your SQL. If however, the problem IS with your SQL, then you can ask the database to show you its plan for executing it. Once the plan, or path or strategy to get to the data, is exposed to the user, they can make changes to their query to get the database to take a more efficient route. Oracle has a split second to see your query and come up with a good plan, and then it has to implement the plan, gather the results, and send it back you, the end user. It wont always pick the best plan. There are often many different routes the database can take to get to your data. In the latest versions of Oracle, these paths are chosen based on the metadata collected on the data you are querying. You can influence the route chosen by writing your SQL statement in different ways. If you write your query poorly, its possible Oracle will choose a bad plan. A robust database can often overcome the limitation with poorly written SQL with horsepower or with its self-tuning powered optimizers built into the database. However, there is no such thing YET as the perfect database that allows you to put junk in and get excellence out.

Plans How to Get Them

Toad makes it very easy to see the execution plan for your SQL statement. In Toad, just put your mouse on the query in the editor and hit CTRL+E on the keyboard. This will take you to the Explain Plan. You can also use the Ambulance button in the editor toolbar to generate a plan.

Oracles plan for executing the query shown in the editor.

Theoretical versus Actual Plans

When you ask for an execution plan in Toad, Oracle responds with what the plan should be if you were to run it then. However, it is possible that when the SQL is executed a DIFFERENT plan is chosen. This can happen for several reasons. The statistics and optimizer modes can change or resources can become unavailable at run time causing Oracle to choose a different plan. To see what plan was ACTUALLY chosen by the optimizer when your query was executed, you need to investigate the V$SQL_PLAN data dictionary view. Toad will automatically do this for you when you view your session with the Session Browser. Plans shown in the Current Statement plan come from V$SQL_PLAN versus from an EXPLAIN PLAN request.

Plan as executed shown in Toads Session Browser.

You can also see what a given querys plan was at execution time by viewing a trace file of the appropriate session.

PINNED PLANS
If a query is executed frequently enough, or if it is manually PINNED by a user, Oracle will not generate a plan at execution time. Instead, it will rely on a plan that has already been generated and stored in memory. This memory area is known as the SQL Shared Pool. Toad has a screen (Database Monitor SGA Trace|Optimization that will show you everything in the pool and the statements associated plans. If you are trying to tune a query and do not see the plan changing for your query, you may need to Flush the SGA. This will cause Oracle to re-parse every query submitted and generate new plans on the fly until the Buffer can be built out again. This should not be undertaken lightly as it could cause dramatic performance changes in the short term.

Toads SGA Trace screen shows you all of the cached queries and plans. You can also see execution statistics for each query.

Plans How to Read Them

Reading execution plans can be a challenging task. Simple plans like the ones weve seen above are very straightforward. Generally, you read from Top to Bottom, Left to Right. Each plan step has: A plan step number A plan access method (and optionally a segment name, e.g. index, table, etc) Cost Cost Cost is a relative metric that Oracle generates to represent the amount of work required to undertake a specific step. The sum of costs for all steps represents the cost to execute an entire statement. Generally speaking, a lower cost plan represents a better chance of running optimally than a higher cost plan. However, it is very common to see plans with significantly higher costs run better than their lower cost brethren. Just ask any DBA if they feel comfortable tuning queries solely by examining planning cost! For this reason, it is very important that you be able to decipher the plan steps and have a good understanding of your applications data model and understand what you are asking the database to do for you.

Plan Access Method If you have ever heard or read the words Full Table Scan, then you have some experience with execution plans. Often times this phrase is uttered as a curse or seen as a worst case scenario. Each different type of execution plan step represents a different method for accessing the data. They should not be seen as being inherently good or bad by themselves. If an index is available, then using an index to get to your data CAN be faster than doing a full table scan. However, if you are trying to read in ALL the data from a table, then using an index could generate extra unnecessary work. You may hear things like HASH JOINS are bad, dont ever use those. This probably comes from a place of truth. Your DBA may have seen over the years as they have administered your application that this method is less successful than others. But that doesnt mean it will ALWAYS be bad. So, how can you figure out what each of these plan methods mean? You have two options built into Toad. 1. Knowledge Xpert Available for all commercial Toad users, Knowledge Xpert is a built-in Oracle knowledge repository. Documentation and hints for reading and interpreting execution plans are available by doing a search.

You can bookmark your favorite topics and add custom notes appropriate for your environment.

2. Quest SQL Optimizer When you start a Tuning Lab session (thats right, Toad can tune your queries for you if you have the Xpert edition), the execution plans are also available for review. If you need help interpreting the step, simply mouse-right-click on the step and select the GET HELP ON item.

Excellent documentation for dozens of the most frequently seen execution plan steps is available at the click of a mouse!

Simplify the plan display for easier comprehension In Toad, you can choose to view a plan in several different ways. Your options are available with a mouse-right-click and include: Tree (default) Plain English - Steps listed in numerical order without cost and bytes fields. Graphic Illustration shows the plan in action MS Graphic Execution Plan as seen in MS SQL Server. Tree View:

Plain English View:

Graphic View:

MS Graphic View:

Execution Plan Tricks

1. See immediately what segments are included in your plans. For example, have you re-written your query to promote an index? If your plan is very large, it may be very hard to see if that index is showing up. In Toad, you can mouse-right-click on a plan and select Show Object Usage

2. Toad selectively takes the plan step information from the Plan Table. You may want to see an exhaustive set of information for each step. You can see all of the execution plan data by also right-mouse-clicking in the Explain Plan tab and selecting Single Record View.

3. Save and compare plans. If you are tuning a query, it might be very hard to discern changes between one plan and the next. If you do not have the Xpert edition of Toad (which automatically compares all plans available for a query), you can still use Toad to manually compare 2 plans.

Again, mouse-right-click in the plan and choose Compare to another plan.

Do You Need More Help?

Tuning queries and working with execution plans can be a very time-consuming process. For example, I could spend twenty or thirty minutes re-writing a query to influence a new plan, making sure it doesnt have syntax errors, and more importantly making sure the correct data is returned. What happens if Oracle generates the same plan though? In essence that is twenty to thirty minutes of lost time. Toad offers a different way to re-write queries, and it is known as Toad for Oracle Xpert Edition. Our proprietary tuning technology can automatically re-write your query or queries in hundreds of different ways to force Oracle into considering other execution plans. You can then choose the plan that makes the most sense for your environment. If you cannot get a better plan, it can even suggest different index sets that will give you new execution plans for consideration. If you would like to try this technology out, either contact your local Quest sales representative or go to Quest.com and download a 30-day evaluation copy of Toad today. I also highly recommend Guy Harrisons and Richard Tos whitepaper series on tuning at Toad World as well. They go into a much deeper level and discuss how Quests Oracle technology facilitates tuning at the database AND SQL level.

About the Author

Jeff Smith is a Solutions Architect at Quest Software. What does that mean exactly? He gets paid to talk about Toad and the other database products at Quest. He has been with Quest since 2001, working on the Toad R&D, nd Product Management, and Sales organizations. Jeff is the primary author of the Toad Handbook, 2 Edition, published by OReilly and is currently working with Bert and Patrick on the next edition! He holds a bachelor's degree in Computer Science from West Virginia University. Jeff is a regular speaker at Toad User Groups and Oracle User Groups worldwide.