Effective SQL Tuning Using Toad - Toad for Oracle - Toad for Oracle - Toad World Página 1 de 5

Effective SQL Tuning

Using Toad
Effective SQL Tuning Using Toad

Bert Scalzo / 9.29.2013 at 8:27pm

A hot topic that always attracts lots of readers is SQL Tuning. The
problem is that quite often SQL tuning requires a slow hand –
because as the song says “You're walking on thin ice. You're living
on borrowed time. You're playing with dynamite. Still waters run
deep. You better look before you leap.” All too often SQL
developers and/or DBA’s rush to explore explain plans, optimizer
costs, execution times and several other technical particulars (all of
which of course Toad can assist with). However many times the
simple, best first step is to understand in English the problem the
query is attempting to answer – because many times SQL is
fundamentally flawed. Therefore it’s universally constructive to first
fix the coding problems before trying to optimize the SQL.

Let’s examine a simple, single table example – a SELECT with many

sub-SELECT’s, and zero joins.

select * from employee

where emp_dept in (select distinct emp_dept

from employee

where emp_dept like 'W%'

or emp_dept like 'X%'

or emp_dept like 'Y%'

or emp_dept like 'Z%')

and emp_telephone in (select distinct

emp_telephone

from employee

where substr(emp_telephone,2,3)
like '5%'

or substr(emp_telephone,2,3)
like '6%')

and emp_id in (select distinct emp_id

http://www.toadworld.com/products/toad-for-oracle/b/weblog/archive/2013/09/29/eff... 27/09/2015
Effective SQL Tuning Using Toad - Toad for Oracle - Toad for Oracle - Toad World Página 2 de 5

from employee

where emp_age between 55 and 65

and emp_sex in ('M','F'))

and job_id in (select distinct job_id

from employee

where job_id not like '%PRES'

and job_id not like '%VP'

and job_id not like '%MAN'

and job_id not like '%MGR')

and emp_salary >= (select avg(emp_salary)

from employee

where job_id in (

select distinct
job_id

from employee

where job_id not

like '%PRES'

and job_id not

like '%VP'

and job_id not

like '%MAN'

and job_id not

like '%MGR'))

If I ignore my own advice and start by looking at the “explain

plan” (shown in Figure 1 below), then I see it has four full table
scans highlighted in red – where red means generally bad.
Moreover the optimizer cost is almost 23,000! If I furthermore
submit this original query to Toad Xpert’s automatic SQL tuning
(which leverages SQL Optimizer), it works for over three hours
generating thousands of potential explain plans. That’s far too long
to wait for an overwhelming plethora of options – even if there is a
“clear cut” winner. The key takeaway here is that for SQL tuning,
“garbage in means not such good results out” – as it took forever
for marginal advice. In reality no one would wait over three hours
for tuning just one SQL statement. There has to be a better way to
work.

http://www.toadworld.com/products/toad-for-oracle/b/weblog/archive/2013/09/29/eff... 27/09/2015
Effective SQL Tuning Using Toad - Toad for Oracle - Toad for Oracle - Toad World Página 3 de 5

Figure 1: Explain Plan for Original Demo Query

So let’s first discern what business question the query is trying to

answer? The business wants to a list of employees that work in
departments that start with W, X, Y or Z, having telephone area
code that start with 5 or 6, are in a protected class (i.e. over 55
years old), are non-managers, and whose base salaries are above
the average of other non-managers in general (i.e. across the
entire company).

Now look at the original query. It’s clear that whoever wrote the
query broke the problem down into its sub-parts, solved them
each independently and then simply “glued” together all the sub-
solutions into the overly complex and expensive query with a
suboptimal optimizer cost and explain plan. Now don’t laugh,
many complex queries get written this way. Incremental SQL
development is quite common. In fact GUI tools like Toad and SQL
Developer with their tabbed editors make it simple to cut and
paste sub-pieces or partial solutions back and forth, often resulting
in queries like the original query above.

If we just clean-up the original SQL to remove unnecessary sub-

SELECT’s resulting from such incremental development, the
resulting query is almost half the size by number of lines and the
run time is twice as fast. Note again, that’s nearly half the code size
and twice the runtime speed simply from understanding the SQL
problem in English and then cleaning up the SQL code to remove
any superfluous, incremental development constructs.

http://www.toadworld.com/products/toad-for-oracle/b/weblog/archive/2013/09/29/eff... 27/09/2015
Effective SQL Tuning Using Toad - Toad for Oracle - Toad for Oracle - Toad World Página 4 de 5

with avg_sal as (

select avg(emp_salary) as avg_emp_sal

from quest_perf.employee

where job_id not like '%PRES'

and job_id not like '%VP'

and job_id not like '%MAN'

and job_id not like '%MGR')

select count(*) from quest_perf.employee, avg_sal

where substr(emp_dept,1,1) in ('W','X', 'Y', 'Z')

and substr(emp_telephone,2,1) in ('5', '6')

and emp_age between 55 and 65

and job_id not like '%PRES'

and job_id not like '%VP'

and job_id not like '%MAN'

and job_id not like '%MGR'

and emp_salary >= avg_sal.avg_emp_sal

Note that the resulting new “explain plan” (shown in Figure 2

below), is far simpler, costs 2.5times less and has just one full
table scan – which makes far more sense since we know that we’re
working with but one table. Furthermore the run time is twice as
fast – at .858 vs. 1.685 seconds.

Figure 2: Explain Plan for Revised Demo Query

http://www.toadworld.com/products/toad-for-oracle/b/weblog/archive/2013/09/29/eff... 27/09/2015
Effective SQL Tuning Using Toad - Toad for Oracle - Toad for Oracle - Toad World Página 5 de 5

Now I clearly have something far more worth submitting to Toad

Xpert’s automatic SQL tuning (which leverages SQL Optimizer). In
fact SQL Optimizer runs for just five minutes finding a very
understandable and manageable 16 potential rewrites – with
rewrite #9 being the clear cut winner. The key point is that you
really need to apply “human intuition” and “common sense” to SQL
before trying to tune it. If you clean up your SQL code before trying
to optimize it (especially when using automatic tuning tools), the
better the SQL input the better the optimization and tuning output.
So “quality in” means useful results out. Therefore always review
and clean up your SQL before trying to tune it. Life is just better
that way.

Figure 3: Toad Xpert's Auto SQL Tune

8034 0 / 2

http://www.toadworld.com/products/toad-for-oracle/b/weblog/archive/2013/09/29/eff... 27/09/2015