Oracle SQL :

Introduction to Performance Tuning

Javier Durango
Topics

1 Performance Tuning -
When?

2 SQL Tuning Concepts

3 Execution Plans
1 WHEN TO START
TUNING
Tuning During the Life Cycle
• Tuning is of two types:
• Proactive (Make it better, so it
will not break)
• Test scenarios.
• Find the problem areas. Proactive
• Resolve the problem.
• Reactive (Wait until it breaks;
then fix it)
• Monitor production application.
• Tune issues as needed.
Reactive
Application Design and Development
The application can be tuned, even
in the design and development
phases, by building and tuning test
cases:
• Check normalization against major
functions.
• Check data structures against
access times.
• Look at the points where processes
are serialized.
• Tune the major reports.
• Tune the high-volume processes.
• Quantity of SQL statements issued.
the most efficient
SQL statement is
the one that
is never executed
2 SQL TUNING
SQL Processing Phases

Open Parse

Bind

Execute

Close Fetch
SQL Tuning
• Single execution
• Concurrent execution
SQL Tuning
• Single execution
• Queries
• Bulk Inserts
• Bulk Updates
• Bulk Deletes
• Concurrent execution
SQL Tuning
• Single execution
• Queries
• Execution plan
• Bulk Inserts
• Bulk Updates
• Bulk Deletes
• Concurrent execution
SQL Tuning
• Single execution
• Queries
• Bulk Inserts
• Context switching
• Find available block
• Index balancing
• Bulk Updates
• Bulk Deletes
• Concurrent execution
Context Switching

PL/SQL Engine
BEGIN
procedural Procedural
PL/SQL FOR i IN … LOOP
Statement
Block Executor INSERT ...
SQL and/or
UPDATE ...
and/or
DELETE ...
SQL Statement END LOOP;
Executor END;
SQL Engine
Insert – Context
switching
• Use insert – select whenever
possible
• Use forall insert when
working with pl/sql
collections
Insert – Find available blocks
Regular insert: Direct-path insert:

available available
blocks blocks

HWM HWM

HWM
Insert – Find available
blocks
• Use append hint for insert –
select operations
• Use append-values hint in
forall insert operations
Insert – Index maintenance
Index Maintenance
• Remove unnecessary indexes DROP INDEX emp_email;

• Make indexes unusable

before bulk operation ALTER INDEX emp_name UNUSABLE;

• Rebuild index after bulk ALTER INDEX emp_name REBUILD;

operation
SQL Tuning
• Single execution
• Queries
• Bulk Inserts
• Bulk Updates
• Execution plan
• Eventual index balancing
• Row migration and
chaining
• Bulk Deletes
• Concurrent execution
Row chaining and migration: anatomy of a
block

Block header
Growth
Free space

Row data
Row chaining and migration

Migration

Chaining

Index Table
Row chaining and
migration
• Plan ahead for tables where a
big percentage of rows could
grow considerably in size
• Create tables with bigger
block free space
• DBAs can create tablespaces
with a bigger block size
SQL Tuning
• Single execution
• Queries
• Bulk Inserts
• Bulk Updates
• Bulk Deletes
• Execution Plan
• Index balancing
• Concurrent execution
SQL Tuning
• Single execution
• Concurrent execution
• Parsing time
• Locking
Shared SQL Areas
Cursor for Cursor for
SELECT statement 2 SELECT statement 1

SGA Shared SQL

SELECT SELECT SELECT

statement 1 statement 2 statement 1
User A User B User C
SQL Tuning: Parsing time
• DBAs can find SQL
statements that account for
large parsing times overall
SQL Tuning: Parsing time
• For all SQL that is going to be
executed by many
concurrent users, use bind
variables instead of
concatenating literals
SQL Tuning: Parsing time
• Incorrect:
execute immediate
'select * from orders where order_id = ' || i
into order_rec;

• Correct:
execute immediate
'select * from orders where order_id = :i'
into order_rec
using i;
SQL Processing Phases

Open Parse

Bind

Execute

Close Fetch
SQL Tuning
• Single execution
• Concurrent execution
• Parsing time
• Locking
SQL Tuning: Locking
• Though it is very unusual to face performance issues due to row
locking, poor application design can lead to lock waits:
3 EXECUTION
PLAN
Execution Plan
• Series of steps executed to
find rows for a single query,
update or delete operation
• Usually executed sequentially
• Can be parallelized
SQL Processing Phases

Open Parse

Bind

Execute

Close Fetch
Execution Plan
• There are not good or bad plans
• There are not good or bad steps
• Given a specific scenario, a plan can be optimal or suboptimal

-----------------------------------------------------------------------------------------
|Id | Operation |Name |Rows |Bytes |Cost | TQ |IN -OUT|PQ Distrib|
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 41 | 1066 | 4 | | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) |:TQ10001 | 41 | 1066 | 4 |Q1,01 | P->S |QC (RAND) |
| 3 | SORT GROUP BY | | 41 | 1066 | 4 |Q1,01 | PCWP | |
| 4 | PX RECEIVE | | 41 | 1066 | 4 |Q1,01 | PCWP | |
| 5 | PX SEND HASH |:TQ10000 | 41 | 1066 | 4 |Q1,00 | P ->P | HASH |
| 6 | SORT GROUP BY | | 41 | 1066 | 4 |Q1,00 | PCWP | |
| 7 | PX BLOCK ITERATOR | | 41 | 1066 | 1 |Q1,00 | PCWC | |
| 8 | TABLE ACCESS FULL|EMP2 | 41 | 1066 | 1 |Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------
How does the optimizer build an execution
plan?
Types of Execution Plan Steps
• Data retrieval
• Joins and anti joins
• Sorts
• Temp table transformation
Types of Execution Plan Steps
• Data retrieval
• Table access
• Index access
• Joins and anti joins
• Sorts
• Temp table transformation
Types of Execution Plan Steps
• Data retrieval
• Table access
• Full table scan
• Table access by index rowid
• Index access
• Joins and anti joins
• Sorts
• Temp table transformation
Full Table Scan
• The DB reads all “used” blocks
up to HWM
• It can use multiblock reads
• In Exadata environments it can
“offload” the processing of the
step to the cell storage
Table access by index rowid
• Involves 2 separate readings,
Indexed
access on table
one for the index and then for
the table
• It may be one of the fastest
way to access a single row in a
large table ROWID
Types of Execution Plan Steps
• Data retrieval
• Table access
• Index access
• Index unique scan
• Index range scan
• Index fast full scan
• Joins and anti joins
• Sorts
• Temp table transformation
Index Unique Scan
• This scan returns, at most, a
Accessing a unique
index
single rowid.
• Oracle performs a unique scan
if a statement contains a
UNIQUE or a PRIMARY KEY
constraint that guarantees that ROWID
only a single row is accessed.

select * from orders

where order_id = :i
Index Range Scan
Using a non unique
• Any scan on an index that is condition

not guaranteed to return zero

or one row
• One of the most common
access methods. ROWIDS
• Slower than other methods in
Exadata environments

select * from orders

where order_date > :d
Index Fast Full Scan
Accessing
• The index contains all the entire index
columns that are needed for
the query
• A fast full scan accesses the
data in the index itself, without
accessing the table

Column C
select order_id from orders Column B
Column A
Types of Execution Plan Steps
• Data retrieval
• Joins and anti joins
• Nested loop
• Sort-merge
• Hash join
• Sorts
• Temp table transformation
Nested Loop Join
• One of the two tables is SELECT c.cust_id, co.country_name
defined as the outer table (or FROM customers c
the driving table). INNER JOIN countries co
• The other table is called the ON (c.country_id = co.id);
inner table.
• For each row in the outer
table, all matching rows in the
inner table are retrieved.
• Used when few rows have a
good driving condition.
Nested Loop Join
• One of the two tables is SELECT c.cust_id, co.country_name
defined as the outer table (or FROM customers c
the driving table). INNER JOIN countries co
• The other table is called the ON (c.country_id = co.id);
inner table.
• For each row in the outer
table, all matching rows in the
inner table are retrieved.
• Used when few rows have a
good driving condition.
Sort-Merge Join
Basic Execution Plan:
• The rows from each row MERGE (JOIN)
source are sorted on the join SORT (JOIN)
TABLE ACCESS (…) OF table_A
predicate columns. SORT (JOIN)
TABLE ACCESS (…) OF table_B
• The two sorted row sources
are then merged and returned
as the resulting row source.
• Used when inputs are already
sorted, or sorts are required for
other operations.
Sort-Merge Join
Basic Execution Plan:
• The rows from each row MERGE (JOIN)
source are sorted on the join SORT (JOIN)
TABLE ACCESS (…) OF table_A
predicate columns. SORT (JOIN)
TABLE ACCESS (…) OF table_B
• The two sorted row sources
are then merged and returned
as the resulting row source.
• Used when inputs are already
sorted, or sorts are required for
other operations.
Hash Join
• Both tables are split into as
many partitions as required,
using a full table scan.
• For each partition pair, a hash
table is built in memory on the
smallest partition.
• The other partition is used to
probe the hash table.
Hash Join
• Both tables are split into as
many partitions as required,
using a full table scan.
• For each partition pair, a hash
table is built in memory on the
smallest partition.
• The other partition is used to
probe the hash table.
Types of Execution Plan Steps
• Data retrieval
• Joins and anti joins
• Sorts
• Temp table transformation
Sort Operations
• Sort unique (distinct, union)
SELECT
• Sort aggregate (count) DISTINCT last_name, first_name
• Sort group by FROM customers
WHERE full_name LIKE :b1;
• Hash group by
Plan
• Sort join -----------------------------------
• Sort order by SELECT STATEMENT
SORT UNIQUE
• Sort order by stopkey TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
Sort Operations SELECT *
FROM customers c
• Sort unique (distinct, union) WHERE c.creation_date > SYSDATE-30
• Sort aggregate (count) UNION
SELECT *
• Sort group by FROM customers c
WHERE c.balance < 5000;
• Hash group by
• Sort join Plan
-----------------------------------
• Sort order by SELECT STATEMENT
SORT UNIQUE
• Sort order by stopkey UNION
TABLE ACCESS FULL
TABLE ACCESS FULL
Sort Operations
• Sort unique (distinct, union)
SELECT
• Sort aggregate (count, sum) SUM ( d.revenue_amount )
• Sort group by FROM order_details d
WHERE d.customer_id = :b1;
• Hash group by
Plan
• Sort join -----------------------------------
• Sort order by SELECT STATEMENT
SORT AGGREGATE
• Sort order by stopkey TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
Sort Operations
• Sort unique (distinct, union)
SELECT
• Sort aggregate (count, sum) item_id, SUM(d.revenue_amount)
• Sort group by FROM order_details d
WHERE order_id > :b1
• Hash group by GROUP BY item_id;

• Sort join Plan

• Sort order by -----------------------------------
SELECT STATEMENT
• Sort order by stopkey SORT GROUP BY
TABLE ACCESS FULL
Sort Operations
• Sort unique (distinct, union)
SELECT
• Sort aggregate (count, sum) item_id, SUM(d.revenue_amount)
• Sort group by FROM order_details d
WHERE order_id > :b1
• Hash group by GROUP BY item_id;

• Sort join Plan

• Sort order by -----------------------------------
SELECT STATEMENT
• Sort order by stopkey HASH GROUP BY
TABLE ACCESS FULL
Sort Operations SELECT * FROM
orders o, orders o2
• Sort unique (distinct, union) WHERE
• Sort aggregate (count, sum) o.creation_date < o2.creation_date
AND o.id <> o2.id;
• Sort group by
Plan
• Hash group by -----------------------------------
• Sort join SELECT STATEMENT
MERGE JOIN
• Sort order by SORT JOIN
TABLE ACCESS FULL
• Sort order by stopkey FILTER
SORT JOIN
TABLE ACCESS FULL
Sort Operations
• Sort unique (distinct, union)
SELECT o.order_number
• Sort aggregate (count, sum) FROM orders o
• Sort group by WHERE o.customer_id = :b1
ORDER BY o.creation_date DESC;
• Hash group by
Plan
• Sort join -----------------------------------
• Sort order by SELECT STATEMENT
SORT ORDER BY
• Sort order by stopkey TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
Sort Operations SELECT * FROM
(
• Sort unique (distinct, union) SELECT * FROM orders
• Sort aggregate (count, sum) )
ORDER BY create_date

• Sort group by WHERE ROWNUM <= 10;

• Hash group by Plan

• Sort join -----------------------------------
SELECT STATEMENT
• Sort order by COUNT (STOPKEY)
VIEW
• Sort order by stopkey SORT (ORDER BY STOPKEY)
TABLE ACCESS FULL
Types of Execution Plan Steps
• Data retrieval
• Joins and anti joins
• Sorts
• Temp table transformation
Temp table transformation
• Temp table transformation is the operation in the execution plan
where Oracle stores the subquery results in a temporary table.
--------------------------------------------------
| Id | Operation | Name |
with q as ( --------------------------------------------------
select /*+ materialize */ | 0 | SELECT STATEMENT | |
* from customers | 1 | VIEW | |
| 2 | TEMP TABLE TRANSFORMATION | |
where country_id = 10 | 3 | LOAD AS SELECT | |
) |* 4 | TABLE ACCESS FULL | CUSTOMERS |
| 5 | VIEW | |
select from q; | 6 | TABLE ACCESS FULL | SYS_TEMP_0 |
--------------------------------------------------
Types of Execution Plan Steps
• Data retrieval
• Joins and anti joins
• Sorts
• Temp table transformation
• A lot more:
https://docs.oracle.com/en/dat
abase/oracle/oracle-
database/12.2/tgsql/reading-
execution-plans.html
To be continued…
Next Episode:
See you all next week

Thank you.