Ad Hoc User or Application Cost-based Data Dictionary Statistics Rule-based Execution Plan Asks the question: All people and their grades in a list giving sname and fname and grade SELECT fname, sname, grade FROM persons p, grades g WHERE p.GRADEID = g.GRADEID ; Is cursor in shared pool already? Which optimiser mode? Parser No Returned data set Re-use Yes

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: Parser Decomposes what has been passed and makes sense of it by: –verifying it to be correct in syntax –looking up any table and column definitions in the data dictionary to check for accuracy –Breaking the string up and looking for: –what is being selected, and is it distinct? –What are the prefixes all about? –What are the conditions (WHERE) –What sorts and grouping needs to be carried out? –Checking privileges

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: Parser Re-using SQL saves parsing overhead BUT: –Select * from Persons ; is not the same as: –Select * from PERSONS ; So adopt a naming convention and stick with it! However, by using bind variables: –Select * from Persons where personid=:pid ; IS the same whatever value is bound. So use bind variables wherever possible

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: Optimiser The optimiser determines the most efficient way to execute a SQL statement For any SQL statement there are a finite number of possible 'execution plans'. Best can be: –uses least resources to process all rows affected by the statement. –returns the first row of a statement the quickest

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: Optimiser First decision: How to decide what is efficient? Up until Oracle V7 the optimiser was Rule based (RBO). That is: –It chooses an execution plan based on the access paths available and the ranks of these access paths. –If there is more than one way to execute a SQL statement, RBO always uses the operation with the lower rank because this will, probably, execute faster

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: RBO

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: RBO The problem with the RBO approach is that it doesn’t recognise context as important: –“If there is more than one way to execute a SQL statement, RBO always uses the operation with the lower rank because this will, probably, execute faster” –Different data distributions could cause the actual ranking to be inaccurate in the first place. –It is quite possible that what is the most efficient access path today, will not be the most efficient next week, just because the data distribution has changed.

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: CBO From V7 onwards you can choose to use CBO CBO is a mathematical processor, a sort of expert system It calculates the cost of a SQL statement, based upon statistics, in terms of I/o This gets around the RBO problem of context But is only as good as the statistics And the assumptions made by the “expert” Adds both admin and process overhead because of the need to Analyze all tables regularly. –ANALYZE TABLE persons COMPUTE STATISTICS;

School of Computing and Management Sciences © Sheffield Hallam University Query efficiency: Optimiser For an Oracle instance you can choose which with the OPTIMZER_MODE init.ora param: ALL_ROWS, FIRST_ROWS, CHOOSE, RULE At the query level you can override using a hint after the SELECT: Select /*+FULL*/ Fname, Sname, Grade…. –Forces a full table scan, even if optimser thinks using an index would be better - well most of the time! –The Optimiser is empowered to ignore hints!

School of Computing and Management Sciences © Sheffield Hallam University SET AUTOTRACE ON STAT* SQL> select count(sname) from persons; COUNT(SNAME) Statistics recursive calls 4 db block gets 20 consistent gets 0 physical reads 0 redo size 372 bytes sent via SQL*Net to client 425 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed SQL> *NOTE: you must have the PLUSTRACE role granted to you and a PLAN_TABLE table created in your schema.

-- log in as the test user and change --the settings connect a_user/a_password ; SET TERMOUT OFF SET AUTOTRACE ON STAT --get rid of any existing Person drop table Person ; --create the grade table and pop some data in it START create_grades -- first do the stuff with a foreign key -- create a Person table, with foreign key START create_forkey --start the timer Timing START forkey_ins --run the insert script and then commit START person_inserts Commit ; --spool output to a file SPOOL testresults_withFK.txt -- CONTINUED --stop timer Timing STOP forkey_ins --now do the update test Timing START forkey_update START person_update Commit ; Timing STOP forkey_update SPOOL off SET TERMOUT ON

Garbage!

School of Computing and Management Sciences © Sheffield Hallam University Testing Always remember to run tests many times, but especially remember: –the first time a query runs is likely to take longer than subsequent runs because there is no need to parse if the cursor is still in SGA –Timing, in particular, can be dramatically impacted by what else the database server is doing

Using Explain Plan Execution plan –Whichever optimiser is used, its final output will be an execution plan. An execution plan includes access methods for each table that the statement accesses and the ordering of any joins. –The explain plan displays execution plans chosen by the Oracle optimiser, listing the optimiser decisions. –At a base level a user needs to have created a table called PLAN_TABLE by running the script: ORA_HOME\rdbms\admin\utlxplan.sql. –The data from an explain is stored in that table. You then use some utility to read that table. Oracle provide a script: ORA_HOME\rdbms\admin\UTLXPLS.SQL.

Using Explain Plan EXPLAIN PLAN FOR SELECT a.composer, b.cdid, b.title FROM composers a, cds b WHERE a.composer like 'V%' AND b.composerid = a.composerid ORDER BY a.composer ;

Using Explain Plan

School of Computing and Management Sciences © Sheffield Hallam University Old Wives Tales “ The driving table is the last table in the FROM list ” This is only true if: –the optimiser can’t decide which table to drive from based on the WHERE clause “Unions GOOD, Ors BAD” –IT Depends! (stock tuning response) Primarily: is there an index?

School of Computing and Management Sciences © Sheffield Hallam University Union/OR and Indexing set autotrace on stat set timing on spool uniontest drop index i_grade ; select personid, sname from persons where sname like 'SA%' or gradeid = 2 ; select personid, sname from persons where sname like 'SA%' UNION ALL select personid, sname from persons where gradeid = 2 ; create index i_grade on persons(gradeid) ; select personid, sname from persons where sname like 'SA%' or gradeid = 2 ; select personid, sname from persons where sname like 'SA%' UNION ALL select personid, sname from persons where gradeid = 2 ; spool off

School of Computing and Management Sciences © Sheffield Hallam University Union/OR and Indexing OR, no Index Elapsed: 00:00: db block gets 72 consistent gets 7 sorts (memory) UNION, no Index Elapsed: 00:00: db block gets 62 consistent gets 2 sorts (memory) OR, with Index Elapsed: 00:00: db block gets 42 consistent gets 3 sorts (memory) UNION, with Index Elapsed: 00:00: db block gets 62 consistent gets 2 sorts (memory) No IndexIndexed

School of Computing and Management Sciences © Sheffield Hallam University More Query efficiency Reduce the number of trips to the database –Example scenario: You need to pull the name back to a client application from Persons table for 2 people. –Do you: Write 2 selects Write a select using an IN Write a self join? -- Two distinct goes spool twogoes select sname, fname from persons where personid = 406 ; select sname, fname from persons where personid = 447 ; Select sname, fname from persons where personid in (406, 447) ; select a.sname, a.fname, b.sname, b.fname from persons a, persons b where a.personid = 406 and b.personid = 447 ;

School of Computing and Management Sciences © Sheffield Hallam University More efficiency tips Avoid HAVING if you can filter with WHERE –having clause filters only after all rows fetched Use Stored Procedures Client or Server processing of cursors?

More efficiency tips Test Test again.

School of Computing and Management Sciences © Sheffield Hallam University Further reading Corrigan and Garry, Oracle Performance Tuning, O’Reilly 1995 Cary V. Millsap, Performance Management: Myths & Facts, Oracle Corporation June 28, The Oracle documentation! (There is a whole section on Performance Tuning)