The three fundamental steps of SQL Tuning are: 1) Diagnostics Collection; 2) Root Cause Analysis (RCA); and 3) Remediation. This introductory session on SQL Tuning is for novice DBAs and Developers that are required to investigate a piece of an application performing poorly.
On this session participants will learn about producing a SQL Trace then a summary TKPROF report. A sample TKPROF is navigated with the audience, where the trivial and the no so trivial is exposed and explain. Execution Plans are also navigated and explained, so participants can later untangle complex Execution Plans and start diagnosing SQL performing badly.
This session encourages participants to ask all kind of questions that could be potential road-blocks for deeper understanding of how to address a SQL performing poorly.
• My report is taking too long…
• One Materialize View is sudently hanging...
• This page is taking long since last upgrade...
• It runs faster on my development instance...
• Everything is slow, then the DBA has to fix it...
• Where to start?
• Performance information on individual SQL
• CPU and Elapsed Time
• Wait Events
• Execution Plan
• Rows processed
• Call count (parse, execute and fetch)
• Physical and Logical reads
1. Turn SQL Trace on
2. Execute some SQL or PL/SQL
3. Turn SQL Trace off
4. Find Trace File
5. Aggregate Trace into a Summary report (TKPROF)
6. Review Trace and TKPROF
Turning SQL Trace on and off
– WAITS (default TRUE)
– BINDS (default FALSE)
– PLAN_STAT (default NULL)
• FIRST_EXECUTION (equivalent to NULL)
Other ways to turn Trace on and off
• ALTER SESSION SET SQL_TRACE = TRUE|FALSE
• ALTER SESSION SET EVENT 10046
• DBMS_MONITOR.SESSION_TRACE_ENABLE or DIS
• ALTER SYSTEM SET EVENTS 'sql_trace [sql:&&sql_id]
• Oracle Enterprise Manager (OEM)
• ALTER SESSION SET
– SQL_TRACE = [ TRUE | FALSE ]
– EVENTS ‘10046 trace name context forever, level N’
• N = 1: all executions (10g-) or 1st execution (11g+)
• N = 4: Binds
• N = 8: Waits
• N = 12 = 4 + 8
• N = 16: each execution (11g+)
• N = 64: 1st + each where DB time > 1min (220.127.116.11+)
Finding SQL Trace
• Get Trace Filename from V$DIAG_INFO (11g+)
• Get Trace Directory from USER_DUMP_DEST (10g-)
– Use V$DIAG_INFO on 11g and 12c
• Rows returned on 1st execution, in average and max
• Consistent reads, physical reads/writes, etc.
• Metrics include aggregates of sub-operations
• Rows processed (returned by operations)
• Wait events (enabled by default on API used)
• Useful to understand gap between CPU and Elapsed
• Set of steps to execute a SQL statement
– Mostly Access Operations and Joins
• Better understood by correlating Plan to SQL
• Hard to read without predicate information
• Column projection also eases understanding
• Figuring out execution order can be a challenge!
Common Access Operations
• Table access
– By ROWID
• Index access
• Trace shows performance information per SQL
• Trace and TKPROF do not require additional license
• Trace includes Execution Plan when Cursor closes
• DBMS_XPLAN provides Predicates and Projection
• Understand first what the SQL does
• Then correlate SQL to Execution Plan
• Focus where the Time is spent!
• My Oracle Support (MOS)
– 39817.1 Interpreting Raw SQL_TRACE output
– 376442.1 How to Collect 10046 Trace (SQL_TRACE)
Diagnostics for Performance Issues
• Oracle Documentation