1. M ODULE 4 D ATABASE T UNING Section 3 Application Performance 1 ITEC 450 Fall 2012

2. O VERVIEW OF A PPLICATION P ERFORMANCE Application Performance – Developer and DBA Shared Responsibilities Tuning and optimizing SQL statement to maximize an applications performance Ensuring the application interacts with the DBMS appropriately and efficiently. Fall 2012 2 ITEC 450

3. D ESIGNING A PPLICATIONS FOR D ATABASE For relational database, application design should be for relational access. Type of SQL – planned or not, dynamic or static, embedded or stand-alone Programming language – any features can be explored for database access performance Transaction design and processing Locking strategy Commit strategy Batch processing or Online processing Fall 2012 3 ITEC 450

4. O VERVIEW OF O PTIMIZER The optimizer is the heart of a DBMS, and is an inference engine responsible for determining the most efficient means of accessing the specified data. Each DBMS also provides techniques that you can use to influence the optimizer perform its job better. The query optimizer performs the following operations for each SQL statement: Evaluation of expressions and conditions Statement transformation Choice of optimizer goals – batch for best throughput, online for best response time Choice of access paths Choice of join orders Fall 2012 4 ITEC 450

5. O PTIMIZER I NFLUENCE F ACTORS CPU and I/O costs Database statistics – one of DBAs main responsibilities. You can use ANALYZE TABLE in Oracle, or utilities. Query analysis – involved objects and conditions Joins – how to combine the outputs from each table in the most efficient manner Access path choices Full table scans – read all rows and filters out those that do not meet the selection criteria Indexed access – retrieve by traversing the index Rowid scans – fastest way to retrieve a single row, as rowid specifies the datafile, data block and the location of the row in that block Hashed access – access based on a hash value, similar to indexed access Fall 2012 5 ITEC 450

6. SQL T UNING T IPS SQL tuning is a complicated task that requires a full-length book of its own. KISS principle: Keep It Short and Simple. Retrieve only what is needed Judicious use of LIKE – avoid leading wild-card (%) Beware of code generators – automatically created query statements from a tool can be a nightmare to DBAs Goals for tuning: Reduce the workload – for example to create or use an index Balance the workload – adjust query running time to avoid peak usage Parallelize the workload – for large amounts of data in data warehouse queries Fall 2012 6 ITEC 450

7. M ODULE 4 D ATABASE T UNING Section 4 Oracle SQL Query Optimization 7 ITEC 450 Fall 2012

8. O PTIMIZING O RACLE Q UERY P ROCESSING Query processing is the transformation of your SQL statement into an efficient execution plan to return the requested data from the database. Parsing – checking the syntax and semantics of the SQL statements Optimization – using a cost-based optimizer (CBO) to choose the best access method for retrieving data for the tables and indexes referred to in the query Query rewrite – converting into an abstract logical query plan Execution plan generation phase – permutation of various operations, orders, algorithms, etc. Query execution – executing the physical query plan Fall 2012 8 ITEC 450

9. O RACLE C OST B ASED O PTIMIZER Fall 2012 9 ITEC 450

10. U NDERSTANDING S TATISTICS Optimizer statistics are a collection of data: Table statistics Number of rows Number of blocks Average row length Column statistics Number of distinct values in column Number of nulls in column Data distribution (histogram) Extended statistics Index statistics Number of leaf blocks Levels Clustering factor System statistics I/O performance and utilization CPU performance and utilization Fall 2012 10 ITEC 450

11. P ROVIDING S TATISTICS TO THE O PTIMIZER The recommended approach is to allow Oracle database to automatically collect the statistics. The job to collect statistics can be found SQL> select owner, job_name, enabled, state, comments from dba_scheduler_jobs; To check that the statistics are indeed collected SQL> select table_name, last_analyzed, num_rows from dba_tables where owner = 'OE' ; Oracle also collects the statistics on columns SQL> select column_name, num_distinct from dba_tab_col_statistics where owner = 'OE' and table_name = 'PRODUCT_DESCRIPTIONS'; Fall 2012 11 ITEC 450

12. M ANUALLY G ATHERING S TATISTICS Because the automatic optimizer statistics collection runs during maintenance windows, the statistics on tables which are significantly modified throughout the day may become stale. Volatile tables that are being deleted and rebuilt Objects with large bulk loads Manual Statistics Gathering Using the dbms_stats utility, for example: SQL> exec dbms_stats.gather_schema_stats( - ownname => 'SCOTT', - options => 'GATHER AUTO', - estimate_percent => dbms_stats.auto_sample_size, - method_opt => 'for all columns size repeat', - degree => 34 ) Old-fashion for backward compatibility – Analyze table Fall 2012 12 ITEC 450

13. E XECUTION P LAN (E XPLAIN P LAN ) A statements execution plan is the sequence of operations Oracle performs to run the statement. The row source tree is the core of the execution plan. It shows the following information: An ordering of the tables referenced by the statement An access method for each table mentioned in the statement A join method for tables affected by join operations in the statement Data operations like filter, sort, or aggregation Fall 2012 13 ITEC 450

14. R UNNING E XPLAIN P LAN Using autotrace utilities To generate the execution plan only and doesnt execute the query itself SQL> set autotrace on explain To show only the execution statistics for the SQL statement SQL> set autotrace on statistics To show both the execution plan and execution statistics SQL> set autotrace on Using PLAN_TABLE To explain a SQL statement: SQL> EXPLAIN PLAN FOR SELECT last_name FROM employees; This explains the plan into the PLAN_TABLE table. You can then select the execution plan from PLAN_TABLE. Fall 2012 14 ITEC 450

15. R UNNING E XPLAIN P LAN U SING T OOLS Using Oracle SQL Developer Fall 2012 15 ITEC 450 Using Other Tools TOAD Many Others

16. E XAMPLE OF E XECUTION P LAN An example of SQL statement SQL> select i.product_id, i.product_name, d.translated_name from oe.product_information i, oe.product_descriptions d where i.product_id = d.product_id and rownum < 5; The execution plan is 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=4 Bytes=228) 1 0 COUNT (STOPKEY) 2 1 NESTED LOOPS (Cost=6 Card=4 Bytes=228) 3 2 TABLE ACCESS (FULL) OF 'PRODUCT_DESCRIPTIONS' (TABLE)(Cost=2 Card=4 Bytes=148) 4 2 TABLE ACCESS (BY INDEX ROWID) OF 'PRODUCT_INFORMATION (TABLE) (Cost=1 Card=1 Bytes=20) 5 4 INDEX (UNIQUE SCAN) OF 'PRODUCT_INFORMATION_PK' (INDEX (UNIQUE)) (Cost=0 Card=1) Fall 2012 16 ITEC 450

17. E XECUTION P LAN U SING SQL D EVELOPER Fall 2012 17 ITEC 450

18. W RAP U P Assignment 3-1-4: Lab4: Query Optimization Creation of execution plans Review and interpretation of execution Analysis of the differences between the two execution plans Clearly presented "Lessons Learned" section Fall 2012 18 ITEC 450