Ten SQL Tips

Download Ten SQL Tips

Post on 25-Sep-2015

216 views

Category:

Documents

1 download

Embed Size (px)

DESCRIPTION

SQL tips

TRANSCRIPT

  • Top tips for Oracle SQL tuningGuy HarrisonSenior Software Architect,Quest Software

    BUY QUEST PRODUCTSBUY GUYS BOOKBUY QUEST PRODUCTS

  • Top 10 Oracle SQL tuning tipsDesign and develop with performance in mindEstablish a tuning environmentIndex wiselyReduce parsingTake advantage of Cost Based OptimizerAvoid accidental table scansOptimize necessary table scansOptimize joinsUse array processingConsider PL/SQL for tricky SQL

  • Hint #1: Design and develop with performance in mindExplicitly identify performance targets

    Focus on critical transactionsTest the SQL for these transactions against simulations of production dataMeasure performance as early as possible

    Consider prototyping critical portions of the applications

    Consider de-normalization and other performance by design features early on

  • Hint #2: Establish a tuning and development environment A significant portion of SQL that performs poorly in production was originally crafted against empty or nearly empty tables.

    Make sure you establish a reasonable sub-set of production data that is used during development and tuning of SQL

    Make sure your developers understand EXPLAIN PLAN and tkprof, or equip them with commercial tuning tools.

  • Understanding SQL tuning toolsThe foundation tools for SQL tuning are:

    The EXPLAIN PLAN commandThe SQL Trace facilityThe tkprof trace file formatter

    Effective SQL tuning requires either familiarity with these tools or the use of commercial alternatives such as SQLab

  • EXPLAIN PLANThe EXPLAIN PLAN reveals the execution plan for an SQL statement.

    The execution plan reveals the exact sequence of steps that the Oracle optimizer has chosen to employ to process the SQL.

    The execution plan is stored in an Oracle table called the plan table

    Suitably formatted queries can be used to extract the execution plan from the plan table.

  • A simple EXPLAIN PLANSQL> EXPLAIN PLAN FOR select count(*) from sales where product_id=1;Explained.

    SQL> SELECT RTRIM (LPAD (' ', 2 * LEVEL) || RTRIM (operation) ||' '||RTRIM (options) || ' ' || object_name) query_plan 2 FROM plan_table 3 CONNECT BY PRIOR id = parent_id 4* START WITH id = 0

    QUERY_PLAN-------------------------------------------- SELECT STATEMENT SORT AGGREGATE TABLE ACCESS FULL SALES

  • Interpreting EXPLAIN PLANThe more heavily indented an access path is, the earlier it is executed.

    If two steps are indented at the same level, the uppermost statement is executed first.

    Some access paths are joined such as an index access that is followed by a table lookup.

  • A more complex EXPLAIN PLANSELECT STATEMENT VIEW SYS_DBA_SEGS UNION-ALL NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS VIEW SYS_OBJECTS UNION-ALL TABLE ACCESS FULL TAB$ TABLE ACCESS FULL TABPART$ TABLE ACCESS FULL CLU$ TABLE ACCESS FULL IND$ TABLE ACCESS FULL INDPART$ TABLE ACCESS FULL LOB$ TABLE ACCESS FULL TABSUBPART$ TABLE ACCESS FULL INDSUBPART$ TABLE ACCESS FULL LOBFRAG$ TABLE ACCESS BY INDEX ROWID OBJ$ INDEX UNIQUE SCAN I_OBJ1 TABLE ACCESS CLUSTER SEG$ INDEX UNIQUE SCAN I_FILE#_BLOCK# TABLE ACCESS BY INDEX ROWID FILE$ INDEX UNIQUE SCAN I_FILE2 TABLE ACCESS CLUSTER TS$ INDEX UNIQUE SCAN I_TS# TABLE ACCESS CLUSTER USER$ INDEX UNIQUE SCAN I_USER# NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL UNDO$ TABLE ACCESS BY INDEX ROWID FILE$ INDEX UNIQUE SCAN I_FILE2 TABLE ACCESS CLUSTER SEG$ INDEX UNIQUE SCAN I_FILE#_BLOCK# TABLE ACCESS CLUSTER TS$ INDEX UNIQUE SCAN I_TS# TABLE ACCESS CLUSTER USER$ INDEX UNIQUE SCAN I_USER# NESTED LOOPS NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL FILE$ TABLE ACCESS CLUSTER SEG$ INDEX RANGE SCAN I_FILE#_BLOCK# TABLE ACCESS CLUSTER TS$ INDEX UNIQUE SCAN I_TS# TABLE ACCESS CLUSTER USER$ INDEX UNIQUE SCAN I_USER#

  • SQL_TRACE and tkprofALTER SESSION SET SQL_TRACE TRUE causes a trace of SQL execution to be generated.

    The TKPROF utility formats the resulting output.

    Tkprof output contains breakdown of execution statistics, execution plan and rows returned for each step. These stats are not available from any other source.

    Tkprof is the most powerful tool, but requires a significant learning curve.

  • Tkprof output count2 cpu3 elapsed4 disk5 query6 current7 rows8------ ------ ------ -------- ------- -------- -------- ------Parsea 1d 0.02 0.01 0 0 0 0Executeb 1e 0.00 0.00 0 0 0 0Fetchc 20j 141.10 141.65 1237 1450011 386332 99i------ ------ ------ -------- ------- -------- -------- ------total 22 141.12 141.66 1237k 1450011f 386332g 99hRowsl Execution Planm------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: CHOOSE 99 FILTER 96681 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'CUSTOMERS' 96582 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'EMPLOYEES'

  • Using SQLabBecause EXPLAIN PLAN and tkprof are unwieldy and hard to interpret, third party tools that automate the process and provide expert advice improve SQL tuning efficiency.

    The Quest SQLab product:

    Identifies SQL your database that could benefit from tuningProvides a sophisticated tuning environment to examine, compare and evaluate execution plans.Incorporates an expert system to advise on indexing and SQL statement changes

  • SQLab SQL tuning labDisplay execution plan in a variety of intuitive waysProvide easy access to statistics and other useful dataModel changes to SQL and immediately see the results

  • SQLab Expert AdviceSQLab provides specific advice on how to tune an SQL statement

  • SQLab SQL trace integration

    SQLab can also retrieve the execution statistics that are otherwise only available through tkprof

  • Hint #3: Index wiselyIndex to support selective WHERE clauses and join conditions

    Use concatenated indexes where appropriate

    Consider overindexing to avoid table lookups

    Consider advanced indexing optionsHash ClustersBit mapped indexesIndex only tables

  • Effect of adding columns to a concatenated indexNovice SQL programmers often are satisfied if the execution plan shows an indexMake sure the index has all the columns required

  • Bit-map indexesContrary to widespread belief, can be effective when there are many distinct column valuesNot suitable for OLTP however

  • Hint #4: Reduce parsingUse bind variablesBind variables are key to application scalabilityIf necessary in 8.1.6+, set cursor CURSOR_SHARING to FORCE

    Reuse cursors in your application codeHow to do this depends on your development language

    Use a cursor cacheSetting SESSION_CACHED_CURSORS (to 20 or so) can help applications that are not re-using cursors

  • Hint #5: Take advantage of the Cost Based OptimizerThe older rule based optimizer is inferior in almost every respect to the modern cost based optimizer

    Using the cost based optimizer effectively involves:Regular collection of table statistics using the ANALYZE or DBMS_STATS commandUnderstand hints and how they can be used to influence SQL statement executionChoose the appropriate optimizer mode: FIRST_ROWS is best for OLTP applications; ALL_ROWS suits reporting and OLAP jobs

  • Hint #6: Avoid accidental tablescansTablescans that occur unintentionally are a major source of poorly performing SQL. Causes include:

    Missing IndexUsing !=, or NOTUse inclusive range conditions or IN listsLooking for values that are NULLUse NOT NULL values with a default valueUsing functions on indexed columnsUse functional indexes in Oracle8i

  • Hint #7: Optimize necessary table scansThere are many occasions where a table scan is the only option. If so:Consider parallel query optionTry to reduce size of the tableAdjust PCTFREE and PCTUSEDRelocate infrequently used long columns or BLOBsRebuild when necessary to reduce the high water markImprove the caching of the tableUse the CACHE hint or table propertyImplement KEEP and RECYCLE pools Partition the table (if you really seek a large subset of data)Consider the fast full index scan

  • Fast full index scan performanceUse when you must read every row, but not every columnCounting the rows in a table is a perfect example

  • Hint #8: Optimize joinsPick the best join methodNested loops joins are best for indexed joins of subsetsHash joins are usually the best choice for big joinsPick the best join orderPick the best driving tableEliminate rows as early as possible in the join orderOptimize special joins when appropriateSTAR joins for data-warehousing applicationsSTAR_TRANSFORMATION if you have bitmap indexesANTI-JOIN methods for NOT IN sub-queriesSEMI-JOIN methods for EXISTS sub-queriesProperly index CONNECT BY hierarchical queries

  • Oracle 8 semi-joinsOptimizes queries using EXISTS where there is no supporting index

    select * from customers c where exists (select 1 from employees e where e.surname=c.contact_surname and e.firstname=c.contact_firstname a