SQL Tuning

Presented to NAM

12-Feb-2016
By Kuldeep Singh

Introduction

SQL Tuning is Hard

Providing a Framework

Helps develop your own processes

There is no magic tool

Tools cannot reliably tune SQL statements

Tuning requires the involvement of you and other technical

and functional members of team

Introduction

How to speed up a slow query?

Find a better way to run the query

Cause the database to run the query your way

How does a database run a SQL query?

Join order

Join method

Access method

Challenges

Requires Expertise in Many Areas

Technical Plan, Data Access, SQL Design

Business What is the Purpose of SQL?

Tuning Takes Time

Large Number of SQL Statements

Each Statement is Different

Low Priority in Some Companies

Vendor Applications

Focus on Hardware or System Issues

Never Ending

Database Tuning Options

Hardware Solution (determine bottleneck)

More Memory

Faster or additional Processors

Faster Disk IO (possibly via RAID)

More Network Bandwidth

Software Solution

Database/Instance Tuning(Location of files, block size, db

buffer cache size, etc)

Object Tuning (Index creation, table reorganization, etc)

SQL Tuning (application tuning)

Identify End-to-End

Business Aspects

Who registered yesterday for SQL Tuning

Who uses this information?

Why does the business need to know this?

How often is the information needed?

Technical Information

Review Tables, Indexes, Triggers, Views, etc

Understand Relationships

Know the Data (High Level)

End-to-End Process

Understand Application Architecture

What Portion of the Total Time is Database

Wait Event Information

V$SESSION

V$SESSION_WAIT

SID
USERNAME
SQL_ID
PROGRAM
MODULE
ACTION
PLAN_HASH_VALUE
ROW_WAIT_OBJ#

SID
EVENT
P1, P1RAW, P2, P2RAW, P3, P3RAW
STATE (WAITING, WAITED)
Oracle 10g added this info to V$SESSION

V$SQL

V$SQLAREA

V$SQL_PLAN

SQL_ID

SQL_ID

SQL_ID

SQL_FULLTEXT

EXECUTIONS

PLAN_HASH_VALUE

PARSE_CALLS
BUFFER_GETS
DISK_READS

DBA_OBJECTS

OBJECT_ID
OBJECT_NAME
OBJECT_TYPE

Wait Event Information

SELECT s.sql_id, sql.sql_text, sql.plan_hash_value,
DECODE(s.state, 'WAITING', s.event, 'CPU/LogicalIO')
waitevent,
s.p1, s.p2, s.p3
FROM v$session s
JOIN v$sql sql ON (
s.sql_id = sql.sql_id AND s.sql_address = sql.address
)
WHERE program = AND s.sid =
AND <whatever else you know>

Wait Time Scenario

Which scenario is worse?

SQL Statement 1

Executed 100 times

Caused 100 minutes of wait time for end user

Waited 99% of time on db file sequential read

SQL Statement 2

Executed 1 time

Caused 100 minutes of wait time for end user

Waited 99% on enq: TX row lock contention

Gather - Metrics

Get baseline metrics

How long does it take now

What is acceptable (10 sec, 2 min, 1 hour)

Collect Wait Time Metrics How Long

Locking / Blocking

I/O problem, Latch contention

May be multiple issues

All have different resolutions

Document everything in simple language

Gather Execution Plan

Execution Plan

V$SQL_PLAN

Do not use EXPLAIN PLAN

DBMS_XPLAN

Bind Values

V$SQL_BIND_CAPTURE

Tracing

Table and Index Statistics

ERD

Execution Plan

-----------------------------------------------------------------------------| Id

| Operation

| Name

| Rows

| Bytes | Cost

-----------------------------------------------------------------------------|

0 | SELECT STATEMENT

95 |

1 |

1 |

167 |

95 |

2 |

1 |

138 |

94 |

3 |

7 |

357 |

87 |

4 |

| VW_SQ_1

201 |

7035 |

87 |

|*

5 |

6 |

201 |

3417 |

87 |

|*

7 |

|*

8 |

| REGISTRATION | 80000 |

1328K|

76 |

|*

9 |

|* 10 |
|* 11 |
|

12 |

|* 13 |

NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
VIEW
FILTER
HASH GROUP BY
FILTER
TABLE ACCESS FULL
INDEX UNIQUE SCAN

| SYS_C0036920 |

1 |

16 |

0 |

1 |

87 |

1 |

| SYS_C0036919 |

1 |

0 |

1 |

29 |

1 |

| SYS_C0036918 |

1 |

0 |

TABLE ACCESS BY INDEX ROWID| CLASS

INDEX UNIQUE SCAN

TABLE ACCESS BY INDEX ROWID | STUDENT

INDEX UNIQUE SCAN

------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

5 - filter((MAX("SIGNUP_DATE")>=TRUNC(SYSDATE@!-1) AND
MAX("SIGNUP_DATE")<=TRUNC(SYSDATE@!)))
7 - filter(TRUNC(SYSDATE@!-1)<=TRUNC(SYSDATE@!))
8 - filter("CANCELLED"='N')
9 - access("R1"."STUDENT_ID"="STUDENT_ID" AND "R1"."CLASS_ID"="CLASS_ID" AND
"SIGNUP_DATE"="VW_COL_1")
filter(("SIGNUP_DATE">=TRUNC(SYSDATE@!-1) AND "SIGNUP_DATE"<=TRUNC(SYSDATE@!)))
10 - filter(UPPER("C"."NAME)='SQL TUNING')
11 - access("CLASS_ID"="C"."CLASS_ID")
13 - access("S"."STUDENT_ID"="STUDENT_ID")

Response time

Sum of service time + wait time

Processing strategy has key effect on response time

Eg: Sequential processing

In a queue, wait time for a job = sum of service time of all

previous jobs

If queue gets longer parallel processing required

Response time in Sequential and

Parallel processing
Wait time
jobs

Service time

time
jobs

Oracle tuning methodology

Tune business rules

Tune data design

Tune application design

Tune logical structure

Tune database operations

Tune access paths

Tune memory allocation

Tune I/O and physical structure

Tune resource contention

Access Methods

Access method = way that data is

retrieved from table

Index scan small number of rows

accessed

Full scan larger number of rows

accessed

Modifying the Access Method

Set Initialization Parameter

optimizer_index_caching

optimizer_index_cost_adj

db_file_multiblock_read_count

Hints

Full

Index

I/O and physical design

Use multiple disks + parallel controllers

Optimise block size

Use extents large enough for indexes

Use raw device

Resource contention

Block contention

Shared pool contention

Lock contention

All these can be diagnosed with Oracle

stats

Common Sense Indexing

Dont always need indexes

table with few columns

static data

small tables

appended tables (SQL*Loader)

How to index

single column surrogate sequences

dont override PK and FKs

avoid nullable columns

The Optimizer
An optimizer determines the best way to execute the SQL
query. Oracle has two optimizers.

The Oracle rules based optimizer follows a strict set of rules

when determining how to execute the query. For example,
one rule is that all available indexes should be used.

The Oracle cost based optimizer looks at statistics, such as

the number of rows in a table or the variance of values in a
column, to determine the best way to execute the SQL
statement. For example, the cost based optimizer may
choose to ignore an index if it sees that the table is very
small and will be completely pulled into memory with a
single block (page) read anyway.

Oracle Optimizer Modes

RULE

Uses the rules based optimizer only.

CHOOSE

Uses the cost based optimizer if any

statistics are available for the query tables.

FIRST_ROWS Uses the cost based optimizer but biases

the execution plan toward retrieving the
first rows to the user as fast as possible.
This is the default for the CHOOSE mode.

ALL_ROWS

Uses the cost based optimizer but biases

the execution plan toward minimizing the
total retrieval time, even if that means a
longer delay before the first rows are returned
to the user.

Changing Optimizer Modes

For session:
Alter session set optimizer_mode = <mode>
Alter session set optimizer_mode = RULE

For Query:
Select /*+ <mode> */ first, last from students;
Select /*+ FIRST_ROWS */ first, last from students;
Select /*+ FIRST_ROWS(50) */ first, last from students;
Select /*+ RULE */ first, last from students;
Select /*+ CHOOSE */ first, last from students;
Select /*+ ALL_ROWS */ first, last from students;

Index Decision
Should the Index Be used?
- what is table size
- what is column(s) selectivity
(if you are selecting >20%
dont bother with the index)
Is the optimizer making the correct decision?

Join Order
Small tables or Tables with High Selectivity should be joined before large
tables or tables with low selectivity.

Monitor

Monitor the improvement

Be able to prove that tuning made a difference

Take new metrics measurements

Compare them to initial readings

Brag about the improvements no one else will

Monitor for next tuning opportunity

Tuning is iterative

There are always room for improvements

Make sure you tune things that make a difference

Thank you