Performance Tuning

Database Tuning OptionsHardware Solution (determine bottleneck)More MemoryFaster or additional ProcessorsFaster Disk IO (possibly via RAID)More Network BandwidthSoftware SolutionDatabase/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 AccessConway1Harrington2Lytle3Johnson4Bosworth5Fulton6Adams7Truman8Waters9Rhineman10Matthews11Smith12Darlington13Potter14Varner15Name1 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.StreetZipDeptSalary241422414224142241422414224142241422414224142241422406024060240602406024060$ 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,000FincFincFincFincFincITITITITActgActgActgActgActgActgRowID

Binary TreeConwayHarringtonLytleJohnsonBosworthFultonAdamsTrumanWatersRhinemanMatthewsSmithDarlingtonPotterVarner

Worse Case and Average Search Moves1132731543156361277255851191,02310NodesWorse CaseAverage Case1.001.75Tree Depth2,047114,095128,1911316,3831432,7671565,53516131,07117262,14318524,287191,048,57520123456789101112131415161718192017.0018.0019.002.553.384.265.186.117.078.049.0310.0111.0112.0113.0014.0015.0016.00Worse CaseAverage Case1.001.503.507.5016.5031.5063.50127.50255.50Sequential SearchBalanced Full Binary Tree Search1371531631272555111,0232,0474,0958,19116,38332,76765,535131,071262,143524,2871,048,575511.501,023.502,047.504,095.508,191.5016,383.5032,767.5065,535.50131,071.50262,143.50524,287.50

Binary Tree IndexConway1NNHarrington264Lytle31312Johnson4NNBosworth571Fulton6NNAdams7NNTruman8NNWaters9NNRhineman10NNMatthews11NNSmith121415Darlington1352Potter141110Varner1589ConwayHarringtonLytleJohnsonBosworthFultonAdamsTrumanWatersRhinemanMatthewsSmithDarlingtonPotterVarnerBOF3EOFN

Cluster IndexConway1Harrington2Lytle3Johnson4Bosworth5Fulton6Adams7Truman8Waters9Rhineman10Matthews11Smith12Darlington13Potter14Varner15Name1 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.StreetZipDeptSalary241422414224142241422414224142241422414224142241422406024060240602406024060$ 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,000FincFincFincFincFincITITITITActgActgActgActgActgActgRowIDNN641312NN71NNNNNNNNNNNN141552111089

Cluster (not cluster index)Conway1 Main St.24142$ 50,000FincDatabase PageConwayConwayConwayConwayRow from employees tableRelated Rows from Skills TableCOBOLJAVAVBC #ExcellentGoodExcellentNovice

SQL Tuning GoalsDetermine 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 OptionsChange 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 tablesStore an Outline in the DB for given SQL statements

Oracle OptimizersAn 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 ModesRULEUses the rules based optimizer only.CHOOSE Uses the cost based optimizer if anystatistics are available for the query tables.FIRST_ROWSUses the cost based optimizer but biasesthe execution plan toward retrieving thefirst rows to the user as fast as possible.This is the default for the CHOOSE mode.ALL_ROWSUses 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 compute statistics | for all indexed columns |OrAnalyze table 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 ModesFor session:Alter session set optimizer_mode = Alter session set optimizer_mode = RULE

For Query:Select /*+ */ 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 Queryselect drivername, nickname, phonefrom drivers, performancewhere race='Daytona 500'and drivers.drivername=performance.driverintersectselect drivername, nickname, phonefrom drivers, performancewhere 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.

HINTSOPTIMIZER MODEUSE OF INDEXTYPE OF JOIN and DRIVING TABLEORDER OF JOINS

General Syntax is: /*+ HINT */

INDEX DECISIONShould 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?

EXAMPLE HINT (index use)Select /*+ FULL(hollywood.movies)*/ title, reviewfrom 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 ORDERSmall 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 titlefrom 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 moviefrom 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 genrefrom movie_genres, movies, starred_inwhere movie_genres.movie = movies.titleand starred_in.movie = movies.titleand 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?