Download Week 11 (11/13/12): Lecture Notes

Fall 2012
ITEC 450
MODULE 4
DATABASE TUNING
1
Section 3 Application Performance
OVERVIEW OF APPLICATION
PERFORMANCE
Fall 2012
ITEC 450
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.
2
DESIGNING APPLICATIONS FOR DATABASE
Fall
2012
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
ITEC 450
3
OVERVIEW OF OPTIMIZER





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
ITEC 450

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:
2012

Fall

4
OPTIMIZER INFLUENCE FACTORS


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
ITEC 450

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
2012

Fall


5
SQL TUNING TIPS
Fall
ITEC 450
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
2012
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:

6
Fall
2012
ITEC 450
MODULE 4
DATABASE TUNING
7
Section 4 Oracle SQL Query Optimization
OPTIMIZING ORACLE QUERY PROCESSING
Fall 2012
ITEC 450
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
8
ORACLE COST BASED OPTIMIZER
Fall 2012
ITEC 450
9
UNDERSTANDING STATISTICS
Table statistics



Column statistics





Number of distinct values in column
Number of nulls in column
Data distribution (histogram)
Extended statistics
Index statistics




Number of rows
Number of blocks
Average row length
ITEC 450

2012

Fall
Optimizer statistics are a collection of data:
Number of leaf blocks
Levels
Clustering factor
System statistics


I/O performance and utilization
CPU performance and utilization
10
PROVIDING STATISTICS TO THE OPTIMIZER
ITEC 450

2012
SQL> select owner, job_name, enabled, state, comments from
dba_scheduler_jobs;
Fall
The recommended approach is to allow Oracle
database to automatically collect the statistics.
 The job to collect statistics can be found
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';
11
MANUALLY GATHERING STATISTICS
Fall
2012
ITEC 450
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
12
EXECUTION PLAN (EXPLAIN PLAN)
Fall
2012
ITEC 450
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
13
RUNNING EXPLAIN PLAN
SQL> set autotrace on explain

To show only the execution statistics for the SQL statement
ITEC 450
To generate the execution plan only and doesn’t execute the
query itself
2012

Fall
Using autotrace utilities
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.
14
RUNNING EXPLAIN PLAN USING TOOLS
Fall
2012
Using Oracle SQL Developer
ITEC 450
Using Other Tools
•
•
TOAD
Many Others
15
EXAMPLE OF EXECUTION PLAN

The execution plan is
0
1
2
3
4
5
SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=4
Bytes=228)
0 COUNT (STOPKEY)
1 NESTED LOOPS (Cost=6 Card=4 Bytes=228)
2
TABLE ACCESS (FULL) OF 'PRODUCT_DESCRIPTIONS'
(TABLE)(Cost=2 Card=4 Bytes=148)
2
TABLE ACCESS (BY INDEX ROWID) OF
'PRODUCT_INFORMATION’ (TABLE) (Cost=1 Card=1 Bytes=20)
4
INDEX (UNIQUE SCAN) OF
'PRODUCT_INFORMATION_PK' (INDEX (UNIQUE)) (Cost=0
Card=1)
ITEC 450
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;
2012
An example of SQL statement
Fall

16
EXECUTION PLAN USING SQL DEVELOPER
Fall
2012
ITEC 450
17
WRAP UP
Assignment 3-1-4: Lab4: Query Optimization
ITEC 450
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