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. StreetZipDeptSalary 24142 24060 $ 50,000 $ 45,000 $ 33,000 $ 81,000 $ 44,000 $ 50,000 $ 45,000 $ 33,000 $ 81,000 $ 44,000 $ 50,000 $ 81,000 $ 44,000 Finc IT Actg RowID
Binary Tree Conway Harrington Lytle Johnson Bosworth FultonAdamsTrumanWatersRhinemanMatthews SmithDarlington PotterVarner
Binary Tree Index Conway1NN Harrington264 Lytle31312 Johnson4NN Bosworth571 Fulton6NN Adams7NN Truman8NN Waters9NN Rhineman10NN Matthews11NN Smith121415 Darlington1352 Potter141110 Varner1589 Conway Harrington Lytle Johnson Bosworth Fulton AdamsTrumanWaters RhinemanMatthews Smith Darlington Potter Varner BOF3 EOFN
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. StreetZipDeptSalary 24142 24060 $ 50,000 $ 45,000 $ 33,000 $ 81,000 $ 44,000 $ 50,000 $ 45,000 $ 33,000 $ 81,000 $ 44,000 $ 50,000 $ 81,000 $ 44,000 Finc IT Actg RowID NN 64 1312 NN 71 NN NN NN NN NN NN 1415 52 1110 89
Cluster (not cluster index) Conway1 Main St.24142$ 50,000Finc Database Page Conway Row from employees table Related Rows from Skills Table COBOL 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 hints Provide 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 RULEUses the rules based optimizer only. CHOOSE Uses the cost based optimizer if any statistics are available for the query tables. FIRST_ROWSUses 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_ROWSUses 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.
Analyzing Tables Generally, 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 | Or Analyze 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 Modes For 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 Plans Execution 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: /*+ HINT */
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?
EXAMPLE HINT (index use) Select /*+ FULL(hollywood.movies)*/ title, review from hollywood.movies where rating='PG' -- hints to not use an index Select /*+ INDEX(hollywood.movies) */ title, review from hollywood.movies where rating='NC-17' -- hints to use an index of Oracle's choice Select /*+ INDEX(hollywood.movies movies_rating)*/ title, review from hollywood.movies where rating='NC-17' -- hints to use a specific index
JOIN TYPE and DRIVING TABLE Which 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_genres where genre='Comedy' and movies.title = movie_genres.movie; Select * /*+ USE_MERGE*/ from movies, movie_genres where genre='Comedy' and movies.title = movie_genres.movie; Select * /*+ USE_HASH(movie_genres, movies) */ from movies, movie_genres where 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 1 Request: A list of all movie titles in alphabetic order by title Query 1 Select title from movies order by title; Examine the execution plan for the above query. What is interesting about this query of the MOVIES table?
Exercise 2 Request: Title and Rating of every movie that Tom Hanks has starred in. Query 1 Select title, rating from movies where title in (select movie from starred_in where actor='Tom Hanks'); Query 2 Select title, rating from movies, starred_in where movies.title = starred_in.movie and actor='Tom Hanks'; Which query is more efficient? Can you tune the other?
Exercise 3 Request: A list of Actors that are also Directors Query 1 Select name from actors intersect Select name from directors; Query 2 Select actors.name from actors, directors where 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 4 Request: 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 5 Query: 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 REC Connect 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?
Your consent to our cookies if you continue to use this website.