sqltuning

7/30/2019 sqltuning

1/327

Oracle Database 10g: SQL Tuning

Workshop

Electronic Presentation

D17265GC10

Edition 1.0

November 2004

D40051

7/30/2019 sqltuning

2/327

Copyright 2004, Oracle. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is provided under a

license agreement containing restrictions on use and disclosure and is also protected by copyrightlaw. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S.

Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the

following legend is applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer

software and shall be deemed to be Restricted Rights software under Federal law, as set forth in

subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software

(October 1988).

This material or any portion of it may not be copied in any form or by any means without the express

prior written permission of Oracle Corporation. Any other copying is a violation of copyright law and

may result in civil and/or criminal penalties.

If this documentation is delivered to a U.S. Government Agency not within the Department of

Defense, then it is delivered with Restricted Rights, as defined in FAR 52.227-14, Rights in Data-

General, including Alternate III (June 1987).

The information in this document is subject to change without notice. If you find any problems in the

documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle

Parkway, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is

error-free.

Oracle and all references to Oracle Products are trademarks or registered trademarks of Oracle

Corporation.

All other products or company names are used for identification purposes only, and may be

trademarks of their respective owners.

Author

Priya Vennapusa

Technical Contributors and

Reviewers

Andrew BranniganCecelia GervasioChika IzumiConnie GreenDairy Chan

Donna KeeslingGraham WoodHarald Van BreederodeHelen RobertsonJanet SternJean Francois VerrierJoel GoodmanLata ShivaprasadLawrence Hopper

Lillian HobbsMarcelo ManzanoMartin JensenMughees MinhasRic Van DykeRobert BungenstockRussell BoltonDr. Sabine TeuberStefan Lindblad

Editor

Richard Wallis

Publisher

S. Domingue

7/30/2019 sqltuning

3/327


Course Overview

7/30/2019 sqltuning

4/327

I-2 Copyright 2004, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do

the following:

Describe course objectives

Describe course schedule

7/30/2019 sqltuning

5/327


Course Objectives

Proactive Tuning:

Describe the basic steps in processing SQL

statements

Describe the causes of performance problems

Understand where SQL tuning fits in an overalltuning methodology

Influence the physical data model so as to avoid

performance problems

Understand query optimizer behavior Influence the optimizer behavior

7/30/2019 sqltuning

6/327


Course Objectives

Reactive Tuning:

Use the diagnostic tools to gather information

about SQL statement processing

Describe Automatic SQL Tuning

Describe alternative methods of accessing data

7/30/2019 sqltuning

7/327


Course Schedule

Workshop 1

2

8. Application Tracing

7. Generating Execution Plans

6. Execution Plans5. Optimizer Operations

4. Introducing the optimizer

3. Designing and developing for

performance

2. Following a tuning methodology

1. Oracle Database Architecture1

LessonDay

7/30/2019 sqltuning

8/327


Course Schedule

11. Using Indexes3

Workshop 6 and Optional Workshop 714. Matrialized Views

Workshop 5

13. Using Hints

Workshop 3 and 4

12. Different Types of Indexes

Workshop 2

10. Automatic SQL Tuning

9. Identifying High load SQL2

LessonDay

7/30/2019 sqltuning

9/327


Summary

In this lesson, you should have learned to:

Describe course objectives

Describe course schedule

7/30/2019 sqltuning

10/327


Oracle Database Architecture: Overview

7/30/2019 sqltuning

11/327

1-2 Copyright 2004, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to:

Describe the Oracle Database architecture andcomponents

Make qualified decisions about your tuning

actions

7/30/2019 sqltuning

12/327


Oracle Database Architecture: Overview

The Oracle Database consists of two main

components: The database: physical structures

The instance: memory structures

The size and structure of these components

impact performance.

7/30/2019 sqltuning

13/327


Oracle Instance Management

SystemMonitorSMON

DatabaseWriterDBW0

LogWriterLGWR

ProcessMonitorPMON

ArchiverARC0

CheckpointCKPT

SGA

Java pool

Shared pool Large poolStreams pool

Redo log

buffer

Database

buffer cache

Control

fileData

files

Redo log

files

Archived

redo log

files

7/30/2019 sqltuning

14/327


Database Physical Structure

Data files Online redo log files

Password fileParameter file Archive log files

Control files

7/30/2019 sqltuning

15/327


Oracle Memory Structures

SGA

Java Pool

Shared pool Large poolStreams pool

Redo log

buffer

Database

buffer cache

Server

process 1

PGA

Server

process 2

PGA

Server

process 3

PGA

7/30/2019 sqltuning

16/327


SGA

Java pool

Fixed SGA

Redo log

buffer

Database

buffer cache

Automatic Shared Memory Management

Which size to choose?

Large poolShared pool

7/30/2019 sqltuning

17/327


Shared PoolThe shared pool consists of:

Data dictionary cache containing information on

objects, storage, and privileges Library cache containing information such as SQL

statements, parsed or compiled PL/SQL blocks, and

Java classes

Appropriate sizing of the shared pool affects performanceby:

Reducing disk reads

Allowing shareable SQL code

Reducing parsing, thereby saving CPU resources

Reducing latching overhead, thereby improving

scalability

7/30/2019 sqltuning

18/327


Shared SQL Areas

SGA Shared SQL

Cursor forSELECT statement 2

Cursor forSELECT statement 1

User A User B User C

SELECT

statement 1SELECT

statement 2SELECT

statement 1

7/30/2019 sqltuning

19/327


Program Global Area (PGA)

PGA is a memory area that contains:

Session information

Cursor information

SQL execution work areas

Sort area

Hash join area

Bitmap merge area

Bitmap create area

Work area size influences SQL performance. Work areas can be automatically or manually

managed.

7/30/2019 sqltuning

20/327


Automated SQL Execution Memory (PGA)

Management

Allocation and tuning of PGA memory is simplified

and improved. Efficient memory allocation for varying workloads

Queries optimized for both throughput and

response times

DBAs can use parameters to specify the policy forPGA sizing.

7/30/2019 sqltuning

21/327


Connecting to an Instance

User Server

ServerUser

Client

User Server

Oracle database

ServerApplication server

Browser

7/30/2019 sqltuning

22/327


SQL Statement Processing Phases

CloseOpen

FetchBindParse Execute

7/30/2019 sqltuning

23/327


SQL Statement Processing Phases: Parse

Parse phase:

Searches for the statement in the shared pool

Checks syntax

Checks semantics and privileges

Merges view definitions and subqueries

Determines execution plan

Minimize parsing as much as possible:

Parse calls are expensive.

Avoid reparsing Parse once, execute many times

7/30/2019 sqltuning

24/327


SQL Statement Processing Phases: Bind

Bind phase:

Checks the statement for bind variables

Assigns or reassigns a value to the bind variable

Bind variables impact performance when:

They are not used, and your statement would

benefit from a shared cursor

They are used, and your statement would benefit

from a different execution plan

7/30/2019 sqltuning

25/327


SQL Statement Processing Phases:

Execute and Fetch

Execute phase:

Executes the SQL statement Performs necessary I/O and sorts for data

manipulation language (DML) statements

Fetch phase:

Retrieves rows for a query

Sorts for queries when needed

Uses an array fetch mechanism

7/30/2019 sqltuning

26/327


Processing a DML Statement

Database

Datafiles

Controlfiles

Redolog files

UPDATE

employees ...

Userprocess

SGA

Database

buffer cache

Shared pool

Redo logbuffer

Serverprocess

3

1

4

2

7/30/2019 sqltuning

27/327


Instance

COMMIT Processing

Database

Datafiles

Controlfiles

Redolog files LGWR

Userprocess

SGA

Database

buffer cache

Shared pool

Redo logbuffer

Serverprocess

7/30/2019 sqltuning

28/327


Functions of the Oracle Query Optimizer

The Oracle query optimizer determines the most

efficient execution plan and is the most important stepin the processing of any SQL statement.

The optimizer:

Evaluates expressions and conditions

Uses object and system statistics

Decides how to access the data

Decides how to join tables

Decides which path is most efficient

7/30/2019 sqltuning

29/327


Top Database Performance Issues

Bad connection management

Poor use of cursors and the shared pool

Bad SQL

Nonstandard initialization parameters

I/O issues Long full-table scans

In-disk sorts

High amounts of recursive SQL

Schema errors and optimizer problems

7/30/2019 sqltuning

30/327


Summary

In this lesson, you should have learned about the

Oracle Database architecture and various componentsthat require tuning.

7/30/2019 sqltuning

31/327


Following a Tuning Methodology

7/30/2019 sqltuning

32/327


Objectives


the following: Determine performance problems

Manage performance

Describe tuning methodologies

Identify goals for tuning

Describe automatic SQL tuning features

List manual SQL tuning steps

7/30/2019 sqltuning

33/327


Performance Problems

Inadequate consumable resources

CPU I/O

Memory (may be detected as an I/O problem)

Data communications resources

High-load SQL

Contention

7/30/2019 sqltuning

34/327


Factors to Be Managed

Schema

Data design Indexes

Application

SQL statements

Procedural code

Instance

Database

User expectations Hardware and network tuning

7/30/2019 sqltuning

35/327


Tuning Goals

Reduce the response time

Reduce resource usage

7/30/2019 sqltuning

36/327


Overview of SQL Tuning

1. Identify causes of poor performance.

2. Identify problematic SQL. Automatic: ADDM, Top SQL

Manual: V$ views, statspack

3. Apply a tuning method.

Manual tuning

Automatic SQL tuning

4. Implement changes to:

SQL statement constructs Access structures such as indexes

7/30/2019 sqltuning

37/327


Identifying High-Load SQL

Identify high-load orproblematic SQL

Dynamic performance views Statspack

ADDM Top SQL report

7/30/2019 sqltuning

38/327


Manual Tuning

1. Gather information about the referenced objects.

2. Gather optimizer statistics.3. Review execution plans.

4. Restructure SQL statements.

5. Restructure indexes and create materialized views.6. Maintain execution plans.

7/30/2019 sqltuning

39/327


Gather Information AboutReferenced Objects

SQL text

Structure of tables and indexes Optimizer statistics

Views

Optimizer plan: current and prior

7/30/2019 sqltuning

40/327


Gathering Optimizer Statistics

Gather statistics for all tables.

Gather new statistics when existing statisticsbecome stale.

7/30/2019 sqltuning

41/327


Reviewing the Execution Plan

Driving table has the best filter.

Fewest number of rows are being returned to thenext step.

The join method is appropriate for the number ofrows being returned.

Views are used efficiently.

There are no unintentional Cartesian products.

Each table is being accessed efficiently.

Examine the predicates in the SQL statement andthe number of rows in the table.

A full table scan does not mean inefficiency.

7/30/2019 sqltuning

42/327


Restructuring the SQL Statements

Compose predicates by using AND and = .

Avoid transformed columns in the WHERE clause. Avoid mixed-mode expressions and beware of

implicit type conversions.

Write separate SQL statements for specific tasksand use SQL constructs appropriately

Use EXISTS orIN for subqueries as required.

Cautiously change the access path and join order

with hints.

7/30/2019 sqltuning

43/327


Restructuring the Indexes

Remove unnecessary indexes to speed the DML.

Index the performance-critical access paths. Reorder columns in existing concatenated

indexes.

Add columns to the index to improve selectivity.

Create appropriate indexes based on usage type:

B*tree

Bitmap

Bitmap join Concatenated

Consider index-organized tables.

7/30/2019 sqltuning

44/327


Maintaining Execution Plans over Time

Stored outlines

Stored statistics Locking statistics

7/30/2019 sqltuning

45/327


Automatic SQL Tuning

Automatic SQL tuning facilitates these steps:

Gather information on the referenced objects.

Verify optimizer statistics.

Review execution plans.

Restructure SQL statements

Restructure indexes and create materialized views.

Maintain execution plans.

Four types of analysis are performed in automaticSQL tuning:

Statistics analysis SQL profiling

Access path analysis

SQL structure analysis

7/30/2019 sqltuning

46/327


Automatic Tuning Mechanisms

You can perform automatic SQL tuning using:

SQL Tuning Advisor SQL Access advisor

7/30/2019 sqltuning

47/327


SQL Tuning Advisor

The SQL Tuning Advisor does the following:

Accepts input from:

Automatic Database Diagnostic Monitor (ADDM)

Automatic Workload Repository (AWR)

Cursor cache

Custom SQL as defined by the user

Provides:

Recommendations

Rationale

Expected benefits SQL commands for implementing the

recommendations

7/30/2019 sqltuning

48/327


Summary

In this lesson, you should have learned how to:

Manage performance

Start early; be proactive

Set measurable objectives

Monitor requirements compliance

Handle exceptions and changes

Identify performance problems

Inadequate consumable resources

Inadequate design resources

Critical resources Excessive demand

7/30/2019 sqltuning

49/327


Summary


Tune SQL statements

Analyze the results at each step

Tune the physical schema

Choose when to use SQL

Reuse SQL statements when possible

Design and tune the SQL statement

Get maximum performance with the optimizer

7/30/2019 sqltuning

50/327


Designing and Developing

for Performance

7/30/2019 sqltuning

51/327


Objectives

After completing this lesson, you should be able to

describe the basic steps involved in designing anddeveloping for performance.

7/30/2019 sqltuning

52/327


Understanding Scalability

Scalability is a systems ability to process more

workload, with a proportional increase in systemresource use.

Poor scalability leads to system resource

exhaustion to the extent that additional

throughput is impossible when the systemsworkload is increased.

7/30/2019 sqltuning

53/327


Scalability with Application Design,

Implementation, and Configuration

Applications have a significant impact on scalability.

Poor schema design can cause expensive SQLthat does not scale.

Poor transaction design can cause locking and

serialization problems.

Poor connection management can causeunsatisfactory response times and unreliable

systems.

7/30/2019 sqltuning

54/327


Configuring the Appropriate System

Architecture for Your Requirements

Interactive applications (OLTP)

Process-driven applications (OLAP)

7/30/2019 sqltuning

55/327


Proactive Tuning Methodology

Simple design

Data modeling Tables and indexes

Using views

Writing efficient SQL

Cursor sharing

Using bind variables

SQL versus PL/SQL

Dynamic SQL

7/30/2019 sqltuning

56/327


Simplicity In Application Design

Simple tables

Well-written SQL Indexing only as required

Retrieving only required information

7/30/2019 sqltuning

57/327


Data Modeling

Accurately represent business practices

Focus on the most frequent and importantbusiness transactions

Use modeling tools

Normalize the data

T bl D i

7/30/2019 sqltuning

58/327


Table Design

Compromise between flexibility and performance

Principally normalize Selectively denormalize

Use Oracle performance features

Default values

Check constraints

Materialized views

Clusters

Focus on business-critical tables

I d D i

7/30/2019 sqltuning

59/327


Index Design

Index keys

Primary key Unique key

Foreign keys

Index data that is frequently queried

Use SQL as a guide to index design

U i Vi

7/30/2019 sqltuning

60/327


Using Views

Simplifies application design

Is transparent to the end user Can cause suboptimal execution plans

SQL E ec tion Efficienc

7/30/2019 sqltuning

61/327


SQL Execution Efficiency

Good database connectivity

Using cursors Minimizing parsing

Using bind variables

Importance of Sharing Cursors

7/30/2019 sqltuning

62/327


Importance of Sharing Cursors

Reduces parsing

Dynamically adjusts memory Improves memory usage

Writing SQL to Share Cursors

7/30/2019 sqltuning

63/327


Writing SQL to Share Cursors

Create generic code using the following:

Stored procedures and packages Database triggers

Any other library routines and procedures

Write to format standards:

Case White space

Comments

Object references

Bind variables

Controlling Shared Cursors

7/30/2019 sqltuning

64/327


Controlling Shared Cursors

The CURSOR_SHARING initialization parameter can be

set to: EXACT (default)

SIMILAR (not recommended)

FORCE

Performance Checklist

7/30/2019 sqltuning

65/327


Performance Checklist

Set initialization parameters and storage options.

Verify resource usage of SQL statements. Validate connections by middleware.

Verify cursor sharing.

Validate migration of all required objects.

Verify validity and availability of optimizer

statistics.

Summary

7/30/2019 sqltuning

66/327


Summary

In this lesson, you should have learned the basic steps

that are involved in designing and developing for

performance.

7/30/2019 sqltuning

67/327


Introduction to the Optimizer

Objectives

7/30/2019 sqltuning

68/327


Objectives


the following:

Describe the functions of the Oracle optimizer

Identify the factors influencing the optimizer

Set the optimizer approach at the instance and

session level

Oracle Optimizer

7/30/2019 sqltuning

69/327


Oracle Optimizer

The optimizer creates an execution plan for every SQL

statement by:

Evaluating expressions and conditions

Using object and system statistics

Deciding how to access the data

Deciding how to join tables

Deciding which path is most efficient

Comparing the cost for execution of different

plans Determining the least-cost plan

Functions of the Query Optimizer

7/30/2019 sqltuning

70/327


Functions of the Query Optimizer

Querytransformer

Estimator

Plangenerator

Parsed query(from parser)

Query plan(to row-source generator)

DictionaryStatistics

Transformed query

Query + estimates

Selectivity

7/30/2019 sqltuning

71/327


y

Selectivity represents a fraction of rows from a

row set.

Selectivity lies in a value range from 0.0 to 1.0.

When statistics are available, the estimator uses

them to estimate selectivity.

With histograms on columns that contain skeweddata, the results are good selectivity estimates.

Cardinality and Cost

7/30/2019 sqltuning

72/327


y

Cardinality represents the number of rows in a row

set.

Cost represents the units of work or resource that

are used.

Query Optimizer Statistics in

7/30/2019 sqltuning

73/327


y p

the Data Dictionary

The Oracle optimizer requires statistics to

determine the best execution plan.

Statistics

Stored in the data dictionary tables

Must be true representations of data

Gathered using:DBMS_STATS package

Dynamic sampling

Enabling Query Optimizer Features

7/30/2019 sqltuning

74/327


g y p

The optimizer behavior can be set to prior releases

of the database.

The OPTIMIZER_FEATURES_ENABLE initializationparameter can be set to values of different

database releases (such as 8.1.7 or 10.0.0).

Example:OPTIMIZER_FEATURES_ENABLE=9.2.0;

Controlling the Behavior of the Optimizer

7/30/2019 sqltuning

75/327


Optimizer behavior can be controlled using the

following initialization parameters:

CURSOR_SHARING

DB_FILE_MULTIBLOCK_READ_COUNT

OPTIMIZER_INDEX_CACHING

OPTIMIZER_INDEX_COST_ADJ OPTIMIZER_MODE

PGA_AGGREGATE_TARGET

Choosing an Optimizer Approach

7/30/2019 sqltuning

76/327


OPTIMIZER_MODE initialization parameter

OPTIMIZER_MODE parameter ofALTER SESSIONstatement

Optimizer statistics in the data dictionary

Optimizer SQL hints for influencing the optimizer

decision

Setting the Optimizer Approach

7/30/2019 sqltuning

77/327


At the instance level, set the following parameter:

For a session, use the following SQL command:

OPTIMIZER_MODE = {FIRST_ROWS(_n)|ALL_ROWS}

ALTER SESSION SET optimizer_mode ={first_rows(_n)|all_rows}

Optimizing for Fast Response

7/30/2019 sqltuning

78/327


OPTIMIZER_MODE is set to FIRST_ROWS orFIRST_ROWS_n, where n is 1, 10, 100, or 1000.

This approach is suitable for online users.

The optimizer generates a plan with the lowest

cost to produce the first row or the first few rows.

The value ofn should be chosen based on theonline user requirement (specifically, how the

result is displayed to the user).

The optimizer explores different plans and

computes the cost to produce the first n rows foreach plan.

Optimizing SQL Statements

7/30/2019 sqltuning

79/327


Best throughput

Time required to complete the request Suitable for:

Batch processing

Report applications

Fast response Time for retrieving the first rows

Suitable for:

Interactive applications

Web-based or GUI applications

How the Query Optimizer

7/30/2019 sqltuning

80/327


Executes Statements

The factors considered by the optimizer are:

Access path Join method

Join order

Access Paths

7/30/2019 sqltuning

81/327


Full-table scans

Row ID scans Index scans

Cluster scans

Hash scans

Join Orders

7/30/2019 sqltuning

82/327


A join order is the order in which different join items

(such as tables) are accessed and joined together.

Join Methods

7/30/2019 sqltuning

83/327


The different join methods considered by the optimizer

are:

Nested-loop join

Hash join

Sort-merge join

Cartesian join

Summary

7/30/2019 sqltuning

84/327


In this lesson, you should have learned about:

Functions of the optimizer Cost factors that are considered by the optimizer

Setting the optimizer approach

7/30/2019 sqltuning

85/327


Optimizer Operations

Objectives

7/30/2019 sqltuning

86/327



the following:

Describe different access paths

Optimize sort performance

Describe different join techniques

Explain join optimization Find optimal join execution plans

Review: How the Query Optimizer

E t St t t

7/30/2019 sqltuning

87/327


Executes Statements

The factors considered by the optimizer are:

Access path

Join order

Join method

Access Paths

7/30/2019 sqltuning

88/327


Full table scan

Row ID scan

Index scan

Sample table scan

Choosing an Access Path

7/30/2019 sqltuning

89/327


Available access paths for the statement

Estimated cost of executing the statement, using

each access path or combination of paths

Full Table Scans

7/30/2019 sqltuning

90/327


Lack of index

Large amount of data

Small table

Row ID Scans

7/30/2019 sqltuning

91/327


The row ID specifies the data file and data block

containing the row as well as the location of the

row in that block.

Using the row ID is the fastest way to retrieve a

single row.

Every index scan does not imply access by row ID.

Index Scans

7/30/2019 sqltuning

92/327


Types of index scans:

Index unique scan

Index range scan

Index range scan descending

Index skip scan

Index Scans

7/30/2019 sqltuning

93/327


Types of index scans:

Full scan

Fast-full index scan

Index join

Bitmap join

Joining Multiple Tables

7/30/2019 sqltuning

94/327


You can join only two row sources at a time. Joins

with more than two tables are executed as follows:

1. Two tables are joined, resulting in a row source.

2. The next table is joined with the row source that

results from step 1.

3. Step 2 is repeated until all tables are joined.

Join Terminology

7/30/2019 sqltuning

95/327


Join statement

Join predicate, nonjoin predicate

Single-row predicate

SELECT c.cust_last_name,c.cust_first_name,

co.country_id, co.country_name

FROM customers c JOIN countries coON (c.country_id = co.country_id)

AND ( co.country_id = '52790'

OR c.cust_id = 205);

Join predicate

Nonjoin predicate

Single-row predicate

Join Terminology

7/30/2019 sqltuning

96/327


Natural join

Join with nonequal predicate

SELECT c.cust_last_name, co.country_name

FROM customers c NATURAL JOIN countries co;

SELECT s.amount_sold, p.promo_name

ON( s.time_idFrom sales s, promotions p

BETWEEN p.promo_begin_date

AND p.promo_end_date );

Cross join

SELECT *

FROM customers c CROSS JOIN countries co;

7/30/2019 sqltuning

97/327

Oracle Proprietary Outer Joins

7/30/2019 sqltuning

98/327


Join predicates with a plus (+) sign

Nonjoin predicates with a plus (+) sign

Predicates without a plus (+) sign disable outer

joins

SELECT s.time_id, t.time_id

FROM sales s, times tWHERE s.time_id (+) = t.time_id;

Full Outer Joins

7/30/2019 sqltuning

99/327


A full outer join acts like a combination of the left

and right outer joins.

In addition to the inner join, rows in both tables

that have not been returned in the result of the

inner join are preserved and extended with nulls.

SELECT c.cust_id, c.cust_last_name, co.country_name

FROM customers c

FULL OUTER JOIN countries co

ON (c.country_id = co.country_id);

Execution of Outer Joins

7/30/2019 sqltuning

100/327


Indexes can be used for outer join predicates.

SELECT c.cust_id, co.country_nameFROM customers c

LEFT OUTER JOIN countries co

ON (c.country_id = co.country_id)

AND co.country_id = 'IT';

Join Order Rules

7/30/2019 sqltuning

101/327


Rule 2

Forou ter jo ins, the table with the outer-joined table

must come after the other table in the join order for

processing the join.

Rule 1

A sing le-row predicateforces its row source to beplaced first in the join order.

Join Optimization

7/30/2019 sqltuning

102/327


As a first step, a list of possible join orders is

generated.

This potentially results in the following:

Parse time grows factorially when adding tables to

a join.

Number of Tables Join Orders

---------------- -----------

2 2! = 23 3! = 6

4 4! = 24

Join Methods

7/30/2019 sqltuning

103/327


A join operation combines the output from two

row sources and returns one resulting row source.

Join operation types include the following:

Nested loop join

Sort-merge join

Hash join

Nested Loop Joins

7/30/2019 sqltuning

104/327


One of the two tables is defined as the outertable

(or the dr iv ingtable).

The other table is called the innertable.

For each row in the outer table, all matching rows

in the inner table are retrieved.

For each row in the outer table

For each row in the inner table

Check for a match

Nested Loop Join Plan

7/30/2019 sqltuning

105/327


Nested loops

Table access

(Outer/driving table)

Table access

(Inner table)

1

2 3

When Are Nested Loop Joins Used?

7/30/2019 sqltuning

106/327


Nested loop joins are used when:

Joining a few rows that have a good driving

condition

Order of tables is important

USE_NL(table1 table2)hint is used

Hash Joins

7/30/2019 sqltuning

107/327


A hash join is executed as follows:

Both tables are split into as many partitions as

required, using a full table scan.

For each partition pair, a hash table is built in

memory on the smallest partition.

The other partition is used to probe the hash table.

Hash Join Plan

7/30/2019 sqltuning

108/327


Hash join

Table access Table access

1

2 3

When Are Hash Joins Used?

7/30/2019 sqltuning

109/327


Hash joins are used if either of the following

conditions is true:

A large amount of data needs to be joined.

A large fraction of the table needs to be joined.

Use the USE_HASH hint.

Sort-Merge Joins

7/30/2019 sqltuning

110/327


A sort-merge join is executed as follows:

1. The rows from each row source are sorted

on the join predicate columns.

2. The two sorted row sources are then merged

and returned as the resulting row source.

Sort-Merge Join Plan

Merge 1

7/30/2019 sqltuning

111/327


Merge

Sort Sort

Table access Table access

1

2 3

4 5

When Are Sort-Merge Joins Used?

7/30/2019 sqltuning

112/327


Sort-merge joins can be used if either of the following

conditions is true:

Join condition is not an equijoin.

Sorts are required for other operations.

Star Joins

7/30/2019 sqltuning

113/327


Facts

table

Dimension

tables

SALES

PRODUCTS

CHANNELS PROMOTIONS TIMES

CUSTOMERS

How the Query Optimizer Chooses

Execution Plans for Joins

7/30/2019 sqltuning

114/327


The query optimizer determines:

Row sources

Type of join

Join method

Cost of execution plans

Other costs such as: I/O

CPU time

DB_FILE_MULTIBLOCK_READ_COUNT

Hints specified

Subqueries and Joins

7/30/2019 sqltuning

115/327


Subqueries (like joins) are statements that

reference multiple tables

Subquery types:

Noncorrelated subquery

Correlated subquery

NOT INsubquery (antijoin)

EXISTS subquery (semijoin)

Sort Operations

7/30/2019 sqltuning

116/327


SORT UNIQUE

SORT AGGREGATE

SORT GROUP BY

SORT JOIN

SORT ORDER BY

Tuning Sort Performance

7/30/2019 sqltuning

117/327


Because sorting large sets can be expensive, you

should tune sort parameters.

Note that DISTINCT, GROUP BY, and most setoperators cause implicit sorts.

Minimize sorting by one of the following:

Try to avoid DISTINCT and GROUP BY.

Use UNION ALL instead ofUNION.

Enable index access to avoid sorting.

Top-N SQL

7/30/2019 sqltuning

118/327


SELECT *

FROM (SELECT prod_id

, prod_name, prod_list_price

, prod_min_price

FROM products

ORDER BY prod_list_price DESC)

WHERE ROWNUM

7/30/2019 sqltuning

119/327


Memory-intensive operations use up work areas in

the Program Global Area (PGA).

Automatic PGA memory management simplifiesand improves the way PGA memory is allocated.

The size of a work area must be big enough to

avoid P execution.

A reasonable amount of PGA memory allows

single-pass executions.

The size of PGA is controlled with:

PGA_AGGREGATE_TARGET WORKAREA_SIZE_POLICY

Summary

7/30/2019 sqltuning

120/327



Describe available join operations

Optimize join performance against different

requirements

Influence the join order

Explain why tuning joins is more complicated thantuning single table statements

7/30/2019 sqltuning

121/327


Execution Plans

7/30/2019 sqltuning

122/327

What Is an Execution Plan?

A ti l i t f t th t f d

7/30/2019 sqltuning

123/327


An execution plan is a set of steps that are performed

by the optimizer in executing a SQL statement and

performing an operation.

Methods for Viewing Execution Plans

EXPLAIN PLAN

7/30/2019 sqltuning

124/327


EXPLAIN PLAN

SQL Trace

Statspack

Automatic Workload Repository

V$SQL_PLAN

SQL*Plus AUTOTRACE

Using Execution Plans

Determining the current execution plan

7/30/2019 sqltuning

125/327


Determining the current execution plan

Identifying the effect of indexes

Determining access paths

Verifying the use of indexes

Verifying which execution plan may be used

DBMS_XPLANPackage: Overview

The DBMS XPLANpackage provides an easy way to

7/30/2019 sqltuning

126/327


_ p g p y ydisplay the output from:

EXPLAIN PLANcommand Automatic Workload Repository (AWR)

V$SQL_PLANandV$SQL_PLAN_STATISTICS_ALL

fixed views

The DBMS_XPLANpackage supplies three tablefunctions that can be used to retrieve and display

the execution plan:

DISPLAY

DISPLAY_CURSOR DISPLAY_AWR

Full Notes Page

7/30/2019 sqltuning

127/327


EXPLAIN PLANCommand

Generates an optimizer execution plan

7/30/2019 sqltuning

128/327


Generates an optimizer execution plan

Stores the plan in the PLANtable

Does not execute the statement itself

EXPLAIN PLANCommand

EXPLAIN PLAN

7/30/2019 sqltuning

129/327


SET STATEMENT_ID

= 'text'

EXPLAIN PLAN

INTO your plan table

FOR statement

EXPLAIN PLANCommand: Example

EXPLAIN PLAN

7/30/2019 sqltuning

130/327


EXPLAIN PLAN

SET STATEMENT_ID = 'demo01' FOR

SELECT e.last_name, d.department_nameFROM hr.employees e, hr.departments d

WHERE e.department_id = d.department_id;

Explained.

Note: The EXPLAIN PLANcommand does not

actually execute the statement.

EXPLAIN PLANCommand: Output

SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

7/30/2019 sqltuning

131/327


Plan hash value: 2933537672

-------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU|--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 106 | 2862 | 6 (17|| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|

| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0||* 4 | SORT JOIN | | 107 | 1177 | 4 (25|| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|--------------------------------------------------------------------------------

Predicate Information (identified by operation id):---------------------------------------------------

4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

18 rows selected.

Parse Tree

0

SELECT STATEMENT

7/30/2019 sqltuning

132/327


SORT JOIN

1

2 4

3 5

MERGE JOIN

FULL TABLE SCAN

ofEMPLOYEES

TABLE ACCESS BYINDEX ROWID

ofDEPARTMENTS

INDEX FULL SCANDEPT_ID_PK

Using theV$SQL_PLANView

V$SQL PLANprovides a way of examining the

7/30/2019 sqltuning

133/327


$ Q _ p y g

execution plan for cursors that were recently

executed. Information inV$SQL_PLANis very similar to the

output of an EXPLAIN PLANstatement:

EXPLAIN PLANshows a theoretical plan that can be

used if this statement were to be executed. V$SQL_PLANcontains the actual plan used.

V$SQL_PLANColumns

HASH_VALUE Hash value of the parent statement in the

library cache

7/30/2019 sqltuning

134/327


Note: This is only a partial listing of the columns.

ADDRESS

CHILD_NUMBER

POSITION

PARENT_ID

ID

Object number of the table or the index

Child cursor number using this execution plan

Order of processing for operations that all have

the same PARENT_ID

ID of the next execution step that operates on

the output of the current step

Number assigned to each step in the

execution plan

QueryingV$SQL_PLAN

SQL_ID 47ju6102uvq5q, child number 0-------------------------------------

SELECT PLAN_TABLE_OUTPUT FROMTABLE(DBMS_XPLAN.DISPLAY_CURSOR('47ju6102uvq5q'));

7/30/2019 sqltuning

135/327


-------------------------------------SELECT e.last_name, d.department_nameFROM hr.employees e, hr.departments d WHERE

e.department_id =d.department_id

Plan hash value: 2933537672--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU|--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100|| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0||* 4 | SORT JOIN | | 107 | 1177 | 4 (25|| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|--------------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------

4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

24 rows selected.

V$SQL_PLAN_STATISTICS View

V$SQL_PLAN_STATISTICS provides actual execution

7/30/2019 sqltuning

136/327


statistics.

V$SQL_PLAN_STATISTICS_ALL enablesside-by-side comparisons of the optimizer estimates.

Automatic Workload Repository

Collects, processes, and maintains performance

7/30/2019 sqltuning

137/327


statistics for problem-detection and self-tuning

purposes Statistics include:

Object statistics

Time-model statistics

Some system and session statistics

Active Session History (ASH) statistics

Automatically generates snapshots of the

performance data

Managing AWR with PL/SQL

Creating snapshots

7/30/2019 sqltuning

138/327

6-20Copyright 2004, Oracle. All rights reserved.

Dropping snapshots

Managing snapshot settings

AWR Views

V$ACTIVE_SESSION_HISTORY

7/30/2019 sqltuning

139/327

6-22Copyright 2004, Oracle. All rights reserved.

V$metric views

DBA_HIST views: DBA_HIST_ACTIVE_SESS_HISTORY

DBA_HIST_BASELINEDBA_HIST_DATABASE_INSTANCE

DBA_HIST_SNAPSHOT

DBA_HIST_SQL_PLAN

DBA_HIST_WR_CONTROL

Querying the AWR

SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w'));

7/30/2019 sqltuning

140/327


PLAN_TABLE_OUTPUT--------------------------------------------------------------------------------------SQL_ID 454rug2yva18w--------------------select /* example */ * from hr.employees natural join hr.departments

Plan hash value: 4179021502

----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |----------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100)| || 1 | HASH JOIN | | 11 | 968 | 6 (17)| 00:00:01 || 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 2 (0)| 00:00:01 || 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 2 (0)| 00:00:01 |

| 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 |----------------------------------------------------------------------------------

SQL*Plus AUTOTRACE

OFF

7/30/2019 sqltuning

141/327


TRACE[ONLY]

EXPLAINSTATISTICS

SHOW AUTOTRACE

SET AUTOTRACE ON

SQL*Plus AUTOTRACE: Examples

To start tracing statements using AUTOTRACE

7/30/2019 sqltuning

142/327


To hide statement output

To display execution plans only

Control the layout with column settings

set autotrace on

set autotrace traceonly

set autotrace traceonly explain

SQL*Plus AUTOTRACE: Statistics

set autotrace traceonly statistics

SELECT *FROM products;

7/30/2019 sqltuning

143/327


FROM products;

Statistics------------------------------------------------------

1 recursive calls0 db block gets9 consistent gets3 physical reads0 redo size

15028 bytes sent via SQL*Net to client556 bytes received via SQL*Net from client6 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)72 rows processed

Summary


Use EXPLAIN PLAN to view execution plans

7/30/2019 sqltuning

144/327


Use EXPLAIN PLANto view execution plans

QueryV$SQL_PLANto see the execution plan forcursors that were recently executed

Use the Automatic Workload Repository

Use SQL*Plus AUTOTRACE to run statements

and display execution plans and statistics

Practice 6: Overview

This practice covers the following topics:

Using AUTOTRACE

7/30/2019 sqltuning

145/327


Using AUTOTRACE

Using EXPLAIN PLAN Using AWR

Retrieving the execution plan using DBMS_XPLAN

7/30/2019 sqltuning

146/327

Objectives


the following:

7/30/2019 sqltuning

147/327


the following:

Identify table, index, and column statistics Describe the Automatic Statistics Gathering

mechanism

Use the DBMS_STATS package to collect statistics

manually

Identify predicate selectivity calculations

What Are Optimizer Statistics?

Collection of data that describes the database and

the objects in the database

7/30/2019 sqltuning

148/327


the objects in the database

Information used by query optimizer to estimate: Selectivity of predicates

Cost of each execution plan

Access method and join method

CPU and I/O costs

Types of Optimizer Statistics

Object statistics

Table statistics

7/30/2019 sqltuning

149/327


Table statistics

Column statistics Index statistics

System statistics

I/O performance and utilization

CPU performance and utilization

How Statistics Are Gathered

Automatic statistics gathering

GATHER STATS JOB

7/30/2019 sqltuning

150/327


_ _

Manual statistics gathering DBMS_STATS package

Dynamic sampling

Automatic Statistics Gathering

Oracle Database 10g automates optimizer

statistics collection:

7/30/2019 sqltuning

151/327


Statistics are gathered automatically on alldatabase objects.

GATHER_STATS_JOB is used for statistics collection

and maintenance.

Scheduler interface is used for scheduling themaintenance job.

Automated statistics collection:

Eliminates need for manual statistics collection

Significantly reduces the chances of getting poorexecution plans

Manual Statistics Gathering

You can use the DBMS_STATS package to:

Generate and manage statistics for use by the

7/30/2019 sqltuning

152/327


Generate and manage statistics for use by the

optimizer Gather, modify, view, export, import, and delete

statistics

Identify or name statistics that are gathered

Gather statistics on:

Indexes, tables, columns, and partitions

All schema objects in a schema or database

Gather statistics either serially or in parallel

Managing Automatic Statistics Collection

Job configuration options

Statistics-collection configuration options

7/30/2019 sqltuning

153/327


g p

Job Configuration Options

Setting status: ENABLED orDISABLED

Maintaining schedule: maintenance window

7/30/2019 sqltuning

154/327


g

Managing the Job Scheduler

Verifying Automatic Statistics Gathering:

SELECT owner, job_name,enabledFROM DBA_SCHEDULER_JOBS

7/30/2019 sqltuning

155/327


WHERE JOB_NAME = 'GATHER_STATS_JOB';

BEGIN

DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');

END;

/

BEGIN

DBMS_SCHEDULER.ENABLE('GATHER_STATS_JOB');

END;

/

Disabling and enabling Automatic Statistics Gathering:

Managing the Maintenance Window

WEEKNIGHT_WINDOW

WEEKEND_WINDOW

7/30/2019 sqltuning

156/327


EXECUTE DBMS_SCHEDULER.SET_ATTRIBUTE(

'WEEKNIGHT_WINDOW',

'repeat_interval',

'freq=daily; byday= MON, TUE, WED, THU, FRI;

byhour=0; byminute=0; bysecond=0');

Changing the GATHER_STATS_JOB Schedule

7/30/2019 sqltuning

157/327


Statistics Collection Configuration

DML monitoring

Sampling

7/30/2019 sqltuning

158/327


Degree of parallelism Histograms

Cascade

7/30/2019 sqltuning

159/327

Sampling

Statistics gathering relies on sampling to minimize

resource usage.

You can use the ESTIMATE_PERCENT argument of

7/30/2019 sqltuning

160/327


the DBMS_STATS procedures to change thesampling percentage to any value.

Set to DBMS_STATS.AUTO_SAMPLE_SIZE (default)

to maximize performance gains.

AUTO_SAMPLE_SIZE enables the database todetermine the appropriate sample size for each

object automatically.

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS

('SH',DBMS_STATS.AUTO_SAMPLE_SIZE);

Degree of Parallelism

Automatic Statistics Gathering operations can run

either serially or in parallel.

By default, the degree of parallelism is determined

7/30/2019 sqltuning

161/327


automatically. You can also manually specify the degree of

parallelism using the DEGREE argument of the

DBMS_STATS procedures.

Setting the DEGREE parameter toDBMS_STATS.AUTO_DEGREE (default) enables the

Oracle Database to choose an appropriate degree

of parallelism even when collecting statistics

manually.

Histograms

Influence optimizer decisions on selecting the

optimal execution plan

7/30/2019 sqltuning

162/327


Provide improved selectivity estimates in thepresence of data skew

Enable optimal execution plans with nonuniform

data distributions

1263056740

24850

105020

1010

Count of

Rows

Column

Value

10 5020 30 40

Number of

buckets = 5

10 5020 30 40

Creating Histograms

The Automatic Statistics Gathering mechanism

creates histograms as needed by default.

7/30/2019 sqltuning

163/327


You can use the DBMS_STATS package to changethis default.

You can use DBMS_STATS to create histograms

manually.

The following example shows how to create ahistogram with 50 buckets on PROD_LIST_PRICE:

EXECUTE dbms_stats.gather_table_stats

('sh','products',method_opt => 'for columns size 50

prod_list_price');

Viewing Histogram Statistics

SELECT column_name, num_distinct,

num_buckets, histogram

FROM USER_TAB_COL_STATISTICS

WHERE histogram 'NONE';

1

7/30/2019 sqltuning

164/327


SELECT column_name, num_distinct,

num_buckets, histogram

FROM USER_TAB_COL_STATISTICS

WHERE column_name = 'PROD_LIST_PRICE';

2

Histogram Tips

The default option forDBMS_STATSMETHOD_OPTS is FOR ALL COLUMNS SIZE

AUTO, which enables automatic creation of

7/30/2019 sqltuning

165/327


histograms as needed. Alternatively, you can create histograms

manually: On skewed columns that are used frequently inWHERE

clauses of queries On columns that have a highly skewed data distribution

Bind Variable Peeking

The optimizer peeks at the values of bind variables

on the first invocation of a cursor.

7/30/2019 sqltuning

166/327


This is done to determine the selectivity of thepredicate.

Peeking does not occur for subsequent

invocations of the cursor.

Cursor is shared, based on the standard cursor-sharing criteria even for different bind values.

Cascading to Indexes

The Automatic Statistics Gathering mechanism is

configured by default to gather index statistics

while gathering statistics on the parent tables.

7/30/2019 sqltuning

167/327


g g p

You can change the default behavior by modifyingthe CASCADE option of the DBMS_STATS package.

Set the CASCADE option to:

TRUE to gather index statistics DBMS_STATS.AUTO_CASCADE to have the Oracle

Database determine whether index statistics are to

be collected or not

Managing Statistics Collection: Example

dbms_stats.gather_table_stats

('sh' -- schema

,'customers' -- table

7/30/2019 sqltuning

168/327


, null -- partition, 20 -- sample size(%)

, false -- block sample?

,'for all columns' -- column spec

, 4 -- degree of parallelism

,'default' -- granularity, true ); -- cascade to indexes

dbms_stats.set_param('CASCADE',

'DBMS_STATS.AUTO_CASCADE');dbms_stats.set_param('ESTIMATE_PERCENT','5');

dbms_stats.set_param('DEGREE','NULL');

When to Gather Manual Statistics

Rely mostly on automatics statistics collection

Change frequency of automatic statistics

7/30/2019 sqltuning

169/327


collection to meet your needs Gather statistics manually:

For objects that are volatile

For objects modified in batch operations

Statistics Gathering: Manual Approaches

Dynamic sampling:

BEGIN

DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');

DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');

7/30/2019 sqltuning

170/327


END;

BEGIN

DBMS_STATS.GATHER_TABLE_STATS('OE','ORDERS');DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');

END;

For objects modified in batch operations: gather

statistics as part of the batch operation For new objects: gather statistics immediately

after object creation

Manual statistics collection:

Dynamic Sampling

Dynamic sampling is used to automatically collect

statistics when:

Th t f ll ti th t ti ti i i i l

7/30/2019 sqltuning

171/327


The cost of collecting the statistics is minimalcompared to the execution time

The query is executed many times

Locking Statistics

Prevents automatic gathering

Is used primarily for volatile tables

L k ith t t ti ti i li d i li

7/30/2019 sqltuning

172/327


Lock without statistics implies dynamic sampling. Lock with statistics is for representative values.

EXECUTE DBMS_STATS.LOCK_TABLE_STATS

('owner name', 'table name');

EXECUTE DBMS_STATS.LOCK_SCHEMA_STATS

('owner name');

SELECT stattype_lockedFROM dba_tab_statistics;

Verifying Table Statistics

SELECT last_analyzed analyzed, sample_size,

monitoring,table_name

FROM dba_tables

WHERE t bl 'EMPLOYEES'

7/30/2019 sqltuning

173/327


WHERE table_name ='EMPLOYEES';

ANALYZED SAMPLE_SIZE MON TABLE_NAME

--------- ----------- --- -------------------

09-FEB-04 2000 YES EMPLOYEES

Verifying Column Statistics

SELECT column_name, num_distinct,histogram,

num_buckets, density, last_analyzed analyzed

FROM dba_tab_col_statistics

WHERE t bl 'SALES'

7/30/2019 sqltuning

174/327


WHERE table_name ='SALES'ORDER BY column_name;

COLUMN_NAME NUM_DISTINCT HISTOGRAM NUM_BUCKETS DENSITY ANALYZED

------------- ------------ ----------- ----------- ---------- ---------

AMOUNT_SOLD 3586 NONE 1 .000278862 09-FEB-04

CHANNEL_ID 4 NONE 1 .25 09-FEB-04

CUST_ID 7059 NONE 1 .000141663 09-FEB-04

PROD_ID 72 FREQUENCY 72 5.4416E-07 09-FEB-04

PROMO_ID 4 NONE 1 .25 09-FEB-04

QUANTITY_SOLD 1 NONE 1 1 09-FEB-04TIME_ID 1460 NONE 1 .000684932 09-FEB-04

7 rows selected.

Verifying Index Statistics

SELECT index_name name, num_rows n_r,

last_analyzed l_a, distinct_keys

d_k, leaf_blocks l_b,

avg leaf blocks per key a l

7/30/2019 sqltuning

175/327


avg_leaf_blocks_per_key a_l,join_index j_I

FROM dba_indexes

WHERE table_name = 'EMPLOYEES'

ORDER BY index_name;

History of Optimizer Statistics

GATHER_STATS IMPORT_STATS SET_STATS

7/30/2019 sqltuning

176/327


DBA_TAB_STATS_HISTORY

New

statistics

Old

statistics

DBA_OPTSTATS_OPERATIONS

31

days

RESTORE_TABLE_STATS

Operation

date

Managing Historical Optimizer Statistics

RESTORE_*_STATS()

PURGE_STATS()

ALTER_STATS_HISTORY_RETENTION()

7/30/2019 sqltuning

177/327


Generating System Statistics

I/O

CPU

7/30/2019 sqltuning

178/327


BEGINdbms_stats.gather_system_stats(

gathering_mode => 'interval',interval => 720,stattab => 'mystats',statid => 'oltp');

END;/

Statistics on Dictionary Objects

GATHER_FIXED_OBJECTS_STATS

Dictionary tables

7/30/2019 sqltuning

179/327


GATHER_DATABASE_STATS

Dictionary tables

Fixed tables

GATHER_DICTIONARY_STATS

Dictionary Statistics: Best Practices

GATHER_SCHEMA_STATS('SYS')

GATHER_DICTIONARY_STATS

CREATE

7/30/2019 sqltuning

180/327


GATHER_DATABASE_STATS(OPTIONS=>'GATHER AUTO')

GATHER_FIXED_OBJECTS_STATSCREATE

ALTER

DROP

Workload DDLs

7/30/2019 sqltuning

181/327



Using DBMS_STATS to gather manual statistics

Verifying the existence of the gather stats job

7/30/2019 sqltuning

182/327


Verifying the existence of the gather_stats_job Understanding the use of histograms

Understanding bind variable peeking

7/30/2019 sqltuning

183/327

Objectives


the following:

Configure the SQL Trace facility to collect session

statistics

7/30/2019 sqltuning

184/327


statistics

Enable SQL Trace and locate your trace files

Format trace files using the TKPROF utility

Interpret the output of the TKPROF command

7/30/2019 sqltuning

185/327

End to End Application Tracing

Simplifies the process of diagnosing performance

problems in multitier environments

Can be used to

Identify high-load SQL

7/30/2019 sqltuning

186/327


Identify high load SQL

Monitor what a user's session is doing at the

database level

Simplifies management of application workloadsby tracking specific modules and actions in a

service

End to End Application Tracing Using EM

7/30/2019 sqltuning

187/327


Using DBMS_MONITOR

EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_ENABLE(

client_id => 'OE.OE',

waits => TRUE, binds => FALSE);

EXECUTE DBMS MONITOR.SERV MOD ACT STAT ENABLE(

1

7/30/2019 sqltuning

188/327


CU S_ O O .S _ O _ C _S _ (

service_name =>'ACCTG',

module_name => 'PAYROLL');

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name =>'ACCTG',

module_name => 'GLEDGER',

action_name => 'INSERT ITEM');2

Viewing Gathered Statistics for

End to End Application Tracing

The accumulated statistics for a specified servicecan be displayed in theV$SERVICE_STATS view.

The accumulated statistics for a combination of

specified service, module, and action can be

7/30/2019 sqltuning

189/327


pdisplayed in theV$SERV_MOD_ACT_STATS view.

The accumulated statistics for elapsed time of

database calls and for CPU use can be displayedin theV$SVCMETRIC view.

All outstanding traces can be displayed in an

Oracle Enterprise Manager report or with the

DBA_ENABLED_TRACES view.

trcsess Utility

Client

Dedicated

server

Clients

Shared

server

Shared

server

Shared

server

Client

Dedicated

server

Client

Dedicated

server

7/30/2019 sqltuning

190/327


Trace

file

Trace

file

Trace

file

Trace

fileTrace

file

TRCSESS

Trace file

for one clientTKPROF

Report

file

TRCSESS

Trace file

for one service

Trace

file

trcsess Utility

SQL> select sid||'.'||serial#, username

2 from v$session

3 where username in ('HR', 'SH');

SID||'.'||SERIAL# USERNAME

7/30/2019 sqltuning

191/327


------------------- --------------------------

236.57 HR

245.49845 SH

$ trcsess session= 236.57 orcl_ora_11155.trc

output=x.txt

SQL Trace Facility

Usually enabled at the session level

Gathers session statistics for SQL statements

grouped by session

Produces output that can be formatted by TKPROF

7/30/2019 sqltuning

192/327


Report

file

Database

Trace

file

TKPROF

Server process

Information Captured by SQL Trace

Parse, execute, and fetch counts

CPU and elapsed times

Physical reads and logical reads Number of rows processed

7/30/2019 sqltuning

193/327


Number of rows processed

Misses on the library cache

Username under which each parse occurred

Each commit and rollback

How to Use the SQL Trace Facility

1. Set the initialization parameters.

2. Enable tracing.

3. Run the application.

4. Disable Trace5. Close the session.

7/30/2019 sqltuning

194/327


5. Close the session.

6. Format the trace file.

7. Interpret the output.

Report

file

Database

Tracefile

TKPROF

SQL Trace

Initialization Parameters

TIMED_STATISTICS = {false|true}

MAX_DUMP_FILE_SIZE = {n|unlimited}

USER_DUMP_DEST = directory_path

STATISTICS_LEVEL = {BASIC|TYPICAL|ALL}

7/30/2019 sqltuning

195/327


Enabling SQL Trace

For your current session:

For any session:

SQL> ALTER SESSION SET sql_trace = true;

7/30/2019 sqltuning

196/327


For an instance, set the following parameter:

SQL> EXECUTE dbms_session.set_sql_trace(true);

SQL> EXECUTE dbms_system.set_sql_trace_in_session2 (session_id, serial_id, true);

SQL_TRACE = TRUE

Formatting Your Trace Files

TKPROF command examples:

OS> tkprof

OS> tkprof tracefile outputfile[options]

7/30/2019 sqltuning

197/327


OS> tkprof ora_902.trc run1.txt

OS> tkprof ora_902.trc run2.txt sys=no

sort=execpu print=3

TKPROF Command Options

SORT = option

PRINT = n

EXPLAIN = username/password

INSERT = filename

7/30/2019 sqltuning

198/327


SYS = NO

AGGREGATE = NO

RECORD = filenameTABLE = schema.tablename

Output of the TKPROF Command

Text of the SQL statement

Trace statistics (for statement and recursive calls)

separated into three SQL processing steps:

Translates the SQL statement into an execution planPARSE

7/30/2019 sqltuning

199/327


Retrieves the rows returned by a query

(Fetches are performed only forSELECT statements.)

p

Executes the statement

(This step modifies the data forINSERT, UPDATE,and DELETE statements.)

EXECUTE

FETCH


There are seven categories of trace statistics:

Count

CPU

Elapsed

Number of times the procedure was executed

Number of seconds to process

Total number of seconds to execute

7/30/2019 sqltuning

200/327


Elapsed

Disk

QueryCurrent

Rows

Total number of seconds to execute

Number of physical blocks read

Number of logical buffers read for consistent readNumber of logical buffers read in current mode

Number of rows processed by the fetch or execute


The TKPROF output also includes the following:

Recursive SQL statements

Library cache misses

Parsing user ID

Execution plan

7/30/2019 sqltuning

201/327


Execution plan

Optimizer mode or hint

Row source operation...Misses in library cache during parse: 1Optimizer mode: ALL_ROWSParsing user id: 61

Rows Row Source Operation

------- ---------------------------------------------------24 TABLE ACCESS BY INDEX ROWID EMPLOYEES (cr=9 pr=0 pw=0 time=129 us)24 INDEX RANGE SCAN SAL_IDX (cr=3 pr=0 pw=0 time=1554 us)(object id

TKPROF Output with No Index: Example

...select max(cust_credit_limit)from customerswhere cust_city ='Paris'

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- -------Parse 1 0.02 0.02 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 2 0.10 0.09 1408 1459 0 1

7/30/2019 sqltuning

202/327


------- ------ -------- ---------- ---------- ---------- ---------- -------total 4 0.12 0.11 1408 1459 0 1

Misses in library cache during parse: 1Optimizer mode: ALL_ROWS

Parsing user id: 61

Rows Row Source Operation------- ---------------------------------------------------

1 SORT AGGREGATE (cr=1459 pr=1408 pw=0 time=93463 us)77 TABLE ACCESS FULL CUSTOMERS (cr=1459 pr=1408 pw=0 time=31483 us)

TKPROF Output with Index: Example

...select max(cust_credit_limit) from customerswhere cust_city ='Paris'

call count cpu elapsed disk query currentrows------- ------ -------- ---------- ---------- ---------- ---------- ---------Parse 1 0.01 0.00 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0Fetch 2 0.00 0.00 0 77 0 1------- ------ -------- ---------- ---------- ---------- ---------- ---------total 4 0.01 0.00 0 77 0 1

7/30/2019 sqltuning

203/327


Misses in library cache during parse: 1Optimizer mode: ALL_ROWSParsing user id: 61

Rows Row Source Operation------- ---------------------------------------------------

1 SORT AGGREGATE (cr=77 pr=0 pw=0 time=732 us)77 TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=77 pr=0 pw=0 time=1760 us)77 INDEX RANGE SCAN CUST_CUST_CITY_IDX (cr=2 pr=0 pw=0 time=100

us)(object id55097)

Summary


Set SQL Trace initialization parameters

SQL_TRACE, TIMED_STATISTICS

USER_DUMP_DEST, MAX_DUMP_FILE_SIZE

Enable SQL Trace for a session

7/30/2019 sqltuning

204/327


Enable SQL Trace for a session

Format trace files with TKPROF

Interpret the output

ALTER SESSION set sql_trace = true

dbms_session.set_sql_trace()

dbms_system.set_sql_trace_in_session()



Using TKPROF

Using DBMS_MONITOR

7/30/2019 sqltuning

205/327



7/30/2019 sqltuning

206/327


Objectives

After completing this lesson, you should understand

the different methods of identifying high-load SQL:

ADDM

Top SQL

Dynamic performance views

7/30/2019 sqltuning

207/327



Statspack

SQL Tuning Process: Overview

Identifyhigh-load

SQL

7/30/2019 sqltuning

208/327


Analyze SQL

Takecorrective

action


SQLworkload

Automatic(ADDM)

7/30/2019 sqltuning

209/327


High-load

SQL

Manual(Top SQL)

Automatic Database Diagnostic Monitor

MMON

SGA

In-memory

statistics 60minutes

7/30/2019 sqltuning

210/327


Snapshots

ADDM

results

AWR

ADDMADDM

results

EM

ADDM Output

ADDM

ADDM

results

AWREM

7/30/2019 sqltuning

211/327


Recommendations

Invoke

advisors

Findings

with impact

Manual Identification: Top SQL

SQLworkload

7/30/2019 sqltuning

212/327


SQL Tuning

Advisor

High-load

SQL

Top SQL

Spot SQL

7/30/2019 sqltuning

213/327


Period SQL

7/30/2019 sqltuning

214/327


Manual Identification: Statspack

Statspack:

Collects data about high-load SQL

Precalculates useful data

Cache hit ratios

Transaction statistics

7/30/2019 sqltuning

215/327


Uses permanent tables owned by the PERFSTAT

user to store performance statistics Separates data collection from report generation

Uses snapshots to compare performance at

different times

7/30/2019 sqltuning

216/327

V$SQLAREA View

First thousand characters of the SQL textSQL_TEXT

Sum of the number of sorts that were done for

all the child cursors

SORTS

Total number of executions, totaled over all the

child cursors

EXECUTIONS

DescriptionColumn

7/30/2019 sqltuning

217/327


child cursors

Sum of the number of disk reads over all child

cursors

DISK_READS

Elapsed time (in microseconds) used by this

cursor for parsing, executing, and fetching

ELAPSED_TIME

CPU time (in microseconds) used by this

cursor for parsing/executing/fetching

CPU_TIME

Querying theV$SQLAREA View

SELECT sql_text, disk_reads , sorts,

cpu_time, elapsed_time

FROM v$sqlarea

WHERE upper(sql_text) like '%PROMOTIONS%'

ORDER BY sql_text;

7/30/2019 sqltuning

218/327


Investigating Full Table Scan Operations

SELECT name, value FROM v$sysstat

WHERE name LIKE '%table scan%';

NAME VALUE--------------------------------------------- --------

table scans (short tables) 217842

7/30/2019 sqltuning

219/327


table scans (long tables) 3040

table scans (rowid ranges) 254table scans (cache partitions) 7

table scans (direct read) 213

table scan rows gotten 40068909

table scan blocks gotten 1128681

Summary

In this lesson, you should have learned about the

different methods of identifying high-load SQL:

ADDM

Top SQL

Statspack

7/30/2019 sqltuning

220/327




7/30/2019 sqltuning

221/327


Objectives


the following:

Describe automatic SQL tuning

Describe the Automatic Workload Repository

Use Automatic Database Diagnostic Monitor

Vi th h

7/30/2019 sqltuning

222/327


View the cursor cache

Perform automatic SQL tuning Use the SQL Tuning Advisor

Use the SQL Access Advisor

SQL Tuning Process: Overview

Identifyhigh-load

SQL

AnalyzeSQL

7/30/2019 sqltuning

223/327


SQL

Takecorrective

action


DBA

How can I tunehigh-load SQL?

High-load

SQL

ADDM

7/30/2019 sqltuning

224/327


SQL

SQL

workload

Automatic Tuning Optimizer

Is the query optimizer running in tuning mode

Performs verification steps

Performs exploratory steps

7/30/2019 sqltuning

225/327


SQL Tuning Advisor

SQLworkload

7/30/2019 sqltuning

226/327


SQL Tuning

Advisor

High-load

SQL

ADDM

7/30/2019 sqltuning

227/327

Statistics Analysis

AutomaticStatistics Gathering

disabledSQL Tuning

Advisor

Stale or missing

statistics

7/30/2019 sqltuning

228/327


DBMS_STATS.GATHER_TABLE_STATS(

ownname=>'SH', tabname=>'CUSTOMERS',

estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);

SQL Profiling

Optimizer(Tuning mode)

CreateSubmit

SQL ProfileSQL TuningAdvisor

Use

7/30/2019 sqltuning

229/327


Output

Databaseusers

Well-tuned plan

Optimizer(Normal mode)

No application

code change

SQL Access Path Analysis

SQL statements

SQL TuningAdvisor

Significant

f i

7/30/2019 sqltuning

230/327


Indexes

performance gain

SQL Structure Analysis

Poorly written

SQL statement

Restructured

SQL statement

How can Irewrite it?

7/30/2019 sqltuning

231/327


SQL statement

SQL Tuning

Advisor

SQL statement

Design mistakes

Type mismatchand indexes

SQL constructs

SQL Tuning Advisor: Usage Model

SQLTuningAdvisor

ADDM

Sources Manual selection

Automatic selection

AWR

AWR

High-load SQL

7/30/2019 sqltuning

232/327


Cursor cache

STS

Custom

Filter/rank

AWR

DBA

7/30/2019 sqltuning

233/327

SQL Tuning Views

Advisor information views:

DBA_ADVISOR_TASKS

DBA_ADVISOR_FINDINGS

DBA_ADVISOR_RECOMMENDATIONS

DBA_ADVISOR_RATIONALE

SQL tuning information views: DBA_SQLTUNE_STA

sqltuning

Documents

Transcript of sqltuning