ITEC

45

0

1

MODULE 4 DATABASE TUNINGSection 3 Application Performance

Fall 2

01

2

2

ITEC

45

0

OVERVIEW OF APPLICATION PERFORMANCE

Application Performance – Developer and DBA Shared Responsibilities

Tuning and optimizing SQL statement to maximize an application’s performance

Ensuring the application interacts with the DBMS appropriately and efficiently.

Fall 2

01

2

3

ITEC

45

0

DESIGNING APPLICATIONS FOR DATABASE

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 2

01

2

4

ITEC

45

0

OVERVIEW OF OPTIMIZER 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 2

01

2

5

ITEC

45

0

OPTIMIZER INFLUENCE FACTORS CPU and I/O costs Database statistics – one of DBA’s 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 2

01

2

6

ITEC

45

0

SQL TUNING TIPS

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 DBA’s

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 2

01

2

ITEC

45

0

7

MODULE 4 DATABASE TUNINGSection 4 Oracle SQL Query Optimization

Fall 2

01

2

8

ITEC

45

0

OPTIMIZING ORACLE QUERY PROCESSING

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 2

01

2

9

ITEC

45

0

ORACLE COST BASED OPTIMIZER

Fall 2

01

2

10

UNDERSTANDING STATISTICS

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 2

01

2IT

EC

45

0

11

ITEC

45

0

PROVIDING STATISTICS TO THE OPTIMIZER

The recommended approach is to allow Oracle database to automatically collect the statistics.

The job to collect statistics can be foundSQL> select owner, job_name, enabled, state, comments from

dba_scheduler_jobs;

To check that the statistics are indeed collectedSQL> select table_name , last_analyzed, num_rows from

dba_tables where owner = 'OE' ;

Oracle also collects the statistics on columnsSQL> select column_name, num_distinct from

dba_tab_col_statisticswhere owner = 'OE' and table_name = 'PRODUCT_DESCRIPTIONS';

Fall 2

01

2

12

ITEC

45

0

MANUALLY GATHERING STATISTICS

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 2

01

2

13

ITEC

45

0

EXECUTION PLAN (EXPLAIN PLAN)

A statement’s 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 2

01

2

14

ITEC

45

0

RUNNING EXPLAIN PLAN

Using autotrace utilities To generate the execution plan only and doesn’t execute

the query itselfSQL> set autotrace on explain

To show only the execution statistics for the SQL statementSQL> set autotrace on statistics

To show both the execution plan and execution statisticsSQL> set autotrace on

Using PLAN_TABLE To explain a SQL statement:

SQL> EXPLAIN PLAN FORSELECT last_name FROM employees;

This explains the plan into the PLAN_TABLE table. You can then select the execution plan from PLAN_TABLE.

Fall 2

01

2

15

ITEC

45

0

RUNNING EXPLAIN PLAN USING TOOLS

Using Oracle SQL Developer

Fall 2

01

2

Using Other Tools• TOAD• Many Others

16

ITEC

45

0

EXAMPLE OF EXECUTION PLAN An example of SQL statement

SQL> select i.product_id, i.product_name, d.translated_name from oe.product_information i, oe.product_descriptions dwhere 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 2

01

2

17

ITEC

45

0

EXECUTION PLAN USING SQL DEVELOPER Fa

ll 20

12

18

ITEC

45

0

WRAP UP

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 2

01

2