Oracle Database 11g SQL Tuning Workshop - Student Guide.pdf

Oracle Database 11g: SQL Tuning
Workshop
Electronic Presentation
D52163GC10
Edition 1.0
June 2008

Copyright © 2008, Oracle. All rights reserved.
Disclaimer
This document contains proprietary information and is protected by copyright and other intellectual
property laws. You may copy and print this document solely for your own use in an Oracle training
course. The document may not be modified or altered in any way. Except where your use constitutes
"fair use" under copyright law, you may not use, share, download, upload, copy, print, display,
perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part
without the express authorization of Oracle.
The information contained in this document is subject to change without notice. If you find any
problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway,
Redwood Shores, California 94065 USA. This document is not warranted to be error-free.
Restricted Rights Notice
If this documentation is delivered to the United States Government or anyone using the
documentation on behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or disclose these
training materials are restricted by the terms of the applicable Oracle license agreement and/or the
applicable U.S. Government contract.
Trademark Notice
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be
trademarks of their respective owners.
Author
Jean-François Verrier
Technical Contributors and
Reviewers
Muriel Fry (Special thanks)
Joel Goodman
Harald van Breederode
Jörn Bartels
Pekka Siltala
Bernard Soleillant
James Spiller
Clay Fuller
Ira Singer
Christopher Andrews
Magnus Isaksson
Sean Kim
Trevor Bauwen
Yash Jain
Editors
Amitha Narayan
Raj Kumar
Graphic Designer
Priya Saxena
Publishers
Jothi Lakshmi
Veena Narasimhan

Exploring the Oracle Database Architecture

1 - 2
Objectives
After completing this lesson, you should be able to:
• List the major architectural components of the Oracle
Database server
• Explain memory structures
• Describe background processes
• Correlate logical and physical storage structures

1 - 3
Database
Oracle Database Server Architecture: Overview
Instance
SGA
BGP2
BGP1 BGPn
BGP3

1 - 4
Connecting to the Database Instance
• Connection: Bidirectional network
pathway between a user process
on a client or middle tier and an
Oracle process on the server
• Session: Representation of
a specific login by a user
SQL> Select …
Connection
User
User
process
Server
process
Session (Specific connected database user)
S000
User
process
User
process
Dedicated
Server
Shared
Server
D000
Dispatcher
SGA
Listener
process
Server host

1 - 6
Oracle Database Memory Structures: Overview
Background
process
Server
process
Server
process
SGA
Redo log
buffer
Database buffer
cache
Java
pool
Streams
pool
Shared pool Large pool
Aggregated
PGA
… …
…

1 - 7
Database Buffer Cache
• Is a part of the SGA
• Holds copies of data blocks that are read from data files
• Is shared by all concurrent processes
Database writer
process
Database
buffer
cache
SGA
Data files
DBWn
Server
process

1 - 8
Redo Log Buffer
• Is a circular buffer in the SGA (based on the number of
CPUs)
• Contains redo entries that have the information to redo
changes made by operations, such as DML and DDL
Log writer
process
Redo log
buffer
SGA
Redo log
files
LGWR
Server
process

1 - 9
SGA
Shared Pool
• Is part of the SGA
• Contains:
– Library cache
— Shared parts of SQL and
PL/SQL statements
– Data dictionary cache
– Result cache:
— SQL queries
— PL/SQL functions
– Control structures
— Locks
Library
cache
Data
dictionary
cache
(row cache)
Control
structures
Result
cache
Server
process
Shared pool

1 - 10
Processing a DML Statement: Example
Database
Data
files
Control
files
Redo
log files
User
process
Shared pool
Redo log
buffer
Server
process 3
5
1 Library cache
2
4
Database
buffer cache
DBWn SGA
2

1 - 11
COMMIT Processing: Example
Database
Data
files
Control
files
Redo
log files
User
process
SGA
Shared pool
Redo log
buffer
Server
process 1
3
Library cache
Database
buffer cache
DBWn
2
LGWR
SGA

1 - 12
• Provides large memory allocations for:
– Session memory for the shared server and Oracle XA
interface
– Parallel execution buffers
– I/O server processes
– Oracle Database backup
and restore operations
• Optional pool better suited
when using the following:
– Parallel execution
– Recovery Manager
– Shared server
SGA
Server
process
Large Pool
Large pool
I/O buffer
Free
memory
Response
queue
Request
queue

1 - 13
Java Pool and Streams Pool
• Java pool memory is used in server memory for all session-
specific Java code and data in the JVM.
• Streams pool memory is used exclusively by Oracle Streams
to:
– Store buffered queue messages
– Provide memory for Oracle Streams processes
Java pool Streams pool

1 - 14
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.
Stack
Space
User Global Area (UGA)
User
Session
Data
Cursor
Status
SQL
Area
Server
process

1 - 15
Background Process Roles
PMON SMON ARCn
DBWn LGWR
CKPT
Database
buffer
cache
Shared pool
SGA Redo log
buffer
MMON CJQ0 QMNn
RCBG MMAN

1 - 16
SGA
Java
pool
Fixed SGA
Redo log
buffer
Database
buffer cache
Automatic Shared Memory Management
Which size to choose?
Large pool
Shared pool
Streams
pool
SGA_TARGET + STATISTICS_LEVEL
Automatically tuned SGA components

1 - 17
Automated SQL Execution Memory Management
Background
process
Server
process
Server
process
… …
…
PGA_AGGREGATE_TARGET
Which size to choose?
Aggregated
PGA

1 - 18
Automatic Memory Management
• Sizing of each memory component is vital for SQL execution
performance.
• It is difficult to manually size each component.
• Automatic memory management automates memory
allocation of each SGA component and aggregated PGA.
Buffer
cache
Large
pool
Shared
pool
Java
pool
Streams
pool
Private
SQL
areas
Other
SGA
Aggregated PGA memory
SGA memory
Untunable
PGA
Free
MEMORY_TARGET + STATISTICS_LEVEL
MMAN

1 - 19
Database Storage Architecture
Online redo log files
Password file
Parameter file Archived redo log
files
Control files Data files
Alert log and trace files
Backup files

1 - 21
Logical and Physical Database Structures
Database
Logical Physical
Tablespace Data file
OS block
Segment
Extent
Oracle data
block
Schema
0, 1, or many
Only 1 with
bigfile
tablespaces
Undo tablespaces
never have 0

1 - 23
Segments, Extents, and Blocks
• Segments exist in a tablespace.
• Segments are collections of extents.
• Extents are collections of data blocks.
• Data blocks are mapped to disk blocks.
Segment Extents Data
blocks
Disk
blocks

1 - 24
SYSTEM and SYSAUX Tablespaces
• The SYSTEM and SYSAUX tablespaces are mandatory
tablespaces that are created at the time of database
creation. They must be online.
• The SYSTEM tablespace is used for core functionality (for
example, data dictionary tables).
• The auxiliary SYSAUX tablespace is used for additional
database components (such as the Enterprise Manager
Repository).

1 - 25
Summary
In this lesson, you should have learned how to:
• List the major architectural components of the Oracle
Database server
• Explain memory structures
• Describe background processes
• Correlate logical and physical storage structures

1 - 26
Practice 1: Overview
This practice covers the following topics:
• Listing the different components of an Oracle Database
server
• Looking at some instance and database components directly
on your machine

Introduction to SQL Tuning

2 - 2
Objectives
• Describe what attributes of a SQL statement can make it
perform poorly
• List the Oracle tools that can be used to tune SQL
• List the tuning tasks

2 - 3
Reasons for Inefficient SQL Performance
• Stale or missing optimizer statistics
• Missing access structures
• Suboptimal execution plan selection
• Poorly constructed SQL

2 - 4
Inefficient SQL: Examples
SELECT COUNT(*) FROM products p
WHERE prod_list_price <
1.15 * (SELECT avg(unit_cost) FROM costs c
WHERE c.prod_id = p.prod_id)
SELECT * FROM job_history jh, employees e
WHERE substr(to_char(e.employee_id),2) =
substr(to_char(jh.employee_id),2)
SELECT * FROM orders WHERE order_id_char = 1205
SELECT * FROM employees
WHERE to_char(salary) = :sal
1
2
3
4
SELECT * FROM parts_old
UNION
SELECT * FROM parts_new
5

2 - 6
Performance Monitoring Solutions
Snapshots
In-memory
statistics
AWR report
SGA
60 mn
ADDM
results
Snapshots
Statspack
Fore-
-ground
Automatic
ADDM
Alerts
ASH
AST
AWR
MMON

2 - 8
Monitoring and Tuning Tools: Overview
Perf
views
SQL
traces
Statspack AWR
reports
EM
perf
pages
Services
Optimizer
statistics
SQL
statistics
Metrics ASH
Wait
model
Time
model
OS
statistics
System
Session
statistics
tkprof trcsess
Base/
Segment
statistics
AWR
baseline
Compared
periods
ADDM
and
advisors
Alert
log
Service
statistics
ASH
report
Histograms
SPA
Alerts
Metric
base
line
Hang
analyzer
Direct
SGA
monitor
SQL
report

2 - 9
EM Performance Pages for Reactive Tuning
Home
Performance
Top
Activity
Top
Consu-
-mers
Duplicate
SQL
Blocking
Sessions
Hang
Analysis
Instance
Locks
Instance
Activity
Baseline
Normalized
Metrics
Nonidle
wait
classes
Top
Sessions
Top
Services
Top
Modules
Top
Actions
Top
Files
Top
Objects
Top
SQL
Wait
event
histograms
ASH
Report
SQL
Tuning
Advisor
SQL
Tuning
Sets
Enable/Disable
aggregation
Enable/Disable
SQL trace
View
SQL trace file
System
statistics
Run
ADDM
SPA
Wait
class
details

2 - 10
Tuning Tools: Overview
• Automatic Database Diagnostic Monitor (ADDM)
• SQL Tuning Advisor
• SQL Tuning Sets
• SQL Access Advisor
• SQL Performance Analyzer
• SQL Monitoring
• SQL Plan Management

2 - 11
SQL Tuning Tasks: Overview
• Identifying high-load SQL
• Gathering statistics
• Generating system statistics
• Rebuilding existing indexes
• Maintaining execution plans
• Creating new index strategies

2 - 12
CPU and Wait Time Tuning Dimensions
Scalability is a system’s ability to process more workload with a
proportional increase in system resource use.
Scalable
application
Scalable
application
Possibly
needs SQL
tuning
Needs
instance/RAC
tuning
CPU
time
Wait
time
No gain achieved
by adding
CPUs/nodes

2 - 13
Scalability with Application Design,
Implementation, and Configuration
Applications have a significant impact on scalability.
• Poor schema design can cause expensive SQL that does
not scale.
• Poor transaction design can cause locking and serialization
problems.
• Poor connection management can cause unsatisfactory
response times.

2 - 14
Common Mistakes on Customer Systems
1. Bad connection management
2. Bad use of cursors and the shared pool
3. Excess of resources consuming SQL statements
4. Use of nonstandard initialization parameters
5. Poor database disk configuration
6. Redo log setup problems
7. Excessive serialization
8. Inappropriate full table scans
9. Large number of space-management or parse-related
generated SQL statements
10.Deployment and migration errors
EDUCATE USERS

2 - 16
Proactive Tuning Methodology
• Simple design
• Data modeling
• Tables and indexes
• Using views
• Writing efficient SQL
• Cursor sharing
• Using bind variables

2 - 17
Simplicity in Application Design
• Simple tables
• Well-written SQL
• Indexing only as required
• Retrieving only required information

2 - 18
Data Modeling
• Accurately represent business practices
• Focus on the most frequent and important business
transactions
• Use modeling tools
• Appropriately normalize data (OLTP versus DW)

2 - 19
Table Design
• Compromise between flexibility and performance:
– Principally normalize
– Selectively denormalize
• Use Oracle performance and management features:
– Default values
– Constraints
– Materialized views
– Clusters
– Partitioning
• Focus on business-critical tables

2 - 20
Index Design
• Create indexes on the following:
– Primary key (can be automatically created)
– Unique key (can be automatically created)
– Foreign keys (good candidates)
• Index data that is frequently queried (select list).
• Use SQL as a guide to index design.

2 - 21
Using Views
• Simplifies application design
• Is transparent to the developer
• Can cause suboptimal execution plans

2 - 22
SQL Execution Efficiency
• Good database connectivity
• Minimizing parsing
• Share cursors
• Using bind variables

2 - 24
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 (improves readability):
– Case
– White space
– Comments
– Object references
– Bind variables

2 - 25
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.

2 - 26
Summary
• Describe what attributes of a SQL statement can make it
perform poorly
• List the Oracle tools that can be used to tune SQL
• List the tuning tasks

2 - 27
• Rewriting queries for better performance
• Rewriting applications for better performance

Introduction to the Optimizer

3 - 2
Objectives
• Describe the execution steps of a SQL statement
• Discuss the need for an optimizer
• Explain the various phases of optimization
• Control the behavior of the optimizer

3 - 3
DML
TCS
DDL
INSERT
UPDATE
DELETE
MERGE
SELECT
COMMIT
ROLLBACK
SAVEPOINT
SET TRANSACTION
CREATE
DROP
ALTER
RENAME
TRUNCATE
GRANT
REVOKE
AUDIT
NOAUDIT
COMMENT
Structured Query Language
SessionCS
ALTER SESSION
SET ROLE
SystemCS
ALTER SYSTEM
ESS
DECLARE
CONNECT
OPEN
CLOSE
DESCRIBE
WHENEVER
PREPARE
EXECUTE
FETCH

3 - 4
SQL Statement Representation
Shared
SQL area
Private
SQL area
Private
SQL area
Private
SQL area
Shared
SQL area
Private
SQL area
Private
SQL area

3 - 5
SQL Statement Implementation
SGA
Shared
SQL area
Library cache
Data dictionary
cache
Result cache
Shared
SQL area
Other
SHARED_POOL
User
process
Server
process
Private
SQL area
User
process
Server
process
User
process
Server
process
User
process
Server
process
User
process
Server
process
Private
SQL area
Private
SQL area
Private
SQL area
Private
SQL area
Java pool
Streams pool
Buffer cache
Redo log
buffer
Client
Server
Aggregated
PGA

3 - 6
SQL Statement Processing: Overview
OPEN
PARSE
describe? DESCRIBE
more?
DEFINE
query?
reparse? bind? BIND
FETCH
query?
PARALLELIZE
EXECUTE
execute
others?
CLOSE
yes
no
yes
yes
no
no
yes
yes
yes
more?
more?
yes
no
no
yes
no
no
no
no
yes
yes
no
more?

3 - 7
SQL Statement Processing: Steps
1. Create a cursor.
2. Parse the statement.
3. Describe query results.
4. Define query output.
5. Bind variables.
6. Parallelize the statement.
7. Execute the statement.
8. Fetch rows of a query.
9. Close the cursor.

3 - 8
Step 1: Create a Cursor
• A cursor is a handle or name for a private SQL area.
• It contains information for statement processing.
• It is created by a program interface call in expectation of a
SQL statement.
• The cursor structure is independent of the SQL statement
that it contains.

3 - 9
Step 2: Parse the Statement
• Statement passed from the user process to the Oracle
instance
• Parsed representation of SQL created and moved into the
shared SQL area if there is no identical SQL in the shared
SQL area
• Can be reused if identical SQL exists

3 - 10
Steps 3 and 4: Describe and Define
• The describe step provides information about the select list
items; it is relevant when entering dynamic queries through
an OCI application.
• The define step defines location, size, and data type
information required to store fetched values in variables.

3 - 11
Steps 5 and 6: Bind and Parallelize
• Bind any bind values:
– Enables memory address to store data values
– Allows shared SQL even though bind values may change
• Parallelize the statement:
– SELECT
– INSERT
– UPDATE
– MERGE
– DELETE
– CREATE
– ALTER

3 - 12
Steps 7 Through 9
• Execute:
– Drives the SQL statement to produce the desired results
• Fetch rows:
– Into defined output variables
– Query results returned in table format
– Array fetch mechanism
• Close the cursor.

3 - 13
SQL Statement Processing PL/SQL: Example
SQL> variable c1 number
SQL> execute :c1 := dbms_sql.open_cursor;
SQL> variable b1 varchar2
SQL> execute dbms_sql.parse
2 (:c1
3 ,'select null from dual where dummy = :b1'
4 ,dbms_sql.native);
SQL> execute :b1:='Y';
SQL> exec dbms_sql.bind_variable(:c1,':b1',:b1);
SQL> variable r number
SQL> execute :r := dbms_sql.execute(:c1);
SQL> variable r number
SQL> execute :r := dbms_sql.close_cursor(:c1);

3 - 14
Syntactic and semantic check
SQL Statement Parsing: Overview
Privileges check
Allocate private SQL Area
Existing shared
SQL area?
Allocate shared SQL area
Execute statement
No
(Hard parse)
Yes (Soft parse)
Parse
call
Parse operation
(Optimization)
Private
SQL area
Shared
SQL area
Parsed representation

3 - 16
Why Do You Need an Optimizer?
SELECT * FROM emp WHERE job = 'MANAGER';
How can I retrieve these rows?
Use the
index.
Read
each row
and check.
Which one is faster?
Query to optimize
Only 1% of employees are managers
Statistics
Schema
information
Use the
index
1
2
3
Possible access paths
I have a plan!

3 - 17
Why Do You Need an Optimizer?
SELECT * FROM emp WHERE job = 'MANAGER';
How can I retrieve these rows?
Use the
index.
Read
each row
and check.
Which one is faster?
Query to optimize
80% of employees are managers
Statistics
Schema
information
Use Full
Table Scan
Possible access paths
I have a plan!
1
2
3

3 - 18
Optimization During Hard Parse Operation
Statistics
Transformer
Dictionary
Optimizer
Estimator
Plan Generator
CBO
Execution Plan
Parsed representation
(query blocks)
Shared
SQL area

3 - 19
Transformer: OR Expansion Example
• Original query:
SELECT *
FROM emp
WHERE job = 'CLERK' OR deptno = 10;
SELECT *
FROM emp
WHERE job = 'CLERK'
UNION ALL
SELECT *
FROM emp
WHERE deptno = 10 AND job <> 'CLERK';
• Equivalent transformed query:
B*-tree Index

3 - 20
Transformer: Subquery Unnesting Example
SELECT *
FROM accounts
WHERE custno IN
(SELECT custno FROM customers);
SELECT accounts.*
FROM accounts, customers
WHERE accounts.custno = customers.custno;
• Original query:
Primary or unique key

3 - 21
Transformer: View Merging Example
CREATE VIEW emp_10 AS
SELECT empno, ename, job, sal, comm, deptno
FROM emp
WHERE deptno = 10;
SELECT empno FROM emp_10 WHERE empno > 7800;
SELECT empno
FROM emp
WHERE deptno = 10 AND empno > 7800;
• Original query:
Index

3 - 22
Transformer: Predicate Pushing Example
CREATE VIEW two_emp_tables AS
SELECT empno, ename, job, sal, comm, deptno FROM emp1
UNION
SELECT empno, ename, job, sal, comm, deptno FROM emp2;
SELECT ename FROM two_emp_tables WHERE deptno = 20;
SELECT ename
FROM ( SELECT empno, ename, job,sal, comm, deptno
FROM emp1 WHERE deptno = 20
UNION
SELECT empno, ename, job,sal, comm, deptno
FROM emp2 WHERE deptno = 20 );
• Original query:
Index

3 - 23
Transformer: Transitivity Example
• Original query:
SELECT *
FROM emp, dept
WHERE emp.deptno = 20 AND emp.deptno = dept.deptno;
SELECT *
FROM emp, dept
WHERE emp.deptno = 20 AND emp.deptno = dept.deptno
AND dept.deptno = 20;
Index

3 - 24
Cost-Based Optimizer
• Piece of code:
– Estimator
– Plan generator
• Estimator determines cost of optimization suggestions made
by the plan generator:
– Cost: Optimizer’s best estimate of the number of standardized
I/Os made to execute a particular statement optimization
• Plan generator:
– Tries out different statement optimization techniques
– Uses the estimator to cost each optimization suggestion
– Chooses the best optimization suggestion based on cost
– Generates an execution plan for best optimization

3 - 25
Estimator: Selectivity
• Selectivity is the estimated proportion of a row set retrieved
by a particular predicate or combination of predicates.
• It is expressed as a value between 0.0 and 1.0:
– High selectivity: Small proportion of rows
– Low selectivity: Big proportion of rows
• Selectivity computation:
– If no statistics: Use dynamic sampling
– If no histograms: Assume even distribution of rows
• Statistic information:
– DBA_TABLES and DBA_TAB_STATISTICS (NUM_ROWS)
– DBA_TAB_COL_STATISTICS (NUM_DISTINCT, DENSITY,
HIGH/LOW_VALUE,…)
Selectivity =
Number of rows satisfying a condition
Total number of rows

3 - 26
Estimator: Cardinality
• Expected number of rows retrieved by a particular operation
in the execution plan
• Vital figure to determine join, filters, and sort costs
• Simple example:
– The number of distinct values in DEV_NAME is 203.
– The number of rows in COURSES (original cardinality) is 1018.
– Selectivity = 1/203 = 4.926*e-03
– Cardinality = (1/203)*1018 = 5.01 (rounded off to 6)
Cardinality = Selectivity * Total number of rows
SELECT days FROM courses WHERE dev_name = 'ANGEL';

3 - 27
Estimator: Cost
• Cost is the optimizer’s best estimate of the number of
standardized I/Os it takes to execute a particular statement.
• Cost unit is a standardized single block random read:
– 1 cost unit = 1 SRds
• The cost formula combines three different costs units into
standard cost units.
#SRds*sreadtim + #MRds*mreadtim + #CPUCycles/cpuspeed
sreadtim
Cost=
Single block I/O cost Multiblock I/O cost CPU cost
#SRds: Number of single block reads
#MRds: Number of multiblock reads
#CPUCycles: Number of CPU Cycles
Sreadtim: Single block read time
Mreadtim: Multiblock read time
Cpuspeed: Millions instructions per second

3 - 28
Plan Generator
select e.last_name, c.loc_id
from employees e, classes c where e.emp_id = c.instr_id;
Join order[1]: DEPARTMENTS[D]#0 EMPLOYEES[E]#1
NL Join: Cost: 41.13 Resp: 41.13 Degree: 1
SM cost: 8.01
HA cost: 6.51
Best:: JoinMethod: Hash
Cost: 6.51 Degree: 1 Resp: 6.51 Card: 106.00
Join order[2]: EMPLOYEES[E]#1 DEPARTMENTS[D]#0
NL Join: Cost: 121.24 Resp: 121.24 Degree: 1
SM cost: 8.01
HA cost: 6.51
Join order aborted
Final cost for query block SEL$1 (#0)
All Rows Plan:
Best join order: 1
+----------------------------------------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost |
+----------------------------------------------------------------+
| 0 | SELECT STATEMENT | | | | 7 |
| 1 | HASH JOIN | | 106 | 6042 | 7 |
| 2 | TABLE ACCESS FULL | DEPARTMENTS| 27 | 810 | 3 |
| 3 | TABLE ACCESS FULL | EMPLOYEES | 107 | 2889 | 3 |
+----------------------------------------------------------------+

3 - 29
Controlling the Behavior of the Optimizer
• CURSOR_SHARING: SIMILAR, EXACT, FORCE
• DB_FILE_MULTIBLOCK_READ_COUNT
• PGA_AGGREGATE_TARGET
• STAR_TRANSFORMATION_ENABLED
• RESULT_CACHE_MODE: MANUAL, FORCE
• RESULT_CACHE_MAX_SIZE
• RESULT_CACHE_MAX_RESULT
• RESULT_CACHE_REMOTE_EXPIRATION

3 - 32
Controlling the Behavior of the Optimizer
• OPTIMIZER_INDEX_CACHING
• OPTIMIZER_INDEX_COST_ADJ
• OPTIMIZER_FEATURES_ENABLED
• OPTIMIZER_MODE: ALL_ROWS, FIRST_ROWS, FIRST_ROWS_n
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES
• OPTIMIZER_USE_SQL_PLAN_BASELINES
• OPTIMIZER_DYNAMIC_SAMPLING
• OPTIMIZER_USE_INVISIBLE_INDEXES
• OPTIMIZER_USE_PENDING_STATISTICS

3 - 34
Optimizer Features and Oracle Database Releases
Null aware antijoins
Group by placement optimization
Partition pruning using join filtering
Use native implementation for full outer joins
Use extended statistics to estimate selectivity
Adaptive cursor sharing
Allow rewrites with multiple MVs and/or base tables
Cost-based query transformations
Automatically compute index statistics as part of creation
Skip unusable indexes
Query rewrite enables
Dynamic sampling
Index joins
Peeking into user-defined bind variables
Complex view merging
Consideration of bitmap access to paths for tables with
only B-tree indexes
Index fast full scan
11.1.0.6
10.2.0 to 10.2.0.2
10.1.0 to 10.1.0.5
9.0.0 to 9.2.0
Features
OPTIMIZER_FEATURES_ENABLED

3 - 35
Summary
• Describe the execution steps of a SQL statement
• Describe the need for an optimizer
• Explain the various phases of optimization
• Control the behavior of the optimizer

3 - 36
This practice covers exploring a trace file to understand the
optimizer’s decisions.

Optimizer Operators

4 - 2
Objectives
• Describe most of the SQL operators
• List the possible access paths
• Explain how join operations are performed

4 - 3
Row Source Operations
• Unary operations
– Access Path
• Binary operations
– Joins
• N-ary operations

4 - 4
Main Structures and Access Paths
Access Paths
1. Full Table Scan
2. Rowid Scan
3. Sample Table Scan
4. Index Scan (Unique)
5. Index Scan (Range)
6. Index Scan (Full)
7. Index Scan (Fast Full)
8. Index Scan (Skip)
9. Index Scan (Index Join)
10. Using Bitmap Indexes
11. Combining Bitmap Indexes
Structures
Tables
Indexes

4 - 5
Full Table Scan
• Performs multiblock reads
(here DB_FILE_MULTIBLOCK_READ_COUNT = 4)
• Reads all formatted blocks below the high-water mark
• May filter rows
• Faster than index
range scans for large amount of data
select * from emp where ename='King';
---------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
---------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)|
|* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)|
---------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ENAME"='King')
B B B B B B B B B
...
HWM

4 - 6
Full Table Scans: Use Cases
• No suitable index
• Low selectivity filters (or no filters)
• Small table
• High degree of parallelism
• Full table scan hint: FULL (<table name>)

4 - 7
ROWID Scan
select * from scott.emp where rowid='AAAQ+LAAEAAAAAfAAJ';
------------------------------------------------------------------
------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 37 | 1|
| 1 | TABLE ACCESS BY USER ROWID| EMP | 1 | 37 | 1|
------------------------------------------------------------------
B B
B
B B
Block
6959–Row
2
.
1034,JF,V,10,
…
2145,MH,V,20,
…
Row migration

4 - 8
Sample Table Scans
SELECT * FROM emp SAMPLE BLOCK (10) [SEED (1)];
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | TABLE ACCESS SAMPLE| EMP | 4 | 99 | 2 (0)|
---------------------------------------------------------------------
B B
B
B B

4 - 10
Indexes: Overview
Index storage techniques:
• B*-tree indexes: The default and the most common
– Normal
– Function based: Precomputed value of a function or
expression
– Index-organized table (IOT)
– Bitmap indexes
– Cluster indexes: Defined specifically for cluster
• Index attributes:
– Key compression
– Reverse key
– Ascending, descending
• Domain indexes: Specific to an application or cartridge

4 - 12
Normal B*-tree Indexes
Index entry header
Key column length
Key column value
rowid
Root
Branch
Leaf
Index entry
Table data retrieved by using rowid

4 - 13
Index Scans
Types of index scans:
• Unique
• Min/Max
• Range (Descending)
• Skip
• Full and fast full
• Index join
B-Tree index IX_EMP
B B
B
B
B B
Table EMP
B : block

4 - 14
Index Unique Scan
create unique index PK_EMP on EMP(empno)
select * from emp where empno = 9999;
--------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost|
--------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 37 | 1|
| 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 0|
--------------------------------------------------------------------
---------------------------------------------------
2 - access("EMPNO"=9999)
index UNIQUE Scan PK_EMP

4 - 15
Index Range Scan
create index I_DEPTNO on EMP(deptno);
select /*+ INDEX(EMP I_DEPTNO) */ *
from emp where deptno = 10 and sal > 1000;
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 261 | 2
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 3 | 261 | 2
| 2 | INDEX RANGE SCAN | I_DEPTNO | 3 | | 1
---------------------------------------------------------------------
---------------------------------------------------
1 - filter("SAL">1000)
2 - access("DEPTNO"=10)
Index Range SCAN I_DEPTNO

4 - 16
Index Range Scan: Descending
create index IDX on EMP(deptno);
select * from emp where deptno>20 order by deptno desc;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 2 | INDEX RANGE SCAN DESCENDING| IDX | 6 | | 1|
---------------------------------------------------------------------
---------------------------------------------------
2 - access("DEPTNO">20)
Index Range SCAN IDX

4 - 17
Descending Index Range Scan
create index IX_D on EMP(deptno desc);
select * from emp where deptno <30;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 2 | INDEX RANGE SCAN | IX_D | 1 | | 1|
---------------------------------------------------------------------
---------------------------------------------------
2 - access(SYS_OP_DESCEND("DEPTNO")>HEXTORAW('3EE0FF') )
filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("DEPTNO"))<30)
Index Range SCAN IX_D

4 - 18
Index Range Scan: Function-Based
create index IX_FBI on EMP(UPPER(ename));
select * from emp where upper(ENAME) like 'A%';
---------------------------------------------------------------------
---------------------------------------------------------------------
| 2 | INDEX RANGE SCAN | IX_FBI | 1 | | 1|
---------------------------------------------------------------------
---------------------------------------------------
2 - access(UPPER("ENAME") LIKE 'A%')
filter(UPPER("ENAME") LIKE 'A%')
Index Range SCAN IX_FBI

4 - 20
Index Fast Full Scan
LEGEND:
SH=segment header
R=root block
B=branch block
L=leaf block
L
...
R B B
L L L L L
SH
multiblock read
discard discard discard
db_file_multiblock_read_count = 4
multiblock read
select /*+ INDEX_FFS(EMP I_DEPTNO) */ deptno from emp
where deptno is not null;
----------------------------------------------------------------
----------------------------------------------------------------
| 1 | INDEX FAST FULL SCAN| I_DEPTNO | 14 | 42 | 2|
----------------------------------------------------------------
---------------------------------------------------
1 - filter("DEPTNO" IS NOT NULL)

4 - 21
Index Skip Scan
F10
F11
F12
F13
F14
F15
Min F16 F20 F26 F30 M10 M16 M20 M26 M30
Min M10
F16
F17
F18
F19
F20
F21
F22
F23
F24
F25
F26
F27
F28
F29
F30
F31
F32
F33
F34
F35
M10
M11
M12
M13
M14
M15
M16
M17
M18
M19
M20
M21
M22
M23
M24
M25
M26
M27
M28
M29
M30
M31
M32
M33
M34
M35
Index on (GENDER, AGE)
SELECT * FROM employees WHERE age BETWEEN 20 AND 29
B1 B2
L1 L3
L2 L4 L8
L5 L6 L7 L9
R
L10

4 - 23
Index Skip Scan: Example
create index IX_SS on EMP(DEPTNO,SAL);
select /*+ index_ss(EMP IX_SS) */ * from emp where SAL < 1500;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 6 | 222 | 6 |
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 6 | 222 | 6 |
| 2 | INDEX SKIP SCAN | IX_SS | 6 | | 5 |
---------------------------------------------------------------------
---------------------------------------------------
2 - access("SAL"<1500)
filter("SAL"<1500)
Index on (DEPTNO, SAL)

4 - 24
Index Join Scan
alter table emp modify (SAL not null, ENAME not null);
create index I_ENAME on EMP(ename);
create index I_SAL on EMP(sal);
select /*+ INDEX_JOIN(e) */ ename, sal from emp e;
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 140 |
| 1 | VIEW | index$_join$_001 | 14 | 140 |
| 2 | HASH JOIN | | | |
| 3 | INDEX FAST FULL SCAN| IX_SS | 14 | 140 |
| 4 | INDEX FAST FULL SCAN| I_ENAME | 14 | 140 |
--------------------------------------------------------------------
---------------------------------------------------
2 - access(ROWID=ROWID)

4 - 25
The AND-EQUAL Operation
SELECT /*+ AND_EQUAL(emp isal ijob) */ *
FROM emp
WHERE sal=1000 and job='CLERK';
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 87 | 2 |
| 2 | AND-EQUAL | | | | |
| 3 | INDEX RANGE SCAN | ISAL | 1 | | 1 |
| 4 | INDEX RANGE SCAN | IJOB | 4 | | 1 |
---------------------------------------------------------------------
---------------------------------------------------
1 - filter("SAL"=1000 AND "JOB"='CLERK')
3 - access("SAL"=1000)
4 - access("JOB"='CLERK')

4 - 26
B*-tree Indexes and Nulls
create table nulltest ( col1 number, col2 number not null);
create index nullind1 on nulltest (col1);
create index notnullind2 on nulltest (col2);
select /*+ index(t nullind1) */ col1 from nulltest t;
--------------------------------------------------------------------
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10000 | 126K| 11 (0)|
| 1 | TABLE ACCESS FULL| NULLTEST | 10000 | 126K| 11 (0)|
select col1 from nulltest t where col1=10;
-------------------------------------------------------------------
-------------------------------------------------------------------
| 1 | INDEX RANGE SCAN| NULLIND1 | 1 | 13 | 1 (0)|
select /*+ index(t notnullind2) */ col2 from nulltest t;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | INDEX FULL SCAN | NOTNULLIND2 | 1 | 13 | 2 (0)|

4 - 27
Using Indexes: Considering Nullable Columns
SELECT COUNT(*) FROM person;
SELECT STATEMENT |
SORT AGGREGATE |
TABLE ACCESS FULL| PERSON
SSN
FNAME
LNAME
PERSON
CREATE UNIQUE INDEX person_ssn_ix
ON person(ssn);
DROP INDEX person_ssn_ix;
Column Null?
Y
Y
N
ALTER TABLE person ADD CONSTRAINT pk_ssn
PRIMARY KEY (ssn);
SELECT /*+ INDEX(person) */ COUNT(*) FROM
person;
SELECT STATEMENT |
SORT AGGREGATE |
INDEX FAST FULL SCAN| PK_SSN
SSN
FNAME
LNAME
PERSON
Column Null?
N
Y
N

4 - 28
Index-Organized Tables
Indexed
access on table
ROWID
Accessing
index-organized table
Row header
Nonkey columns
Key column

4 - 29
Index-Organized Table Scans
select * from iotemp where empno=9999;
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost|
---------------------------------------------------------------------
| 1 | INDEX UNIQUE SCAN| SYS_IOT_TOP_75664 | 1 | 87 | 1|
---------------------------------------------------------------------
---------------------------------------------------
1 - access("EMPNO"=9999)
select * from iotemp where sal>1000;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | INDEX FAST FULL SCAN| SYS_IOT_TOP_75664 | 12 | 1044 |
---------------------------------------------------------------------
---------------------------------------------------

4 - 30
Bitmap Indexes
<Blue, 10.0.3, 12.8.3, 100010000 010000000 010010100>
<Green, 10.0.3, 12.8.3, 000101000 000000000 100100000>
<Red, 10.0.3, 12.8.3, 010000000 001100000 000001001>
<Yellow, 10.0.3, 12.8.3, 001000000 100000000 001000010>
Key Start
ROWID
End
ROWID
Bitmap
Table
Index
Block 10
Block 11
Block 12
File 3

4 - 31
Bitmap Index Access: Examples
SELECT * FROM PERF_TEAM WHERE country='FR';
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | |
| 3 | BITMAP INDEX SINGLE VALUE | IX_B2 | | |
---------------------------------------------------------------------
Predicate: 3 - access("COUNTRY"='FR')
SELECT * FROM PERF_TEAM WHERE country>'FR';
---------------------------------------------------------------------
---------------------------------------------------------------------
| 3 | BITMAP INDEX RANGE SCAN | IX_B2 | | |
---------------------------------------------------------------------
Predicate: 3 - access("COUNTRY">'FR') filter("COUNTRY">'FR')

4 - 32
Combining Bitmap Indexes: Examples
SELECT * FROM PERF_TEAM WHERE country in('FR','DE');
FR 0 0 1 1 1 1 0 0 0 0 0 0
DE 0 1 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 1 0 0 0 0 0
OR
SELECT * FROM EMEA_PERF_TEAM T WHERE country='FR' and gender='M';
F 0 0 1 1 1 1 0 0 0 0 0 0
M 1 1 1 0 1 1 0 1 0 1 1 1
0 0 1 0 1 1 0 0 0 0 0
AND

4 - 33
Combining Bitmap Index Access Paths
SELECT * FROM PERF_TEAM WHERE country in ('FR','DE');
---------------------------------------------------------------------
| 1 | INLIST ITERATOR | | | |
| 4 | BITMAP INDEX SINGLE VALUE | IX_B2 | | |
Predicate: 4 - access("COUNTRY"='DE' OR "COUNTRY"='FR')
SELECT * FROM PERF_TEAM WHERE country='FR' and gender='M';
---------------------------------------------------------------------
| 3 | BITMAP AND | | | |
| 4 | BITMAP INDEX SINGLE VALUE| IX_B1 | | |
| 5 | BITMAP INDEX SINGLE VALUE| IX_B2 | | |
Predicate: 4 - access("GENDER"='M') 5 - access("COUNTRY"='FR')

4 - 34
Bitmap Operations
• BITMAP CONVERSION:
– TO ROWIDS
– FROM ROWIDS
– COUNT
• BITMAP INDEX:
– SINGLE VALUE
– RANGE SCAN
– FULL SCAN
• BITMAP MERGE
• BITMAP AND/OR
• BITMAP MINUS
• BITMAP KEY ITERATION

4 - 35
Bitmap Join Index
Sales
Customers
CREATE BITMAP INDEX cust_sales_bji
ON sales(c.cust_city)
FROM sales s, customers c
WHERE c.cust_id = s.cust_id;
<Rognes, 1.2.3, 10.8000.3, 100010010010100…>
<Aix-en-Provence, 1.2.3, 10.8000.3, 000101000100000…>
<Marseille, 1.2.3, 10.8000.3, 010000001000001…>
1.2.3
10.8000.3

4 - 36
Composite Indexes
Index columns
CARS
create index cars_make_model_idx on cars(make, model);
select *
from cars
where make = 'CITROËN' and model = '2CV';
MAKE MODEL
-----------------------------------------------------------------
| Id | Operation | Name |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS |
|* 2 | INDEX RANGE SCAN | CARS_MAKE_MODEL_IDX |
-----------------------------------------------------------------

4 - 37
INVISIBLE
Index
Invisible Index: Overview
VISIBLE
Index
Optimizer view point
Data view point
Use index. Do not use index.
Update index. Update index.
Update table. Update table.
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE

4 - 38
Invisible Indexes: Examples
• Index is altered as not visible to the optimizer:
• Optimizer does not consider this index:
• Optimizer considers this index:
• Create an index as invisible initially:
ALTER INDEX ind1 INVISIBLE;
SELECT /*+ index(TAB1 IND1) */ COL1 FROM TAB1 WHERE …;
ALTER INDEX ind1 VISIBLE;
CREATE INDEX IND1 ON TAB1(COL1) INVISIBLE;

4 - 39
Guidelines for Managing Indexes
• Create indexes after inserting table data.
• Index the correct tables and columns.
• Order index columns for performance.
• Limit the number of indexes for each table.
• Drop indexes that are no longer required.
• Specify the tablespace for each index.
• Consider parallelizing index creation.
• Consider creating indexes with NOLOGGING.
• Consider costs and benefits of coalescing or rebuilding
indexes.
• Consider cost before disabling or dropping constraints.

4 - 41
Investigating Index Usage
An index may not be used for one of many reasons:
• There are functions being applied to the predicate.
• There is a data type mismatch.
• Statistics are old.
• The column can contain null.
• Using the index would actually be slower than not using it.

4 - 43
This practice covers using different access paths for better
optimization.
• Case 1 through case 13

4 - 44
Clusters
Clustered ORDERS and
ORDER_ITEMS tables
Cluster Key
(ORD_NO)
101 ORD_DT CUST_CD
05-JAN-97 R01
PROD QTY
A4102 20
A5675 19
W0824 10
102 ORD_DT CUST_CD
07-JAN-97 N45
PROD QTY
A2091 11
G7830 20
N9587 26
Unclustered ORDERS and
ORDER_ITEMS tables
ORD_NO PROD QTY ...
------ ------ ------
101 A4102 20
102 A2091 11
102 G7830 20
102 N9587 26
101 A5675 19
101 W0824 10
ORD_NO ORD_DT CUST_CD
------ ------ ------
101 05-JAN-97 R01
102 07-JAN-97 N45

4 - 45
When Are Clusters Useful?
• Index cluster:
– Tables always joined on the same keys
– The size of the table is not known
– In any type of searches
• Hash cluster:
– Tables always joined on the same keys
– Storage for all cluster keys allocated initially
– In either equality (=) or nonequality (<>) searches

4 - 46
When Are Clusters Useful?
• Single-table hash cluster:
– Fastest way to access a large table with an equality search
• Sorted hash cluster:
– Only used for equality search
– Avoid sorts on batch reporting
– Avoid overhead probe on the branch blocks of an IOT

4 - 47
Cluster Access Path: Examples
SELECT * FROM calls WHERE origin_number=33442395322;
----------------------------------------------------------------
----------------------------------------------------------------
| 1 | TABLE ACCESS HASH| CALLS | 1 | 56 | |
----------------------------------------------------------------
1 - access("ORIGIN_NUMBER"=33442395322)
SELECT * FROM emp,dept WHER emp.deptno=dept.deptno;
-----------------------------------------------------------------
-----------------------------------------------------------------
| 1 | NESTED LOOPS | | 1 | 117 | 3 |
| 2 | TABLE ACCESS FULL | EMP | 1 | 87 | 2 |
| 3 | TABLE ACCESS CLUSTER| DEPT | 1 | 30 | 1 |
-----------------------------------------------------------------
3 - filter("EMP"."DEPTNO"="DEPT"."DEPTNO")

4 - 48
Sorting Operators
• SORT operator:
– AGGREGATE: Single row from group function
– UNIQUE: To eliminate duplicates
– JOIN: Precedes a merge join
– GROUP BY, ORDER BY: For these operators
• HASH operator:
– GROUP BY: For this operator
– UNIQUE: Equivalent to SORT UNIQUE
• If you want ordered results, always use ORDER BY.

4 - 49
Buffer Sort Operator
select ename, emp.deptno, dept.deptno, dname
from emp, dept
where ename like 'A%';
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | MERGE JOIN CARTESIAN | | 4 | 124 | 5
| 3 | INDEX RANGE SCAN | I_ENAME | 1 | | 1
| 4 | BUFFER SORT | | 4 | 88 | 3
| 5 | TABLE ACCESS FULL | DEPT | 4 | 88 | 3
---------------------------------------------------------------------
---------------------------------------------------
3 - access("ENAME" LIKE 'A%')
filter("ENAME" LIKE 'A%')

4 - 50
Inlist Iterator
select * from emp where deptno in (1,2);
select * from emp where deptno = 1 or deptno =2 ;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | INLIST ITERATOR | | | | |
| 3 | INDEX RANGE SCAN | IX_SS | 2 | | 1|
---------------------------------------------------------------------
---------------------------------------------------
3 - access("DEPTNO"=1 OR "DEPTNO"=2)
Every value executed separately
deptno=1 deptno=2

4 - 51
View Operator
create view V as select /*+ NO_MERGE */ DEPTNO, sal from emp ;
select * from V;
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 14 | 364 | 1 (0)| 0:01
| 1 | VIEW | V | 14 | 364 | 1 (0)| 0:01
| 2 | INDEX FULL SCAN| IX_SS | 14 | 98 | 1 (0)| 0:01
---------------------------------------------------------------------
select v.*,d.dname from (select DEPTNO, sum(sal) SUM_SAL
from emp group by deptno) v, dept d where v.deptno=d.deptno;
---------------------------------------------------------------------
| 1 | HASH JOIN | | 3 | 144 | 5 (20)|
| 2 | VIEW | | 3 | 78 | 1 (0)|
| 3 | HASH GROUP BY | | 3 | 21 | 1 (0)|
| 4 | INDEX FULL SCAN| IX_SS | 14 | 98 | 1 (0)|
| 5 | TABLE ACCESS FULL| DEPT | 4 | 88 | 3 (0)|
---------------------------------------------------------------------
Predicate: 1 - access("V"."DEPTNO"="D"."DEPTNO")

4 - 52
Count Stop Key Operator
select count(*)
from (select /*+ NO_MERGE */ *
from TC where C1 ='1' and rownum < 10);
---------------------------------------------------------------------
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 4 (0)|
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | VIEW | | 9 | | 4 (0)|
| 3 | COUNT STOPKEY | | | | |
| 4 | TABLE ACCESS FULL| TC | 4282 | 4190K| 4 (0)|
---------------------------------------------------------------------
---------------------------------------------------
3 - filter(ROWNUM<10)
4 - filter("C1"='1')

4 - 53
Min/Max and First Row Operators
select min(id) FROM t WHERE id > 500000;
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 | 13 | |
| 2 | FIRST ROW | | 717K| 9113K| 3|
| 3 | INDEX RANGE SCAN (MIN/MAX)| IXT | 717K| 9113K| 3|
---------------------------------------------------------------------
---------------------------------------------------
3 - access("ID">500000)

4 - 54
Join Methods
• A join defines the relationship between two row sources.
• A join is a method of combining data from two data sources.
• It is controlled by join predicates, which define how the
objects are related.
• Join methods:
– Nested loops
– Sort-merge join
– Hash join
SELECT e.ename,d.dname
FROM emp e, dept d
WHERE e.deptno = d.deptno AND
(e.job = 'ANALYST' OR e.empno = 9999);
Join predicate
Nonjoin predicate
SELECT e.ename, d.dname
FROM dept d JOIN emp e USING (deptno)
WHERE e.job = 'ANALYST' OR e.empno = 9999;
Join predicate
Nonjoin predicate

4 - 55
Nested Loops Join
• Driving row source is scanned
• Each row returned drives a lookup in
inner row source
• Joining rows are then returned
select ename, e.deptno, d.deptno, d.dname
from emp e, dept d
where e.deptno = d.deptno and ename like 'A%';
---------------------------------------------------------------------
| Id | Operation | Name | Rows |Cost |
---------------------------------------------------------------------
| 1 | NESTED LOOPS | | 2 | 4 |
| 2 | TABLE ACCESS FULL | EMP | 2 | 2 |
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 1 |
| 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 | |
---------------------------------------------------------------------
2 - filter("E"."ENAME" LIKE 'A%')
4 - access("E"."DEPTNO"="D"."DEPTNO")
NL
TAF TAR
IS
Driving
Inner
For
each

4 - 56
Nested Loops Join: Prefetching
from emp e, dept d
---------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 22 | 1
| 2 | NESTED LOOPS | | 2 | 84 | 5
|* 3 | TABLE ACCESS FULL | EMP | 2 | 40 | 3
|* 4 | INDEX RANGE SCAN | IDEPT | 1 | | 0
---------------------------------------------------------------------
NL
TAF TAR
IRS
Driving
Inner

4 - 57
Nested Loops Join: 11g Implementation
from emp e, dept d
---------------------------------------------------------------------
| 1 | NESTED LOOPS | | | |
| 2 | NESTED LOOPS | | 2 | 84 | 5
|* 3 | TABLE ACCESS FULL | EMP | 2 | 40 | 3
|* 4 | INDEX RANGE SCAN | DDEPT | 1 | | 0
| 5 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 22 | 1
---------------------------------------------------------------------
NL
TAF IRS
Driving
NL
TAR
Inner

4 - 58
Sort Merge Join
• First and second row sources are sorted
by same sort key.
• Sorted rows from both side are merged.
select ename, e.deptno, d.deptno, dname
from emp e, dept d
where e.deptno = d.deptno and ename > 'A';
---------------------------------------------------------------------
| 1 | MERGE JOIN | | 2 | 84 | 8 (25)|
| 2 | SORT JOIN | | 2 | 40 | 4 (25)|
| 3 | TABLE ACCESS FULL| EMP | 2 | 40 | 3 (0)|
| 4 | SORT JOIN | | 4 | 88 | 4 (25)|
---------------------------------------------------------------------
Predicate: 3 - filter("ENAME">'A')
filter("E"."DEPTNO"="D"."DEPTNO")
MJ
SJ SJ
TAF TAF
Independent
Sorted
Sorted
Merged

4 - 59
Hash Join
• The smallest row source is used
to build a hash table.
• The second row source is hashed
and checked against the hash table.
select ename, e.deptno, d.deptno, dname from emp e, dept d
---------------------------------------------------------------------
---------------------------------------------------------------------
| 1 | HASH JOIN | | 3 | 66 | 6
| 3 | INDEX FULL SCAN | EDEPT | 14 | | 1
| 4 | TABLE ACCESS FULL | DEPT | 4 | 52 | 3
---------------------------------------------------------------------
Predicate: 1 - access("E"."DEPTNO"="D"."DEPTNO")
2 - filter("ENAME" LIKE 'A%')
HJ
TAR
IS
Driving
Probe
Build hash
table in
memory
TAF

4 - 60
Cartesian Join
select ename, e.deptno, d.deptno, dname
from emp e, dept d where ename like 'A%';
--------------------------------------------------------------------
--------------------------------------------------------------------
| 1 | MERGE JOIN CARTESIAN| | 11 | 242 | 8 (0)|
| 2 | TABLE ACCESS FULL | EMP | 3 | 27 | 3 (0)|
| 3 | BUFFER SORT | | 4 | 52 | 5 (0)|
| 4 | TABLE ACCESS FULL | DEPT | 4 | 52 | 2 (0)|
--------------------------------------------------------------------
---------------------------------------------------
2 - filter("ENAME" LIKE 'A%')

4 - 61
Join Types
• A join operation combines the output from two row sources
and returns one resulting row source.
• Join operation types include the following :
– Join (Equijoin/Natural – Nonequijoin)
– Outer join (Full, Left, and Right)
– Semi join: EXISTS subquery
– Anti join: NOT IN subquery
– Star join (Optimization)

4 - 64
20
10
10
30
10
Semijoins
Semijoins only look for the first match.
SELECT deptno, dname
FROM dept
WHERE EXISTS (SELECT 1 FROM emp WHERE emp.deptno=dept.deptno);
--------------------------------------------------------------------
--------------------------------------------------------------------
| 1 | HASH JOIN SEMI | | 3 | 105 | 7 (15)|
| 3 | TABLE ACCESS FULL| EMP | 14 | 182 | 3 (0)|
--------------------------------------------------------------------
1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
10
20
30
40
DEPT
EMP

4 - 65
Antijoins
Reverse of what would have been returned by a join
FROM dept
WHERE deptno not in
(SELECT deptno FROM emp);
---------------------------------------
---------------------------------------
| 1 | NESTED LOOPS ANTI | |
| 3 | INDEX RANGE SCAN | I_DEPTNO |
---------------------------------------
3 - access("DEPTNO"="DEPTNO")
FROM dept
WHERE deptno not in
(SELECT deptno FROM emp);
-----------------------------------
-----------------------------------
| 1 | HASH JOIN ANTI | |
-----------------------------------
20
10
20
30
10
10
20
30
40
DEPT
EMP
EMP DEPT

4 - 66
Other N-Array Operations
• FILTER
• CONCATENATION
• UNION ALL/UNION
• INTERSECT
• MINUS

4 - 67
Filter Operations
• Accepts a set of rows
• Eliminates some of them
• Returns the rest
SELECT deptno, sum(sal) SUM_SAL
FROM emp
GROUP BY deptno
HAVING sum(sal) > 9000;
------------------------------------
------------------------------------
| 1 | FILTER | |
| 2 | HASH GROUP BY | |
------------------------------------
1 - filter(SUM("SAL")>9000)
FROM dept d WHERE NOT EXISTS
(select 1 from emp e
where e.deptno=d.deptno);
------------------------------------
------------------------------------
| 0 | SELECT STATEMENT |
| 1 | FILTER |
| 2 | TABLE ACCESS FULL| DEPT
| 3 | INDEX RANGE SCAN |I_DEPTNO
------------------------------------
1 - filter( NOT EXISTS
(SELECT 0 FROM "EMP" "E" WHERE
"E"."DEPTNO"=:B1))
3 - access("E"."DEPTNO"=:B1)

4 - 68
Concatenation Operation
SELECT * FROM emp WHERE deptno=1 or sal=2;
--------------------------------------------------------------------
--------------------------------------------------------------------
| 1 | CONCATENATION | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| EMP | 4 | 348 |
| 3 | INDEX RANGE SCAN | I_SAL | 2 | |
| 4 | TABLE ACCESS BY INDEX ROWID| EMP | 4 | 348 |
| 5 | INDEX RANGE SCAN | I_DEPTNO | 2 | |
--------------------------------------------------------------------
---------------------------------------------------
3 - access("SAL"=2)
4 - filter(LNNVL("SAL"=2))
5 - access("DEPTNO"=1)

4 - 69
UNION [ALL], INTERSECT, MINUS
3
3
5
4
2
1
3
3
5
4
2
1
3
3
5
4
2
1
3
3
5
4
2
1
MINUS
SORT UNIQUE NOSORT
INDEX FULL SCAN
SORT UNIQUE
INDEX FAST FULL SCAN
INTERSECTION
SORT UNIQUE NOSORT
INDEX FULL SCAN
SORT UNIQUE
SORT UNIQUE
UNION-ALL
INDEX FULL SCAN
UNION ALL
UNION
INTERSECT
MINUS

4 - 70
Result Cache Operator
EXPLAIN PLAN FOR
SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)
FROM employees
GROUP BY department_id;
--------------------------------------------------------------
| Id | Operation | Name |Rows
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 11
| 1 | RESULT CACHE | 8fpza04gtwsfr6n595au15yj4y |
| 2 | HASH GROUP BY | | 11
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107
--------------------------------------------------------------

4 - 71
Summary
In this lesson, you should have learned to:
• Describe most of the SQL operators
• List the possible access paths
• Explain how join operations are performed

4 - 72
• Using different access paths for better optimization
– Case 14 to case 16
• Using the result cache

Interpreting Execution Plans

5 - 2
Objectives
• Gather execution plans
• Display execution plans
• Interpret execution plans

5 - 3
What Is an Execution Plan?
• The execution plan of a SQL statement is composed of small
building blocks called row sources for serial execution plans.
• The combination of row sources for a statement is called the
execution plan.
• By using parent-child relationships, the execution plan can
be displayed in a tree-like structure (text or graphical).

5 - 4
Where to Find Execution Plans?
• PLAN_TABLE (EXPLAIN PLAN or SQL*Plus autotrace)
• V$SQL_PLAN (Library Cache)
• V$SQL_PLAN_MONITOR (11g)
• DBA_HIST_SQL_PLAN (AWR)
• STATS$SQL_PLAN (Statspack)
• SQL Management Base (SQL Plan Management
Baselines)
• SQL tuning set
• Trace files generated by DBMS_MONITOR
• Event 10053 trace file
• Process state dump trace file since 10gR2

5 - 6
Viewing Execution Plans
• The EXPLAIN PLAN command followed by:
– SELECT from PLAN_TABLE
– DBMS_XPLAN.DISPLAY()
• SQL*Plus Autotrace: SET AUTOTRACE ON
• DBMS_XPLAN.DISPLAY_CURSOR()
• DBMS_XPLAN.DISPLAY_AWR()
• DBMS_XPLAN.DISPLAY_SQLSET()
• DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE()

5 - 7
• Generates an optimizer execution plan
• Stores the plan in PLAN_TABLE
• Does not execute the statement itself
The EXPLAIN PLAN Command

5 - 8
SET STATEMENT_ID
= 'text'
EXPLAIN PLAN
INTO your plan table
FOR statement
The EXPLAIN PLAN Command

5 - 9
The EXPLAIN PLAN Command: Example
SQL> EXPLAIN PLAN
2 SET STATEMENT_ID = 'demo01' FOR
3 SELECT e.last_name, d.department_name
4 FROM hr.employees e, hr.departments d
5 WHERE e.department_id = d.department_id;
Explained.
SQL>
Note: The EXPLAIN PLAN command does not actually
execute the statement.

5 - 10
PLAN_TABLE
• PLAN_TABLE:
– Is automatically created to hold the EXPLAIN PLAN output.
– You can create your own using utlxplan.sql.
– Advantage: SQL is not executed
– Disadvantage: May not be the actual execution plan
• PLAN_TABLE is hierarchical.
• Hierarchy is established with the ID and PARENT_ID
columns.

5 - 11
Displaying from PLAN_TABLE: Typical
SQL> EXPLAIN PLAN SET STATEMENT_ID = 'demo01' FOR SELECT * FROM emp
2 WHERE ename = 'KING';
Explained.
SQL> SET LINESIZE 130
SQL> SET PAGESIZE 0
SQL> select * from table(DBMS_XPLAN.DISPLAY());
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
---------------------------------------------------
1 - filter("ENAME"='KING')

5 - 12
Displaying from PLAN_TABLE: ALL
SQL> select * from table(DBMS_XPLAN.DISPLAY(null,null,'ALL'));
--------------------------------------------------------------------------
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$1 / EMP@SEL$1
---------------------------------------------------
1 - filter("ENAME"='KING')
Column Projection Information (identified by operation id):
-----------------------------------------------------------
1 - "EMP"."EMPNO"[NUMBER,22], "ENAME"[VARCHAR2,10], "EMP"."JOB"[VARCHAR2,9],
"EMP"."MGR"[NUMBER,22], "EMP"."HIREDATE"[DATE,7], "EMP"."SAL"[NUMBER,22],
"EMP"."COMM"[NUMBER,22], "EMP"."DEPTNO"[NUMBER,22]

5 - 14
Displaying from PLAN_TABLE: ADVANCED
select plan_table_output from table(DBMS_XPLAN.DISPLAY(null,null,'ADVANCED
-PROJECTION -PREDICATE -ALIAS'));
--------------------------------------------------------------------------
--------------------------------------------------------------------------
| 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Outline Data
-------------
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$1" "EMP"@"SEL$1")
OUTLINE_LEAF(@"SEL$1")
ALL_ROWS
DB_VERSION('11.1.0.6')
OPTIMIZER_FEATURES_ENABLE('11.1.0.6')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
*/

5 - 15
AUTOTRACE
• AUTOTRACE is a SQL*Plus facility.
• Introduced with Oracle7.3
• Needs a PLAN_TABLE
• Needs the PLUSTRACE role to retrieve statistics from some
V$ views
• By default, it produces the execution plan and statistics after
running the query.
• May not be the actual plan when using bind peeking
(recursive EXPLAIN PLAN)

5 - 16
The AUTOTRACE Syntax
OFF
TRACE[ONLY]
EXPLAIN
STATISTICS
SHOW AUTOTRACE
SET AUTOTRACE ON

5 - 17
AUTOTRACE: Examples
• To start tracing statements using AUTOTRACE:
• To display the execution plan only without execution:
• To display rows and statistics:
• To get the plan and the statistics only (suppress rows):
SQL> set autotrace on
SQL> set autotrace traceonly explain
SQL> set autotrace on statistics
SQL> set autotrace traceonly

5 - 18
AUTOTRACE: Statistics
SQL> show autotrace
autotrace OFF
SQL> set autotrace traceonly statistics
SQL> SELECT * FROM oe.products;
288 rows selected.
Statistics
--------------------------------------------------------
1334 recursive calls
0 db block gets
686 consistent gets
394 physical reads
0 redo size
103919 bytes sent via SQL*Net to client
629 bytes received via SQL*Net from client
21 SQL*Net roundtrips to/from client
22 sorts (memory)
0 sorts (disk)
288 rows processed

5 - 20
Using the V$SQL_PLAN View
• V$SQL_PLAN provides a way of examining the execution
plan for cursors that are still in the library cache.
• V$SQL_PLAN is very similar to PLAN_TABLE:
– PLAN_TABLE shows a theoretical plan that can be used if this
statement were to be executed.
– V$SQL_PLAN contains the actual plan used.
• It contains the execution plan of every cursor in the library
cache (including child).
• Link to V$SQL:
– ADDRESS, HASH_VALUE, and CHILD_NUMBER

5 - 21
The V$SQL_PLAN Columns
Note: This is only a partial listing of the columns.
Numerical representation of the SQL plan for the cursor
PLAN_HASH_VALUE
Number assigned to each step in the
execution plan
ID
ID of the next execution step that operates on
the output of the current step
PARENT_ID
Order of processing for all operations that have
the same PARENT_ID
POSITION
Child cursor number using this execution plan
CHILD_NUMBER
Address of the handle to the parent for this cursor
ADDRESS
Hash value of the parent statement in the
library cache
HASH_VALUE

5 - 22
The V$SQL_PLAN_STATISTICS View
• V$SQL_PLAN_STATISTICS provides actual execution
statistics:
– STATISTICS_LEVEL set to ALL
– The GATHER_PLAN_STATISTICS hint
• V$SQL_PLAN_STATISTICS_ALL enables
side-by-side comparisons of the optimizer estimates with the
actual execution statistics.

5 - 23
Links Between Important
Dynamic Performance Views
V$SQL
V$SQL_PLAN
V$SQL_PLAN_STATISTICS
V$SQLAREA V$SQL_WORKAREA
V$SQL_PLAN_STATISTICS_ALL
V$SQLSTATS
Execution statistics
for each row source
Estimated statistics
for each row source

5 - 25
Querying V$SQL_PLAN
SQL_ID 47ju6102uvq5q, child number 0
-------------------------------------
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d WHERE
e.department_id =d.department_id
--------------------------------------------------------------------------------
| 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|
--------------------------------------------------------------------------------
---------------------------------------------------
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
24 rows selected.
SELECT PLAN_TABLE_OUTPUT FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR('47ju6102uvq5q'));

5 - 27
Automatic Workload Repository (AWR)
• Collects, processes, and maintains performance 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

5 - 29
Managing AWR with PL/SQL
• Creating snapshots:
• Dropping snapshots:
• Managing snapshot settings:
SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ('ALL');
SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE –
(low_snap_id => 22, high_snap_id => 32, dbid => 3310949047);
SQL> exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS –
(retention => 43200, interval => 30, dbid => 3310949047);

5 - 31
Important AWR Views
• V$ACTIVE_SESSION_HISTORY
• V$ metric views
• DBA_HIST views:
– DBA_HIST_ACTIVE_SESS_HISTORY
– DBA_HIST_BASELINE
DBA_HIST_DATABASE_INSTANCE
– DBA_HIST_SNAPSHOT
– DBA_HIST_SQL_PLAN
– DBA_HIST_WR_CONTROL

5 - 32
Querying the AWR
• Retrieve all execution plans stored for a particular SQL_ID.
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE (DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
SQL_ID 454rug2yva18w
--------------------
select /* example */ * from hr.employees natural join hr.departments
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
| 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 |
----------------------------------------------------------------------------------
SELECT tf.* FROM DBA_HIST_SQLTEXT ht, table
(DBMS_XPLAN.DISPLAY_AWR(ht.sql_id,null, null, 'ALL' )) tf
WHERE ht.sql_text like '%JF%';
• Display all execution plans of all statements containing “JF.”

5 - 34
Generating SQL Reports from AWR Data
SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt
Specify the Report Type …
Would you like an HTML report, or a plain text report?
Specify the number of days of snapshots to choose from
Specify the Begin and End Snapshot Ids …
Specify the SQL Id …
Enter value for sql_id: 6g1p4s9ra6ag8
Specify the Report Name …

5 - 35
STATISTICS_LEVEL=TYPICAL|ALL
CONTROL_MANAGEMENT_PACK_ACCESS=DIAGNOSTIC+TUNING
+
>5sec
(CPU|IO)
Parallel
MONITOR
hint
SQL monitoring
NO_MONITOR
hint
Every
second V$SQL_MONITOR
V$SQL_PLAN_MONITOR
V$SQL
V$SQL_PLAN
V$ACTIVE_SESSION_HISTORY
V$SESSION_LONGOPS
V$SESSION
DBMS_SQLTUNE.REPORT_SQL_MONITOR
SQL Monitoring: Overview

5 - 37
SQL Monitoring Report: Example
SQL> set long 10000000
SQL> set longchunksize 10000000
SQL> set linesize 200
SQL> select dbms_sqltune.report_sql_monitor from dual;
SQL Monitoring Report
SQL Text
--------------------------
select count(*) from sales
Global Information
Status : EXECUTING
Instance ID : 1
Session ID : 125
SQL ID : fazrk33ng71km
SQL Execution ID : 16777216
Plan Hash Value : 1047182207
Execution Started : 02/19/2008 21:01:18
First Refresh Time : 02/19/2008 21:01:22
Last Refresh Time : 02/19/2008 21:01:42
------------------------------------------------------------
| Elapsed | Cpu | IO | Other | Buffer | Reads |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | |
------------------------------------------------------------
| 22 | 3.36 | 0.01 | 19 | 259K | 199K |
------------------------------------------------------------
SQL> select count(*) from sales;
In a different session

5 - 38
SQL Monitoring Report: Example
SQL Plan Monitoring Details
====================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start |
| | | | (Estim) | | Active(s) | Active |
====================================================================================
| 0 | SELECT STATEMENT | | | 78139 | | |
| 1 | SORT AGGREGATE | | 1 | | | |
| -> 2 | TABLE ACCESS FULL | SALES | 53984K | 78139 | 23 | +1 |
| | | | | | | |
====================================================================================
==================================================================================
Starts | Rows | Activity | Activity Detail | Progress |
| (Actual) | (percent) | (sample #) | |
1 | | | | |
1 | | | | |
1 | 42081K | 100.00 | Cpu (4) | 74% |
==================================================================================

5 - 40
Interpreting an Execution Plan
Transform it into a tree.
Level 1
Level 2
Level 3
Level 4
Parent/Child
Child/Leaf
Parent/Child
Child/Leaf Parent/Child
Child/Leaf
Child/Leaf
Child/Leaf
id= 1 (pid= ) root/parent
id= 2 (pid=1) (pos=1) parent/child
id= 3 (pid=2) (pos=1) child/leaf
id=10 (pid=9) (pos=1) child/leaf
From
top/down
From left/right
Executed first Executed next
Parent/Child
Root/Parent

5 - 42
Execution Plan Interpretation: Example 1
SELECT /*+ RULE */ ename,job,sal,dname
FROM emp,dept
WHERE dept.deptno=emp.deptno and not exists(SELECT *
FROM salgrade
WHERE emp.sal between losal and hisal);
--------------------------------------------------
--------------------------------------------------
|* 1 | FILTER | |
| 2 | NESTED LOOPS | |
| 3 | TABLE ACCESS FULL | EMP |
| 4 | TABLE ACCESS BY INDEX ROWID| DEPT |
|* 5 | INDEX UNIQUE SCAN | PK_DEPT |
|* 6 | TABLE ACCESS FULL | SALGRADE |
--------------------------------------------------
---------------------------------------------------
1 - filter( NOT EXISTS
(SELECT 0 FROM "SALGRADE" "SALGRADE" WHERE
"HISAL">=:B1 AND "LOSAL"<=:B2))
5 - access("DEPT"."DEPTNO"="EMP"."DEPTNO")
6 - filter("HISAL">=:B1 AND "LOSAL"<=:B2)
NESTED
LOOPS 2 6
3 4
5
1
FILTER
TABLE ACCESS FULL
SALGRADE
TABLE ACCESS FULL
EMP
TABLE ACCESS
BY ROWID
DEPT
INDEX UNIQUE SCAN
PK_DEPT

5 - 44
SQL> alter session set statistics_level=ALL;
Session altered.
SQL> select /*+ RULE to make sure it reproduces 100% */ ename,job,sal,dname
from emp,dept where dept.deptno = emp.deptno and not exists (select * from salgrade
where emp.sal between losal and hisal);
no rows selected
SQL> select * from table(dbms_xplan.display_cursor(null,null,'TYPICAL IOSTATS
LAST'));
SQL_ID 274019myw3vuf, child number 0
-------------------------------------
…
--------------------------------------------------------------------------------
| Id | Operation | Name | Starts | A-Rows | Buffers |
--------------------------------------------------------------------------------
|* 1 | FILTER | | 1 | 0 | 61 |
| 2 | NESTED LOOPS | | 1 | 14 | 25 |
| 3 | TABLE ACCESS FULL | EMP | 1 | 14 | 7 |
| 4 | TABLE ACCESS BY INDEX ROWID| DEPT | 14 | 14 | 18 |
|* 5 | INDEX UNIQUE SCAN | PK_DEPT | 14 | 14 | 4 |
|* 6 | TABLE ACCESS FULL | SALGRADE | 12 | 12 | 36 |
--------------------------------------------------------------------------------
…

5 - 45
SQL> select /*+ USE_NL(d) use_nl(m) */ m.last_name as dept_manager
2 , d.department_name
3 , l.street_address
4 from hr.employees m join
5 hr.departments d on (d.manager_id = m.employee_id)
6 natural join
7 hr.locations l
8 where l.city = 'Seattle';
0 SELECT STATEMENT
1 0 NESTED LOOPS
2 1 NESTED LOOPS
3 2 TABLE ACCESS BY INDEX ROWID LOCATIONS
4 3 INDEX RANGE SCAN LOC_CITY_IX
5 2 TABLE ACCESS BY INDEX ROWID DEPARTMENTS
6 5 INDEX RANGE SCAN DEPT_LOCATION_IX
7 1 TABLE ACCESS BY INDEX ROWID EMPLOYEES
8 7 INDEX UNIQUE SCAN EMP_EMP_ID_PK
2 7
3 5
6
1
4
8

5 - 47
select /*+ ORDERED USE_HASH(b) SWAP_JOIN_INPUTS(c) */ max(a.i)
from t1 a, t2 b, t3 c
where a.i = b.i and a.i = c.i;
0 SELECT STATEMENT
1 SORT AGGREGATE
2 1 HASH JOIN
3 2 TABLE ACCESS FULL T3
4 2 HASH JOIN
4
3
5 6
2
1
Join order is: T1 - T2 - T3

5 - 48
Reading More Complex Execution Plans
SELECT owner , segment_name , segment_type
FROM dba_extents
WHERE file_id = 1
AND 123213 BETWEEN block_id AND block_id + blocks -1;
Collapse using indentation
and
focus on operations consuming most resources.

5 - 49
Reviewing the Execution Plan
• Drive from the table that has most selective filter.
• Look for the following:
– Driving table has the best filter
– Fewest number of rows are returned to the next step
– The join method is appropriate for the number of rows
returned
– Views are correctly used
– Unintentional Cartesian products
– Tables accessed efficiently

5 - 50
Looking Beyond Execution Plans
• An execution plan alone cannot tell you whether a plan is
good or not.
• May need additional testing and tuning:
– SQL Tuning Advisor
– SQL Access Advisor
– SQL Performance Analyzer
– SQL Monitoring
– Tracing

5 - 51
Summary
• Gather execution plans
• Display execution plans
• Interpret execution plans

5 - 52
• Using different techniques to extract execution plans
• Using SQL monitoring

Case Study:
Star Transformation

6 - 2
Objectives
• Define a star schema
• Show a star query plan without transformation
• Define the star transformation requirements
• Show a star query plan after transformation

6 - 3
The Star Schema Model
PRODUCTS
PROD_ID
PROD_NAME
PROD_DESC PROD_ID
TIME_ID
CHANNEL_ID
SALES
AMOUNT_SOLD
QUANTITY_SOLD
Fact table
Dimension/Lookup table
Fact >> Dimension
Measures
Keys
TIMES
TIME_ID
DAY_NAME
CALENDAR_YEAR
CHANNELS
CHANNEL_ID
CHANNEL_DESC
CHANNEL_CLASS
CUSTOMERS
CUST_ID
CUST_GENDER
CUST_CITY

6 - 4
The Snowflake Schema Model
PRODUCTS
SALES
CHANNELS
TIMES
COUNTRIES
CUSTOMERS

6 - 5
Star Query: Example
SELECT ch.channel_class, c.cust_city,
t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sales s,times t,customers c,channels ch
WHERE s.time_id = t.time_id AND
s.cust_id = c.cust_id AND
s.channel_id = ch.channel_id AND
c.cust_state_province = 'CA' AND
ch.channel_desc IN ('Internet','Catalog') AND
t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
GROUP BY ch.channel_class, c.cust_city,
t.calendar_quarter_desc;
0
1
1
0
0
1
1
0
0
1
1
0

6 - 6
Execution Plan Without Star Transformation
SALES
CUSTOMERS
Hash Join
TIMES
Hash Join
CHANNELS
Hash Join
-------------------------------------------
-------------------------------------------
| 1 | HASH GROUP BY | |
|* 2 | HASH JOIN | |
|* 3 | TABLE ACCESS FULL | CHANNELS |
|* 5 | TABLE ACCESS FULL | TIMES |
|* 7 | TABLE ACCESS FULL| CUSTOMERS |
| 8 | TABLE ACCESS FULL| SALES |
-------------------------------------------
Predicate Information (by operation id):
--------------------------------------------
2 - access("S"."CHANNEL_ID"="CH"."CHANNEL_ID")
3 - filter("CH"."CHANNEL_DESC"='Catalog' OR
"CH"."CHANNEL_DESC"='Internet')
4 - access("S"."TIME_ID"="T"."TIME_ID")
5 - filter("T"."CALENDAR_QUARTER_DESC"='1999-Q1' OR
"T"."CALENDAR_QUARTER_DESC"='1999-Q2')
6 - access("S"."CUST_ID"="C"."CUST_ID")
7 - filter("C"."CUST_STATE_PROVINCE"='CA')

6 - 7
Star Transformation
• Create bitmap indexes on fact tables foreign keys.
• Set STAR_TRANSFORMATION_ENABLED to TRUE.
• Requires at least two dimensions and one fact table
• Gather statistics on all corresponding objects.
• Carried out in two phases:
– First, identify interesting fact rows using bitmap indexes based
on dimensional filters.
– Join them to the dimension tables.

6 - 8
Star Transformation: Considerations
• Queries containing bind variables are not transformed.
• Queries referring to remote fact tables are not transformed.
• Queries containing antijoined tables are not transformed.
• Queries referring to unmerged nonpartitioned views are not
transformed.

6 - 9
Star Transformation: Rewrite Example
SELECT s.amount_sold
FROM sales s
WHERE time_id IN (SELECT time_id
FROM times
WHERE calendar_quarter_desc
IN('1999-Q1','1999-Q2'))
AND cust_id IN (SELECT cust_id
FROM customers
WHERE cust_state_province = 'CA')
AND channel_id IN(SELECT channel_id
FROM channels
WHERE channel_desc IN
('Internet','Catalog'));
0
1
1
0
0
1
1
0
0
1
1
0
Phase 1

6 - 10
Retrieving Fact Rows from
One Dimension
BITMAP
KEY
ITERATION
Dimension
Table
Access
Fact Table
Bitmap
Access
BITMAP
MERGE One bitmap
is
Produced.
Phase 1

6 - 11
Retrieving Fact Rows from All Dimensions
…
Multiple bitmaps
are
ANDed together.
Intermediate
Result Set
(IRS)
MERGE i
…
BITMAP AND
MERGE 1 MERGE n
BITMAP
Conversion
To Rowids
Phase 1

6 - 12
Joining the Intermediate Result Set
with Dimensions
HASH JOIN
Dimension 1
Table
Access
Fact Table
Access
From
IRS
Dimension n
Table
Access
HASH JOIN
Dimension i
Table
Access
HASH JOIN
Phase 2

6 - 13
Star Transformation Plan: Example 1
SORT GROUP BY
HASH JOIN
HASH JOIN
TABLE ACCESS BY INDEX ROWID SALES
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP MERGE
BITMAP KEY ITERATION
BUFFER SORT
TABLE ACCESS FULL CHANNELS
BITMAP INDEX RANGE SCAN SALES_CHANNELS_BX
BITMAP MERGE
BUFFER SORT
TABLE ACCESS FULL TIMES
BITMAP INDEX RANGE SCAN SALES_TIMES_BX
…

6 - 14
Star Transformation: Further Optimization
• In a star transformation execution plan, dimension tables are
accessed twice; once for each phase.
• This might be a performance issue in the case of big
dimension tables and low selectivity.
• If the cost is lower, the system might decide to create a
temporary table and use it instead of accessing the same
dimension table twice.
• Temporary table’s creation in the plan:
LOAD AS SELECT SYS_TEMP_0FD9D6720_BEBDC
TABLE ACCESS FULL CUSTOMERS
…
filter("C"."CUST_STATE_PROVINCE"='CA')

6 - 15
Using Bitmap Join Indexes
• Volume of data to be joined is reduced
• Can be used to eliminate bitwise operations
• More efficient in storage than MJVs
CREATE BITMAP INDEX sales_q_bjx
ON sales(times.calendar_quarter_desc)
FROM sales, times
WHERE sales.time_id = times.time_id

6 - 16
Star Transformation Plan: Example 2
SORT GROUP BY
HASH JOIN
HASH JOIN
TABLE ACCESS BY INDEX ROWID SALES
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP MERGE
BUFFER SORT
BITMAP INDEX RANGE SCAN SALES_CHANNELS_BX
BITMAP OR
BITMAP INDEX SINGLE VALUE SALES_Q_BJX
BITMAP INDEX SINGLE VALUE SALES_Q_BJX

6 - 17
Star Transformation Hints
• The STAR_TRANSFORMATION hint: Use best plan containing
a star transformation, if there is one.
• The FACT(<table_name>) hint: The hinted table should be
considered as the fact table in the context of a star
transformation.
• The NO_FACT (<table_name>) hint: The hinted table should
not be considered as the fact table in the context of a star
transformation.
• The FACT and NO_FACT hints are useful for star queries
containing more than one fact table.

6 - 18
Bitmap Join Indexes: Join Model 1
pk
d f
CREATE BITMAP INDEX bji ON f(d.c1)
FROM f, d
WHERE d.pk = f.fk;
c1 fk
SELECT sum(f.facts)
FROM d, f
WHERE d.pk = f.fk AND d.c1 = 1;

6 - 19
pk
d f
c1 fk
c2
CREATE BITMAP INDEX bjx ON f(d.c1,d.c2)
FROM f, d
WHERE d.pk = f.fk;
SELECT sum(f.facts)
FROM d, f
WHERE d.pk = f.fk AND d.c1 = 1 AND d.c2 = 1;

6 - 20
pk
d1 f
CREATE BITMAP INDEX bjx ON f(d1.c1,d2.c1)
FROM f, d1, d2
WHERE d1.pk = f.fk1 AND d2.pk = f.fk2;
c1 fk1
SELECT sum(f.sales)
FROM d1, f, d2
WHERE d1.pk = f.fk1 AND d2.pk = f.fk2 AND
d1.c1 = 1 AND d2.c1 = 2;
d1 d2
fk2 pk c1

6 - 21
pk
d1 d2
CREATE BITMAP INDEX bjx ON f(d1.c1)
FROM f, d1, d2
WHERE d1.pk = d2.c2 AND d2.pk = f.fk;
c1 c2
SELECT sum(f.sales)
FROM d1, d2, f
WHERE d1.pk = d2.c2 AND d2.pk = f.fk AND
d1.c1 = 1;
d1 f
pk fk

6 - 22
Summary
• Define a star schema
• Show a star query plan without transformation
• Define the star transformation requirements
• Show a star query plan after transformation

6 - 23
This practice covers using the star transformation technique to
optimize your query.

Optimizer Statistics

7 - 2
Objectives
After completing this lesson, you should be able to do the
following:
• Gather optimizer statistics
• Gather system statistics
• Set statistic preferences
• Use dynamic sampling
• Manipulate optimizer statistics

7 - 3
Optimizer Statistics
• Describe the database and the objects in the database
• Information used by the query optimizer to estimate:
– Selectivity of predicates
– Cost of each execution plan
– Access method, join order, and join method
– CPU and input/output (I/O) costs
• Refreshing optimizer statistics whenever they are stale is as
important as gathering them:
– Automatically gathered by the system
– Manually gathered by the user with DBMS_STATS

7 - 4
Types of Optimizer Statistics
• Table statistics:
– Number of rows
– Number of blocks
– Average row length
• Index Statistics:
– B*-tree level
– Distinct keys
– Number of leaf blocks
– Clustering factor
• System statistics
– I/O performance and
utilization
– CPU performance and
utilization
• Column statistics
– Basic: Number of distinct
values, number of nulls,
average length, min, max
– Histograms (data distribution
when the column data is
skewed)
– Extended statistics

7 - 5
Table Statistics (DBA_TAB_STATISTICS)
• Used to determine:
– Table access cost
– Join cardinality
– Join order
• Some of the statistics gathered are:
– Row count (NUM_ROWS)
– Block count (BLOCKS) Exact
– Empty blocks (EMPTY_BLOCKS) Exact
– Average free space per block (AVG_SPACE)
– Number of chained rows (CHAIN_CNT)
– Average row length (AVG_ROW_LEN)
– Statistics status (STALE_STATS)

7 - 6
Index Statistics (DBA_IND_STATISTICS)
• Used to decide:
– Full table scan versus index scan
• Statistics gathered are:
– B*-tree level (BLEVEL) Exact
– Leaf block count (LEAF_BLOCKS)
– Clustering factor (CLUSTERING_FACTOR)
– Distinct keys (DISTINCT_KEYS)
– Average number of leaf blocks in which each distinct value in
the index appears (AVG_LEAF_BLOCKS_PER_KEY)
– Average number of data blocks in the table pointed to by a
distinct value in the index (AVG_DATA_BLOCKS_PER_KEY)
– Number of rows in the index (NUM_ROWS)

7 - 8
Index Clustering Factor
A B C A B C A B C
Block 1 Block 2 Block 3
A A A B B B C C C
Block 1 Block 2 Block 3
A B C
Small clustering factor:
Favor the
index range scan path
Big clustering factor:
Favor alternative paths
DBA_IND_STATISTICS.CLUSTERING_FACTOR
Number of blocks (3)
Number of rows (9)
Only need to read one block to retrieve all As
Must read all blocks to retrieve all As
A
B
C

7 - 10
Column Statistics (DBA_TAB_COL_STATISTICS)
• Count of distinct values of the column (NUM_DISTINCT)
• Low value (LOW_VALUE) Exact
• High value (HIGH_VALUE) Exact
• Number of nulls (NUM_NULLS)
• Selectivity estimate for nonpopular values (DENSITY)
• Number of histogram buckets (NUM_BUCKETS)
• Type of histogram (HISTOGRAM)

7 - 11
Histograms
• The optimizer assumes uniform distributions; this may lead
to suboptimal access plans in the case of data skew.
• Histograms:
– Store additional column distribution information
– Give better selectivity estimates in the case of nonuniform
distributions
• With unlimited resources you could store each different
value and the number of rows for that value.
• This becomes unmanageable for a large number of distinct
values and a different approach is used:
– Frequency histogram (#distinct values ≤ #buckets)
– Height-balanced histogram (#buckets < #distinct values)
• They are stored in DBA_TAB_HISTOGRAMS.

7 - 12
Frequency Histograms
10 buckets, 10 distinct values
0
10000
20000
30000
40000
1 3 5 7 10 16 27 32 39 49
ENDPOINT VALUE: Column value
ENDPOINT
NUMBER
Cumulative cardinality
# rows for column value
Distinct values: 1, 3, 5, 7, 10, 16, 27, 32, 39, 49
Number of rows: 40001

7 - 13
Viewing Frequency Histograms
BEGIN
DBMS_STATS.gather_table_STATS (OWNNAME=>'OE', TABNAME=>'INVENTORIES',
METHOD_OPT => 'FOR COLUMNS SIZE 20 warehouse_id');
END;
SELECT column_name, num_distinct, num_buckets, histogram
FROM USER_TAB_COL_STATISTICS
WHERE table_name = 'INVENTORIES' AND
column_name = 'WAREHOUSE_ID';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM
------------ ------------ ----------- ---------
WAREHOUSE_ID 9 9 FREQUENCY
SELECT endpoint_number, endpoint_value
FROM USER_HISTOGRAMS
WHERE table_name = 'INVENTORIES' and column_name = 'WAREHOUSE_ID'
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- --------------
36 1
213 2
261 3
…

7 - 14
Height-Balanced Histograms
5 buckets, 10 distinct values
(8000 rows per bucket)
0 1 3 4 5
ENDPOINT NUMBER: Bucket number
ENDPOINT
VALUE
2
Same number
of rows per bucket
1 7 10 10 32 49
Distinct values: 1, 3, 5, 7, 10, 16, 27, 32, 39, 49
Number of rows: 40001
Popular
value

7 - 15
Viewing Height-Balanced Histograms
BEGIN
DBMS_STATS.gather_table_STATS(OWNNAME =>'OE', TABNAME=>'INVENTORIES',
METHOD_OPT => 'FOR COLUMNS SIZE 10 quantity_on_hand');
END;
SELECT column_name, num_distinct, num_buckets, histogram
FROM USER_TAB_COL_STATISTICS
WHERE table_name = 'INVENTORIES' AND column_name = 'QUANTITY_ON_HAND';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM
------------------------------ ------------ ----------- ---------------
QUANTITY_ON_HAND 237 10 HEIGHT BALANCED
SELECT endpoint_number, endpoint_value
FROM USER_HISTOGRAMS
WHERE table_name = 'INVENTORIES' and column_name = 'QUANTITY_ON_HAND'
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- --------------
0 0
1 27
2 42
3 57
…

7 - 16
Histogram Considerations
• Histograms are useful when you have a high degree of skew
in the column distribution.
• Histograms are not useful for:
– Columns which do not appear in the WHERE or JOIN clauses
– Columns with uniform distributions
– Equality predicates with unique columns
• The maximum number of buckets is the least (254,# distinct
values).
• Do not use histograms unless they substantially improve
performance.

7 - 17
Multicolumn Statistics: Overview
VEHICLE
MAKE MODEL
S(MAKE Λ MODEL)=S(MAKE)xS(MODEL)
select
dbms_stats.create_extended_stats('jfv','vehicle','(make,model)')
from dual;
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns size 1 for columns (make,model) size 3');
VEHICLE
MAKE MODEL
S(MAKE Λ MODEL)=S(MAKE,MODEL)
DBA_STAT_EXTENSIONS SYS_STUF3GLKIOP5F4B0BTTCFTMX0W
1
2
3
4

7 - 19
Expression Statistics: Overview
S(upper( MODEL))=0.01
VEHICLE
MODEL
VEHICLE
MODEL
CREATE INDEX upperidx ON VEHICLE(upper(MODEL))
VEHICLE
MODEL
select dbms_stats.create_extended_stats('jfv','vehicle','(upper(model))') from dual;
SYS_STU3FOQ$BDH0S_14NGXFJ3TQ50
DBA_STAT_EXTENSIONS
Recommended
Still possible
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns size 1 for columns (upper(model)) size 3');

7 - 20
Gathering System Statistics
• System statistics enable the CBO to use CPU and I/O
characteristics.
• System statistics must be gathered on a regular basis; this
does not invalidate cached plans.
• Gathering system statistics equals analyzing system activity
for a specified period of time:
• Procedures:
– DBMS_STATS.GATHER_SYSTEM_STATS
– DBMS_STATS.SET_SYSTEM_STATS
– DBMS_STATS.GET_SYSTEM_STATS
• GATHERING_MODE:
– NOWORKLOAD|INTERVAL
– START|STOP

7 - 22
Gathering System Statistics: Example
First day
First night
Next days
Next nights
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS(
interval => 120,
stattab => 'mystats', statid => 'OLTP');
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS(
interval => 120,
stattab => 'mystats', statid => 'OLAP');
EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS(
stattab => 'mystats', statid => 'OLTP');
EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS(
stattab => 'mystats', statid => 'OLAP');

7 - 23
Gathering System Statistics: Example
• Start manual system statistics collection in the data
dictionary:
• Generate the workload.
• End the collection of system statistics:
SQL> EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( -
2 gathering_mode => 'STOP');
SQL> EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( -
2 gathering_mode => 'START');

7 - 24
Mechanisms for Gathering Statistics
• Automatic statistics gathering
– gather_stats_prog automated task
• Manual statistics gathering
– DBMS_STATS package
• Dynamic sampling
• When statistics are missing:
Selectivity:
Equality 1%
Inequality 5%
Other predicates 5%
Table row length 20
# of index leaf blocks 25
# of distinct values 100
Table cardinality 100
Remote table cardinality 2000

7 - 25
Statistic Preferences: Overview
Database level
Schema level
Table level
Statement level
Optimizer
statistics
gathering
task
set_database_prefs
set_schema_prefs
set_table_prefs
gather_*_stats
DBMS_STATS
set | get | delete
export | import
exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13');
DBA_TAB_STAT_PREFS
CASCADE DEGREE
ESTIMATE_PERCENT METHOD_OPT
NO_INVALIDATE GRANULARITY
PUBLISH INCREMENTAL
STALE_PERCENT
Global level
set_global_prefs

7 - 27
When to Gather Statistics Manually
• Rely mostly on automatic statistics collection:
– Change the frequency of automatic statistics collection to
meet your needs.
– Remember that STATISTICS_LEVEL should be set to
TYPICAL or ALL for automatic statistics collection to work
properly.
• Gather statistics manually for:
– Objects that are volatile
– Objects modified in batch operations
– External tables, system statistics, fixed objects
– Objects modified in batch operations: Gather statistics as part
of the batch operation.
– New objects: Gather statistics right after object creation.

7 - 28
Manual Statistics Gathering
You can use Enterprise Manager and the DBMS_STATS
package to:
• Generate and manage statistics for use by the optimizer:
– Gather/Modify
– View/Name
– Export/Import
– Delete/Lock
• Gather statistics on:
– Indexes, tables, columns, partitions
– Object, schema, or database
• Gather statistics either serially or in parallel
• Gather/Set system statistics (currently not possible in EM)

7 - 29
Manual Statistics Collection: Factors
• Monitor objects for DMLs.
• Determine the correct sample sizes.
• Determine the degree of parallelism.
• Determine if histograms should be used.
• Determine the cascading effects on indexes.
• Procedures to use in DBMS_STATS:
– GATHER_INDEX_STATS
– GATHER_TABLE_STATS
– GATHER_SCHEMA_STATS
– GATHER_DICTIONARY_STATS
– GATHER_DATABASE_STATS
– GATHER_SYSTEM_STATS

7 - 30
Managing Statistics Collection: Example
dbms_stats.gather_table_stats
('sh' -- schema
,'customers' -- table
, 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');

7 - 31
Optimizer Dynamic Sampling: Overview
• Dynamic sampling can be done for tables and indexes:
– Without statistics
– Whose statistics cannot be trusted
• Used to determine more accurate statistics when estimating:
– Table cardinality
– Predicate selectivity
• Feature controlled by:
– The OPTIMIZER_DYNAMIC_SAMPLING parameter
– The OPTIMIZER_FEATURES_ENABLE parameter
– The DYNAMIC_SAMPLING hint
– The DYNAMIC_SAMPLING_EST_CDN hint

7 - 32
Optimizer Dynamic Sampling at Work
• Sampling is done at compile time.
• If a query benefits from dynamic sampling:
– A recursive SQL statement is executed to sample data
– The number of blocks sampled depends on the
OPTIMIZER_DYNAMIC_SAMPLING initialization parameter
• During dynamic sampling, predicates are applied to the
sample to determine selectivity.
• Use dynamic sampling when:
– Sampling time is a small fraction of the execution time
– Query is executed many times
– You believe a better plan can be found

7 - 33
OPTIMIZER_DYNAMIC_SAMPLING
• Dynamic session or system parameter
• Can be set to a value from “0” to “10”
• “0” turns off dynamic sampling
• “1” samples all unanalyzed tables, if an unanalyzed table:
– Is joined to another table or appears in a subquery or
nonmergeable view
– Has no indexes
– Has more than 32 blocks
• “2” samples all unanalyzed tables
• The higher the value the more aggressive application of
sampling
• Dynamic sampling is repeatable if no update activity

7 - 34
Locking Statistics
• Prevents automatic gathering
• Is mainly used for volatile tables:
– Lock without statistics implies dynamic sampling.
– Lock with statistics for representative values.
• The FORCE argument overrides statistics locking.
BEGIN
DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;
SELECT stattype_locked FROM dba_tab_statistics;
BEGIN
DBMS_STATS.GATHER_TABLE_STATS('OE','ORDERS');
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;

7 - 35
Summary
• Collect optimizer statistics
• Collect system statistics
• Set statistic preferences
• Use dynamic sampling
• Manipulate optimizer statistics

7 - 36
• Using system statistics
• Using automatic statistics gathering

Using Bind Variables

8 - 2
Objectives
• List the benefits of using bind variables
• Use bind peeking
• Use adaptive cursor sharing

8 - 3
Cursor Sharing and Different Literal Values
SELECT * FROM jobs WHERE min_salary > 12000;
Library cache
Cursor sharing

8 - 4
Cursor Sharing and Bind Variables
SELECT * FROM jobs WHERE min_salary > :min_sal;
Library cache
Cursor sharing
12000
18000
17500

8 - 5
Bind Variables in SQL*Plus
SQL> variable job_id varchar2(10)
SQL> exec :job_id := 'SA_REP';
PL/SQL procedure successfully completed.
SQL> select count(*) from employees where job_id = :job_id;
COUNT(*)
----------
30
SQL> exec :job_id := 'AD_VP';
PL/SQL procedure successfully completed.
SQL> select count(*) from employees where job_id = :job_id;
COUNT(*)
----------
2

8 - 6
Bind Variables in Enterprise Manager

8 - 7
Bind Variable Peeking
SELECT * FROM jobs WHERE min_salary > :min_sal
min_sal=12000
Plan A
First time
you execute
12000
SELECT * FROM jobs WHERE min_salary > :min_sal 18000
Next time
you execute

8 - 8
Bind Variable Peeking
SELECT * FROM jobs WHERE min_salary > :min_sal
1
2
3
Plan A
min_sal=12000
min_sal=18000
min_sal=7500
One plan not always appropriate for all bind values

8 - 9
Cursor Sharing Enhancements
• Oracle8i introduced the possibility of sharing SQL
statements that differ only in literal values.
• Oracle9i extends this feature by limiting it to similar
statements only, instead of forcing it.
• Similar: Regardless of the literal value, same execution plan
• Not similar: Possible different execution plans for different
literal values
SQL> SELECT * FROM employees
2 WHERE employee_id = 153;
SQL> SELECT * FROM employees
2 WHERE department_id = 50;

8 - 11
The CURSOR_SHARING Parameter
• The CURSOR_SHARING parameter values:
– FORCE
– EXACT (default)
– SIMILAR
• CURSOR_SHARING can be changed using:
– ALTER SYSTEM
– ALTER SESSION
– Initialization parameter files
• The CURSOR_SHARING_EXACT hint

8 - 12
Forcing Cursor Sharing: Example
SELECT * FROM jobs WHERE min_salary > :"SYS_B_0"
SQL> alter session set cursor_sharing = FORCE;
System-generated
bind variable

8 - 13
Adaptive Cursor Sharing: Overview
Adaptive cursor sharing:
• Allows for intelligent cursor sharing only for statements that
use bind variables
• Is used to compromise between cursor sharing and
optimization
• Has the following benefits:
– Automatically detects when different executions would benefit
from different execution plans
– Limits the number of generated child cursors to a minimum
– Automated mechanism that cannot be turned off

8 - 14
Adaptive Cursor Sharing: Architecture
Initial selectivity cube
Bind-sensitive cursor
SELECT * FROM emp WHERE sal = :1 and dept = :2
.
0.15
0.0025
:1=A & :2=B ⇒ S(:1)=0.15 ∧ S(:2)=0.0025
.
0.18
0.003
:1=C & :2=D ⇒ S(:1)=0.18 ∧ S(:2)=0.003
HJ
GB
Initial plan
HJ
GB
No need
for new plan
.
0.3
0.009
:1=E & :2=F ⇒ S(:1)=0.3 ∧ S(:2)=0.009
HJ
GB
HJ
HJ
GB
HJ
.
0.28
0.004
:1=G & :2=H ⇒ S(:1)=0.28 ∧ S(:2)=0.004
HJ
GB
HJ
GB
Same selectivity cube
Second selectivity cube Need new plan
Merged selectivity cubes
Cubes merged
No need
for new plan
Bind-aware cursor
S
o
f
t
P
a
r
s
e
H
a
r
d
a
r
s
e
P
H
a
r
d
a
r
s
e
P
1
System
observes
statement
for a while.
1
2
3
4
HJ
HJ
HJ
HJ

8 - 16
Adaptive Cursor Sharing: Views
The following views provide information about adaptive cursor
sharing usage:
Two new columns show whether a
cursor is bind sensitive or bind aware.
V$SQL
Shows the selectivity cubes stored for
every predicate containing a bind
variable and whose selectivity is used in
the cursor sharing checks
V$SQL_CS_SELECTIVITY
Shows execution statistics of a cursor
using different bind sets
V$SQL_CS_STATISTICS
V$SQL_CS_HISTOGRAM Shows the distribution of the execution
count across the execution history
histogram

8 - 18
Adaptive Cursor Sharing: Example
SQL> variable job varchar2(6)
SQL> exec :job := 'AD_ASST'
SQL> select count(*), max(salary) from emp where job_id=:job;
'AD_ASST'
Selectivity
Plan A Plan B
'SA_REP'

8 - 19
Interacting with Adaptive Cursor Sharing
• CURSOR_SHARING:
– If CURSOR_SHARING <> EXACT, statements containing
literals may be rewritten using bind variables.
– If statements are rewritten, adaptive cursor sharing may apply
to them.
• SQL Plan Management (SPM):
– If OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is set to
TRUE, only the first generated plan is used.
– As a workaround, set this parameter to FALSE, and run your
application until all plans are loaded in the cursor cache.
– Manually load the cursor cache into the corresponding plan
baseline.

8 - 20
Summary
• List the benefits of using bind variables
• Use bind peeking
• Use adaptive cursor sharing

8 - 21
• Using adaptive cursor sharing and bind peeking
• Using the CURSOR_SHARING initialization parameter

Using Optimizer Hints

9 - 2
Objectives
After completing this lesson, you should be able to :
• Use hints when appropriate
• Specify hints for:
– Optimizer mode
– Query transformation
– Access path
– Join orders
– Join methods

9 - 3
Optimizer Hints: Overview
Optimizer hints:
• Influence optimizer decisions
• Example:
• HINTS SHOULD ONLY BE USED AS A LAST RESORT.
• When you use a hint, it is good practice to also add a
comment about that hint.
SELECT /*+ INDEX(e empfirstname_idx) skewed col */ *
FROM employees e
WHERE first_name='David'

9 - 4
Types of Hints
Apply to the entire SQL statement
Statement hints
Query block hints
Multitable hints
Single-table hints Specified on one table or view
Operate on a single query block
Specify more than one table or view

9 - 5
Specifying Hints
Hints apply to the optimization of only one statement block:
• A self-contained DML statement against a table
• A top-level DML or a subquery
hint
comment
text
*/
/*+
hint
comment
text
--+
SELECT
INSERT
DELETE
UPDATE
MERGE
SELECT
INSERT
DELETE
UPDATE
MERGE

9 - 6
Rules for Hints
• Place hints immediately after the first SQL keyword of a
statement block.
• Each statement block can have only one hint comment, but
it can contain multiple hints.
• Hints apply to only the statement block in which they
appear.
• If a statement uses aliases, hints must reference the aliases
rather than the table names.
• The optimizer ignores hints specified incorrectly without
raising errors.

9 - 7
Hint Recommendations
• Use hints carefully because they imply a high-maintenance
load.
• Be aware of the performance impact of hard-coded hints
when they become less valid.

9 - 8
Optimizer Hint Syntax: Example
UPDATE /*+ INDEX(p PRODUCTS_PROD_CAT_IX)*/
products p
SET p.prod_min_price =
(SELECT
(pr.prod_list_price*.95)
FROM products pr
WHERE p.prod_id = pr.prod_id)
WHERE p.prod_category = 'Men'
AND p.prod_status = 'available, on stock'
/

9 - 9
Hint Categories
There are hints for:
• Optimization approaches and goals
• Access paths
• Query transformations
• Join orders
• Join operation
• Parallel execution
• Additional hints

9 - 10
Optimization Goals and Approaches
Note: The ALTER SESSION... SET OPTIMIZER_MODE
statement does not affect SQL that is run from within PL/SQL.
FIRST_ROWS(n)
ALL_ROWS Selects a cost-based approach with a goal
of best throughput
Instructs the Oracle server to optimize an
individual SQL statement for fast response

9 - 11
Hints for Access Paths
Accesses table by hash scan
HASH
Accesses table by cluster scan
CLUSTER
Explicitly chooses a bitmap access path
INDEX_COMBINE
Scans an index in the ascending order
INDEX_ASC
Scans an index in the ascending order
INDEX
ROWID
FULL Performs a full table scan
Accesses a table by ROWID

9 - 13
Hints for Access Paths
Performs an index skip scan
INDEX_SS
Instructs the optimizer to use an index
join as an access path
INDEX_JOIN
Merges single-column indexes
AND_EQUAL
Does not allow using a set of indexes
NO_INDEX
Performs a fast-full index scan
INDEX_FFS
Selects an index scan for the specified
table
INDEX_DESC

9 - 15
The INDEX_COMBINE Hint: Example
SELECT --+INDEX_COMBINE(CUSTOMERS)
cust_last_name
FROM SH.CUSTOMERS
WHERE ( CUST_GENDER= 'F' AND
CUST_MARITAL_STATUS = 'single')
OR CUST_YEAR_OF_BIRTH BETWEEN '1917'
AND '1920';

9 - 17
Hints for Query Transformation
Merges subquery bodies into
surrounding query block
UNNEST
Turns off query rewrite
NO_REWRITE
Prevents OR expansions
NO_EXPAND
Rewrites query in terms of
materialized views
REWRITE
Skips all query transformation
NO_QUERY_TRANSFORMATION
Rewrites OR into UNION ALL and
disables INLIST processing
USE_CONCAT
Turns off unnesting
NO_UNNEST

9 - 18
Hints for Query Transformation
Merges complex views or subqueries
with the surrounding query
MERGE
Indicates that the hinted table should
not be considered as a fact table
NO_FACT
Indicates that the hinted table should
be considered as a fact table
FACT
Makes the optimizer use the best plan
in which the transformation can be
used
STAR_TRANSFORMATION
Prevents merging of mergeable views
NO_MERGE

9 - 20
Hints for Join Orders
Uses the specified tables as the first table
in the join order
LEADING
Causes the Oracle server to join tables in
the order in which they appear in the
FROM clause
ORDERED

9 - 21
Hints for Join Operations
Does not use hash join
NO_USE_HASH
Instructs the optimizer to execute the query at a
different site than that selected by the database
DRIVING_SITE
Similar to USE_NL, but must be able to use an
index for the join
USE_NL_WITH_INDEX
Joins the specified table using a hash join
USE_HASH
Does not perform sort-merge operations for the
join
NO_USE_MERGE
Joins the specified table using a nested loop join
USE_NL
Joins the specified table using a sort-merge join
USE_MERGE
Does not use nested loops to perform the join
NO_USE_NL

9 - 23
Additional Hints
Evaluates nonmerged subqueries
first
PUSH_SUBQ
Pushes join predicate into view
PUSH_PRED
Overrides the default caching
specification of the table
CACHE
Controls dynamic sampling to
improve server performance
DYNAMIC_SAMPLING
Enables direct-path INSERT
APPEND
Prevents replacing literals with
bind variables
CURSOR_SHARING_EXACT
Forces the optimizer to preserve
the order of predicate evaluation
ORDERED_PREDICATES
Enables regular INSERT
NOAPPEND

9 - 25
Additional Hints
Sets initialization parameter for
query duration
OPT_PARAM
Forces real-time query monitoring
MONITOR
Disables result caching for the
query or query fragment
NO_RESULT_CACHE
Caches the result of the query or
query fragment
RESULT_CACHE
Disables real-time query
monitoring
NO_MONITOR

9 - 26
Hints and Views
• Do not use hints in views.
• Use view-optimization techniques:
– Statement transformation
– Results accessed like a table
• Hints can be used on mergeable views and nonmergeable
views.

9 - 28
Global Table Hints
• Extended hint syntax enables specifying for tables that
appear in views
• References a table name in the hint with a recursive dot
notation
CREATE view city_view AS
SELECT *
FROM customers c
WHERE cust_city like 'S%';
SELECT /*+ index(v.c cust_credit_limit_idx) */
v.cust_last_name, v.cust_credit_limit
FROM city_view v
WHERE cust_credit_limit > 5000;

9 - 29
Specifying a Query Block in a Hint
explain plan for
select /*+ FULL(@strange dept) */ ename
from emp e, (select /*+ QB_NAME(strange) */ *
from dept where deptno=10) d
where e.deptno = d.deptno and d.loc = 'C';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'ALL'));
---------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost(%CPU)|
---------------------------------------------------------------
|* 1 | HASH JOIN | | 1 | 41 | 7 (15)|
|* 2 | TABLE ACCESS FULL| DEPT | 1 | 21 | 3 (0)|
|* 3 | TABLE ACCESS FULL| EMP | 3 | 60 | 3 (0)|
---------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$DB579D14
2 - SEL$DB579D14 / DEPT@STRANGE
3 - SEL$DB579D14 / E@SEL$1

9 - 30
Specifying a Full Set of Hints
SELECT /*+ LEADING(e2 e1) USE_NL(e1)
INDEX(e1 emp_emp_id_pk) USE_MERGE(j) FULL(j) */
e1.first_name, e1.last_name, j.job_id,
sum(e2.salary) total_sal
FROM hr.employees e1, hr.employees e2,
hr.job_history j
WHERE e1.employee_id = e2.manager_id
AND e1.employee_id = j.employee_id
AND e1.hire_date = j.start_date
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;

9 - 31
Summary
• Set the optimizer mode
• Use optimizer hint syntax
• Determine access-path hints
• Analyze hints and their impact on views

9 - 32
This practice covers using various hints to influence execution
plans.

Application Tracing

10 - 2
Objectives
following:
• Configure the SQL Trace facility to collect session statistics
• Use the TRCSESS utility to consolidate SQL trace files
• Format trace files using the tkprof utility
• Interpret the output of the tkprof command

10 - 3
End-to-End Application Tracing Challenge
• I want to retrieve traces from CRM service.
• I want to retrieve traces from client C4.
• I want to retrieve traces from session 6.
Client
Dedicated
server
Trace
file
Clients
Shared
server
Trace
file
Shared
server
Trace
file
Shared
server
Trace
file
Client
Dedicated
server
Trace
file
Client
Dedicated
server
Trace
file
CRM ERP CRM CRM ERP CRM
Client C4
Client OE Client JF/Session 6
Client OE

10 - 4
End-to-End Application Tracing
• Simplifies the process of diagnosing performance problems
in multitier environments by allowing application workloads
to be seen by:
– Service
– Module
– Action
– Session
– Client
• End-to-End Application Tracing tools:
– Enterprise Manager
– DBMS_APPICATION_INFO, DBMS_SERVICE,
DBMS_MONITOR, DBMS_SESSION
– SQL Trace and TRCSESS utility
– tkprof

10 - 5
Location for Diagnostic Traces
$ADR_HOME/incident/incdir_n
USER|BACKGROUND_DUMP_DES
T
Incident dumps
$ADR_HOME/cdump
CORE_DUMP_DEST
Core dumps
$ADR_HOME/alert&trace
BACKGROUND_DUMP_DEST
Alert log data
$ADR_HOME/trace
BACKGROUND_DUMP_DEST
Background process
traces
$ADR_HOME/trace
USER_DUMP_DEST
Foreground process
traces
ADR Location
Previous Location
Diagnostic Data
ADR trace Oracle Database 10g trace – critical error trace
=
V$DIAG_INFO
DIAGNOSTIC_DEST

10 - 6
What Is a Service?
• Is a means of grouping sessions that perform the same kind
of work
• Provides a single-system image instead of a multiple-
instances image
• Is a part of the regular administration tasks that provide
dynamic service-to-instance allocation
• Is the base for High Availability of connections
• Provides a performance-tuning dimension
• Is a handle for capturing trace information

10 - 7
Use Services with Client Applications
ERP=(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=mynode)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))
url="jdbc:oracle:oci:@ERP"
url="jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=mynode)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))"

10 - 8
Tracing Services
• Applications using services can be further qualified by:
– MODULE
– ACTION
– CLIENT_IDENTIFIER
• Set using the following PL/SQL packages:
– DBMS_APPLICATION_INFO
– DBMS_SESSION
• Tracing can be done at all levels:
– CLIENT_IDENTIFIER
– SESSION_ID
– SERVICE_NAMES
– MODULE
– ACTION
– Combination of SERVICE_NAME, MODULE, ACTION

10 - 10
Use Enterprise Manager to Trace Services

10 - 11
Service Tracing: Example
• Trace on service, module, and action:
• Trace a particular client identifier:
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE('AP');
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(-
'AP', 'PAYMENTS', 'QUERY_DELINQUENT');
exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE
(client_id=>'C4', waits => TRUE, binds => FALSE);

10 - 12
Session Level Tracing: Example
• For all sessions in the database:
• For a particular session:
EXEC dbms_monitor.DATABASE_TRACE_ENABLE(TRUE,TRUE);
EXEC dbms_monitor.DATABASE_TRACE_DISABLE();
EXEC dbms_monitor.SESSION_TRACE_ENABLE(session_id=>
27, serial_num=>60, waits=>TRUE, binds=>FALSE);
EXEC dbms_monitor.SESSION_TRACE_DISABLE(session_id
=>27, serial_num=>60);

10 - 13
Trace Your Own Session
• Enabling trace:
• Disabling trace:
• Easily identifying your trace files:
EXEC DBMS_SESSION.SESSION_TRACE_DISABLE();
EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(waits =>
TRUE, binds => FALSE);
alter session set
tracefile_identifier='mytraceid';

10 - 14
The trcsess Utility
TRCSESS
Trace file
for one client
tkprof
Report
file
TRCSESS
Trace file
for CRM service
Client
Dedicated
server
Clients
Shared
server
Shared
server
Trace
file
Shared
server
Client
Dedicated
server
Trace
file
Client
Dedicated
server
CRM ERP CRM CRM ERP CRM
Trace
file
Trace
file
Trace
file
Trace
file

10 - 15
Invoking the trcsess Utility
trcsess [output=output_file_name]
[session=session_id]
[clientid=client_identifier]
[service=service_name]
[action=action_name]
[module=module_name]
[<trace file names>]
Trace
file
Trace
file
TRCSESS
Consolidated
trace file
Trace
file

10 - 16
The trcsess Utility: Example
exec dbms_session.set_identifier('HR session');
exec dbms_session.set_identifier('HR session');
exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE( -
client_id=>'HR session', waits => FALSE, binds => FALSE);
select * from employees;
select * from departments;
exec DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE( -
client_id => 'HR session');
trcsess output=mytrace.trc clientid='HR session'
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc
…
…
First session Second session
Third session

10 - 17
SQL Trace File Contents
• Parse, execute, and fetch counts
• CPU and elapsed times
• Physical reads and logical reads
• Number of rows processed
• Misses on the library cache
• Username under which each parse occurred
• Each commit and rollback
• Wait event and bind data for each SQL statement
• Row operations showing the actual execution plan of each
SQL statement
• Number of consistent reads, physical reads, physical writes,
and time elapsed for each operation on a row

10 - 18
SQL Trace File Contents: Example
*** [ Unix process pid: 19687 ]
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
…
====================
PARSING IN CURSOR #4 len=23 dep=0 uid=82 oct=3 lid=82 tim=1203929332521849
hv=4069246757 ad='34b6f730' sqlid='f34thrbt8rjt5'
select * from employees
END OF STMT
PARSE #4:c=49993,e=67123,p=28,cr=403,cu=0,mis=1,r=0,dep=0,og=1,tim=1203929332521845
EXEC #4:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1203929332521911
FETCH #4:c=1000,e=581,p=6,cr=6,cu=0,mis=0,r=1,dep=0,og=1,tim=1203929332522553
…
STAT #4 id=1 cnt=107 pid=0 pos=1 obj=70272 op='TABLE ACCESS FULL EMPLOYEES (cr=15
pr=6 pw=6 time=0 us cost=3 size=7276 card=107)'
*** [ Unix process pid: 19687 ]
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
*** 2008-02-25 15:49:19.820
…

10 - 19
Formatting SQL Trace Files: Overview
Use the tkprof utility to format your SQL trace files:
• Sort raw trace file to exhibit top SQL statements
• Filter dictionary statements
Trace
file
Trace
file
Trace
file
tkprof
Report
file
TRCSESS
Consolidated
trace file
Trace
file
Trace
file
Trace
file
Trace
file
Trace
file
Trace
file
Concatenated
trace file

10 - 20
Invoking the tkprof Utility
tkprof inputfile outputfile [waits=yes|no]
[sort=option]
[print=n]
[aggregate=yes|no]
[insert=sqlscritfile]
[sys=yes|no]
[table=schema.table]
[explain=user/password]
[record=statementfile]
[width=n]

10 - 22
tkprof Sorting Options
Description
Sort Option
Number of buffers for current read during execute
execu
Number of buffers for consistent read during execute
exeqry
Number of disk reads during execute
exedsk
Elapsed time executing
exeela
CPU time spent executing
execpu
Number of executes that were called
execnt
Number of misses in the library cache during parse
prsmis
Number of buffers for current read during parse
prscu
Number of buffers for consistent read during parse
prsqry
Number of disk reads during parse
prsdsk
Elapsed time parsing
prsela
CPU time parsing
prscpu
Number of times parse was called
prscnt

10 - 23
tkprof Sorting Options
Elapsed time fetching
fchela
Description
Sort Option
User ID of user that parsed the cursor
userid
Number of rows fetched
fchrow
Number of buffers for current read during fetch
fchcu
Number of buffers for consistent read during fetch
fchqry
Number of disk reads during fetch
fchdsk
CPU time spent fetching
fchcpu
Number of times fetch was called
fchcnt
Number of library cache misses during execute
exemis
Number of rows processed during execute
exerow

10 - 24
Output of the tkprof Command
• Text of the SQL statement
• Trace statistics (for statement and recursive calls) separated
into three SQL processing steps:
FETCH
EXECUTE
PARSE Translates the SQL statement into an execution plan
Retrieves the rows returned by a query
(Fetches are performed only for the SELECT
statements.)
Executes the statement
(This step modifies the data for the INSERT, UPDATE,
and DELETE statements.)

10 - 25
There are seven categories of trace statistics:
Number of rows processed by the fetch or execute
Rows
Number of logical buffers read in current mode
Current
Number of logical buffers read for consistent read
Query
Number of physical blocks read
Disk
Elapsed
CPU
Count Number of times the procedure was executed
Total number of seconds to execute
Number of seconds to process

10 - 27
The tkprof output also includes the following:
• Recursive SQL statements
• Library cache misses
• Parsing user ID
• Execution plan
• Optimizer mode or hint
• Row source operation
...
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing 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 …

10 - 29
tkprof Output with No Index: Example
...
select max(cust_credit_limit)
from customers
where cust_city ='Paris'
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- -------
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.10 0.09 1408 1459 0 1
------- ------ -------- ---------- ---------- ---------- ---------- -------
total 4 0.12 0.11 1408 1459 0 1
Parsing user id: 61
------- ---------------------------------------------------
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)

10 - 30
tkprof Output with Index: Example
...
select max(cust_credit_limit) from customers
where cust_city ='Paris'
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ---------
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 77 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ---------
total 4 0.01 0.00 0 77 0 1
Parsing user id: 61
------- ---------------------------------------------------
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 id 55097)

10 - 31
Summary
• Configure the SQL Trace facility to collect session statistics
• Use the TRCSESS utility to consolidate SQL trace files
• Format trace files using the tkprof utility
• Interpret the output of the tkprof command

10 - 32
• Creating a service
• Tracing your application using services
• Interpreting trace information using trcsess and tkprof

Automating SQL Tuning

11 - 2
Objectives
following:
• Describe statement profiling
• Use SQL Tuning Advisor
• Use SQL Access Advisor
• Use Automatic SQL Tuning

11 - 3
Tuning SQL Statements Automatically
• Tuning SQL statements automatically eases the entire SQL
tuning process and replaces manual SQL tuning.
• Optimizer modes:
– Normal mode
– Tuning mode or Automatic Tuning Optimizer (ATO)
• SQL Tuning Advisor is used to access tuning mode.
• You should use tuning mode only for high-load SQL
statements.

11 - 4
Application Tuning Challenges
ADDM
High-load
SQL
SQL workload
How can I
tune my
high-load
SQL?
SQL Tuning
Advisor
I can do
it for you!

11 - 5
SQL Tuning Advisor: Overview
Add missing index.
Run Access Advisor.
Restructure SQL.
Plan tuning
(SQL Profile).
Automatic Tuning
Optimizer
SQL Analysis
optimization
mode
Access Analysis
optimization
mode
Plan Tuning
optimization
mode
Statistics Check
optimization
mode
Detect stale or
missing statistics.
Comprehensive
SQL tuning
SQL Tuning
Advisor

11 - 6
DBMS_STATS.GATHER_TABLE_STATS(
ownname=>'SH', tabname=>'CUSTOMERS',
estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
Stale or Missing Object Statistics
• Object statistics are key inputs to the optimizer.
• ATO verifies object statistics for each query object.
• ATO uses dynamic sampling and generates:
– Auxiliary object statistics to compensate for missing or stale
object statistics
– Recommendations to gather object statistics where
appropriate:

11 - 7
SQL Statement Profiling
• Statement statistics are key inputs to the optimizer.
• ATO verifies statement statistics such as:
– Predicate selectivity
– Optimizer settings (FIRST_ROWS versus ALL_ROWS)
• Automatic Tuning Optimizer uses:
– Dynamic sampling
– Partial execution of the statement
– Past execution history statistics of the statement
• ATO builds a profile if statistics were generated:
exec :profile_name := -
dbms_sqltune.accept_sql_profile( -
task_name =>'my_sql_tuning_task');

11 - 8
Plan Tuning Flow and SQL Profile Creation
Optimizer
(Tuning mode)
Create
Submit
Output
SQL
Profile
SQL Tuning
Advisor
Database
users
Well-tuned
plan
Optimizer
(Normal mode)
Use
No application
code change

11 - 9
SQL Tuning Loop
SQL Tuning
Advisor
High load
ADDM
Generate
profiles
Workload

11 - 10
Access Path Analysis
SQL Tuning
Advisor
Workload
Indexes
Indexes
SQL
Access
Advisor
Significant
performance
gain
Comprehensive
index
analysis
CREATE INDEX JFV.IDX$_00002 on JFV.TEST("C");

11 - 11
SQL Structure Analysis
Poorly written
SQL statement
SQL Tuning
Advisor
Restructured
SQL statement
Design mistakes
Type mismatch and
indexes
SQL constructs
How can I
rewrite it?

11 - 12
SQL Tuning Advisor: Usage Model
SQL
Tuning
Advisor
ADDM High-load SQL
Filter
Sources
Manual Selection
Automatic selection
Cursor cache
Custom
AWR
AWR

11 - 13
Database Control and SQL Tuning Advisor

11 - 14
Running SQL Tuning Advisor: Example

11 - 15
Implementing Recommendations

11 - 16
SQL Access Advisor: Overview
Workload
SQL
Access
Advisor
Solution
Component
of CBO
Provides
implementation
script
No expertise
required
What
partitions, indexes,
and MVs do I need
to optimize
my entire
workload?

11 - 17
SQL Access Advisor: Usage Model
Indexes Materialized
views
Materialized
views log
SQL Access
Advisor
Hypothetical
SQL cache
Filter
Options
STS
Workload
Partitioned
objects

11 - 18
Possible Recommendations
YES
YES
Modify an existing materialized view log to add new columns
or clauses.
YES
YES
Partition an existing unpartitioned table or index.
YES
YES
Add a new materialized view log.
NO
YES
Drop an unused materialized view (log).
YES
YES
Add a new (partitioned) materialized view.
YES
YES
Modify an existing index by adding columns at the end.
NO
YES
Modify an existing index by changing the index type.
NO
YES
Drop an unused index.
YES
YES
Add new (partitioned) index on table or materialized view.
Limited
Comprehensive
Recommendation

11 - 19
SQL Access Advisor Session: Initial Options

11 - 20
SQL Access Advisor Session: Initial Options

11 - 21
SQL Access Advisor: Workload Source

11 - 22
SQL Access Advisor: Recommendation Options

11 - 23
SQL Access Advisor: Schedule and Review

11 - 24
SQL Access Advisor: Results

11 - 25
SQL Access Advisor: Results and Implementation

11 - 26
SQL Tuning Loop
SQL Tuning
Advisor
High load
ADDM
Workload
Run SQL Tuning Advisor.
Acc
ept
prof
iles.
Generate
SQL profiles.
Automatic
1
2
3
4

11 - 27
Automatic SQL Tuning
Auto matic
SQL Tuning
Workload
1
2
3
4
Top SQL
AWR
Reports

11 - 28
Automatic Tuning Process
Existing
profile?
Replace profile.
Y
N 3X
benefit?
3X
benefit?
Y
Accept profile.
Y
Ignore new profile.
N
N
New
SQL profile
GATHER_STATS_JOB
Indexes
Not considered for
auto implementation
Stale
stats
Restructure
SQL.
Considered for
auto implementation

11 - 30
Automatic SQL Tuning Controls
• Autotask configuration:
– On/off switch
– Maintenance windows running tuning task
– CPU resource consumption of tuning task
• Task parameters:
– SQL profile implementation automatic/manual switch
– Global time limit for tuning task
– Per-SQL time limit for tuning task
– Test-execute mode disabled to save time
– Maximum number of SQL profiles automatically implemented
per execution as well as overall
– Task execution expiration period

11 - 31
Automatic SQL Tuning Task

11 - 32
Configuring Automatic SQL Tuning

11 - 33
Automatic SQL Tuning: Result Summary

11 - 34
Automatic SQL Tuning: Result Details

11 - 35
Automatic SQL Tuning Result Details: Drilldown

11 - 36
Automatic SQL Tuning Considerations
• SQL not considered for Automatic SQL Tuning:
– Ad hoc or rarely repeated SQL
– Parallel queries
– Long-running queries after profiling
– Recursive SQL statements
– DML and DDL
• These statements can still be manually tuned by using SQL
Tuning Advisor.

11 - 37
Summary
In this lesson, you should have learned the following:
• Statement profiling
• SQL Tuning Advisor
• SQL Access Advisor
• Automatic SQL Tuning

11 - 38
• Using ADDM and SQL Tuning Advisor to tune your SQL
statements
• Using SQL Access Advisor to change your schema
• Using Automatic SQL Tuning to tune your statements

Oracle Database 11g SQL Tuning Workshop - Student Guide.pdf

Recommended

More Related Content

What's hot (20)

Similar to Oracle Database 11g SQL Tuning Workshop - Student Guide.pdf (20)

Recently uploaded (20)

Oracle Database 11g SQL Tuning Workshop - Student Guide.pdf