0% found this document useful (0 votes)
99 views

12 Step Query Tuning Oracle IG

sf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
99 views

12 Step Query Tuning Oracle IG

sf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Oracle Query Performance Tuning:

A 12Step Program
REVIEW FILTER AND
EXAMINE THE Examine cost, ACCESS PREDICATES
Dont use
EXECUTION PLAN row count and explain plans
Know how query
time is interpreted (e.g.,
bind variables)
2
Know when
1 Get actual plan
Get actual
row counts
predicate is applied
(should be earlier
Find the (use DBMS_XPLAN. for each step rather than later)
expensive DISPLAY_CURSOR)
operators
Review data types
to avoid implicit
EVALUATE
Review table conversions
EXISTING
definitions
INDEXES Get table sizes
ANALYZE 3
COLUMNS IN Get index and row count GATHER TABLE
WHERE CLAUSE
definition INFORMATION

Look for select * or


4
If its a view, get
scalar functions (some Review current the underlying table
are less optimal)
5 statistics definitions
Know order of
columns and their
selectivity
Know if histograms or
Foreign key constraints
Know table baselines are being
can help the optimizer create
relationships (avoid used; get sample bind
Know the selectivity and REVIEW EXISTING better execution plans
duplicating efforts variable values
cardinality of the columns KEYS AND later on)
(is there data skew?)
CONSTRAINTS
TIP

6 What is primary
key definition? RUN THE QUERY AND
RECORD BASELINE
Avoid sub-queries SARG-able METRICS
(need index?)
7
TUNE
Gather average
Look for high-cost steps THE QUERY execution times
and steps with largest
RE-RUN Nested loop/ number of rows
THE QUERY merge/hash joins
8 Focus on logical
I/Os (number of
Capture wait logical reads)
TIP Focus on events
Seeks vs scanswhich most expensive
Record the 9 is more expensive in this operations first
Out-of-date
time, logical I/O scenario?
statistics can impact
and wait events, performance
and compare RE-RUN
with initial
Consider using a function-
THE QUERY
baseline
CONSIDER ADJUSTING INDEXES based index to exclude rows LOOK FOR
in very large tables PERFORMANCE
INHIBITORS
11
Make small
changes 10
Reduce
logical I/O 12
Abuse of wildcards (*)
pulling back too many
Nested views that go rows
Cursors and row-by-row
across database links
processing
Code-based SQL
generators (e.g. EMF,
LNO, Hibernate)
Join/query/table hints Scalar functions

Find and fix query performance faster with SolarWinds Database Performance Analyzer. Free 14-day trial at: www.solarwinds.com/dpa-oracle-download
2015 SolarWinds, Inc. All rights reserved.

You might also like