Performance Tuning

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)

Sequential Table Access

Conway1

Harrington2

Lytle3

Johnson4

Bosworth5

Fulton6

Adams7

Truman8

Waters9

Rhineman10

Matthews11

Smith12

Darlington13

Potter14

Varner15

Name

1 Main St.

12 Elm Ave.

11 Southern St.

12 Elm Ave.

3 Main St.

18 Oak Rd.

14 Pine Ct.

11 Pine Ct.

18 Main St.

23 Main St.

31 Elm Ave.

2 Oak Rd.

8 Ridge Rd.

5 Elm Ave.

1 Elm Ave.

Street Zip Dept Salary

24142

24142

24142

24142

24142

24142

24142

24142

24142

24142

24060

24060

24060

24060

24060

$ 50,000

$ 50,000

$ 45,000

$ 33,000

$ 81,000

$ 44,000

$ 50,000

$ 50,000

$ 45,000

$ 33,000

$ 81,000

$ 44,000

$ 50,000

$ 81,000

$ 44,000

Finc

Finc

Finc

Finc

Finc

IT

IT

IT

IT

Actg

Actg

Actg

Actg

Actg

Actg

RowID

Binary Tree

Conway

Harrington

Lytle

Johnson

Bosworth

FultonAdams Truman WatersRhinemanMatthews

SmithDarlington

Potter Varner

Worse Case and Average Search Moves

113273

154315636

127725585119

1,02310

Nodes Worse Case Average Case

1.001.75

Tree Depth

2,047114,095128,19113

16,3831432,7671565,53516

131,07117262,14318524,28719

1,048,57520

123456789

1011121314151617181920

17.0018.0019.00

2.553.384.265.186.117.078.049.03

10.0111.0112.0113.0014.0015.0016.00

Worse Case Average Case

1.001.503.507.50

16.5031.5063.50

127.50255.50

Sequential SearchBalanced Full Binary Tree Search

137

153163

127255511

1,0232,0474,0958,191

16,38332,76765,535

131,071262,143524,287

1,048,575

511.501,023.502,047.504,095.508,191.50

16,383.5032,767.5065,535.50

131,071.50262,143.50524,287.50

Binary Tree Index

Conway1 N N

Harrington2 6 4

Lytle3 13 12

Johnson4 N N

Bosworth5 7 1

Fulton6 N N

Adams7 N N

Truman8 N N

Waters9 N N

Rhineman10 N N

Matthews11 N N

Smith12 14 15

Darlington13 5 2

Potter14 11 10

Varner15 8 9

Conway

Harrington

Lytle

Johnson

Bosworth

Fulton

Adams Truman Waters

RhinemanMatthews

SmithDarlington

Potter

Varner

BOF 3

EOF N

Cluster Index

Conway1

Harrington2

Lytle3

Johnson4

Bosworth5

Fulton6

Adams7

Truman8

Waters9

Rhineman10

Matthews11

Smith12

Darlington13

Potter14

Varner15

Name

1 Main St.

12 Elm Ave.

11 Southern St.

12 Elm Ave.

3 Main St.

18 Oak Rd.

14 Pine Ct.

11 Pine Ct.

18 Main St.

23 Main St.

31 Elm Ave.

2 Oak Rd.

8 Ridge Rd.

5 Elm Ave.

1 Elm Ave.

Street Zip Dept Salary

24142

24142

24142

24142

24142

24142

24142

24142

24142

24142

24060

24060

24060

24060

24060

$ 50,000

$ 50,000

$ 45,000

$ 33,000

$ 81,000

$ 44,000

$ 50,000

$ 50,000

$ 45,000

$ 33,000

$ 81,000

$ 44,000

$ 50,000

$ 81,000

$ 44,000

Finc

Finc

Finc

Finc

Finc

IT

IT

IT

IT

Actg

Actg

Actg

Actg

Actg

Actg

RowID

N N

6 4

13 12

N N

7 1

N N

N N

N N

N N

N N

N N

14 15

5 2

11 10

8 9

Cluster (not cluster index)

Conway 1 Main St. 24142 $ 50,000Finc

Database Page

Conway

Conway

Conway

Conway

Row from employees table

Related Rows from Skills TableCOBOL

JAVA

VB

C #

Excellent

Good

Excellent

Novice

SQL Tuning Goals• Determine Optimal Execution Plan for each

SQL statement.• Lock down the execution plan for each

statement . (careful here)• Maintain Indexes, Perform Routine Table

Analysis, and otherwise maintain instance in a fashion that supports the execution plans.

• Locate problematic SQL statements and retune (implies monitoring)

SQL Tuning Options• Change SQL syntax (not completely stable, may want hints or outlines also)

The structure of an SQL query can effect the execution plan of that query. In oracle this is particularly true when the rule based optimizer is being used.

• Add Optimizer hintsProvide optimizer hints in the SQL that indicate:

- which optimizer mode to use- whether or not to use available indexes

- the order in which tables are to be joined - the method by which Oracle should join the tables

• Store an Outline in the DB for given SQL statements

Oracle Optimizers

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 thefirst rows to the user as fast as possible.This is the default for the CHOOSE mode.

• ALL_ROWS Uses the cost based optimizer but biasesthe execution plan toward minimizing thetotal retrieval time, even if that means a longer delay before the first rows are returnedto the user.

Analyzing TablesGenerally, the cost based optimizer provides better performance. For

the cost based optimizer to run statistics on tables must be periodically gathered. This can be done with either:

• Analyze table <tablename> compute statistics | for all indexed columns |

Or• Analyze table <tablename> estimate statistics | for all indexed columns |

Estimating statistics forces Oracle to make estimates based on only a partial examination of tables rows. This saves time when there is a need to gather statistics on very large tables. DBAs try to schedule table analysis during off-peak hours to avoid performance issues.

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;

Examining Execution PlansExecution Plans can be captured and examined by using either the Oracle EXPLAIN PLAN command which operates on a single query or by using the Oracle AUTOTRACE feature which turns on plan tracing for all queries. To control autotrace use one of the following:– Set autotrace on (gives plan, performance stats, and query results)– Set autotrace traceonly (gives plan and perf. stats but not query results)– Set autotrace on explain (gives plan and query results)– Set autotrace on statistics (gives performances stats and query results)– Set autotrace off (turns autotrace off)– Set timing on (times each query but is effect by screen delay so repress

query results)

Neither EXPLAIN PLAN or autotrace will work unless you first create a table in your schema to hold the execution plan steps. To create the plan_table table run \\neelix\dropbox\itec\itec340\_instructorFiles\scripts\utlxplan.sql

Sample Query

select drivername, nickname, phone

from drivers, performance

where race='Daytona 500'

and drivers.drivername=performance.driver

intersect

select drivername, nickname, phone

from drivers, performance

where race='Brickyard 400'

and drivers.drivername=performance.driver

* Retrieves driver info for those who drove in both races

Execution Plan for Sample Query 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 INTERSECTION 2 1 SORT (UNIQUE) 3 2 NESTED LOOPS 4 3 TABLE ACCESS (FULL) OF 'PERFORMANCE' 5 3 TABLE ACCESS (BY INDEX ROWID) OF 'DRIVERS' 6 5 INDEX (UNIQUE SCAN) OF 'DRIVERS_DRIVERNAME_PK' (UN IQUE) 7 1 SORT (UNIQUE) 8 7 NESTED LOOPS 9 8 TABLE ACCESS (FULL) OF 'PERFORMANCE' 10 8 TABLE ACCESS (BY INDEX ROWID) OF 'DRIVERS' 11 10 INDEX (UNIQUE SCAN) OF 'DRIVERS_DRIVERNAME_PK' (UN IQUE)

• The second column shows the parent process of any subprocess. Execution order is generally from The HIGHEST number is in the second column to the lowest number with some exceptions such as nested loops. For nested loops the table access order is from top to bottomFULL table access indicates a sequential read of the entire table. A scan indicates the use of an index. Access by ROWID is direct access to a table row after an index has been consulted to obtain the ROWID.

HINTS

• OPTIMIZER MODE

• USE OF INDEX

• TYPE OF JOIN and DRIVING TABLE

• ORDER OF JOINS

General Syntax is: <COMMAND> /*+ HINT */

INDEX DECISION

Should the Index Be used?

- what is table size

- what is column(s) selectivity

(if you are selecting >20%

don’t bother with the index)

Is the optimizer making the correct decision?

EXAMPLE HINT (index use)Select /*+ FULL(hollywood.movies)*/ title, review

from hollywood.movieswhere rating='PG' -- hints to not use an index

Select /*+ INDEX(hollywood.movies) */title, reviewfrom hollywood.movieswhere rating='NC-17' -- hints to use an index of Oracle's choice

Select /*+ INDEX(hollywood.movies movies_rating)*/ title, reviewfrom hollywood.movieswhere rating='NC-17' -- hints to use a specific index

JOIN TYPE and DRIVING TABLEWhich Join?

- Large tables are best joined with Nested Loops- Nested Loops return first rows fastest- A Sort Merge gives the fasted total time for small tables- A Hash Merge on Small to Medium tables will cause the least I/O but be more processor intensive

Driving Table for Nested Loops- Larger table or table with least selectivity should be Driving Table- Avoid Full Scans on Inner Table (if only one table is indexed make it the inner table)

Is the optimizer making the correct decision?

EXAMPLE HINT (join type)

Select * /*+ USE_NL(movie_genres)*/ from movies, movie_genreswhere genre='Comedy'and movies.title = movie_genres.movie;

Select * /*+ USE_MERGE*/ from movies, movie_genreswhere genre='Comedy'and movies.title = movie_genres.movie;

Select * /*+ USE_HASH(movie_genres, movies) */ from movies, movie_genreswhere genre='Comedy'and movies.title = movie_genres.movie;

JOIN ORDER

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

Under RULE optimization tables are joined left to right as they appear in the FROM clause.

Sample Query Performance Stats Statistics---------------------------------------------------------- 0 recursive calls 8 db block gets 18 consistent gets 2 physical reads 0 redo size 319 bytes sent via SQL*Net to client 313 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 0 rows processed

Exercise 1Request: A list of all movie titles in alphabetic order by title

Query 1 Select title

from moviesorder by title;

Examine the execution plan for the above query.

What is interesting about this query of the MOVIES table?

Exercise 2Request: Title and Rating of every movie that Tom Hanks has starred in.

Query 1Select title, ratingfrom movieswhere title in (select movie

from starred_inwhere actor='Tom Hanks');

Query 2Select title, ratingfrom movies, starred_inwhere movies.title = starred_in.movieand actor='Tom Hanks';

Which query is more efficient? Can you tune the other?

Exercise 3Request: A list of Actors that are also Directors

Query 1 Select name from actors intersect Select name from directors;

Query 2Select actors.namefrom actors, directorswhere actors.name = directors.name;

Which query is more efficient? Which requires less DISK I/O?Which do you think requires less Memory?Which has the fastest clock time?

Exercise 4Request: A non-repeating list of the genres of movies that Tom Hanks has starred in.

select distinct genre

from movie_genres, movies, starred_in

where movie_genres.movie = movies.title

and starred_in.movie = movies.title

and actor='Tom Hanks';

Tune the above query. Hint: I had success with hints, indexing, and restructuring

Exercise 5Query:

Select * from movies where upper(title) = 'ALIENS';

Examine the execution plan for this query.

What is wrong?

How can it be fixed/tuned?

Exercise 6 (OR vs UNION part 1)Create a schema on your server named RECConnect to that account@\\neelix\oracle\scripts\utlxplan -- get a plan table@\\neelix\oracle\scripts\admin\random -- get random package@\\neelix\oracle\scripts\admin\makesales – make tables@\\neelix\oracle\scripts\admin\populatesales -- takes a minute

Query 1: Select * from salesorders where sonum=15000 or sonum=22000;

Query 2: Select * from salesorders where sonum=15000 UNION Select * from salesorders where sonum=22000; Which query is more efficient?

Exercise 7 (OR vs UNION part 2)

ALTER TABLE salesorders ADD CONSTRAINT salesorders_sonum_pk PRIMARY KEY(sonum);ANALYZE TABLE salesorders COMPUTE STATISTICS FOR ALL INDEXED COLUMNS;

Query 1: Select * from salesorders where sonum=15000 or sonum=22000;

Query 2: Select * from salesorders where sonum=15000 UNION Select * from salesorders where sonum=22000; Which query is more efficient?

Exercise 8 (OR vs UNION part 3)

CREATE INDEX salesorders_custid ON salesorders(custid);ANALYZE TABLE salesorders COMPUTE STATISTICS FOR ALL INDEXED COLUMNS;

Query 1: Select * from salesorders where sonum=15000 or custid=321;

Query 2: Select * from salesorders where sonum=15000 UNION Select * from salesorders where custid=321; Which query is more efficient?