View
223
Download
0
Category
Tags:
Preview:
Citation preview
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?
Recommended