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
Copyright 2004, Oracle. All rights reserved.
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
I-3 Copyright 2004, Oracle. All rights reserved.
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
I-4 Copyright 2004, Oracle. All rights reserved.
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
I-5 Copyright 2004, Oracle. All rights reserved.
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
I-6 Copyright 2004, Oracle. All rights reserved.
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
I-7 Copyright 2004, Oracle. All rights reserved.
Summary
In this lesson, you should have learned to:
Describe course objectives
Describe course schedule
7/30/2019 sqltuning
10/327
Copyright 2004, Oracle. All rights reserved.
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
1-3 Copyright 2004, Oracle. All rights reserved.
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
1-4 Copyright 2004, Oracle. All rights reserved.
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
1-5 Copyright 2004, Oracle. All rights reserved.
Database Physical Structure
Data files Online redo log files
Password fileParameter file Archive log files
Control files
7/30/2019 sqltuning
15/327
1-6 Copyright 2004, Oracle. All rights reserved.
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
1-8 Copyright 2004, Oracle. All rights reserved.
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
1-9 Copyright 2004, Oracle. All rights reserved.
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
1-10 Copyright 2004, Oracle. All rights reserved.
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
1-11 Copyright 2004, Oracle. All rights reserved.
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
1-13 Copyright 2004, Oracle. All rights reserved.
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
1-14 Copyright 2004, Oracle. All rights reserved.
Connecting to an Instance
User Server
ServerUser
Client
User Server
Oracle database
ServerApplication server
Browser
7/30/2019 sqltuning
22/327
1-16 Copyright 2004, Oracle. All rights reserved.
SQL Statement Processing Phases
CloseOpen
FetchBindParse Execute
7/30/2019 sqltuning
23/327
1-17 Copyright 2004, Oracle. All rights reserved.
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
1-19 Copyright 2004, Oracle. All rights reserved.
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
1-20 Copyright 2004, Oracle. All rights reserved.
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
1-21 Copyright 2004, Oracle. All rights reserved.
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
1-23 Copyright 2004, Oracle. All rights reserved.
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
1-25 Copyright 2004, Oracle. All rights reserved.
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
1-26 Copyright 2004, Oracle. All rights reserved.
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
1-28 Copyright 2004, Oracle. All rights reserved.
Summary
In this lesson, you should have learned about the
Oracle Database architecture and various componentsthat require tuning.
7/30/2019 sqltuning
31/327
Copyright 2004, Oracle. All rights reserved.
Following a Tuning Methodology
7/30/2019 sqltuning
32/327
2-2 Copyright 2004, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do
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
2-3 Copyright 2004, Oracle. All rights reserved.
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
2-4 Copyright 2004, Oracle. All rights reserved.
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
2-6 Copyright 2004, Oracle. All rights reserved.
Tuning Goals
Reduce the response time
Reduce resource usage
7/30/2019 sqltuning
36/327
2-8 Copyright 2004, Oracle. All rights reserved.
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
2-9 Copyright 2004, Oracle. All rights reserved.
Identifying High-Load SQL
Identify high-load orproblematic SQL
Dynamic performance views Statspack
ADDM Top SQL report
7/30/2019 sqltuning
38/327
2-10 Copyright 2004, Oracle. All rights reserved.
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
2-11 Copyright 2004, Oracle. All rights reserved.
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
2-12 Copyright 2004, Oracle. All rights reserved.
Gathering Optimizer Statistics
Gather statistics for all tables.
Gather new statistics when existing statisticsbecome stale.
7/30/2019 sqltuning
41/327
2-14 Copyright 2004, Oracle. All rights reserved.
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
2-16 Copyright 2004, Oracle. All rights reserved.
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
2-18 Copyright 2004, Oracle. All rights reserved.
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
2-19 Copyright 2004, Oracle. All rights reserved.
Maintaining Execution Plans over Time
Stored outlines
Stored statistics Locking statistics
7/30/2019 sqltuning
45/327
2-20 Copyright 2004, Oracle. All rights reserved.
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
2-22 Copyright 2004, Oracle. All rights reserved.
Automatic Tuning Mechanisms
You can perform automatic SQL tuning using:
SQL Tuning Advisor SQL Access advisor
7/30/2019 sqltuning
47/327
2-23 Copyright 2004, Oracle. All rights reserved.
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
2-25 Copyright 2004, Oracle. All rights reserved.
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
2-26 Copyright 2004, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to:
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
Copyright 2004, Oracle. All rights reserved.
Designing and Developing
for Performance
7/30/2019 sqltuning
51/327
3-2 Copyright 2004, Oracle. All rights reserved.
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
3-3 Copyright 2004, Oracle. All rights reserved.
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
3-4 Copyright 2004, Oracle. All rights reserved.
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
3-5 Copyright 2004, Oracle. All rights reserved.
Configuring the Appropriate System
Architecture for Your Requirements
Interactive applications (OLTP)
Process-driven applications (OLAP)
7/30/2019 sqltuning
55/327
3-6 Copyright 2004, Oracle. All rights reserved.
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
3-7 Copyright 2004, Oracle. All rights reserved.
Simplicity In Application Design
Simple tables
Well-written SQL Indexing only as required
Retrieving only required information
7/30/2019 sqltuning
57/327
3-8 Copyright 2004, Oracle. All rights reserved.
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
3-9 Copyright 2004, Oracle. All rights reserved.
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
3-10 Copyright 2004, Oracle. All rights reserved.
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
3-12 Copyright 2004, Oracle. All rights reserved.
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
3-13 Copyright 2004, Oracle. All rights reserved.
SQL Execution Efficiency
Good database connectivity
Using cursors Minimizing parsing
Using bind variables
Importance of Sharing Cursors
7/30/2019 sqltuning
62/327
3-14 Copyright 2004, Oracle. All rights reserved.
Importance of Sharing Cursors
Reduces parsing
Dynamically adjusts memory Improves memory usage
Writing SQL to Share Cursors
7/30/2019 sqltuning
63/327
3-15 Copyright 2004, Oracle. All rights reserved.
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
3-16 Copyright 2004, Oracle. All rights reserved.
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
3-17 Copyright 2004, Oracle. All rights reserved.
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
3-18 Copyright 2004, Oracle. All rights reserved.
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
Copyright 2004, Oracle. All rights reserved.
Introduction to the Optimizer
Objectives
7/30/2019 sqltuning
68/327
4-2 Copyright 2004, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do
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
4-3 Copyright 2004, Oracle. All rights reserved.
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
4-5 Copyright 2004, Oracle. All rights reserved.
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
4-7 Copyright 2004, Oracle. All rights reserved.
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
4-8 Copyright 2004, Oracle. All rights reserved.
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
4-9 Copyright 2004, Oracle. All rights reserved.
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
4-10 Copyright 2004, Oracle. All rights reserved.
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
4-11 Copyright 2004, Oracle. All rights reserved.
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
4-13 Copyright 2004, Oracle. All rights reserved.
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
4-14 Copyright 2004, Oracle. All rights reserved.
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
4-15 Copyright 2004, Oracle. All rights reserved.
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
4-17 Copyright 2004, Oracle. All rights reserved.
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
4-18 Copyright 2004, Oracle. All rights reserved.
Executes Statements
The factors considered by the optimizer are:
Access path Join method
Join order
Access Paths
7/30/2019 sqltuning
81/327
4-19 Copyright 2004, Oracle. All rights reserved.
Full-table scans
Row ID scans Index scans
Cluster scans
Hash scans
Join Orders
7/30/2019 sqltuning
82/327
4-20 Copyright 2004, Oracle. All rights reserved.
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
4-21 Copyright 2004, Oracle. All rights reserved.
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
4-22 Copyright 2004, Oracle. All rights reserved.
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
Copyright 2004, Oracle. All rights reserved.
Optimizer Operations
Objectives
7/30/2019 sqltuning
86/327
5-2 Copyright 2004, Oracle. All rights reserved.
After completing this lesson, you should be able to do
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
5-3 Copyright 2004, Oracle. All rights reserved.
Executes Statements
The factors considered by the optimizer are:
Access path
Join order
Join method
Access Paths
7/30/2019 sqltuning
88/327
5-4 Copyright 2004, Oracle. All rights reserved.
Full table scan
Row ID scan
Index scan
Sample table scan
Choosing an Access Path
7/30/2019 sqltuning
89/327
5-5 Copyright 2004, Oracle. All rights reserved.
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
5-6 Copyright 2004, Oracle. All rights reserved.
Lack of index
Large amount of data
Small table
Row ID Scans
7/30/2019 sqltuning
91/327
5-8 Copyright 2004, Oracle. All rights reserved.
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
5-9 Copyright 2004, Oracle. All rights reserved.
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
5-11 Copyright 2004, Oracle. All rights reserved.
Types of index scans:
Full scan
Fast-full index scan
Index join
Bitmap join
Joining Multiple Tables
7/30/2019 sqltuning
94/327
5-13 Copyright 2004, Oracle. All rights reserved.
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
5-14 Copyright 2004, Oracle. All rights reserved.
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
5-15 Copyright 2004, Oracle. All rights reserved.
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
5-17 Copyright 2004, Oracle. All rights reserved.
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
5-18 Copyright 2004, Oracle. All rights reserved.
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
5-19 Copyright 2004, Oracle. All rights reserved.
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
5-20 Copyright 2004, Oracle. All rights reserved.
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
5-21 Copyright 2004, Oracle. All rights reserved.
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
5-22 Copyright 2004, Oracle. All rights reserved.
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
5-23 Copyright 2004, Oracle. All rights reserved.
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
5-24 Copyright 2004, Oracle. All rights reserved.
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
5-25 Copyright 2004, Oracle. All rights reserved.
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
5-26 Copyright 2004, Oracle. All rights reserved.
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
5-27 Copyright 2004, Oracle. All rights reserved.
Hash join
Table access Table access
1
2 3
When Are Hash Joins Used?
7/30/2019 sqltuning
109/327
5-28 Copyright 2004, Oracle. All rights reserved.
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
5-29 Copyright 2004, Oracle. All rights reserved.
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
5-30 Copyright 2004, Oracle. All rights reserved.
Merge
Sort Sort
Table access Table access
1
2 3
4 5
When Are Sort-Merge Joins Used?
7/30/2019 sqltuning
112/327
5-31 Copyright 2004, Oracle. All rights reserved.
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
5-32 Copyright 2004, Oracle. All rights reserved.
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
5-33 Copyright 2004, Oracle. All rights reserved.
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
5-35 Copyright 2004, Oracle. All rights reserved.
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
5-38 Copyright 2004, Oracle. All rights reserved.
SORT UNIQUE
SORT AGGREGATE
SORT GROUP BY
SORT JOIN
SORT ORDER BY
Tuning Sort Performance
7/30/2019 sqltuning
117/327
5-39 Copyright 2004, Oracle. All rights reserved.
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
5-40 Copyright 2004, Oracle. All rights reserved.
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
5-41 Copyright 2004, Oracle. All rights reserved.
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
5-42 Copyright 2004, Oracle. All rights reserved.
In this lesson, you should have learned how to:
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
Copyright 2004, Oracle. All rights reserved.
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
6-3 Copyright 2004, Oracle. All rights reserved.
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
6-4 Copyright 2004, Oracle. All rights reserved.
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
6-6 Copyright 2004, Oracle. All rights reserved.
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
6-7 Copyright 2004, Oracle. All rights reserved.
_ 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
6-8 Copyright 2004, Oracle. All rights reserved.
EXPLAIN PLANCommand
Generates an optimizer execution plan
7/30/2019 sqltuning
128/327
6-9 Copyright 2004, Oracle. All rights reserved.
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
6-10 Copyright 2004, Oracle. All rights reserved.
SET STATEMENT_ID
= 'text'
EXPLAIN PLAN
INTO your plan table
FOR statement
EXPLAIN PLANCommand: Example
EXPLAIN PLAN
7/30/2019 sqltuning
130/327
6-11 Copyright 2004, Oracle. All rights reserved.
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
6-12 Copyright 2004, Oracle. All rights reserved.
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
6-13 Copyright 2004, Oracle. All rights reserved.
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
6-14 Copyright 2004, Oracle. All rights reserved.
$ 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
6-15 Copyright 2004, Oracle. All rights reserved.
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
6-16 Copyright 2004, Oracle. All rights reserved.
-------------------------------------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
6-17 Copyright 2004, Oracle. All rights reserved.
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
6-18 Copyright 2004, Oracle. All rights reserved.
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
6-23 Copyright 2004, Oracle. All rights reserved.
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
6-25 Copyright 2004, Oracle. All rights reserved.
TRACE[ONLY]
EXPLAINSTATISTICS
SHOW AUTOTRACE
SET AUTOTRACE ON
SQL*Plus AUTOTRACE: Examples
To start tracing statements using AUTOTRACE
7/30/2019 sqltuning
142/327
6-26 Copyright 2004, Oracle. All rights reserved.
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
6-27 Copyright 2004, Oracle. All rights reserved.
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
In this lesson, you should have learned how to:
Use EXPLAIN PLAN to view execution plans
7/30/2019 sqltuning
144/327
6-28 Copyright 2004, Oracle. All rights reserved.
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
6-29 Copyright 2004, Oracle. All rights reserved.
Using AUTOTRACE
Using EXPLAIN PLAN Using AWR
Retrieving the execution plan using DBMS_XPLAN
7/30/2019 sqltuning
146/327
Objectives
After completing this lesson, you should be able to do
the following:
7/30/2019 sqltuning
147/327
7-2 Copyright 2004, Oracle. All rights reserved.
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
7-3 Copyright 2004, Oracle. All rights reserved.
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
7-4 Copyright 2004, Oracle. All rights reserved.
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
7-6 Copyright 2004, Oracle. All rights reserved.
_ _
Manual statistics gathering DBMS_STATS package
Dynamic sampling
Automatic Statistics Gathering
Oracle Database 10g automates optimizer
statistics collection:
7/30/2019 sqltuning
151/327
7-7 Copyright 2004, Oracle. All rights reserved.
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
7-8 Copyright 2004, Oracle. All rights reserved.
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
7-9 Copyright 2004, Oracle. All rights reserved.
g p
Job Configuration Options
Setting status: ENABLED orDISABLED
Maintaining schedule: maintenance window
7/30/2019 sqltuning
154/327
7-10 Copyright 2004, Oracle. All rights reserved.
g
Managing the Job Scheduler
Verifying Automatic Statistics Gathering:
SELECT owner, job_name,enabledFROM DBA_SCHEDULER_JOBS
7/30/2019 sqltuning
155/327
7-11 Copyright 2004, Oracle. All rights reserved.
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
7-12 Copyright 2004, Oracle. All rights reserved.
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
7-13 Copyright 2004, Oracle. All rights reserved.
Statistics Collection Configuration
DML monitoring
Sampling
7/30/2019 sqltuning
158/327
7-14 Copyright 2004, Oracle. All rights reserved.
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
7-17 Copyright 2004, Oracle. All rights reserved.
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
7-18 Copyright 2004, Oracle. All rights reserved.
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
7-19 Copyright 2004, Oracle. All rights reserved.
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
7-20 Copyright 2004, Oracle. All rights reserved.
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
7-22 Copyright 2004, Oracle. All rights reserved.
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
7-23 Copyright 2004, Oracle. All rights reserved.
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
7-25 Copyright 2004, Oracle. All rights reserved.
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
7-26 Copyright 2004, Oracle. All rights reserved.
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
7-27 Copyright 2004, Oracle. All rights reserved.
, 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
7-28 Copyright 2004, Oracle. All rights reserved.
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
7-29 Copyright 2004, Oracle. All rights reserved.
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
7-30 Copyright 2004, Oracle. All rights reserved.
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
7-31 Copyright 2004, Oracle. All rights reserved.
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
7-32 Copyright 2004, Oracle. All rights reserved.
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
7-33 Copyright 2004, Oracle. All rights reserved.
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
7-34 Copyright 2004, Oracle. All rights reserved.
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
7-36 Copyright 2004, Oracle. All rights reserved.
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
7-37 Copyright 2004, Oracle. All rights reserved.
Generating System Statistics
I/O
CPU
7/30/2019 sqltuning
178/327
7-39 Copyright 2004, Oracle. All rights reserved.
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
7-41 Copyright 2004, Oracle. All rights reserved.
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
7-42 Copyright 2004, Oracle. All rights reserved.
GATHER_DATABASE_STATS(OPTIONS=>'GATHER AUTO')
GATHER_FIXED_OBJECTS_STATSCREATE
ALTER
DROP
Workload DDLs
7/30/2019 sqltuning
181/327
Practice 7: Overview
This practice covers the following topics:
Using DBMS_STATS to gather manual statistics
Verifying the existence of the gather stats job
7/30/2019 sqltuning
182/327
7-44 Copyright 2004, Oracle. All rights reserved.
Verifying the existence of the gather_stats_job Understanding the use of histograms
Understanding bind variable peeking
7/30/2019 sqltuning
183/327
Objectives
After completing this lesson, you should be able to do
the following:
Configure the SQL Trace facility to collect session
statistics
7/30/2019 sqltuning
184/327
8-2 Copyright 2004, Oracle. All rights reserved.
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
8-4 Copyright 2004, Oracle. All rights reserved.
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
8-5 Copyright 2004, Oracle. All rights reserved.
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
8-6 Copyright 2004, Oracle. All rights reserved.
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
8-8 Copyright 2004, Oracle. All rights reserved.
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
8-9 Copyright 2004, Oracle. All rights reserved.
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
8-10 Copyright 2004, Oracle. All rights reserved.
------------------- --------------------------
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
8-12 Copyright 2004, Oracle. All rights reserved.
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
8-13 Copyright 2004, Oracle. All rights reserved.
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
8-14 Copyright 2004, Oracle. All rights reserved.
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
8-15 Copyright 2004, Oracle. All rights reserved.
Enabling SQL Trace
For your current session:
For any session:
SQL> ALTER SESSION SET sql_trace = true;
7/30/2019 sqltuning
196/327
8-17 Copyright 2004, Oracle. All rights reserved.
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
8-19 Copyright 2004, Oracle. All rights reserved.
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
8-20 Copyright 2004, Oracle. All rights reserved.
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
8-22 Copyright 2004, Oracle. All rights reserved.
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
Output of the TKPROF Command
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
8-23 Copyright 2004, Oracle. All rights reserved.
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
Output of the TKPROF Command
The TKPROF output also includes the following:
Recursive SQL statements
Library cache misses
Parsing user ID
Execution plan
7/30/2019 sqltuning
201/327
8-25 Copyright 2004, Oracle. All rights reserved.
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
8-27 Copyright 2004, Oracle. All rights reserved.
------- ------ -------- ---------- ---------- ---------- ---------- -------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
8-28 Copyright 2004, Oracle. All rights reserved.
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
In this lesson, you should have learned how to:
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
8-29 Copyright 2004, Oracle. All rights reserved.
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()
Practice 8: Overview
This practice covers the following topics:
Using TKPROF
Using DBMS_MONITOR
7/30/2019 sqltuning
205/327
8-30 Copyright 2004, Oracle. All rights reserved.
Identifying High-Load SQL
7/30/2019 sqltuning
206/327
Copyright 2004, Oracle. All rights reserved.
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
9-2 Copyright 2004, Oracle. All rights reserved.
Dynamic performance views
Statspack
SQL Tuning Process: Overview
Identifyhigh-load
SQL
7/30/2019 sqltuning
208/327
9-3 Copyright 2004, Oracle. All rights reserved.
Analyze SQL
Takecorrective
action
Identifying High-Load SQL
SQLworkload
Automatic(ADDM)
7/30/2019 sqltuning
209/327
9-4 Copyright 2004, Oracle. All rights reserved.
High-load
SQL
Manual(Top SQL)
Automatic Database Diagnostic Monitor
MMON
SGA
In-memory
statistics 60minutes
7/30/2019 sqltuning
210/327
9-6 Copyright 2004, Oracle. All rights reserved.
Snapshots
ADDM
results
AWR
ADDMADDM
results
EM
ADDM Output
ADDM
ADDM
results
AWREM
7/30/2019 sqltuning
211/327
9-7 Copyright 2004, Oracle. All rights reserved.
Recommendations
Invoke
advisors
Findings
with impact
Manual Identification: Top SQL
SQLworkload
7/30/2019 sqltuning
212/327
9-8 Copyright 2004, Oracle. All rights reserved.
SQL Tuning
Advisor
High-load
SQL
Top SQL
Spot SQL
7/30/2019 sqltuning
213/327
9-9 Copyright 2004, Oracle. All rights reserved.
Period SQL
7/30/2019 sqltuning
214/327
9-10 Copyright 2004, Oracle. All rights reserved.
Manual Identification: Statspack
Statspack:
Collects data about high-load SQL
Precalculates useful data
Cache hit ratios
Transaction statistics
7/30/2019 sqltuning
215/327
9-11 Copyright 2004, Oracle. All rights reserved.
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
9-13 Copyright 2004, Oracle. All rights reserved.
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
9-14 Copyright 2004, Oracle. All rights reserved.
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
9-15 Copyright 2004, Oracle. All rights reserved.
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
9-16 Copyright 2004, Oracle. All rights reserved.
Dynamic performance views
Automatic SQL Tuning
7/30/2019 sqltuning
221/327
Copyright 2004, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do
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
10-2 Copyright 2004, Oracle. All rights reserved.
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
10-3 Copyright 2004, Oracle. All rights reserved.
SQL
Takecorrective
action
Automatic SQL Tuning
DBA
How can I tunehigh-load SQL?
High-load
SQL
ADDM
7/30/2019 sqltuning
224/327
10-4 Copyright 2004, Oracle. All rights reserved.
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
10-5 Copyright 2004, Oracle. All rights reserved.
SQL Tuning Advisor
SQLworkload
7/30/2019 sqltuning
226/327
10-7 Copyright 2004, Oracle. All rights reserved.
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
10-9 Copyright 2004, Oracle. All rights reserved.
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
10-10 Copyright 2004, Oracle. All rights reserved.
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
10-12 Copyright 2004, Oracle. All rights reserved.
Indexes
performance gain
SQL Structure Analysis
Poorly written
SQL statement
Restructured
SQL statement
How can Irewrite it?
7/30/2019 sqltuning
231/327
10-13 Copyright 2004, Oracle. All rights reserved.
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
10-14 Copyright 2004, Oracle. All rights reserved.
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