An Approach to Sql tuning - Part 1

An Approach to SQL Tuning
Part - I

Who AM I?
 Navneet Upneja (Oracle DBA)
7 Years of Experience in Oracle Databases and
Middleware Applications
 Oracle Certified Professional
 Hand on experience on OLTP, Datawarehouse,
Oracle BI, APEX…
Member of North India Chapter.

Agenda
• SQL
• Execution Process
• Scope of Tuning
• Set of Actions
• Generation of Explain Plan
• Discussing Various Techniques for
Execution Plan generation
• We are not tuning anything today

What is SQL?
• Stands for "Structured Query Language,"
• pronounced as either "sequel" or "S-Q-L.
• created by IBM in 1975
In Oracle:
• Way to query database.
• Identified by SQL ID
• 310rmwf1kf334 (13 Character Base 32
encod)

Types of SQL
• QUERY
– Select
• DML
– Insert
– Update
– Delete
– Merge
• DDL
– Create
– ALTER
– DROP
• …..

Steps in SQL Execution
Parse
• Syntax
• Symantec
• Optimization
• Execution
Plan(s)
Execute
• Bind
Variable to
Bind Values
• Execution of
Query with
Select
Execution
Plan
Fetch
• Data
Fetched to
be returned
back to
users (Only
for Quries)

Scope of Tuning
• Parse
– Hard Parsing
– Soft Parsing
– Optimization
• Object Statistics
• Latch Contention
• Execute
– IO Waits (Physical IO’s)
– CPU waits (Logical IO’s)
• Fetch
– Network Waits (Sql*net message to client)

Scenarios
• Someone complains of Application Slow or
some report is slow.
• Query from somewhere suddenly pops
that making things go bad.
• Your scheduled database program like
ETL Load starts taking longer.
• Some Ad hoc queries.
• New queries from development team.

Action Plan
• Find the offending session
– v$session
– OEM
• Find the bad SQL
– OEM
– AWR
– ASH
– Data Dictionary Views (v$SQL,v$SQLSTATS,DBA_HIST_SQLSTAT…)
• Generate Execution Plan
– Explain Plan for
– DBMS_XPLAN
• Display_Cursor
• Display_AWR
– SQL Monitoring from OEM
– DBMS_SQLTUNE.REPORT_SQL_MONITOR
• Interpret the Plan
– Go through the plan
– Look out for suspicious steps that may be causing Issue
– Cardinality
• Apply your fixes
– Optimizer Statistics
– Missing Indexes (Be careful)
– SQL Profile
– SQL Baseline

Finding Long Running
Sessions
• From SQL Script

Finding Bad SQL
• From OEM Top
Activity

Execution Plan
• Detailed Steps required
to execute a SQL.
• Combination of various
database operations.
• Designed by Query
Optimizer
• Tree Shaped
• For better usability,
shown in Tabular form.
• OEM shows both plans.

Generating Explain plan
• Explain plan for .. <SQL Statement>
– Populated plan_table
– Captured plan can be viewed using SQL
Statsment
– select plan_table_output from
table(dbms_xplan.display('plan_table',null,'serial'))
– @?rdbmsadminutlxpls
– Not always right specifically if SQL Statement
contains BIND Variables

Example of Explain plan…
• Explain plan for a simple select with one Bind Variable
• Resulted plan shows Index Range scan.

• Lets run the same query with Literal
select * from employees where department_id=50
Optimizer decided to perform Full table scan instead of using Index
Check the difference in Number of Rows returned against FTS

So, Then What if not Explain
plan?
• DBMS_XPLAN
– Display Plan from Cursor
Cache
– From AWR
– From SQL Plan Baseline
– From SQL Set

DBMS_XPLAN
• DBMS_XPLAN.DISPLAY
• DBMS_XPLAN.DISPLAY_CURSOR
• DBMS_XPLAN.DISPLAY_AWR
• DBMS_XPLAN.DISPLAY_SQL_PLAN_BA
SELINE
• DBMS_XPLAN.DISPLAY_SQLSET

DBMS_XPLAN.DISPLAY_CURSOR
– Display from GV$SQL_PLAN (or
GV$SQL_PLAN_STATISTICS_ALL)
– Useful in providing real statistics for SQL
execution
– Various options to display different details like
Advanced, Allstats, IOSTATS etc..
– Is NOT RAC Aware

Is it Sufficient?
Estimates ..not
Real

Rowsource Statistics
• More detailed statistics
• Provide real picture but
after execution of query
• Must to find out exact
cause of problem
• v$sql_plan_statistics_all
• Provides Real Numbers
for :
– Rows returned
– CPU
– Physical IO
– LIO
– Elapsed Time
Pre-requisite:
STATISTICS_LEVEL=ALL
(At session level)
OR
/*+ gather_plan_statistics */
Hint in SQL

DBMS_XPLAN.DISPLAY_AWR
– Display Execution plan for SQL_ID’s captured
in AWR
– Can show details of Peeked Bind Values.
– Useful to troubleshoot performance of SQL
from the past
– Can be used to compare the execution plan
from the past
– Is definitely a next step after AWR Report.

Example..
• select * from table(dbms_xplan.display_awr('86bh2bn3gtmm0',null,
null, 'ALL +peeked_binds'));

An Approach to Sql tuning - Part 1

SQL Monitor
• Real Time Monitoring
• Identify run time problems
• Useful for long running Queries
• Provide actual run time values for each step in execution
plan.
• Easy to access through OEM.
• DBMS_SQLTUNE.report_sql_monitor
• STATISTICS_LEVEL=TYPICAL/ALL
• control_management_pack_access
=DIAGNOSTIC+TUNING

In the Next Session..
• Interpreting Execution Plan
• 10046 Trace
• CBO Basics
• Finding out the bottlenecks
• Much More…

An Approach to Sql tuning - Part 1

Recommended

More Related Content

What's hot (20)

Similar to An Approach to Sql tuning - Part 1 (20)

More from Navneet Upneja (9)

Recently uploaded (20)

An Approach to Sql tuning - Part 1