You are on page 1of 600

Oracle Database 11g: SQL

Tuning Workshop
Student Guide
D52163GC20
Edition 2.0
October 2010
D69160

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. 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 and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
Author
James Spiller, Tulika Srivastava
Technical Contributors and Reviewers
Abhinav Gupta, Branislav Valny, Clinton Shaffer, Donna Keesling, Ira Singer, Howard Bradley,
Sean Kim, Sue Harper, Teria Kidd
This book was published using: Oracle Tutor


V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
i
Table of Contents
Exploring the Oracle Database Architecture .................................................................................................1-1
Exploring the Oracle Database Architecture ..................................................................................................1-2
Objectives ......................................................................................................................................................1-3
Oracle Database Server Architecture: Overview ............................................................................................1-4
Connecting to the Database Instance ............................................................................................................1-5
Oracle Database Memory Structures: Overview ............................................................................................1-7
Database Buffer Cache ..................................................................................................................................1-8
Redo Log Buffer .............................................................................................................................................1-9
Shared Pool ...................................................................................................................................................1-10
Processing a DML Statement: Example .........................................................................................................1-11
COMMIT Processing: Example ......................................................................................................................1-13
Large Pool ......................................................................................................................................................1-14
Java Pool and Streams Pool ..........................................................................................................................1-16
Program Global Area (PGA) ..........................................................................................................................1-17
Background Process ......................................................................................................................................1-18
Automatic Shared Memory Management .......................................................................................................1-20
Automated SQL Execution Memory Management .........................................................................................1-21
Automatic Memory Management ...................................................................................................................1-22
Database Storage Architecture ......................................................................................................................1-23
Logical and Physical Database Structures .....................................................................................................1-25
Segments, Extents, and Blocks......................................................................................................................1-27
SYSTEM and SYSAUX Tablespaces .............................................................................................................1-28
Quiz ................................................................................................................................................................1-29
Summary ........................................................................................................................................................1-32
Practice 1: Overview ......................................................................................................................................1-33
Introduction to SQL Tuning .............................................................................................................................2-1
Introduction to SQL Tuning ............................................................................................................................2-2
Objectives ......................................................................................................................................................2-3
Reasons for Inefficient SQL Performance ......................................................................................................2-4
Inefficient SQL: Examples ..............................................................................................................................2-6
Performance Monitoring Solutions .................................................................................................................2-8
Monitoring and Tuning Tools: Overview .........................................................................................................2-10
EM Performance Pages for Reactive Tuning .................................................................................................2-11
Tuning Tools: Overview .................................................................................................................................2-12
SQL Tuning Tasks: Overview.........................................................................................................................2-14
CPU and Wait Time Tuning Dimensions ........................................................................................................2-15
Scalability with Application Design, Implementation, and Configuration ........................................................2-16
Common Mistakes on Customer Systems .....................................................................................................2-17
Proactive Tuning Methodology .......................................................................................................................2-19
Simplicity in Application Design ......................................................................................................................2-20
Data Modeling ................................................................................................................................................2-21
Table Design ..................................................................................................................................................2-22
Index Design ..................................................................................................................................................2-23
Using Views ...................................................................................................................................................2-24
SQL Execution Efficiency ...............................................................................................................................2-25
Writing SQL to Share Cursors ........................................................................................................................2-27
Performance Checklist ...................................................................................................................................2-29
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
ii
Development Environments: Overview ..........................................................................................................2-30
What Is Oracle SQL Developer? ....................................................................................................................2-31
Coding PL/SQL in SQL*Plus ..........................................................................................................................2-32
Quiz ................................................................................................................................................................2-34
Summary ........................................................................................................................................................2-38
Practice 2: Overview ......................................................................................................................................2-39
Introduction to the Optimizer ..........................................................................................................................3-1
Introduction to the Optimizer ..........................................................................................................................3-2
Objectives ......................................................................................................................................................3-3
Structured Query Language ...........................................................................................................................3-4
SQL Statement Representation .....................................................................................................................3-6
SQL Statement Implementation .....................................................................................................................3-7
SQL Statement Processing: Overview ...........................................................................................................3-8
SQL Statement Processing: Steps .................................................................................................................3-9
Step 1: Create a Cursor .................................................................................................................................3-10
Step 2: Parse the Statement ..........................................................................................................................3-11
Steps 3 and 4: Describe and Define ...............................................................................................................3-12
Steps 5 and 6: Bind and Parallelize ...............................................................................................................3-13
Steps 7 Through 9 ..........................................................................................................................................3-14
SQL Statement Processing PL/SQL: Example ..............................................................................................3-15
SQL Statement Parsing: Overview .................................................................................................................3-16
Why Do You Need an Optimizer? ..................................................................................................................3-18
Optimization During Hard Parse Operation ....................................................................................................3-20
Transformer: OR Expansion Example ............................................................................................................3-21
Transformer: Subquery Unnesting Example ..................................................................................................3-22
Transformer: View Merging Example .............................................................................................................3-23
Transformer: Predicate Pushing Example ......................................................................................................3-24
Transformer: Transitivity Example ..................................................................................................................3-25
Cost-Based Optimizer ....................................................................................................................................3-26
Estimator: Selectivity ......................................................................................................................................3-27
Estimator: Cardinality .....................................................................................................................................3-29
Estimator: Cost...............................................................................................................................................3-30
Plan Generator ...............................................................................................................................................3-31
Controlling the Behavior of the Optimizer .......................................................................................................3-32
Optimizer Features and Oracle Database Releases ......................................................................................3-37
Quiz ................................................................................................................................................................3-38
Summary ........................................................................................................................................................3-41
Practice 3: Overview ......................................................................................................................................3-42
Interpreting Execution Plans ...........................................................................................................................4-1
Interpreting Execution Plans ..........................................................................................................................4-2
Objectives ......................................................................................................................................................4-3
What Is an Execution Plan? ...........................................................................................................................4-4
Where to Find Execution Plans? ....................................................................................................................4-6
Viewing Execution Plans ................................................................................................................................4-8
The EXPLAIN PLAN Command .....................................................................................................................4-9
The EXPLAIN PLAN Command: Example .....................................................................................................4-11
PLAN_TABLE ................................................................................................................................................4-12
Displaying from PLAN_TABLE: Typical .........................................................................................................4-14
Displaying from PLAN_TABLE: ALL ..............................................................................................................4-16
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
iii
The EXPLAIN PLAN Command .....................................................................................................................4-18
Displaying from PLAN_TABLE: ADVANCED .................................................................................................4-19
Explain Plan Using SQL Developer ................................................................................................................4-20
AUTOTRACE .................................................................................................................................................4-21
The AUTOTRACE Syntax ..............................................................................................................................4-22
AUTOTRACE: Examples ...............................................................................................................................4-23
AUTOTRACE: Statistics .................................................................................................................................4-24
AUTOTRACE Using SQL Developer .............................................................................................................4-26
Using the V$SQL_PLAN View .......................................................................................................................4-27
The V$SQL_PLAN Columns ..........................................................................................................................4-28
The V$SQL_PLAN_STATISTICS View ..........................................................................................................4-29
Links Between Important Dynamic Performance Views .................................................................................4-30
Querying V$SQL_PLAN .................................................................................................................................4-32
Automatic Workload Repository (AWR) .........................................................................................................4-34
Managing AWR with PL/SQL .........................................................................................................................4-36
Important AWR Views ....................................................................................................................................4-38
Querying the AWR .........................................................................................................................................4-40
Generating SQL Reports from AWR Data ......................................................................................................4-42
SQL Monitoring: Overview .............................................................................................................................4-43
SQL Monitoring Report: Example ...................................................................................................................4-45
Interpreting an Execution Plan .......................................................................................................................4-49
Execution Plan Interpretation: Example 1 ......................................................................................................4-51
Execution Plan Interpretation: Example 2 ......................................................................................................4-55
Execution Plan Interpretation: Example 3 ......................................................................................................4-57
Reading More Complex Execution Plans .......................................................................................................4-59
Reviewing the Execution Plan ........................................................................................................................4-60
Looking Beyond Execution Plans ...................................................................................................................4-62
Quiz ................................................................................................................................................................4-63
Summary ........................................................................................................................................................4-67
Practice 4: Overview ......................................................................................................................................4-68
Application Tracing ..........................................................................................................................................5-1
Application Tracing .........................................................................................................................................5-2
Objectives ......................................................................................................................................................5-3
End-to-End Application Tracing Challenge ....................................................................................................5-4
End-to-End Application Tracing......................................................................................................................5-5
Location for Diagnostic Traces .......................................................................................................................5-6
What Is a Service? .........................................................................................................................................5-7
Using Services with Client Applications .........................................................................................................5-8
Tracing Services ............................................................................................................................................5-9
Use Enterprise Manager to Trace Services ...................................................................................................5-11
Service Tracing: Example ..............................................................................................................................5-12
Session Level Tracing: Example ....................................................................................................................5-14
Trace Your Own Session ...............................................................................................................................5-16
The trcsess Utility ...........................................................................................................................................5-17
Invoking the trcsess Utility ..............................................................................................................................5-18
The trcsess Utility: Example ...........................................................................................................................5-20
SQL Trace File Contents ................................................................................................................................5-21
SQL Trace File Contents: Example ................................................................................................................5-23
Formatting SQL Trace Files: Overview ..........................................................................................................5-24
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
iv
Invoking the tkprof Utility ................................................................................................................................5-26
tkprof Sorting Options ....................................................................................................................................5-28
Output of the tkprof Command .......................................................................................................................5-30
tkprof Output with No Index: Example ............................................................................................................5-35
tkprof Output with Index: Example .................................................................................................................5-36
Quiz ................................................................................................................................................................5-37
Summary ........................................................................................................................................................5-40
Practice 5: Overview ......................................................................................................................................5-41
Optimizer Operators ........................................................................................................................................6-1
Optimizer Operators .......................................................................................................................................6-2
Objectives ......................................................................................................................................................6-3
Row Source Operations .................................................................................................................................6-4
Main Structures and Access Paths ................................................................................................................6-5
Full Table Scan ..............................................................................................................................................6-6
Full Table Scans: Use Cases .........................................................................................................................6-7
ROWID Scan..................................................................................................................................................6-9
Sample Table Scans ......................................................................................................................................6-10
Indexes: Overview ..........................................................................................................................................6-12
Normal B*-tree Indexes ..................................................................................................................................6-14
Index Scans ...................................................................................................................................................6-15
Index Unique Scan .........................................................................................................................................6-16
Index Range Scan ..........................................................................................................................................6-17
Index Range Scan: Descending .....................................................................................................................6-19
Descending Index Range Scan ......................................................................................................................6-20
Index Range Scan: Function-Based ...............................................................................................................6-21
Index Full Scan ..............................................................................................................................................6-22
Index Fast Full Scan ......................................................................................................................................6-23
Index Skip Scan .............................................................................................................................................6-24
Index Skip Scan: Example .............................................................................................................................6-26
Index Join Scan ..............................................................................................................................................6-27
B*-tree Indexes and Nulls ..............................................................................................................................6-28
Using Indexes: Considering Nullable Columns ..............................................................................................6-29
Index-Organized Tables .................................................................................................................................6-30
Index-Organized Table Scans ........................................................................................................................6-32
Bitmap Indexes ..............................................................................................................................................6-33
Bitmap Index Access: Examples ....................................................................................................................6-35
Combining Bitmap Indexes: Examples ...........................................................................................................6-37
Combining Bitmap Index Access Paths .........................................................................................................6-38
Bitmap Operations .........................................................................................................................................6-39
Bitmap Join Index ...........................................................................................................................................6-40
Composite Indexes ........................................................................................................................................6-42
Invisible Index: Overview ...............................................................................................................................6-43
Invisible Indexes: Examples ...........................................................................................................................6-44
Guidelines for Managing Indexes ...................................................................................................................6-45
Investigating Index Usage ..............................................................................................................................6-47
Quiz ................................................................................................................................................................6-49
Summary ........................................................................................................................................................6-52
Practice 6: Overview ......................................................................................................................................6-53
Optimizer: Join Operators ...............................................................................................................................7-1
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
v
Optimizer: Join Operators ..............................................................................................................................7-2
Objectives ......................................................................................................................................................7-3
Join Methods ..................................................................................................................................................7-4
Nested Loops Join .........................................................................................................................................7-6
Nested Loops Join: Prefetching .....................................................................................................................7-7
Nested Loops Join: 11g Implementation ........................................................................................................7-8
Sort Merge Join ..............................................................................................................................................7-9
Hash Join .......................................................................................................................................................7-11
Cartesian Join ................................................................................................................................................7-12
Join Types ......................................................................................................................................................7-13
Equijoins and Nonequijoins ............................................................................................................................7-14
Outer Joins .....................................................................................................................................................7-15
Semijoins .......................................................................................................................................................7-17
Antijoins .........................................................................................................................................................7-18
Quiz ................................................................................................................................................................7-19
Summary ........................................................................................................................................................7-23
Practice 7: Overview ......................................................................................................................................7-24
Other Optimizer Operators ..............................................................................................................................8-1
Other Optimizer Operators .............................................................................................................................8-2
Objectives ......................................................................................................................................................8-3
Clusters ..........................................................................................................................................................8-4
When Are Clusters Useful? ............................................................................................................................8-6
Cluster Access Path: Examples .....................................................................................................................8-8
Sorting Operators ...........................................................................................................................................8-9
Buffer Sort Operator .......................................................................................................................................8-11
Inlist Iterator ...................................................................................................................................................8-12
View Operator ................................................................................................................................................8-13
Count Stop Key Operator ...............................................................................................................................8-14
Min/Max and First Row Operators ..................................................................................................................8-15
Other N-Array Operations ..............................................................................................................................8-16
FILTER Operations ........................................................................................................................................8-17
Concatenation Operation ...............................................................................................................................8-18
UNION [ALL], INTERSECT, MINUS ..............................................................................................................8-19
Result Cache Operator ..................................................................................................................................8-20
Quiz ................................................................................................................................................................8-21
Summary ........................................................................................................................................................8-25
Practice 8: Overview ......................................................................................................................................8-26
Case Study: Star Transformation ...................................................................................................................9-1
Case Study: Star Transformation ...................................................................................................................9-2
Objectives ......................................................................................................................................................9-3
The Star Schema Model ................................................................................................................................9-4
The Snowflake Schema Model.......................................................................................................................9-5
Star Query: Example ......................................................................................................................................9-6
Execution Plan Without Star Transformation .................................................................................................9-7
Star Transformation .......................................................................................................................................9-8
Star Transformation: Considerations ..............................................................................................................9-10
Star Transformation: Rewrite Example ..........................................................................................................9-11
Retrieving Fact Rows from One Dimension ...................................................................................................9-12
Retrieving Fact Rows from All Dimensions ....................................................................................................9-13
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
vi
Joining the Intermediate Result Set with Dimensions ...................................................................................9-14
Star Transformation Plan: Example 1 ............................................................................................................9-15
Star Transformation: Further Optimization .....................................................................................................9-16
Using Bitmap Join Indexes .............................................................................................................................9-17
Star Transformation Plan: Example 2 ............................................................................................................9-18
Star Transformation Hints ..............................................................................................................................9-19
Bitmap Join Indexes: Join Model 1 .................................................................................................................9-20
Bitmap Join Indexes: Join Model 2 .................................................................................................................9-21
Bitmap Join Indexes: Join Model 3 .................................................................................................................9-22
Bitmap Join Indexes: Join Model 4 .................................................................................................................9-23
Quiz ................................................................................................................................................................9-24
Summary ........................................................................................................................................................9-27
Practice 9: Overview ......................................................................................................................................9-28
Optimizer Statistics ..........................................................................................................................................10-1
Optimizer Statistics ........................................................................................................................................10-2
Objectives ......................................................................................................................................................10-3
Optimizer Statistics ........................................................................................................................................10-4
Types of Optimizer Statistics ..........................................................................................................................10-5
Table Statistics (DBA_TAB_STATISTICS) ....................................................................................................10-6
Index Statistics (DBA_IND_STATISTICS) .....................................................................................................10-7
Index Clustering Factor ..................................................................................................................................10-9
Column Statistics (DBA_TAB_COL_STATISTICS) ........................................................................................10-11
Histograms .....................................................................................................................................................10-12
Frequency Histograms ...................................................................................................................................10-13
Viewing Frequency Histograms......................................................................................................................10-14
Height-Balanced Histograms .........................................................................................................................10-15
Viewing Height-Balanced Histograms ............................................................................................................10-16
Histogram Considerations ..............................................................................................................................10-17
Multicolumn Statistics: Overview ....................................................................................................................10-18
Expression Statistics: Overview .....................................................................................................................10-20
Gathering System Statistics ...........................................................................................................................10-21
Gathering System Statistics: Example ...........................................................................................................10-23
Mechanisms for Gathering Statistics ..............................................................................................................10-25
Statistic Preferences: Overview .....................................................................................................................10-26
When to Gather Statistics Manually ...............................................................................................................10-28
Manual Statistics Gathering ...........................................................................................................................10-29
Manual Statistics Collection: Factors .............................................................................................................10-30
Managing Statistics Collection: Example .......................................................................................................10-31
Optimizer Dynamic Sampling: Overview ........................................................................................................10-32
Optimizer Dynamic Sampling at Work ............................................................................................................10-33
OPTIMIZER_DYNAMIC_SAMPLING .............................................................................................................10-34
Locking Statistics ...........................................................................................................................................10-36
Restoring Statistics ........................................................................................................................................10-37
Export and Import Statistics ...........................................................................................................................10-38
Quiz ................................................................................................................................................................10-39
Summary ........................................................................................................................................................10-42
Practice 10: Overview ....................................................................................................................................10-43
Using Bind Variables .......................................................................................................................................11-1
Using Bind Variables ......................................................................................................................................11-2
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
vii
Objectives ......................................................................................................................................................11-3
Cursor Sharing and Different Literal Values ...................................................................................................11-4
Cursor Sharing and Bind Variables ................................................................................................................11-6
Bind Variables in SQL*Plus ............................................................................................................................11-7
Bind Variables in Enterprise Manager ............................................................................................................11-8
Bind Variables in SQL Developer ...................................................................................................................11-9
Bind Variable Peeking ....................................................................................................................................11-10
Cursor Sharing Enhancements ......................................................................................................................11-12
The CURSOR_SHARING Parameter ............................................................................................................11-14
Forcing Cursor Sharing: Example ..................................................................................................................11-15
Adaptive Cursor Sharing: Overview ...............................................................................................................11-16
Adaptive Cursor Sharing: Architecture ...........................................................................................................11-17
Adaptive Cursor Sharing: Views .....................................................................................................................11-19
Adaptive Cursor Sharing: Example ................................................................................................................11-21
Interacting with Adaptive Cursor Sharing .......................................................................................................11-22
Quiz ................................................................................................................................................................11-23
Summary ........................................................................................................................................................11-26
Practice 11: Overview ....................................................................................................................................11-27
SQL Tuning Advisor ........................................................................................................................................12-1
SQL Tuning Advisor .......................................................................................................................................12-2
Objectives ......................................................................................................................................................12-3
Tuning SQL Statements Automatically ...........................................................................................................12-4
Application Tuning Challenges .......................................................................................................................12-5
SQL Tuning Advisor: Overview ......................................................................................................................12-6
Stale or Missing Object Statistics ...................................................................................................................12-7
SQL Statement Profiling .................................................................................................................................12-8
Plan Tuning Flow and SQL Profile Creation ...................................................................................................12-9
SQL Tuning Loop ...........................................................................................................................................12-10
Access Path Analysis .....................................................................................................................................12-11
SQL Structure Analysis ..................................................................................................................................12-12
SQL Tuning Advisor: Usage Model ................................................................................................................12-13
Database Control and SQL Tuning Advisor ...................................................................................................12-14
Running SQL Tuning Advisor: Example .........................................................................................................12-15
Schedule SQL Tuning Advisor .......................................................................................................................12-16
Implementing Recommendations ...................................................................................................................12-17
Compare Explain Plan ...................................................................................................................................12-18
Quiz ................................................................................................................................................................12-19
Summary ........................................................................................................................................................12-21
Practice 12: Overview ....................................................................................................................................12-22
Using SQL Access Advisor .............................................................................................................................13-1
Using SQL Access Advisor ............................................................................................................................13-2
Objectives ......................................................................................................................................................13-3
SQL Access Advisor: Overview ......................................................................................................................13-4
SQL Access Advisor: Usage Model ...............................................................................................................13-6
Possible Recommendations ...........................................................................................................................13-8
SQL Access Advisor Session: Initial Options .................................................................................................13-10
SQL Access Advisor: Workload Source .........................................................................................................13-12
SQL Access Advisor: Recommendation Options ...........................................................................................13-13
SQL Access Advisor: Schedule and Review ..................................................................................................13-14
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
viii
SQL Access Advisor: Results ........................................................................................................................13-15
SQL Access Advisor: Results and Implementation ........................................................................................13-16
Quiz ................................................................................................................................................................13-18
Summary ........................................................................................................................................................13-20
Practice 13: Overview ....................................................................................................................................13-21
Automating SQL Tuning ..................................................................................................................................14-1
Automating SQL Tuning .................................................................................................................................14-2
Objectives ......................................................................................................................................................14-3
SQL Tuning Loop ...........................................................................................................................................14-4
Automatic SQL Tuning ...................................................................................................................................14-5
Automatic Tuning Process .............................................................................................................................14-6
Automatic SQL Tuning Controls .....................................................................................................................14-8
Automatic SQL Tuning Task ..........................................................................................................................14-9
Configuring Automatic SQL Tuning ................................................................................................................14-10
Automatic SQL Tuning: Result Summary .......................................................................................................14-11
Automatic SQL Tuning: Result Details ...........................................................................................................14-12
Automatic SQL Tuning Result Details: Drilldown ...........................................................................................14-13
Automatic SQL Tuning Considerations ..........................................................................................................14-14
Quiz ................................................................................................................................................................14-15
Summary ........................................................................................................................................................14-16
Practice 14: Overview ....................................................................................................................................14-17
SQL Plan Management ....................................................................................................................................15-1
SQL Plan Management ..................................................................................................................................15-2
Objectives ......................................................................................................................................................15-3
Maintaining SQL Performance .......................................................................................................................15-4
SQL Plan Management: Overview .................................................................................................................15-5
SQL Plan Baseline: Architecture ....................................................................................................................15-7
Loading SQL Plan Baselines .........................................................................................................................15-9
Evolving SQL Plan Baselines .........................................................................................................................15-11
Important Baseline SQL Plan Attributes .........................................................................................................15-12
SQL Plan Selection ........................................................................................................................................15-14
Possible SQL Plan Manageability Scenarios .................................................................................................15-16
SQL Performance Analyzer and SQL Plan Baseline Scenario .....................................................................15-17
Loading a SQL Plan Baseline Automatically ..................................................................................................15-18
Purging SQL Management Base Policy .........................................................................................................15-19
Enterprise Manager and SQL Plan Baselines ................................................................................................15-20
Quiz ................................................................................................................................................................15-21
Summary ........................................................................................................................................................15-22
Practice 15: Overview Using SQL Plan Management ....................................................................................15-23
Using Optimizer Hints ......................................................................................................................................16-1
Using Optimizer Hints ....................................................................................................................................16-2
Objectives ......................................................................................................................................................16-3
Optimizer Hints: Overview ..............................................................................................................................16-4
Types of Hints ................................................................................................................................................16-5
Specifying Hints .............................................................................................................................................16-6
Rules for Hints................................................................................................................................................16-7
Hint Recommendations ..................................................................................................................................16-8
Optimizer Hint Syntax: Example.....................................................................................................................16-9
Hint Categories ..............................................................................................................................................16-10
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
ix
Optimization Goals and Approaches ..............................................................................................................16-11
Hints for Access Paths ...................................................................................................................................16-13
The INDEX_COMBINE Hint: Example ...........................................................................................................16-17
Hints for Query Transformation ......................................................................................................................16-19
Hints for Join Orders ......................................................................................................................................16-22
Hints for Join Operations ................................................................................................................................16-23
Additional Hints ..............................................................................................................................................16-25
Hints and Views .............................................................................................................................................16-28
Global Table Hints ..........................................................................................................................................16-30
Specifying a Query Block in a Hint .................................................................................................................16-31
Specifying a Full Set of Hints .........................................................................................................................16-32
Summary ........................................................................................................................................................16-33
Practice Appendix B: Overview ......................................................................................................................16-34
Using SQL Developer ......................................................................................................................................17-1
Using SQL Developer ....................................................................................................................................17-2
Objectives ......................................................................................................................................................17-3
What Is Oracle SQL Developer? ....................................................................................................................17-4
Specifications of SQL Developer ....................................................................................................................17-5
SQL Developer 2.1 Interface ..........................................................................................................................17-6
Creating a Database Connection ...................................................................................................................17-8
Browsing Database Objects ...........................................................................................................................17-11
Displaying the Table Structure .......................................................................................................................17-12
Browsing Files ................................................................................................................................................17-13
Creating a Schema Object .............................................................................................................................17-14
Creating a New Table: Example .....................................................................................................................17-15
Using the SQL Worksheet ..............................................................................................................................17-16
Executing SQL Statements ............................................................................................................................17-20
Saving SQL Scripts ........................................................................................................................................17-21
Executing Saved Script Files: Method 1 .........................................................................................................17-22
Executing Saved Script Files: Method 2 .........................................................................................................17-23
Formatting the SQL Code ..............................................................................................................................17-24
Using Snippets ...............................................................................................................................................17-25
Using Snippets: Example ...............................................................................................................................17-26
Debugging Procedures and Functions ...........................................................................................................17-27
Database Reporting .......................................................................................................................................17-28
Creating a User-Defined Report .....................................................................................................................17-30
External Tools ................................................................................................................................................17-31
Setting Preferences ........................................................................................................................................17-32
Resetting the SQL Developer Layout .............................................................................................................17-33
Summary ........................................................................................................................................................17-34


V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
xi
Preface
Profile
Before You Begin This Course
Before you begin this course, you should be familiar with SQL Language statements, and have
taken the Oracle Database 11g: Introduction to SQL course or have equivalent experience. It is
also recommended that you have taken the Oracle Database 11g: SQL Fundamentals I course.
How This Course Is Organized
Oracle Database 11g: SQL Tuning Workshop is an instructor-led course featuring lectures and
hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts
and skills that are introduced.
Related Publications
Oracle Publications
Title Part Number
Oracle Database SQL Reference 11g Release 2 (11.2) E10592-04
Oracle Database Performance Tuning Guide 11g Release 2 (11.2)E10821-05
Oracle SQL Developer User's Guide Release 2.1 E15222-02

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
xii
Typographic Conventions
The following two lists explain Oracle University typographical conventions for words that
appear within regular text or within code samples.
1. Typographic Conventions for words within regular text

Convention Object or Term Example
Courier new, User input;
commands;
column, table, and
schema names;
functions;
PL/SQL objects;
paths
Use the SELECT command to view
information stored in the LAST_NAME
column of the EMPLOYEES table.

Enter 300.

Log in as scott
Initial cap Triggers;
user interface object
names, such as
button names
Assign a When-Validate-Item trigger to
the ORD block.

Click the Cancel button.
Italic Titles of
courses and
manuals;
emphasized
words or phrases;
placeholders or
variables
For more information on the subject see
Oracle SQL Reference Manual

Do not save changes to the database.

Enter hostname, where hostname is the
host on which the password is to be changed
Quotation
marks
Lesson or module
title referenced
within a course
This subject is covered in Lesson 3, “Working with
Objects.”
2. Typographic Conventions for words within code samples

Convention Object or term Example
Uppercase Commands,
functions
SELECT employee_id
FROM employees
Lowercase
italic
Syntax variables CREATE ROLE role
Initial cap Forms triggers Form module: ORD
Trigger level: S_ITEM.QUANTITY
item
Trigger name: When-Validate-Item
. . .
Lowercase Column names,
table names
Filenames,
PL/SQL objects
. . .
OG_ACTIVATE_LAYER
(OG_GET_LAYER ('prod_pie_layer'))
. . .
SELECT last_name
FROM employees;
Bold Text that must be
entered by a user
CREATE USER scott
IDENTIFIED BY tiger;
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
xiii
3. Typographic Conventions for Oracle Application Navigation Paths
This course uses simplified navigation paths, such as the following example, to direct you
through Oracle Applications.
(N) Invoice > Entry > Invoice Batches Summary (M) Query > Find (B) Approve
This simplified path translates to the following:
1. (N) From the Navigator window, select Invoice then Entry then Invoice Batches
Summary.
2. (M) From the menu, select Query then Find.
3. (B) Click the Approve button.
Notations:
(N) = Navigator
(M) = Menu
(T) = Tab
(B) = Button
(I) = Icon
(H) = Hyperlink
(ST) = Sub Tab
4. Typographic Conventions for Oracle Application Help System Paths
This course uses a “navigation path” convention to represent actions you perform to find
pertinent information in the Oracle Applications Help System.
The following help navigation path, for example—
(Help) General Ledger > Journals > Enter Journals
—represents the following sequence of actions:
1. In the navigation frame of the help system window, expand the General Ledger entry.
2. Under the General Ledger entry, expand Journals.
3. Under Journals, select Enter Journals.
4. Review the Enter Journals topic that appears in the document frame of the help system
window.

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents
xiv

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 1
Exploring the Oracle
Database Architecture
Chapter 1

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 2
Exploring the Oracle Database Architecture

Exploring the Oracle Database Architecture
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 3
Objectives

Objectives
This lesson provides an overview of the Oracle Database server architecture. You learn about
physical and logical structures and about the various components.
Objectives
After completing this lesson, you should be able to:
• List the major architectural components of Oracle
Database server
• Explain memory structures
• Describe background processes
• Correlate logical and physical storage structures
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 4
Oracle Database Server Architecture: Overview

Oracle Database Server Architecture: Overview
An Oracle Database server consists of an Oracle Database and one or more Oracle Database
instances. An instance consists of memory structures and background processes. Every time
an instance is started, a shared memory area called the System Global Area (SGA) is
allocated and the background processes are started.
The SGA contains data and control information for one Oracle Database instance.
The background processes consolidate functions that would otherwise be handled by multiple
Oracle Database server programs running for each user process. They may asynchronously
perform input/output (I/O) and monitor other Oracle Database processes to provide increased
parallelism for better performance and reliability.
The database consists of physical files and logical structures discussed later in this lesson.
Because the physical and logical structures are separate, the physical storage of data can be
managed without affecting access to the logical storage structures.
Note: Oracle Real Application Clusters (Oracle RAC) comprises two or more Oracle Database
instances running on multiple clustered computers that communicates with each other by
means of an interconnect and access the same Oracle Database.
Database
Oracle Database Server Architecture: Overview
Instance
SGA
BGP2 BGP1 BGPn BGP3
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 5
Connecting to the Database Instance

Connecting to the Database Instance
When users connect to an Oracle Database server, they are connected to an Oracle
Database instance. The database instance services those users by allocating other memory
areas in addition to the SGA, and starting other processes in addition to the Oracle Database
background processes:
• User processes sometimes called client or foreground processes are created to run the
software code of an application program. Most environments have separate machines
for the client processes. A user process also manages communication with a
corresponding server process through a program interface.
• Oracle Database server creates server processes to handle requests from connected
user processes. A server process communicates with the user process and interacts
with the instance and the database to carry out requests from the associated user
process.
An Oracle Database instance can be configured to vary the number of user processes for
each server process. In a dedicated server configuration, a server process handles requests
for a single user process.
A shared server configuration enables many user processes to share a small number of
shared server processes, minimizing the number of server processes and maximizing the use
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 6
of available system resources. One or more dispatcher processes are then used to queue
user process requests in the SGA and dequeue shared server responses.
The Oracle Database server runs a listener that is responsible for handling network
connections. The application connects to the listener that creates a dedicated server process
or handles the connection to a dispatcher.
Connections and sessions are closely related to user processes, but are very different in
meaning:
• A connection is a communication pathway between a user process and an Oracle
Database instance. A communication pathway is established by using available
interprocess communication mechanisms (on a computer that runs both the user
process and Oracle Database) or network software (when different computers run the
database application and Oracle Database, and communicate through a network).
• A session represents the state of a current database user login to the database instance.
For example, when a user starts SQL*Plus, the user must provide a valid database
username and password, and then a session is established for that user. A session lasts
from the time a user connects until the user disconnects or exits the database
application.
Note: Multiple sessions can be created and exist concurrently for a single Oracle database
user using the same username. For example, a user with the username/password of HR/HR
can connect to the same Oracle Database instance several times.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 7
Oracle Database Memory Structures: Overview

Oracle Database Memory Structures: Overview
Oracle Database allocates memory structures for various purposes. For example, memory
stores the program code that is run, data that is shared among users, and private data areas
for each connected user. Two basic memory structures are associated with an instance:
• System Global Area (SGA): The SGA is shared by all server and background
processes. The SGA includes the following data structures:
- Database buffer cache: Caches blocks of data retrieved from the database files
- Redo log buffer: Caches recovery information before writing it to the physical files
- Shared pool: Caches various constructs that can be shared among sessions
- Large pool: Optional area used for certain operations, such as Oracle backup and
recovery operations, and I/O server processes
- Java pool: Used for session-specific Java code and data in the Java Virtual
Machine (JVM)
- Streams pool: Used by Oracle Streams to store information about the capture and
apply processes
• Program Global Areas (PGA): Memory regions that contain data and control
information about a server or background process. A PGA is suballocated from the
aggregated PGA area.
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
… …

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 8
Database Buffer Cache

Database Buffer Cache
The database buffer cache is the portion of the SGA that holds copies of data blocks that are
read from data files. All users concurrently connected to the instance share access to the
database buffer cache.
The first time an Oracle Database server process requires a particular piece of data, it
searches for the data in the database buffer cache. If the process finds the data already in the
cache (a cache hit), it can read the data directly from memory. If the process cannot find the
data in the cache (a cache miss), it must copy the data block from a data file on disk into a
buffer in the cache before accessing the data. Accessing data through a cache hit is faster
than data access through a cache miss.
The buffers in the cache are managed by a complex algorithm that uses a combination of
least recently used (LRU) lists and touch count. The DBWn (Database Writers) processes are
responsible for writing modified (dirty) buffers in the database buffer cache to disk when
necessary.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 9
Redo Log Buffer

Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that holds information about changes made
to the database. This information is stored in redo entries. Redo entries contain the
information necessary to reconstruct (or redo) changes that are made to the database by
INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations. Redo entries are used for
database recovery, if necessary.
Redo entries are copied by Oracle Database server processes from the user’s memory space
to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the
buffer. The LGWR (log writer) background process writes the redo log buffer to the active redo
log file (or group of files) on disk. LGWR is a background process that is capable of
asynchronous I/O.
Note: Depending on the number of CPUs on your system, there may be more than one redo
log buffer. They are automatically allocated.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 10
Shared Pool

Shared Pool
The shared pool portion of the SGA contains the following main parts:
• The library cache includes the sharable parts of SQL statements, PL/SQL procedures
and packages. It also contains control structures such as locks.
• The data dictionary is a collection of database tables containing reference information
about the database. The data dictionary is accessed so often by Oracle Database that
two special locations in memory are designated to hold dictionary data. One area is
called the data dictionary cache, also known as the row cache, and the other area is
called the library cache. All Oracle Database server processes share these two caches
for access to data dictionary information.
• The result cache is composed of the SQL query result cache and the PL/SQL function
result cache. This cache is used to store results of SQL queries or PL/SQL functions to
speed up their future executions.
• Control structures are essentially lock structures.
Note: In general, any item in the shared pool remains until it is flushed according to a modified
LRU algorithm.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 11
Processing a DML Statement: Example

Processing a DML Statement: Example
The steps involved in executing a data manipulation language (DML) statement are:
1. The server process receives the statement and checks the library cache for any shared
SQL area that contains a similar SQL statement. If a shared SQL area is found, the
server process checks the user’s access privileges to the requested data, and the
existing shared SQL area is used to process the statement. If not, a new shared SQL
area is allocated for the statement, so that it can be parsed and processed.
2. If the data and undo segment blocks are not already in the buffer cache, the server
process reads them from the data files into the buffer cache. The server process locks
the rows that are to be modified.
3. The server process records the changes to be made to the data buffers as well as the
undo changes. These changes are written to the redo log buffer before the in-memory
data and undo buffers are modified. This is called write-ahead logging.
4. The undo segment buffers contain values of the data before it is modified. The undo
buffers are used to store the before image of the data so that the DML statements can
be rolled back, if necessary. The data buffers record the new values of the data.
5. The user gets the feedback from the DML operation (such as how many rows were
affected by the operation).
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 12
Note: Any changed blocks in the buffer cache are marked as dirty buffers; that is, the buffers
are not the same as the corresponding blocks on the disk. These buffers are not immediately
written to disk by the DBWn processes.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 13
COMMIT Processing: Example

COMMIT Processing: Example
When COMMIT is issued, the following steps are performed:
1. The server process places a commit record, along with the system change number
(SCN), in the redo log buffer. The SCN is a number monotonically incremented and is
unique within the database. It is used by Oracle Database as an internal time stamp to
synchronize data and to provide read consistency when data is retrieved from the data
files. Using the SCN enables Oracle Database to perform consistency checks without
depending on the date and time of the operating system.
2. The LGWR background process performs a contiguous write of all the redo log buffer
entries up to and including the commit record to the redo log files. After this point, Oracle
Database can guarantee that the changes are not lost even if there is an instance
failure.
3. If modified blocks are still in the SGA, and if no other session is modifying them, then the
database removes lock-related transaction information from the blocks. This process is
known as commit cleanout.
4. The server process provides feedback to the user process about the completion of the
transaction.
Note: If not done already, DBWn eventually writes the actual changes back to disk based on its
own internal timing mechanism.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 14
Large Pool

Large Pool
You can configure an optional memory area called the large pool to provide large memory
allocations for:
• Session memory for the shared server, the Oracle XA interface (used where
transactions interact with more than one database), or parallel execution buffers
• I/O server processes
• Oracle Database backup and restore operations
By allocating the above memory components from the large pool, Oracle Database can use
the shared pool primarily for caching the shared part of SQL and PL/SQL constructs. The
shared pool was originally designed to store SQL and PL/SQL constructs. Using the large
pool avoids fragmentation issues associated with having large and small allocations sharing
the same memory area. Unlike the shared pool, the large pool does not have an LRU list.
You should consider configuring a large pool if your instance uses any of the following:
• Parallel execution: Parallel query uses shared pool memory to cache parallel execution
message buffers.
• Recovery Manager: Recovery Manager uses the shared pool to cache I/O buffers
during backup and restore operations.
Large Pool
• 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
I/O buffer
Free
memory
Response
queue
Request
queue
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 15
• Shared server: In a shared server architecture, the session memory for each client
process is included in the shared pool.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 16
Java Pool and Streams Pool

Java Pool and Streams Pool
Java pool memory is used for all session-specific Java code and data in the JVM. Java pool
memory is used in different ways, depending on the mode in which Oracle Database runs.
Oracle Streams enables the propagation and management of data, transactions and events in
a data stream either within a database, or from one database to another. The Streams pool is
used exclusively by Oracle Streams. The Streams pool stores buffered queue messages, and
it provides memory for Oracle Streams capture and apply processes.
Note: A detailed discussion of Java programming and Oracle Streams is beyond the scope of
this course.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 17
Program Global Area (PGA)

Program Global Area (PGA)
The PGA can be compared to a temporary countertop workspace used by a file clerk (the
server process) to perform a function on behalf of a customer (client process). The clerk
clears a section of the countertop, uses the workspace to store details about the customer’s
request, and then gives up the space when the work is done.
Generally, the PGA memory is divided into the following areas:
• Session memory is the memory allocated to hold a session’s variables (logon
information) and other information related to the session. For a shared server, the
session memory is shared and not private.
• Cursors are handles to private memory structures of specific SQL statements
• SQL work areas are allocated to support memory-intensive operators, such as the ones
listed in the slide. Generally, bigger work areas can significantly improve the
performance of a particular operator at the cost of higher memory consumption.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 18
Background Process

Background Process
The background processes commonly seen in non-RAC, non-ASM environments can include
the following:
• Database writer process (DBWn): Asynchronously writes modified (dirty) buffers in the
database buffer cache to disk
• Log writer process (LGWR): Writes the recovery information called redo information in
the log buffer to a redo log file on disk
• Checkpoint process (CKPT): Records checkpoint information in control files and each
data file header
• System Monitor process (SMON): Performs recovery at instance startup and cleans up
unused temporary segments
• Process monitor process (PMON): Performs process recovery when a user process
fails
• Result cache background process (RCBG): Used to maintain the result cache in the
shared pool
• Job queue process (CJQ0): Runs user jobs used in batch processing through the
Scheduler
Background Process
PMON SMON ARCn DBWn LGWR CKPT
Database
buffer
cache
Shared pool
SGA
Redo log
buffer
MMON CJQ0 QMNn RCBG MMAN
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 19
• Archiver processes (ARCn): Copies redo log files to a designated storage device after
a log switch has occurred
• Queue monitor processes (QMNn): Monitors the Oracle Streams message queues
• Manageability monitoring process (MMON): Performs manageability-related
background tasks
• Memory Manager background process (MMAN): Used to manage SGA and PGA
memory components automatically
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 20
Automatic Shared Memory Management

Automatic Shared Memory Management
You can use the Automatic Shared Memory Management (ASMM) feature to enable the
database to automatically determine the size of each of these memory components within the
limits of the total SGA size.
The system uses an SGA size parameter (SGA_TARGET) that includes all the memory in the
SGA, including all the automatically sized components, manually sized components, and any
internal allocations during startup. ASMM simplifies the configuration of the SGA by enabling
you to specify a total memory amount to be used for all SGA components. The Oracle
Database then periodically redistributes memory between the automatically tuned
components, according to workload requirements.
Note: You must set STATISTICS_LEVEL to TYPICAL or ALL to use ASMM.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 21
Automated SQL Execution Memory Management

Automated SQL Execution Memory Management
This feature provides an automatic mode for allocating memory to working areas in the PGA.
You can use the PGA_AGGREGATE_TARGET parameter to specify the total amount of memory
that should be allocated to the PGA areas of the instance’s sessions. In automatic mode,
working areas that are used by memory-intensive operators (sorts and hash joins) can be
automatically and dynamically adjusted.
This feature offers several performance and scalability benefits for decision support system
(DSS) workloads and mixed workloads with complex queries. The overall system performance
is maximized, and the available memory is allocated more efficiently among queries to
optimize both throughput and response time. In particular, the savings that are gained from
improved use of memory translate to better throughput at high loads.
Note: In earlier releases of Oracle Database server, you had to manually specify the
maximum work area size for each type of SQL operator, such as sort or hash join. This proved
to be very difficult because the workload changes constantly. Although the current release of
Oracle Database supports this manual PGA memory management method that might be
useful for specific sessions, it is recommended that you leave automatic PGA memory
management enabled.
Automated SQL Execution Memory Management
Background
process
Server
process
Server
process
… …

PGA_AGGREGATE_TARGET
Which size to choose?
Aggregated
PGA
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 22
Automatic Memory Management

Automatic Memory Management
As seen already, the size of the various memory areas of the instance directly impacts the
speed of SQL processing. Depending on the database workload, it is difficult to size those
components manually.
With Automatic Memory Management, the system automatically adapts the size of each
memory’s components to your workload memory needs.
Set your MEMORY_TARGET initialization parameter for the database instance and the MMAN
background process automatically tunes to the target memory size, redistributing memory as
needed between the internal components of the SGA and between the SGA and the
aggregated PGAs.
The Automatic Shared Memory Management feature uses the SGA memory broker that is
implemented by two background processes Manageability Monitor (MMON) and Memory
Manager (MMAN). Statistics and memory advisory data are periodically captured in memory
by MMON. MMAN coordinates the sizing of the memory components according to MMON
decisions.
Note: Currently, this mechanism is only implemented on Linux, Solaris, HP-UX, AIX, and
Windows.
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.
B
u
f
f
e
r

c
a
c
h
e
L
a
r
g
e

p
o
o
l
S
h
a
r
e
d

p
o
o
l
J
a
v
a

p
o
o
l
S
t
r
e
a
m
s

p
o
o
l
P
r
i
v
a
t
e
S
Q
L

a
r
e
a
s
O
t
h
e
r

S
G
A
U
n
t
u
n
a
b
l
e
P
G
A
F
r
e
e
MEMORY_TARGET + STATISTICS_LEVEL
MMAN
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 23
Database Storage Architecture

Database Storage Architecture
The files that constitute an Oracle database are organized into the following:
• Control file: Contain data about the database itself (that is, physical database structure
information). These files are critical to the database. Without them, you cannot open
data files to access the data in the database.
• Data files: Contain the user or application data of the database, as well as metadata
and the data dictionary
• Online redo log files: Allow for instance recovery of the database. If the database
server crashes and does not lose any data files, the instance can recover the database
with the information in these files.
The following additional files are important for the successful running of the database:
• Parameter file: Is used to define how the instance is configured when it starts up
• Password file: Allows sysdba, sysoper, and sysasm to connect remotely to the
database and perform administrative tasks
• Backup files: Are used for database recovery. You typically restore a backup file when
a media failure or user error has damaged or deleted the original file.
Database Storage Architecture
Online redo log files
Password file
Parameter file Archived redo log
files
Control file
Data files
Alert log and trace files
Backup files
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 24
• Archived redo log files: Contain an ongoing history of the data changes (redo) that are
generated by the instance. Using these files and a backup of the database, you can
recover a lost data file. That is, archive logs enable the recovery of restored data files.
• Trace files: Each server and background process can write to an associated trace file.
When an internal error is detected by a process, the process dumps information about
the error to its trace file. Some of the information written to a trace file is intended for the
developer, whereas other information is for Oracle Support Services.
• Alert log file: These are special trace entries. The alert log of a database is a
chronological log of messages and errors. Each instance has one alert log file. It is
recommended that you review this periodically.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 25
Logical and Physical Database Structures

Logical and Physical Database Structures
The database has logical structures and physical structures.
Tablespaces
A database is divided into logical storage units called tablespaces, which group related logical
structures together. For example, tablespaces commonly group all of an application’s objects
to simplify some administrative operations. You may have a tablespace for different
applications.
Databases, Tablespaces, and Data Files
The relationship among databases, tablespaces, and data files is illustrated in the slide. Each
database is logically divided into one or more tablespaces. One or more data files are
explicitly created for each tablespace to physically store the data of all logical structures in a
tablespace. If it is a TEMPORARY tablespace instead of a tablespace containing data, the
tablespace has a temporary file.
Schemas
A schema is a collection of database objects that are owned by a database user. Schema
objects are the logical structures that directly refer to the database’s data. Schema objects
include structures, such as tables, views, sequences, stored procedures, synonyms, indexes,
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 26
clusters, and database links. In general, schema objects include everything that your
application creates in the database.
Data Blocks
At the finest level of granularity, an Oracle database’s data is stored in data blocks. One data
block corresponds to a specific number of bytes of physical database space on the disk. A
data block size is specified for each tablespace when it is created. A database uses and
allocates free database space in Oracle data blocks.
Extents
The next level of logical database space is an extent. An extent is a specific number of
contiguous data blocks (obtained in a single allocation) that are used to store a specific type of
information.
Segments
The level of logical database storage above an extent is called a segment. A segment is a set
of extents that are allocated for a certain logical structure. Different types of segments include:
• Data segments: Each nonclustered, non-index-organized table has a data segment,
with the exception of external tables and global temporary tables that have no segments,
and partitioned tables in which each table has one or more segments. All of the table’s
data is stored in the extents of its data segment. For a partitioned table, each partition
has a data segment. Each cluster has a data segment. The data of every table in the
cluster is stored in the cluster’s data segment.
• Index segments: Each index has an index segment that stores all of its data. For a
partitioned index, each partition has an index segment.
• Undo segments: One UNDO tablespace is created for each database instance. This
tablespace contains numerous undo segments to temporarily store undo information.
The information in an undo segment is used to generate read-consistent database
information and, during database recovery, to roll back uncommitted transactions for
users.
• Temporary segments: Temporary segments are created by the Oracle Database when
a SQL statement needs a temporary work area to complete execution. When the
statement finishes execution, the temporary segment’s extents are returned to the
instance for future use. Specify either a default temporary tablespace for every user, or a
default temporary tablespace that is used across the database.
The Oracle Database dynamically allocates space. When the existing extents of a segment
are full, additional extents are added. Because extents are allocated as needed, the extents of
a segment may or may not be contiguous on the disk.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 27
Segments, Extents, and Blocks

Segments, Extents, and Blocks
Database objects, such as tables and indexes are stored as segments in tablespaces. Each
segment contains one or more extents. An extent consists of contiguous data blocks, which
means that each extent can exist only in one data file. Data blocks are the smallest unit of I/O
in the database.
When the database requests a set of data blocks from the operating system (OS), the OS
maps this to an actual file system or disk block on the storage device. Because of this, you do
not need to know the physical address of any of the data in your database. This also means
that a data file can be striped or mirrored on several disks.
The size of the data block can be set at the time of database creation. The default size of 8
KB is adequate for most databases. If your database supports a data warehouse application
that has large tables and indexes, a larger block size may be beneficial.
If your database supports a transactional application in which reads and writes are random,
specifying a smaller block size may be beneficial. The maximum block size depends on your
OS. The minimum Oracle block size is 2 KB; it should rarely (if ever) be used.
You can have tablespaces with a nonstandard block size. For details, see the Oracle
Database Administrator’s Guide.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 28
SYSTEM and SYSAUX Tablespaces

SYSTEM and SYSAUX Tablespaces
Each Oracle Database must contain a SYSTEM tablespace and a SYSAUX tablespace, which
are automatically created when the database is created. The system default is to create a
smallfile tablespace. You can also create bigfile tablespaces, which enable the Oracle
database to manage ultra large files (up to 8 exabytes in size).
A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is
always online when the database is open. It stores tables that support the core functionality of
the database, such as the data dictionary tables.
The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX
tablespace stores many database components, and it must be online for the correct
functioning of all database components.
Note: The SYSAUX tablespace may be taken offline for performing tablespace recovery,
whereas this is not possible in the case of the SYSTEM tablespace. Neither of them may be
made read-only.
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).
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 29
Quiz

Answer: a
Quiz
The first time an Oracle Database server process requires a
particular piece of data, it searches for the data in the:
a. Database Buffer Cache
b. PGA
c. Redo Log Buffer
d. Shared Pool
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 30
Quiz

Answer: b
Quiz
Which of the following is not a database logical structure?
a. Tablespace
b. Data File
c. Schema
d. Segment
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 31
Quiz

Answer: b
Quiz
The SYSAUX tablespace is used for core functionality and the
SYSTEM tablespace is used for additional database
components such as the Enterprise Manager Repository.
a. True
b. False
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 32
Summary

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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 33
Practice 1: Overview


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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture
Chapter 1 - Page 34

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 1
Introduction to SQL Tuning
Chapter 2

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 2
Introduction to SQL Tuning

Introduction to SQL Tuning
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 3
Objectives

Objectives
This lesson gives you an understanding of the tuning process and the different components of
an Oracle Database that may require tuning.
Objectives
After completing this lesson, you should be able to:
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 4
Reasons for Inefficient SQL Performance

Reasons for Inefficient SQL Performance
SQL statements can perform poorly for a variety of reasons:
• Stale optimizer statistics: SQL execution plans are generated by the cost-based
optimizer (CBO). For CBO to effectively choose the most efficient plan, it needs accurate
information on the data volume and distribution of tables and indexes referenced in the
queries. Without accurate optimizer statistics, the CBO can easily be mislead and
generate suboptimal execution plans.
• Missing access structures: Absence of access structures, such as indexes,
materialized views, and partitions is a common reason for poor SQL performance. The
right set of access structures can improve SQL performance by several orders of
magnitude.
• Suboptimal execution plan selection: The CBO can sometimes select a suboptimal
execution plan for a SQL statement. This happens for most part because of incorrect
estimates of some attributes of that SQL statement, such as its cost, cardinality, or
predicate selectivity.
• Poorly constructed SQL: If the SQL statement is designed poorly, there is not much
that the optimizer can do to improve its performance. A missing join condition leading to
a Cartesian product, or the use of more expensive SQL constructs like UNION in place of
UNION ALL, are just a couple of examples of inefficient SQL design.
Reasons for Inefficient SQL Performance
• Stale or missing optimizer statistics
• Missing access structures
• Suboptimal execution plan selection
• Poorly constructed SQL
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 5
These four main causes of poor SQL optimization can have a drastic impact on performance.
Note: Additional reasons for poor performance might be connected with hardware-related
issues, such as memory, I/Os, CPUs, and so on.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 6
Inefficient SQL: Examples

Inefficient SQL: Examples
The slide shows five examples of possibly poorly constructed SQL that could easily result in
inefficient execution.
1. This is a common business question type. The query determines how many products
have list prices less than 15% above the average cost of the product. This statement has
a correlated subquery, which means that the subquery is run for every row found in the
outer query. The query is better written as:
SELECT COUNT(*) FROM products p,
(SELECT prod_id, AVG(unit_cost) ac FROM costs
GROUP BY prod_id) c
WHERE p.prod_id = c.prod_id AND
p.prod_list_price < 1.15 * c.ac
2. This query applies functions to the join columns, restricting the conditions where indexes
can be used. Use a simple equality, if you can. Otherwise, a function-based index may
be necessary.
3. This query has a condition that forces implicit data type conversion; the
ORDER_ID_CHAR column is a character type, and the constant is a numeric type. You
should make the literal match the column type.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 7
4. The fourth query uses a data type conversion function in it to make the data types match
in the comparison. The problem here is that the TO_CHAR function is applied to the
column value, rather than to the constant. This means that the function is called for every
row in the table. It would be better to convert the literal once, and not convert the column.
This is better queried as:
SELECT * FROM employees
WHERE salary = TO_NUMBER(:sal)
5. The UNION operator, as opposed to the UNION ALL operator, ensures that there are no
duplicate rows in the result set. However, this requires an extra step, a unique sort, to
eliminate any duplicates. If you know that there are no rows in common between the two
UNIONed queries, use UNION ALL instead of UNION. This eliminates the unnecessary
sort.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 8
Performance Monitoring Solutions

Performance Monitoring Solutions
Automatic Workload Repository (AWR): It collects, processes, and maintains performance
statistics for problem detection and self-tuning purposes. This data is both in memory and
stored in the database. The gathered data can be displayed in both reports and views.
Active Session History (ASH): It provides sampled session activity in the instance. Active
sessions are sampled every second and are stored in a circular buffer in SGA.
Snapshots: Snapshots are sets of historical data for specific time periods that are used for
performance comparisons by ADDM. AWR compares the difference between snapshots to
determine which SQL statements to capture based on the effect on the system load. This
reduces the number of SQL statements that must be captured over time.
Automatic Database Diagnostic Monitor (ADDM)
In addition to the classical reactive tuning capabilities of previous releases, such as Statspack,
SQL trace files, and performance views, Oracle Database 10g introduced new methodologies
to monitor your database in two categories:
• Proactive monitoring:
- Automatic Database Diagnostic Monitor (ADDM) automatically identifies
bottlenecks within the Oracle Database. Additionally, working with other
Performance Monitoring Solutions
Snapshots
In-memory
statistics
AWR report
SGA
60 min
ADDM
results
Snapshots
Statspack
Fore-
ground
Automatic
ADDM
Alerts
ASH
AST
AWR
MMON
ASH: Active Session History
AWR: Automatic Workload Repository
ADDM: Automatic Database Diagnostic Monitor
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 9
manageability components, ADDM makes recommendations on the options
available for fixing these bottlenecks.
- Oracle Database 11g further automates the SQL tuning process by identifying
problematic SQL statements, running SQL Tuning Advisor on them, and
implementing the resulting SQL profile recommendations to tune the statement
without requiring user intervention. This automation uses the AUTOTASK
framework through a new task called Automatic SQL Tuning Task that runs every
night by default.
• Reactive monitoring:
- Server-generated alerts: The Oracle Database can automatically detect
problematic situations. In reaction to a detected problem, the Oracle Database
sends you an alert message with possible remedial action.
- The Oracle Database has powerful new data sources and performance-reporting
capabilities. Enterprise Manager provides an integrated performance management
console that uses all relevant data sources. Using a drill-down method, you can
manually identify bottlenecks with just a few mouse clicks.
New data sources are introduced to capture important information about your database’s
health—for example, new memory statistics (for current diagnostics) as well as statistics
history stored in Automatic Workload Repository (AWR).
Note: Accessing Enterprise Manager or tools discussed here may require additional licenses
and certain privileges generally reserved for database administrators.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 10
Monitoring and Tuning Tools: Overview

Monitoring and Tuning Tools: Overview
Since Oracle Database 10g, Release 2, you can generate SQL reports from AWR data
($ORACLE_HOME/rdbms/admin/awrsqrpt.sql), basically, the equivalent to
sqrepsql.sql in Statspack.
Note
• SPA stands for SQL Performance Analyzer.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 11
EM Performance Pages for Reactive Tuning

EM Performance Pages for Reactive Tuning
There are cases where real-time problem diagnosis must be performed. An irate user calls
you, or you see a sudden spike in the activity of the system on the monitor. The Enterprise
Manager (EM) Performance pages use the same data sources as AWR and ADDM to display
information about the running of the database and the host system in a manner that is easily
absorbed and allows for rapid manual drilldown to the source of the problem.
EM Performance Pages for Reactive Tuning
Home
Performance
Top
Activity
Top
Consu-
mers
Duplicate
SQL
Blocking
Sessions
Hang
Analysis
Instance
Locks
Instance
Activity
AWR
Baselines
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 12
Tuning Tools: Overview

Tuning Tools: Overview
Automatic Database Diagnostic Monitor: Continually analyzes the performance data that is
collected from the database instance
SQL Tuning Advisor: Analyzes SQL statements that have been identified as problematic, in
an effort to retune them. By default, this is an automated task. You can also, at any time, run
the SQL Tuning Advisor on a specific SQL workload to look for ways to improve performance.
SQL Tuning Sets: Serve as a repository for sets of SQL statements. For example, the SQL
Tuning Advisor can run against a workload that is represented by a SQL Tuning Set. They can
even be transported from database to database, to perform analysis on different machines.
SQL Access Advisor: Analyzes a SQL statement, and provides advice on materialized
views, indexes, materialized view logs, and partitions
SQL Performance Analyzer: Automates the process of assessing the overall effect of a
change, such as upgrading a database or adding new indexes, on the full SQL workload by
identifying performance divergence for each statement
SQL Monitoring: Enables you to monitor the performance of SQL statements while they
execute
SQL Plan Management (SPM): Can be used to control execution plan evolution. By creating
a SQL baseline, SPM will allow only approved execution plans to be used. Other plans
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 13
discovered by the optimizer will be stored in the SQL plan history, but will not be used until
they are approved.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 14
SQL Tuning Tasks: Overview

SQL Tuning Tasks: Overview
Many SQL tuning tasks should be performed on a regular basis. You may see a way to rewrite
a WHERE clause, but it may depend on a new index being built. This list of tasks gives you a
background of some important tasks that must be performed, and gives you an idea of what
dependencies you may have as you tune SQL:
• Identifying high-load SQL statements is one of the most important tasks you should
perform. The ADDM is the ideal tool for this particular task.
• By default, the Oracle Database gathers optimizer statistics automatically. For this, a job
is scheduled to run in the maintenance windows.
• Operating system statistics provide information about the usage and performance of the
main hardware components as well as the performance of the operating system itself.
• Often, there is a beneficial impact on performance by rebuilding indexes. For example,
removing nonselective indexes to speed the data manipulation language (DML), or
adding columns to the index to improve selectivity.
• You can maintain the existing execution plan of SQL statements over time by using
stored statistics or SQL plan baselines.
SQL Tuning Tasks: Overview
• Identifying high-load SQL
• Gathering statistics
• Generating system statistics
• Rebuilding existing indexes
• Maintaining execution plans
• Creating new index strategies
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 15
CPU and Wait Time Tuning Dimensions

CPU and Wait Time Tuning Dimensions
When you tune your system, it is important that you compare the CPU time with the wait time
of your system. By comparing CPU time with wait time, you can determine how much of the
response time is spent on useful work and how much on waiting for resources potentially held
by other processes.
As a general rule, the systems where CPU time is dominant usually need less tuning than the
ones where wait time is dominant. On the other hand, high CPU usage can be caused by
badly-written SQL statements.
Although the proportion of CPU time to wait time always tends to decrease as load on the
system increases, steep increases in wait time are a sign of contention and must be
addressed for good scalability.
Adding more CPUs to a node, or nodes to a cluster, would provide very limited benefit under
contention. Conversely, a system where the proportion of CPU time does not decrease
significantly as load increases can scale better, and would most likely benefit from adding
CPUs or Real Application Clusters (RAC) instances if needed.
Note: AWR reports display CPU time together with wait time in the Top 5 Timed Events
section, if the CPU time portion is among the top five events.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 16
Scalability with Application Design, Implementation, and
Configuration

Scalability with Application Design, Implementation, and Configuration
Poor application design, implementation, and configuration have a significant impact on
scalability. This results in:
• Poor SQL and index design, resulting in a higher number of logical input/output (I/O) for
the same number of rows returned
• Reduced availability because database objects take longer to maintain
However, design is not the only problem. The physical implementation of the application can
be the weak link, as in the following examples:
• Systems can move to production environments with poorly written SQL that cause high
I/O.
• Infrequent transaction COMMITs or ROLLBACKs can cause long locks on resources.
• The production environment can use different execution plans than those generated in
testing.
• Memory-intensive applications that allocate a large amount of memory without much
thought for freeing the memory can cause excessive memory fragmentation.
• Inefficient memory usage places high stress on the operating virtual memory subsystem.
This affects performance and availability.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 17
Common Mistakes on Customer Systems

Common Mistakes on Customer Systems
1. Bad connection management: The application connects and disconnects for each
database interaction. This problem is common with stateless middleware in application
servers. It has over two orders of magnitude impact on performance, and is not scalable.
2. Bad use of cursors and the shared pool: Not using cursors results in repeated
parses. If bind variables are not used, there may be hard parsing of all similar SQL
statements. This has an order of magnitude impact on performance, and it is not
scalable. Use cursors with bind variables that open the cursor and execute it many
times. Be suspicious of applications generating dynamic SQL.
3. Bad SQL: Bad SQL is SQL that uses more resources than appropriate for the
application. This can be a decision support system (DSS) query that runs for more than
24 hours or a query from an online application that takes more than a minute. SQL that
consumes significant system resources should be investigated for potential
improvement. ADDM identifies high-load SQL and the SQL Tuning Advisor can be used
to provide recommendations for improvement.
4. Use of nonstandard initialization parameters: These might have been implemented
based on poor advice or incorrect assumptions. Most systems give acceptable
performance using only the set of basic parameters. In particular, undocumented
optimizer features can cause a great deal of problems that may require considerable
investigation. Likewise, optimizer parameters set in the initialization parameter file can
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 recursive SQL statements related to
space management or parsing activity
10. Deployment and migration errors
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 18
override proven optimal execution plans. For these reasons, schemas, schema
statistics, and optimizer settings should be managed together as a group to ensure
consistency of performance.
5. Getting database I/O wrong: Many sites lay out their databases poorly over the
available disks. Other sites specify the number of disks incorrectly because they
configure disks by disk space and not by I/O bandwidth.
6. Redo log setup problems: Many sites run with too small redo log files. Small redo logs
cause system checkpoints to continuously put a high load on the buffer cache and the
I/O system. If there are very few redo logs, the archive cannot keep up, and the
database waits for the archive process to catch up.
7. Excessive serialization: Serialization of data blocks in the buffer cache due to shortage
of undo segments is particularly common in applications with large numbers of active
users and a few undo segments. Use Automatic Segment Space Management (ASSM)
and automatic undo management to solve this problem.
8. Long full table scans: Long full table scans for high-volume or interactive online
operations could indicate poor transaction design, missing indexes, or poor SQL
optimization. Long table scans, by nature, are I/O-intensive and not scalable.
9. High amounts of recursive (SYS) SQL: Large amounts of recursive SQL executed by
SYS could indicate that space management activities, such as extent allocations, take
place. This is not scalable and impacts user response time. Use locally managed
tablespaces to reduce recursive SQL due to extent allocation. Recursive SQL executed
under another user ID is probably SQL and PL/SQL, so this is not a problem.
10. Deployment and migration errors: In many cases, an application uses too many
resources because the schema owning the tables has not been successfully migrated
from the development environment or from an older implementation. Examples of this
are missing indexes or incorrect statistics. These errors can lead to suboptimal
execution plans and poor interactive user performance. When migrating applications of
known performance, export the schema statistics to maintain plan stability using the
DBMS_STATS package.
Although these errors are not directly detected by ADDM, ADDM highlights the resulting high-
load SQL.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 19
Proactive Tuning Methodology

Proactive Tuning Methodology
Tuning usually implies fixing a performance problem. However, tuning should be part of the
life cycle of an application, through the analysis, design, coding, production, and maintenance
stages. The tuning phase is often left until the system is in production. At that time, tuning
becomes a reactive exercise, where the most important bottleneck is identified and fixed.
The slide lists some of the issues that affect performance and that should be tuned proactively
instead of reactively. These are discussed in more detail in the following slides.
Proactive Tuning Methodology
• Simple design
• Data modeling
• Tables and indexes
• Using views
• Writing efficient SQL
• Cursor sharing
• Using bind variables
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 20
Simplicity in Application Design

Simplicity in Application Design
Applications are no different from any other designed and engineered product. If the design
looks right, it probably is right. This principle should always be kept in mind when building
applications. Consider some of the following design issues:
• If the table design is so complicated that nobody can fully understand it, the table is
probably designed badly.
• If SQL statements are so long and involved that it would be impossible for any optimizer
to effectively optimize it in real time, there is probably a bad statement, underlying
transaction, or table design.
• If there are many indexes on a table and the same columns are repeatedly indexed,
there is probably a bad index design.
• If queries are submitted without suitable qualification (the WHERE clause) for rapid
response for online users, there is probably a bad user interface or transaction design.
Simplicity in Application Design
• Simple tables
• Well-written SQL
• Indexing only as required
• Retrieving only required information
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 21
Data Modeling

Data Modeling
Data modeling is important in successful relational application design. This should be done in
a way that quickly and accurately represents the business practices. Apply your greatest
modeling efforts to those entities affected by the most frequent business transactions. Use of
modeling tools can then rapidly generate schema definitions and can be useful when a fast
prototype is required.
Normalizing data prevents duplication. When data is normalized, you have a clear picture of
the keys and relationships. It is then easier to perform the next step of creating tables,
constraints, and indexes. A good data model ultimately means that your queries are written
more efficiently.
Data Modeling
• Accurately represent business practices
• Focus on the most frequent and important business
transactions
• Use modeling tools
• Appropriately normalize data (OLTP versus DW)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 22
Table Design

Table Design
Table design is largely a compromise between flexibility and performance of core
transactions. To keep the database flexible and able to accommodate unforeseen workloads,
the table design should be very similar to the data model, and it should be normalized to at
least third normal form. However, certain core transactions can require selective
denormalization for performance purposes.
Use the features supplied with Oracle Database to simplify table design for performance, such
as storing tables prejoined in clusters, adding derived columns and aggregate values, and
using materialized views or partitioned tables. Additionally, create check constraints and
columns with default values to prevent bad data from getting into the tables.
Design should be focused on business-critical tables so that good performance can be
achieved in areas that are the most used. For noncritical tables, shortcuts in design can be
adopted to enable a more rapid application development. If, however, a noncore table
becomes a performance problem during prototyping and testing, remedial design efforts
should be applied immediately.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 23
Index Design

Index Design
Index design is also a largely iterative process based on the SQL that is generated by
application designers. However, it is possible to make a sensible start by building indexes that
enforce foreign key constraints (to reduce response time on joins between primary key tables
and foreign key tables) and creating indexes on frequently accessed data, such as a person’s
name. Primary keys and unique keys are automatically indexed except for the DISABLE
VALIDATE and DISABLE NOVALIDATE RELY constraints. As the application evolves and
testing is performed on realistic sizes of data, certain queries need performance
improvements, for which building a better index is a good solution.
The following indexing design ideas should be considered when building a new index.
Appending Columns to an Index or Using Index-Organized Tables
One of the easiest ways to speed up a query is to reduce the number of logical I/Os by
eliminating a table scan from the execution plan. This can be done by creating an index over
all the columns of the table referenced by the query. These columns are the select list
columns, WHERE clause columns, and any required join or sort columns. This technique is
particularly useful in speeding up an online application’s response times when time-
consuming I/Os are reduced. This is best applied when testing the application with
properly-sized data for the first time. The most aggressive form of this technique is to build an
index-organized table (IOT).
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 24
Using Views

Using Views
Views can speed up and simplify application design. A simple view definition can mask data
model complexity from the programmers whose priorities are to retrieve, display, collect, and
store data. Views are often used to provide simple row and column-level access restrictions.
However, though views provide clean programming interfaces, they can cause suboptimal,
resource-intensive queries when nested too deeply. The worst type of view use is creating
joins on views that reference other views, which in turn reference other views. In many cases,
developers can satisfy the query directly from the table without using a view. Because of their
inherent properties, views usually make it difficult for the optimizer to generate the optimal
execution plan.
Using Views
• Simplifies application design
• Is transparent to the developer
• Can cause suboptimal execution plans
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 25
SQL Execution Efficiency

SQL Execution Efficiency
An application that is designed for SQL execution efficiency must support the following
characteristics:
Good database connection management: Connecting to the database is an expensive
operation that is not scalable. Therefore, the number of concurrent connections to the
database should be minimized as much as possible. A simple system, where a user connects
at application initialization, is ideal. However, in a Web-based or multitiered application, where
application servers are used to multiplex database connections to users, this can be difficult.
With these types of applications, design efforts should ensure that database connections are
pooled and not reestablished for each user request.
Good cursor usage and management: Maintaining user connections is equally important for
minimizing the parsing activity on the system. Parsing is the process of interpreting a SQL
statement and creating an execution plan for it. This process has many phases, including
syntax checking, security checking, execution plan generation, and loading shared structures
into the shared pool.
There are two types of parse operations:
• Hard parsing: A SQL statement is submitted for the first time, and no match is found in
the shared pool. Hard parses are the most resource-intensive and are not scalable
because they perform all the operations involved in a parse.
SQL Execution Efficiency
• Good database connectivity
• Minimizing parsing
• Share cursors
• Using bind variables
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 26
• Soft parsing: A SQL statement is submitted for the first time, and a match is found in
the shared pool. The match can be the result of previous execution by another user. The
SQL statement is shared, which is good for performance. However, soft parses are not
ideal because they still require syntax and security checking, which consume system
resources.
Because parsing should be minimized as much as possible, application developers should
design their applications to parse SQL statements once and execute them many times. This is
done through cursors. Experienced SQL programmers should be familiar with the concept of
opening and reexecuting cursors.
Application developers must also ensure that SQL statements are shared within the shared
pool. To do this, bind variables to represent the parts of the query that change from execution
to execution. If this is not done, the SQL statement is likely to be parsed once and never
reused by other users. To ensure that SQL is shared, use bind variables and do not use string
literals with SQL statements.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 27
Writing SQL to Share Cursors

Writing SQL to Share Cursors
Applications can share cursors when the code is written in the same way characterwise
(which allows the system to recognize that two statements are the same and thus can be
shared), even if you use some special initialization parameters, such as CURSOR_SHARING
discussed later in the lesson titled “Using Bind Variables.” You should develop coding
conventions for SQL statements in ad hoc queries, SQL scripts, and Oracle Call Interface
(OCI) calls.
Use generic shared code:
• Write and store procedures that can be shared across applications.
• Use database triggers.
• Write referenced triggers and procedures when using application development tools.
• Write library routines and procedures in other environments.
Write to format standards:
• Develop format standards for all statements, including those in PL/SQL code.
• Develop rules for the use of uppercase and lowercase characters.
• Develop rules for the use of white space (spaces, tabs, returns).
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 28
• Develop rules for the use of comments (preferably keeping them out of the SQL
statements themselves).
• Use the same names to refer to identical database objects. If possible, prefix each object
with a schema name.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 29
Performance Checklist

Performance Checklist
• Set the minimal number of initialization parameters. Ideally, most initialization
parameters should be left at default. If there is more tuning to perform, this shows up
when the system is under load. Set storage options for tables and indexes in appropriate
tablespaces.
• Verify that all SQL statements are optimal and understand their resource usage.
• Validate that middleware and programs that connect to the database are efficient in their
connection management and do not log on and log off repeatedly.
• Validate that the SQL statements use cursors efficiently. Each SQL statement should be
parsed once and then executed multiple times. This happens mostly when bind variables
are not used properly and the WHERE clause predicates are sent as string literals.
• Validate that all schema objects are correctly migrated from the development
environment to the production database. This includes tables, indexes, sequences,
triggers, packages, procedures, functions, Java objects, synonyms, grants, and views.
Ensure that any modifications made in testing are made to the production system.
• As soon as the system is rolled out, establish a baseline set of statistics from the
database and operating system. This first set of statistics validates or corrects any
assumptions made in the design and rollout process.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 30
Development Environments: Overview

PL/SQL Development Environments
SQL Developer
This course has been developed using Oracle SQL Developer as the tool for running the SQL
statements discussed in the examples in the slide and the practices.
• SQL Developer is shipped with Oracle Database 11g Release 2, and is the default tool
for this class.
SQL*Plus
The SQL*Plus environment may also be used to run all SQL commands covered in this
course.
Note: See Appendix C titled “Using SQL Developer” for information about using SQL
Developer, including simple instructions on installing version 2.1.
Development Environments: Overview
• SQL Developer
• SQL*Plus
SQL Developer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 31
What Is Oracle SQL Developer?

What Is Oracle SQL Developer?
Oracle SQL Developer is a free graphical tool designed to improve your productivity and
simplify the development of everyday database tasks. With just a few clicks, you can easily
create and maintain stored procedures, test SQL statements, and view optimizer plans.
SQL Developer, the visual tool for database development, simplifies the following tasks:
• Browsing and managing database objects
• Executing SQL statements and scripts
• Editing and debugging PL/SQL statements
• Creating reports
You can connect to any target Oracle database schema using standard Oracle database
authentication. When connected, you can perform operations on objects in the database.
Appendix C
Appendix C of this course provides an introduction on using the SQL Developer interface. It
also provides information about creating a database connection, interacting with data using
SQL and PL/SQL, and so on.
What Is Oracle SQL Developer?
• Oracle SQL Developer is a free graphical tool that
enhances productivity and simplifies database
development tasks.
• You can connect to any target Oracle database schema
using standard Oracle database authentication.
• You will use SQL Developer in this course.
• Appendix C contains details on using SQL Developer
SQL Developer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 32
Coding PL/SQL in SQL*Plus

Coding PL/SQL in SQL*Plus
Oracle SQL*Plus is a command-line interface that enables you to submit SQL statements and
PL/SQL blocks for execution and receive the results in an application or a command window.
SQL*Plus is:
• Shipped with the database
• Accessed from an icon or the command line
When coding PL/SQL subprograms using SQL*Plus, remember the following:
• You create subprograms by using the CREATE SQL statement.
• You execute subprograms by using either an anonymous PL/SQL block or the EXECUTE
command.
• If you use the DBMS_OUTPUT package procedures to print text to the screen, you must
first execute the SET SERVEROUTPUT ON command in your session.
Note
• To launch SQL*Plus in the Linux environment, open a Terminal window and enter the
sqlplus command.
Coding PL/SQL in SQL*Plus
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 33
• For more information about how to use SQL*Plus, see the SQL*Plus User's Guide and
Reference.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 34
Quiz

Answer: c
Quiz
_________automatically identifies bottlenecks within Oracle
Database and makes recommendations on the options
available for fixing these bottlenecks.
a. ASH
b. AWR
c. ADDM
d. Snapshots
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 35
Quiz

Answer: a
Quiz
Normalizing data results in a good data model, which ultimately
means that your queries are written more efficiently.
a. True
b. False
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 36
Quiz

Answer: a
Quiz
Views should be used carefully because, though they provide
clean programming interfaces, they can cause suboptimal,
resource-intensive queries when nested too deeply.
a. True
b. False
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 37
Quiz

Answer: b, c
Quiz
Identify the characteristics that must be supported by an
application designed for SQL execution efficiency.
a. Use concurrent connections to the database.
b. Use cursors so that SQL statements are parsed once and
executed multiple times.
c. Use bind variables.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 38
Summary

Summary
In this lesson, you should have learned how to:
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 39
Practice 2: Overview


Practice 2: Overview
This practice covers the following topics:
• Rewriting queries for better performance
• Rewriting applications for better performance
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
Chapter 2 - Page 40

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 1
Introduction to the Optimizer
Chapter 3

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 2
Introduction to the Optimizer

Introduction to the Optimizer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 3
Objectives

Objectives
After completing this lesson, you should be able to:
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 4
Structured Query Language

Structured Query Language
All programs and users access data in an Oracle Database with the language SQL Oracle
tools and Application programs often allow users to access the database without using SQL
directly, but then these applications must use SQL when executing user requests. Oracle
Corp strives to comply with industry-accepted standards and participates in SQL standards
committees (ANSI and ISO). You can categorize SQL statements into six main sets:
• Data manipulation language (DML) statements manipulate or query data in existing
schema objects.
• Data definition language (DDL) statements define, alter the structure of, and drop
schema objects.
• Transaction control statements (TCS) manage the changes made by DML statements
and group DML statements into transactions.
• System Control statements change the properties of the Oracle Database instance.
• Session Control statements manage the properties of a particular user’s session.
• Embedded SQL statements incorporate DDL, DML, and TCS within a procedural
language program, such as PL/SQL and Oracle precompilers. This incorporation is done
using the statements listed in the slide under the ESS category.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 5
Note: SELECT statements are the most used statements. While his course focuses mainly on
queries, it is important to note that any type of SQL statement is subject to optimization.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 6
SQL Statement Representation

SQL Statement Representation
Oracle Database represents each SQL statement it runs with a shared SQL area and a
private SQL area. Oracle Database recognizes when two users execute the same SQL
statement and reuses the shared SQL area for those users. However, each user must have a
separate copy of the statement’s private SQL area.
A shared SQL area contains all optimization information necessary to execute the statement
whereas a private SQL area contains all run-time information related to a particular execution
of the statement.
Oracle Database saves memory by using one shared SQL area for SQL statements run
multiple times, which often happens when many users run the same application.
Note: In evaluating whether statements are similar or identical, Oracle Database considers
SQL statements issued directly by users and applications, as well as recursive SQL
statements issued internally by a DDL statement.
SQL Statement Representation
Private
SQL area
Private
SQL area
Private
SQL area
Shared
SQL area
Private
SQL area
Private
SQL area
Shared
SQL area
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 7
SQL Statement Implementation

SQL Statement Implementation
Oracle Database creates and uses memory structures for various purposes. For example,
memory stores program codes that are run, data that is shared among users, and private data
areas for each connected user.
Oracle Database allocates memory from the shared pool when a new SQL statement is
parsed, to store in the shared SQL area. The size of this memory depends on the complexity
of the statement. If the entire shared pool has already been allocated, Oracle Database can
deallocate items from the pool using a modified least recently used (LRU) algorithm until there
is enough free space for the new statement’s shared SQL area. If Oracle Database
deallocates a shared SQL area, the associated SQL statement must be reparsed and
reassigned to another shared SQL area at its next execution.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 8
SQL Statement Processing: Overview

SQL Statement Processing: Overview
The graphic in the slide shows all the steps involved in query execution and these steps can
be found in Oracle® Database Concepts 11g Release 1 (11.1).
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?
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 9
SQL Statement Processing: Steps

SQL Statement Processing: Steps
Note that not all statements require all these steps. For example, nonparallel DDL statements
are required in only two steps: Create and Parse.
Parallelizing the statement involves deciding that it can be parallelized as opposed to actually
building parallel execution structures.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 10
Step 1: Create a Cursor

Step 1: Create a Cursor
A cursor can be thought of as an association between a cursor data area in a client program
and Oracle server’s data structures. Most Oracle tools hide much of cursor handling from the
user, but Oracle Call Interface (OCI) programs need the flexibility to be able to process each
part of query execution separately. Therefore, precompilers allow explicit cursor declaration.
Most of this can also be done using the DBMS_SQL package as well.
A handle is similar to the handle on a mug. When you have a hold of the handle, you have a
hold of the cursor. It is a unique identifier for a particular cursor that can only be obtained by
one process at a time.
Programs must have an open cursor to process a SQL statement. The cursor contains a
pointer to the current row. The pointer moves as rows are fetched until there are no more rows
left to process.
The following slides use the DBMS_SQL package to illustrate cursor management. This may be
confusing to people unfamiliar with it; however, it is more friendly than PRO*C or OCI. It is
slightly problematic in that it performs FETCH and EXECUTE together, so the execute phase
cannot be separately identified in the trace.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 11
Step 2: Parse the Statement

Step 2: Parse the Statement
During parsing, the SQL statement is passed from the user process to the Oracle instance,
and a parsed representation of the SQL statement is loaded into a shared SQL area.
Translation and verification involve checking if the statement already exists in the library
cache.
For distributed statements, check for the existence of database links.
Typically, the parse phase is represented as the stage where the query plan is generated.
The parse step can be deferred by the client software to reduce network traffic. What this
means is that the PARSE is bundled with the EXECUTE, so there are fewer round-trips to the
server.
Note: When checking if statements are identical, they must be identical in every way including
case and spacing.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 12
Steps 3 and 4: Describe and Define

Steps 3 and 4: Describe and Define
Step 3: Describe
The describe stage is necessary only if the characteristics of a query’s result are not known,
for example, when a query is entered interactively by a user. In this case, the describe stage
determines the characteristics (data types, lengths, and names) of a query’s result. Describe
tells the application what select list items are required. If, for example, you enter a query such
as:
SQL> select * from employees;,
information about the columns in the employees table is required.
Step 4: Define
In the define stage, you specify the location, size, and data type of variables defined to receive
each fetched value. These variables are called define variables. Oracle Database performs
data type conversion, if necessary.
These two steps are generally hidden from users in tools such as SQL*Plus. However, with
DBMS_SQL or OCI, it is necessary to tell the client what the output data is and which the setup
areas are.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 13
Steps 5 and 6: Bind and Parallelize

Steps 5 and 6: Bind and Parallelize
Step 5: Bind
At this point, Oracle Database knows the meaning of the SQL statement, but still does not
have enough information to run the statement. Oracle Database needs values for any
variables listed in the statement. The process of obtaining these values is called binding
variables.
Step 6: Parallelize
Oracle Database can parallelize the execution of SQL statements (such as SELECT, INSERT,
UPDATE, MERGE, DELETE), and some DDL operations, such as index creation, creating a table
with a subquery, and operations on partitions. Parallelization causes multiple server
processes to perform the work of the SQL statement, so it can complete faster.
Parallelization involves dividing the work of a statement among a number of slave processes.
Parsing has already identified if a statement can be parallelized or not and has built the
appropriate parallel plan. At execution time, this plan is then implemented if sufficient resource
is available.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 14
Steps 7 Through 9

Steps 7 Through 9
At this point, Oracle Database has all the necessary information and resources, so the
statement is run. If the statement is a query (without the FOR UPDATE clause) statement, no
rows need to be locked because no data is changed. If the statement is an UPDATE or a
DELETE statement, however, all rows that the statement affects are locked until the next
COMMIT, ROLLBACK, or SAVEPOINT for the transaction. This ensures data integrity.
For some statements, you can specify a number of executions to be performed. This is called
array processing. Given n number of executions, the bind and define locations are assumed to
be the beginning of an array of size n.
In the fetch stage, rows are selected and ordered (if requested by the query), and each
successive fetch retrieves another row of the result until the last row has been fetched.
The final stage of processing a SQL statement is closing the cursor.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 15
SQL Statement Processing PL/SQL: Example

SQL Statement Processing PL/SQL: Example
This example summarizes the various steps discussed previously.
Note: In this example, you do not show the fetch operation. It is also possible to combine both
the EXECUTE and FETCH operations in EXECUTE_AND_FETCH to perform EXECUTE and
FETCH together in one call. This may reduce the number of network round-trips when used
against a remote database.
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 16
SQL Statement Parsing: Overview

SQL Statement Parsing: Overview
Parsing is one stage in the processing of a SQL statement. When an application issues a SQL
statement, the application makes a parse call to Oracle Database. During the parse call,
Oracle Database performs the following actions:
• Checks the statement for syntactic and semantic validity
• Determines whether the process issuing the statement has the privileges to run it
• Allocates a private SQL area for the statement
• Determines whether or not there is an existing shared SQL area containing the parsed
representation of the statement in the library cache. If so, the user process uses this
parsed representation and runs the statement immediately. If not, Oracle Database
generates the parsed representation of the statement, and the user process allocates a
shared SQL area for the statement in the library cache and stores its parsed
representation there.
Note the difference between an application making a parse call for a SQL statement and
Oracle Database actually parsing the statement.
• A parse call by the application associates a SQL statement with a private SQL area.
After a statement has been associated with a private SQL area, it can be run repeatedly
without your application making a parse call.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 17
• A parse operation by Oracle Database allocates a shared SQL area for a SQL
statement. After a shared SQL area has been allocated for a statement, it can be run
repeatedly without being reparsed.
Both parse calls and parsing can be expensive relative to execution, so perform them as
rarely as possible.
Note: Although parsing a SQL statement validates that statement, parsing only identifies
errors that can be found before statement execution. Thus, some errors cannot be caught by
parsing. For example, errors in data conversion or errors in data (such as an attempt to enter
duplicate values in a primary key) and deadlocks are all errors or situations that can be
encountered and reported only during the execution stage.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 18
Why Do You Need an Optimizer?

Why Do You Need an Optimizer?
The optimizer should always return the correct result as quickly as possible.
The query optimizer tries to determine which execution plan is most efficient by considering
available access paths and by factoring in information based on statistics for the schema
objects (tables or indexes) accessed by the SQL statement.
The query optimizer performs the following steps:
1. The optimizer generates a set of potential plans for the SQL statement based on
available access paths.
2. The optimizer estimates the cost of each plan based on statistics in the data dictionary
for the data distribution and storage characteristics of the tables, and indexes accessed
by the statement.
3. The optimizer compares the costs of the plans and selects the one with the lowest cost.
Note: Because of the complexity of finding the best possible execution plan for a particular
query, the optimizer’s goal is to find a “good” plan that is generally called the best cost plan.
Why Do You Need an Optimizer?
SELECT * FROM emp WHERE job = 'MANAGER';
How to 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!
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 19
Why Do You Need an Optimizer?

Why Do You Need an Optimizer? (continued)
The example in the slide shows you that if statistics change, the optimizer adapts its execution
plan. In this case, statistics show that 80 percent of the employees are managers. In the
hypothetical case, a full table scan is probably a better solution than using the index.
Why Do You Need an Optimizer?
SELECT * FROM emp WHERE job = 'MANAGER';
How to 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
Generate a plan
1
2
3
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 20
Optimization During Hard Parse Operation

Optimization During Hard Parse Operation
The optimizer creates the execution plan for a SQL statement.
SQL queries submitted to the system first run through the parser, which checks syntax and
analyzes semantics. The result of this phase is called a parsed representation of the
statement, and is constituted by a set of query blocks. A query block is a self-contained DML
against a table. A query block can be a top-level DML or a subquery. This parsed
representation is then sent to the optimizer, which handles three main functionalities:
Transformation, estimation, and execution plan generation.
Before performing any cost calculation, the system may transform your statement into an
equivalent
statement and calculate the cost of the equivalent statement. Depending on the version of
Oracle Database, there are transformations that cannot be done, some that are always done,
and some that are done, costed, and discarded.
The input to the query transformer is a parsed query, which is represented by a set of
interrelated query blocks. The main objective of the query transformer is to determine if it is
advantageous to change the structure of the query so that it enables generation of a better
query plan. Several query transformation techniques are employed by the query transformer,
such as transitivity, view merging, predicate pushing, subquery unnesting, query rewrite, star
transformation, and OR expansion.
Optimization During Hard Parse Operation
Statistics
Transformer
Dictionary
Optimizer
Estimator
Plan Generator C
B
O
Execution Plan
Parsed representation
(query blocks)
Shared
SQL area
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 21
Transformer: OR Expansion Example

Transformer: OR Expansion Example
If a query contains a WHERE clause with multiple conditions combined with OR operators, the
optimizer transforms it into an equivalent compound query that uses the UNION ALL set
operator, if this makes the query execute more efficiently.
For example, if each condition individually makes an index access path available, the
optimizer can make the transformation. The optimizer selects an execution plan for the
resulting statement that accesses the table multiple times using the different indexes and then
puts the results together. This transformation is done if the cost estimation is better than the
cost of the original statement.
In the example in the slide, it is assumed that there are indexes on both the JOB and DEPTNO
columns. Then, the optimizer might transform the original query into the equivalent
transformed query shown in the slide. When the cost-based optimizer (CBO) decides whether
to make a transformation, the optimizer compares the cost of executing the original query
using a full table scan with that of executing the resulting query.
Transformer: OR Expansion Example
• Original query:
• Equivalent transformed 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';
B*-tree Index
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 22
Transformer: Subquery Unnesting Example

Transformer: Subquery Unnesting Example
To unnest a query, the optimizer may choose to transform the original query into an equivalent
JOIN statement, and then optimize the JOIN statement.
The optimizer may do this transformation only if the resulting JOIN statement is guaranteed to
return exactly the same rows as the original statement. This transformation allows the
optimizer to take advantage of the join optimizer techniques.
In the example in the slide, if the CUSTNO column of the customers table is a primary key or
has a UNIQUE constraint, the optimizer can transform the complex query into the shown JOIN
statement that is guaranteed to return the same data.
If the optimizer cannot transform a complex statement into a JOIN statement, it selects
execution plans for the parent statement and the subquery as though they were separate
statements. The optimizer then executes the subquery and uses the rows returned to execute
the parent query.
Note: Complex queries whose subqueries contain aggregate functions such as AVG cannot be
transformed into JOIN statements.
Transformer: Subquery Unnesting Example
• Original query:
• Equivalent transformed query:
SELECT *
FROM accounts
WHERE custno IN
(SELECT custno FROM customers);
SELECT accounts.*
FROM accounts, customers
WHERE accounts.custno = customers.custno;
Primary or unique key
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 23
Transformer: View Merging Example

Transformer: View Merging Example
To merge the view’s query into a referencing query block in the accessing statement, the
optimizer replaces the name of the view with the names of its base tables in the query block
and adds the condition of the view’s query’s WHERE clause to the accessing query block’s
WHERE clause.
This optimization applies to select-project-join views, which contain only selections,
projections, and joins. That is, views that do not contain set operators, aggregate functions,
DISTINCT, GROUP BY, CONNECT BY, and so on.
The view in this example is of all employees who work in department 10.
The query that follows the view’s definition in the slide accesses the view. The query selects
the IDs greater than 7800 of employees who work in department 10.
The optimizer may transform the query into the equivalent transformed query shown in the
slide that accesses the view’s base table.
If there are indexes on the DEPTNO or EMPNO columns, the resulting WHERE clause makes
them available.
Transformer: View Merging Example
• Original query:
• Equivalent transformed query:
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;
Index
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 24
Transformer: Predicate Pushing Example

Transformer: Predicate Pushing Example
The optimizer can transform a query block that accesses a nonmergeable view by pushing the
query block’s predicates inside the view’s query.
In the example in the slide, the two_emp_tables view is the union of two employee tables.
The view is defined with a compound query that uses the UNION set operator.
The query that follows the view’s definition in the slide accesses the view. The query selects
the IDs and names of all employees in either table who work in department 20.
Because the view is defined as a compound query, the optimizer cannot merge the view’s
query into the accessing query block. Instead, the optimizer can transform the accessing
statement by pushing its predicate, the WHERE clause condition deptno = 20, into the view’s
compound query. The equivalent transformed query is shown in the slide.
If there is an index in the DEPTNO column of both tables, the resulting WHERE clauses make
them available.
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:
• Equivalent transformed query:
Index
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 25
Transformer: Transitivity Example

Transformer: Transitivity Example
If two conditions in the WHERE clause involve a common column, the optimizer sometimes can
infer a third condition, using the transitivity principle. The optimizer can then use the inferred
condition to optimize the statement.
The inferred condition can make available an index access path that was not made available
by the original conditions.
This is demonstrated with the example in the slide. The WHERE clause of the original query
contains two conditions, each of which uses the EMP.DEPTNO column. Using transitivity, the
optimizer infers the following condition: dept.deptno = 20
If an index exists in the DEPT.DEPTNO column, this condition makes access paths available
using that index.
Note: The optimizer only infers conditions that relate columns to constant expressions, rather
than columns to other columns.
Transformer: Transitivity Example
• Original query:
• Equivalent transformed 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 26
Cost-Based Optimizer

Cost-Based Optimizer
The combination of the estimator and plan generator code is commonly called the cost-based
optimizer (CBO).
The estimator generates three types of measures: selectivity, cardinality, and cost. These
measures are related to each other. Cardinality is derived from selectivity and often the cost
depends on cardinality. The end goal of the estimator is to estimate the overall cost of a given
plan. If statistics are available, the estimator uses these to improve the degree of accuracy
when computing the measures.
The main function of the plan generator is to try out different possible plans for a given query
and pick the one that has the lowest cost. Many different plans are possible because of the
various combinations of different access paths, join methods, and join orders that can be used
to access and process data in different ways and produce the same result. The number of
possible plans for a query block is proportional to the number of join items in the FROM clause.
This number rises exponentially with the number of join items.
The optimizer uses various pieces of information to determine the best path: WHERE clause,
statistics, initialization parameters, supplied hints, and schema information.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 27
Estimator: Selectivity

Estimator: Selectivity
Selectivity represents a fraction of rows from a row set. The row set can be a base table, a
view, or the result of a join or a GROUP BY operator. The selectivity is tied to a query
predicate, such as last_name = 'Smith', or a combination of predicates, such as
last_name = 'Smith' AND job_type = 'Clerk'. A predicate acts as a filter that
filters a certain number of rows from a row set. Therefore, the selectivity of a predicate
indicates the percentage of rows from a row set that passes the predicate test. Selectivity lies
in a value range from 0.0 to 1.0. A selectivity of 0.0 means that no rows are selected from a
row set, and a selectivity of 1.0 means that all rows are selected.
If no statistics are available, the optimizer either uses dynamic sampling or an internal default
value, depending on the value of the OPTIMIZER_DYNAMIC_SAMPLING initialization
parameter. When statistics are available, the estimator uses them to estimate selectivity. For
example, for an equality predicate (last_name = 'Smith'), selectivity is set to the
reciprocal of the number n of distinct values of LAST_NAME because the query selects rows
that contain one out of n distinct values. Thus, even distribution is assumed. If a histogram is
available in the LAST_NAME column, the estimator uses it instead of the number of distinct
values. The histogram captures the distribution of different values in a column, so it yields
better selectivity estimates.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 28
Note: It is important to have histograms in columns that contain values with large variations in
the number of duplicates (data skew).
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 29
Estimator: Cardinality

Estimator: Cardinality
The cardinality of a particular operation in the execution plan of a query represents the
estimated number of rows retrieved by that particular operation. Most of the time, the row
source can be a base table, a view, or the result of a join or GROUP BY operator.
When costing a join operation, it is important to know the cardinality of the driving row source.
With nested loops join, for example, the driving row source defines how often the system
probes the inner row source.
Because sort costs are dependent on the size and number of rows to be sorted, cardinality
figures are also vital for sort costing.
In the example in the slide, based on assumed statistics, the optimizer knows that there are
203 different values in the DEV_NAME column, and that the total number of rows in the
COURSES table is 1018. Based on this assumption, the optimizer deduces that the selectivity
of the DEV_NAME='ANGEL' predicate is 1/203 (assuming there are no histograms), and also
deduces the cardinality of the query to be (1/203)*1018. This number is then rounded off to
the nearest integer, 6.
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';
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 30
Estimator: Cost

Estimator: Cost
The cost of a statement represents the optimizer’s best estimate of the number of
standardized inputs/outputs (I/Os) it takes to execute that statement. Basically, the cost is a
normalized value in terms of a number of single block random reads
The standard cost metric measured by the optimizer is in terms of number of single block
random reads, so one cost unit corresponds to one single block random read. The formula
shown in the slide combines three different cost units:
• Estimated time to do all the single-block random reads
• Estimated time to do all the multiblock reads
• Estimated time for the CPU to process the statement into one standard cost unit
The model includes CPU costing because in most cases CPU utilization is as important as
I/O; often it is the only contribution to the cost (in cases of in-memory sort, hash, predicate
evaluation, and cached I/O).
This model is straightforward for serial execution. For parallel execution, necessary
adjustments are made while computing estimates for #SRds, #MRds, and #CPUCycles.
Note: #CPUCycles includes CPU cost of query processing (pure CPU cost) and CPU cost of
data retrieval (CPU cost of the buffer cache get).
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 31
Plan Generator

Plan Generator
The plan generator explores various plans for a query block by trying out different access
paths, join methods, and join orders. Ultimately, the plan generator delivers the best execution
plan for your statement. The slide shows you an extract of an optimizer trace file generated for
the select statement. As you can see from the trace, the plan generator has six possibilities, or
six different plans to test: Two join orders, and for each, three different join methods. It is
assumed that there are no indexes in this example.
To retrieve the rows, you can start to join the DEPARTMENTS table to the EMPLOYEES table.
For that particular join order, you can use three possible join mechanisms that the optimizer
knows: Nested Loop, Sort Merge, or Hash Join. For each possibility, you have the cost of the
corresponding plan. The best plan is the one shown at the end of the trace.
The plan generator uses an internal cutoff to reduce the number of plans it tries when finding
the one with the lowest cost. The cutoff is based on the cost of the current best plan. If the
current best cost is large, the plan generator tries harder (in other words, explores more
alternate plans) to find a better plan with lower cost. If the current best cost is small, the plan
generator ends the search swiftly because further cost improvement is not significant. The
cutoff works well if the plan generator starts with an initial join order that produces a plan with
a cost close to optimal. Finding a good initial join order is a difficult problem.
Note: Access path, join methods, and plan are discussed in more detail in the lessons titled
“Optimizer Operators” and “Interpreting Execution Plans.”
Plan Generator
select e.last_name, d.department_name
from employees e, departments d
where e.department_id = d.department_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 |
+----------------------------------------------------------------+
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 32
Controlling the Behavior of the Optimizer

Controlling the Behavior of the Optimizer
These parameters control the optimizer behavior:
• CURSOR_SHARING determines what kind of SQL statements can share the same
cursors:
- FORCE: Forces statements that may differ in some literals, but are otherwise
identical, to share a cursor, unless the literals affect the meaning of the statement
- SIMILAR: Causes statements that may differ in some literals, but are otherwise
identical, to share a cursor, unless the literals affect either the meaning of the
statement or the degree to which the plan is optimized. Forcing cursor sharing
among similar (but not identical) statements can have unexpected results in some
decision support system (DSS) applications, or applications that use stored
outlines.
- EXACT: Only allows statements with identical text to share the same cursor. This is
the default.
• DB_FILE_MULTIBLOCK_READ_COUNT is one of the parameters you can use to
minimize I/O during table scans or index fast full scan. It specifies the maximum number
of blocks read in one I/O operation during a sequential scan. The total number of I/Os
needed to perform a full table scan or an index fast full scan depends on factors, such as
the size of the segment, the multiblock read count, and whether parallel execution is
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 33
being utilized for the operation. As of Oracle Database 10g, Release 2, the default value
of this parameter is a value that corresponds to the maximum I/O size that can be
performed efficiently. This value is platform-dependent and is calculated at instance
startup for most platforms.
Because the parameter is expressed in blocks, it automatically computes a value that is
equal to the maximum I/O size that can be performed efficiently divided by the standard
block size. Note that if the number of sessions is extremely large, the multiblock read
count value is decreased to avoid the buffer cache getting flooded with too many table
scan buffers. Even though the default value may be a large value, the optimizer does not
favor large plans if you do not set this parameter. It would do so only if you explicitly set
this parameter to a large value. Basically, if this parameter is not set explicitly (or is set is
0), the optimizer uses a default value of 8 when costing full table scans and index fast
full scans. Online transaction processing (OLTP) and batch environments typically have
values in the range of 4 to 16 for this parameter. DSS and data warehouse environments
tend to benefit most from maximizing the value of this parameter. The optimizer is more
likely to select a full table scan over an index, if the value of this parameter is high.
• PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all
server processes attached to the instance. Setting PGA_AGGREGATE_TARGET to a
nonzero value has the effect of automatically setting the WORKAREA_SIZE_POLICY
parameter to AUTO. This means that SQL working areas used by memory-intensive SQL
operators (such as sort, group-by, hash-join, bitmap merge, and bitmap create) are
automatically sized. A nonzero value for this parameter is the default because, unless
you specify otherwise, the system sets it to 20% of the SGA or 10 MB, whichever is
greater. Setting PGA_AGGREGATE_TARGET to 0 automatically sets the
WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL work areas are
sized using the *_AREA_SIZE parameters. The system attempts to keep the amount of
private memory below the target specified by this parameter by adapting the size of the
work areas to private memory. When increasing the value of this parameter, you
indirectly increase the memory allotted to work areas. Consequently, more memory-
intensive operations are able to run fully in memory and a less number of them work
their way over to disk. When setting this parameter, you should examine the total
memory on your system that is available to the Oracle instance and subtract the SGA.
You can assign the remaining memory to PGA_AGGREGATE_TARGET.
• STAR_TRANSFORMATION_ENABLED determines whether a cost-based query
transformation is applied to star queries. This optimization is explained in the lesson
titled “Case Study: Star Transformation.”
• The query optimizer manages the result cache mechanism depending on the settings of
the RESULT_CACHE_MODE parameter in the initialization parameter file. You can use this
parameter to determine whether or not the optimizer automatically sends the results of
queries to the result cache. The possible parameter values are MANUAL, and FORCE:
- When set to MANUAL (the default), you must specify, by using the RESULT_CACHE
hint, that a particular result is to be stored in the cache.
- When set to FORCE, all results are stored in the cache. For the FORCE setting, if the
statement contains a [NO_]RESULT_CACHE hint, the hint takes precedence over
the parameter setting.
• The memory size allocated to the result cache depends on the memory size of the SGA
as well as the memory management system. You can change the memory allocated to
the result cache by setting the RESULT_CACHE_MAX_SIZE parameter. The result cache
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 34
is disabled if you set its value to 0. The value of this parameter is rounded to the largest
multiple of 32 KB that is not greater than the specified value. If the rounded value is 0,
the feature is disabled.
• Use the RESULT_CACHE_MAX_RESULT parameter to specify the maximum amount of
cache memory that can be used by any single result. The default value is 5%, but you
can specify any percentage value between 1 and 100.
• Use the RESULT_CACHE_REMOTE_EXPIRATION parameter to specify the time (in
number of minutes) for which a result that depends on remote database objects remains
valid. The default value is 0, which implies that results using remote objects should not
be cached. Setting this parameter to a nonzero value can produce stale answers, for
example, if the remote table used by a result is modified at the remote database.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 35
Controlling the Behavior of the Optimizer

Controlling the Behavior of the Optimizer (continued)
• OPTIMIZER_INDEX_CACHING: This parameter controls the costing of an index probe in
conjunction with a nested loop or an inlist iterator. The range of values 0 to 100 for
OPTIMIZER_INDEX_CACHING indicates percentage of index blocks in the buffer cache,
which modifies the optimizer’s assumptions about index caching for nested loops and
inlist iterators. A value of 100 infers that 100% of the index blocks are likely to be found
in the buffer cache and the optimizer adjusts the cost of an index probe or nested loop
accordingly. The default for this parameter is 0, which results in default optimizer
behavior. Use caution when using this parameter because execution plans can change
in favor of index caching.
• OPTIMIZER_INDEX_COST_ADJ lets you tune optimizer behavior for access path
selection to be more or less index friendly, that is, to make the optimizer more or less
prone to selecting an index access path over a full table scan. The range of values is 1
to 10000. The default for this parameter is 100 percent, at which the optimizer evaluates
index access paths at the regular cost. Any other value makes the optimizer evaluate the
access path at that percentage of the regular cost. For example, a setting of 50 makes
the index access path look half as expensive as normal.
• OPTIMIZER_FEATURES_ENABLED acts as an umbrella parameter for enabling a series
of optimizer features based on an Oracle release number.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 36
For example, if you upgrade your database from release 10.1 to release 11.1, but you
want to keep the release 10.1 optimizer behavior, you can do so by setting this
parameter to 10.1.0. At a later time, you can try the enhancements introduced in
releases up to and including release 11.1 by setting the parameter to 11.1.0.6. However,
it is not recommended to explicitly set the OPTIMIZER_FEATURES_ENABLE parameter
to an earlier release. To avoid possible SQL performance regression that may result
from execution plan changes, consider using SQL plan management instead.
• OPTIMIZER_MODE establishes the default behavior for selecting an optimization
approach for either the instance or your session. The possible values are:
- ALL_ROWS: The optimizer uses a cost-based approach for all SQL statements in
the session regardless of the presence of statistics and optimizes with a goal of
best throughput (minimum resource use to complete the entire statement). This is
the default value.
- FIRST_ROWS_n: The optimizer uses a cost-based approach, regardless of the
presence of statistics, and optimizes with a goal of best response time to return the
first n number of rows; n can equal 1, 10, 100, or 1000.
- FIRST_ROWS: The optimizer uses a mix of cost and heuristics to find a best plan
for fast delivery of the first few rows. Using heuristics sometimes leads the query
optimizer to generate a plan with a cost that is significantly larger than the cost of a
plan without applying the heuristic. FIRST_ROWS is available for backward
compatibility and plan stability; use FIRST_ROWS_n instead.
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES enables or disables the automatic
recognition of repeatable SQL statements, as well as the generation of SQL plan
baselines for such statements.
• OPTIMIZER_USE_SQL_PLAN_BASELINES enables or disables the use of SQL plan
baselines stored in SQL Management Base. When enabled, the optimizer looks for a
SQL plan baseline for the SQL statement being compiled. If one is found in SQL
Management Base, the optimizer costs each of the baseline plans and picks one with
the lowest cost.
• OPTIMIZER_DYNAMIC_SAMPLING controls the level of dynamic sampling performed by
the optimizer. If OPTIMIZER_FEATURES_ENABLE is set to:
- 10.0.0 or later, the default value is 2
- 9.2.0, the default value is 1
- 9.0.1 or earlier, the default value is 0
• OPTIMIZER_USE_INVISIBLE_INDEXES enables or disables the use of invisible
indexes.
• OPTIMIZER_USE_PENDING_STATISTICS specifies whether or not the optimizer uses
pending statistics when compiling SQL statements.
Note: Invisible indexes, pending statistics, and dynamic sampling are discussed later in this
course.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 37
Optimizer Features and Oracle Database Releases

Optimizer Features and Oracle Database Releases
OPTIMIZER_FEATURES_ENABLED acts as an umbrella parameter for enabling a series of
optimizer features based on an Oracle release number. The table in the slide describes some
of the optimizer features that are enabled depending on the value specified for the
OPTIMIZER_FEATURES_ENABLED parameter.
Optimizer Features and Oracle Database Releases
Features 9.0.0 to 9.2.0 10.1.0 to 10.1.0.5 10.2.0 to 10.2.0.2 11.1.0.6
Index fast full scan
Consideration of bitmap access to paths for tables with only B-
tree indexes
Complex view merging
Peeking into user-defined bind variables
Index joins
Dynamic sampling
Query rewrite enables
Skip unusable indexes
Automatically compute index statistics as part of creation
Cost-based query transformations
Allow rewrites with multiple MVs and/or base tables
Adaptive cursor sharing
Use extended statistics to estimate selectivity
Use native implementation for full outer joins
Partition pruning using join filtering
Group by placement optimization
Null aware antijoins
OPTIMIZER_FEATURES_ENABLED
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 38
Quiz

Answer: c
Quiz
The _________step provides information about the select list
items and is relevant when entering dynamic queries through
an OCI application.
a. Parse
b. Define
c. Describe
d. Parallelize
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 39
Quiz

Answer: d
Quiz
Which of the following steps is performed by the query
optimizer?
a. Generating a set of potential plans for the SQL statement
based on available access paths
b. Estimating and comparing the cost of each plan
c. Selecting the plan with the lowest cost
d. All of the above
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 40
Quiz

Answer: b
Quiz
The expected number of rows retrieved by a particular
operation in the execution plan is known as its:
a. Cost
b. Cardinality
c. Optimization quotient
d. Selectivity
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 41
Summary

Summary
In this lesson, you should have learned how to:
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer
Chapter 3 - Page 42
Practice 3: Overview

Practice 3: Overview
This practice covers exploring a trace file to understand the
optimizer’s decisions.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 1
Interpreting Execution Plans
Chapter 4

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 2
Interpreting Execution Plans

Interpreting Execution Plans
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 3
Objectives

Objectives
After completing this lesson, you should be able to:
• Gather execution plans
• Display execution plans
• Interpret execution plans
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 4
What Is an Execution Plan?

What Is an Execution Plan?
An execution plan is the output of the optimizer and is presented to the execution engine for
implementation. It instructs the execution engine about the operations it must perform for
retrieving the data required by a query most efficiently.
The EXPLAIN PLAN statement gathers execution plans chosen by the Oracle optimizer for
the SELECT, UPDATE, INSERT, and DELETE statements. The steps of the execution plan are
not performed in the order in which they are numbered. There is a parent-child relationship
between steps. The row source tree is the core of the execution plan. It shows the following
information:
• An ordering of the tables referenced by the statement
• An access method for each table mentioned in the statement
• A join method for tables affected by join operations in the statement
• Data operations, such as filter, sort, or aggregation
In addition to the row source tree (or data flow tree for parallel operations), the plan table
contains information about the following:
• Optimization, such as the cost and cardinality of each operation
• Partitioning, such as the set of accessed partitions
• Parallel execution, such as the distribution method of join inputs
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).
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 5
The EXPLAIN PLAN results help you determine whether the optimizer selects a particular
execution plan, such as nested loops join.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 6
Where to Find Execution Plans?

Where to Find Execution Plans?
There are many ways to retrieve execution plans inside the database. The most well-known
ones are listed in the slide:
• The EXPLAIN PLAN command enables you to view the execution plan that the
optimizer might use to execute a SQL statement. This command is very useful because
it outlines the plan that the optimizer may use and inserts it in a table called
PLAN_TABLE without executing the SQL statement. This command is available from
SQL*Plus or SQL Developer.
• V$SQL_PLAN provides a way to examine the execution plan for cursors that were
recently executed. Information in V$SQL_PLAN is very similar to the output of an
EXPLAIN PLAN statement. However, while EXPLAIN PLAN shows a theoretical plan
that can be used if this statement was executed, V$SQL_PLAN contains the actual plan
used.
• V$SQL_PLAN_MONITOR displays plan-level monitoring statistics for each SQL statement
found in V$SQL_MONITOR. Each row in V$SQL_PLAN_MONITOR corresponds to an
operation of the execution plan that is monitored.
• The Automatic Workload Repository (AWR) infrastructure and Statspack store execution
plans of top SQL statements. Plans are recorded into DBA_HIST_SQL_PLAN or
STATS$SQL_PLAN.
Where to Find Execution Plans?
• PLAN_TABLE (SQL Developer or SQL*Plus)
• V$SQL_PLAN (Library Cache)
• V$SQL_PLAN_MONITOR (11g)
• DBA_HIST_SQL_PLAN (AWR)
• STATS$SQL_PLAN (Statspack)
• SQL management base (SQL plan baselines)
• SQL tuning set
• Trace files generated by DBMS_MONITOR
• Event 10053 trace file
• Process state dump trace file since 10gR2
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 7
• Plan and row source operations are dumped in trace files generated by DBMS_MONITOR.
• The SQL management base (SMB) is a part of the data dictionary that resides in the
SYSAUX tablespace. It stores statement log, plan histories, and SQL plan baselines, as
well as SQL profiles.
• The event 10053, which is used to dump cost-based optimizer (CBO) computations may
include a plan.
• Starting with Oracle Database 10g, Release 2, when you dump process state (or
errorstack from a process), execution plans are included in the trace file that is
generated.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 8
Viewing Execution Plans

Viewing Execution Plans
If you execute the EXPLAIN PLAN SQL*Plus command, you can then SELECT from the
PLAN_TABLE to view the execution plan. There are several SQL*Plus scripts available to
format the plan table output. The easiest way to view an execution plan is to use the
DBMS_XPLAN package. The DBMS_XPLAN package supplies five table functions:
• DISPLAY: To format and display the contents of a plan table
• DISPLAY_AWR: To format and display the contents of the execution plan of a stored
SQL statement in the AWR
• DISPLAY_CURSOR: To format and display the contents of the execution plan of any
loaded cursor
• DISPLAY_SQL_PLAN_BASELINE: To display one or more execution plans for the SQL
statement identified by SQL handle
• DISPLAY_SQLSET: To format and display the contents of the execution plan of
statements stored in a SQL tuning set
An advantage of using the DBMS_XPLAN package table functions is that the output is
formatted consistently without regard to the source.
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()
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 9
The EXPLAIN PLAN Command

The EXPLAIN PLAN Command
The EXPLAIN PLAN command is used to generate the execution plan that the optimizer uses
to execute a SQL statement. It does not execute the statement, but simply produces the plan
that may be used, and inserts this plan into a table. If you examine the plan, you can see how
the Oracle Server executes the statement.
Using EXPLAIN PLAN
• First use the EXPLAIN PLAN command to explain a SQL statement.
• Then retrieve the plan steps by querying PLAN_TABLE.
PLAN_TABLE is automatically created as a global temporary table to hold the output of an
EXPLAIN PLAN statement for all users. PLAN_TABLE is the default sample output table into
which the EXPLAIN PLAN statement inserts rows describing execution plans.
Note: You can create your own PLAN_TABLE using the
$ORACLE_HOME/rdbms/admin/utlxplan.sql script if you want to keep the execution
plan information for a long term.
The EXPLAIN PLAN Command
• Generates an optimizer execution plan
• Stores the plan in PLAN_TABLE
• Does not execute the statement itself
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 10
The EXPLAIN PLAN Command

The EXPLAIN PLAN Command (continued)
This command inserts a row in the plan table for each step of the execution plan.
In the syntax diagram in the slide, the fields in italics have the following meanings:
The EXPLAIN PLAN Command
SET STATEMENT_ID
= 'text'
EXPLAIN PLAN
INTO your plan table
FOR statement
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 11
The EXPLAIN PLAN Command: Example

The EXPLAIN PLAN Command: Example
This command inserts the execution plan of the SQL statement in the plan table and adds the
optional demo01 name tag for future reference. You can also use the following syntax:
EXPLAIN PLAN
FOR
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d
WHERE e.department_id =d.department_id;
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 12
PLAN_TABLE

PLAN_TABLE
There are various available methods to gather execution plans. Now, you are introduced only
to the EXPLAIN PLAN statement. This SQL statement gathers the execution plan of a SQL
statement without executing it, and outputs its result in the PLAN_TABLE table. Whatever the
method to gather and display the explain plan, the basic format and goal are the same.
However, PLAN_TABLE just shows you a plan that might not be the one chosen by the
optimizer. PLAN_TABLE is automatically created as a global temporary table and is visible to
all users. PLAN_TABLE is the default sample output table into which the EXPLAIN PLAN
statement inserts rows describing execution plans. PLAN_TABLE is organized in a tree-like
structure and you can retrieve that structure by using both the ID and PARENT_ID columns
with a CONNECT BY clause in a SELECT statement. While a PLAN_TABLE table is
automatically set up for each user, you can use the utlxplan.sql SQL script to manually
create a local PLAN_TABLE in your schema and use it to store the results of EXPLAIN PLAN.
The exact name and location of this script depends on your operating system. On UNIX, it is
located in the $ORACLE_HOME/rdbms/admin directory. It is recommended that you drop and
rebuild your local PLAN_TABLE table after upgrading the version of the database because the
columns might change. This can cause scripts to fail or cause TKPROF to fail, if you are
specifying the table.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 13
Note: If you want an output table with a different name, first create PLAN_TABLE manually
with the utlxplan.sql script, and then rename the table with the RENAME SQL statement.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 14
Displaying from PLAN_TABLE: Typical

Displaying from PLAN_TABLE: Typical
In the example in the slide, the EXPLAIN PLAN command inserts the execution plan of the
SQL statement in PLAN_TABLE and adds the optional demo01 name tag for future reference.
The DISPLAY function of the DBMS_XPLAN package can be used to format and display the
last statement stored in PLAN_TABLE. You can also use the following syntax to retrieve the
same result: SELECT * FROM
TABLE(dbms_xplan.display('plan_table','demo01','typical',null));
The output is the same as shown in the slide. In this example, you can substitute the name of
another plan table instead of PLAN_TABLE and demo01 represents the statement ID.
TYPICAL displays the most relevant information in the plan: operation ID, name and option,
number of rows, bytes, and optimizer cost. The last parameter for the DISPLAY function is the
one corresponding to filter_preds. This parameter represents a filter predicate or
predicates to restrict the set of rows selected from the table where the plan is stored. When
value is null (the default), the plan displayed corresponds to the last executed explain plan.
This parameter can reference any column of the table where the plan is stored and can
contain any SQL construct—for example, subquery or function calls.
Note: Alternatively, you can run the utlxpls.sql (or utlxplp.sql for parallel queries)
script (located in the ORACLE_HOME/rdbms/admin/ directory) to display the execution plan
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 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ENAME"='KING')
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 15
stored in PLAN_TABLE for the last statement explained. This script uses the DISPLAY table
function from the DBMS_XPLAN package.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 16
Displaying from PLAN_TABLE: ALL

Displaying from PLAN_TABLE: ALL
Here you use the same EXPLAIN PLAN command example as in the previous slide. The ALL
option used with the DISPLAY function allows you to output the maximum user level
information. It includes information displayed with the TYPICAL level, with additional
information such as PROJECTION, ALIAS, and information about REMOTE SQL, if the
operation is distributed.
For finer control on the display output, the following keywords can be added to the format
parameter to customize its default behavior. Each keyword either represents a logical group of
plan table columns (such as PARTITION) or logical additions to the base plan table output
(such as PREDICATE). Format keywords must be separated by either a comma or a space:
• ROWS: If relevant, shows the number of rows estimated by the optimizer
• BYTES: If relevant, shows the number of bytes estimated by the optimizer
• COST: If relevant, shows optimizer cost information
• PARTITION: If relevant, shows partition pruning information
• PARALLEL: If relevant, shows PX information (distribution method and table queue
information)
• PREDICATE: If relevant, shows the predicate section
Displaying from PLAN_TABLE: ALL
SQL> select * from table(DBMS_XPLAN.DISPLAY(null,null,'ALL'));
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 |
--------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$1 / EMP@SEL$1
Predicate Information (identified by operation id):
---------------------------------------------------
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]
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 17
• PROJECTION: If relevant, shows the projection section
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 18
The EXPLAIN PLAN Command

Displaying from PLAN_TABLE: ALL (continued)
• ALIAS: If relevant, shows the “Query Block Name/Object Alias” section
• REMOTE: If relevant, shows the information for the distributed query (for example, remote
from serial distribution and remote SQL)
• NOTE: If relevant, shows the note section of the explain plan
If the target plan table also stores plan statistics columns (for example, it is a table used to
capture the content of the fixed view V$SQL_PLAN_STATISTICS_ALL), additional format
keywords can be used to specify which class of statistics to display when using the DISPLAY
function. These additional format keywords are IOSTATS, MEMSTATS, ALLSTATS and LAST.
Note: Format keywords can be prefixed with the “-” sign to exclude the specified information.
For example, “-PROJECTION” excludes projection information.
SET STATEMENT_ID
= 'text'
EXPLAIN PLAN
INTO your plan table
FOR statement
The EXPLAIN PLAN Command
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 19
Displaying from PLAN_TABLE: ADVANCED

Displaying from PLAN_TABLE: ADVANCED
The ADVANCED format is available only from Oracle Database 10g, Release 2 and later
versions.
This output format includes all sections from the ALL format plus the outline data that
represents a set of hints to reproduce that particular plan.
This section may be useful if you want to reproduce a particular execution plan in a different
environment.
This is the same section, which is displayed in the trace file for event 10053.
Note: When the ADVANCED format is used with V$SQL_PLAN, there is one more section
called Peeked Binds (identified by position).
Displaying from PLAN_TABLE: ADVANCED
select plan_table_output from table(DBMS_XPLAN.DISPLAY(null,null,'ADVANCED
-PROJECTION -PREDICATE -ALIAS'));
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 |
--------------------------------------------------------------------------
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
*/
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 20
Explain Plan Using SQL Developer

Explain Plan Using SQL Developer
The Explain Plan icon generates the execution plan, which you can see in the Explain tab. An
execution plan shows a row source tree with the hierarchy of operations that make up the
statement. For each operation, it shows the ordering of the tables referenced by the
statement, access method for each table mentioned in the statement, join method for tables
affected by join operations in the statement, and data operations such as filter, sort, or
aggregation. In addition to the row source tree, the plan table displays information about
optimization (such as the cost and cardinality of each operation), partitioning (such as the set
of accessed partitions), and parallel execution (such as the distribution method of join inputs).

Explain Plan Using SQL Developer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 21
AUTOTRACE

AUTOTRACE
When running SQL statements under SQL*Plus or SQL Developer, you can automatically get
a report on the execution plan and the statement execution statistics. The report is generated
after successful SQL DML (that is, SELECT, DELETE, UPDATE, and INSERT) statements. It is
useful for monitoring and tuning the performance of these statements.
To use this feature, you must have a PLAN_TABLE available in your schema, and then have
the PLUSTRACE role granted to you. The database administrator (DBA) privileges are required
to grant the PLUSTRACE role. The PLUSTRACE role is created and granted to the DBA role by
running the supplied $ORACLE_HOME/sqlplus/admin/plustrce.sql script.
On some versions and platforms, this is run by the database creation scripts. If this is not the
case on your platform, connect as SYSDBA and run the plustrce.sql script.
The PLUSTRACE role contains the select privilege on three V$ views. These privileges are
necessary to generate AUTOTRACE statistics.
AUTOTRACE is an excellent diagnostic tool for SQL statement tuning. Because it is purely
declarative, it is easier to use than EXPLAIN PLAN.
Note: The system does not support EXPLAIN PLAN for statements performing implicit type
conversion of date bind variables. With bind variables in general, the EXPLAIN PLAN output
might not represent the real execution plan.
AUTOTRACE
• Is a SQL*Plus and SQL Developer facility
• Was introduced with Oracle 7.3
• Needs a PLAN_TABLE
• Needs the PLUSTRACE role to retrieve statistics from some
V$ views
• By default, produces the execution plan and statistics after
running the query
• May not be the execution plan used by the optimizer when
using bind peeking (recursive EXPLAIN PLAN)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 22
The AUTOTRACE Syntax

The AUTOTRACE Syntax
You can enable AUTOTRACE in various ways using the syntax shown in the slide. The
command options are as follows:
• OFF: Disables autotracing SQL statements
• ON: Enables autotracing SQL statements
• TRACE or TRACE[ONLY]: Enables autotracing SQL statements and suppresses
statement output
• EXPLAIN: Displays execution plans, but does not display statistics
• STATISTICS: Displays statistics, but does not display execution plans
Note: If both the EXPLAIN and STATISTICS command options are omitted, execution plans
and statistics are displayed by default.
The AUTOTRACE Syntax
OFF
TRACE[ONLY]
EXPLAIN
STATISTICS
SHOW AUTOTRACE
SET AUTOTRACE ON
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 23
AUTOTRACE: Examples

AUTOTRACE: Examples
You can control the report by setting the AUTOTRACE system variable. The following are some
examples:
• SET AUTOTRACE ON: The AUTOTRACE report includes both the optimizer execution
plan and the SQL statement execution statistics.
• SET AUTOTRACE TRACEONLY EXPLAIN: The AUTOTRACE report shows only the
optimizer execution path without executing the statement.
• SET AUTOTRACE ON STATISTICS: The AUTOTRACE report shows the SQL statement
execution statistics and rows.
• SET AUTOTRACE TRACEONLY: This is similar to SET AUTOTRACE ON, but it
suppresses the printing of the user’s query output, if any. If STATISTICS is enabled, the
query data is still fetched, but not printed.
• SET AUTOTRACE OFF: No AUTOTRACE report is generated. This is the default.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 24
AUTOTRACE: Statistics

AUTOTRACE: Statistics
The statistics are recorded by the server when your statement executes and indicate the
system resources required to execute your statement. The results include the following
statistics:
• recursive calls is the number of recursive calls generated at both the user and
system level. Oracle Database maintains tables used for internal processing. When
Oracle Database needs to make a change to these tables, it internally generates an
internal SQL statement, which in turn generates a recursive call.
• db block gets is the number of times a CURRENT block was requested.
• consistent gets is the number of times a consistent read was requested for a block.
• physical reads is the total number of data blocks read from disk. This number
equals the value of “physical reads direct” plus all reads into buffer cache.
• redo size is the total amount of redo generated in bytes.
• bytes sent via SQL*Net to client is the total number of bytes sent to the client
from the foreground processes.
• bytes received via SQL*Net from client is the total number of bytes received
from the client over Oracle Net.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 25
• SQL*Net roundtrips to/from client is the total number of Oracle Net
messages sent to and received from the client.
Note: The statistics printed by AUTOTRACE are retrieved from V$SESSTAT.
• sorts (memory) is the number of sort operations that were performed completely in
memory and did not require any disk writes.
• sorts (disk) is the number of sort operations that required at least one disk write.
• rows processed is the number of rows processed during the operation.
The client referred to in the statistics is SQL*Plus. Oracle Net refers to the generic process
communication between SQL*Plus and the server, regardless of whether Oracle Net is
installed. You cannot change the default format of the statistics report.
Note: db block gets indicates reads of the current block from the database. consistent
gets are reads of blocks that must satisfy a particular system change number (SCN).
physical reads indicates reads of blocks from disk. db block gets and consistent
gets are the two statistics that are usually monitored. These should be low compared to the
number of rows retrieved. Sorts should be performed in memory rather than on disk.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 26
AUTOTRACE Using SQL Developer

AUTOTRACE Using SQL Developer
The Autotrace pane displays trace-related information when you execute the SQL statement
by clicking the Autotrace icon. This information can help you to identify SQL statements that
will benefit from tuning.
AUTOTRACE Using SQL Developer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 27
Using the V$SQL_PLAN View

Using the V$SQL_PLAN View
This view displays the execution plan for cursors that are still in the library cache. The
information in this view is very similar to the information in PLAN_TABLE. However,
V$SQL_PLAN contains the actual plan used. The execution plan obtained by the EXPLAIN
PLAN statement can be different from the execution plan used to execute the cursor. This is
because the cursor might have been compiled with different values of session parameters or
bind variables..
V$SQL_PLAN shows the plan for a cursor rather than for all cursors associated with a SQL
statement. The difference is that a SQL statement can have more than one cursor associated
with it, with each cursor further identified by a CHILD_NUMBER. For example, the same
statement executed by different users has different cursors associated with it if the object that
is referenced is in a different schema. Similarly, different hints can cause different cursors.
The V$SQL_PLAN table can be used to see the different plans for different child cursors of the
same statement.
Note: Another useful view is V$SQL_PLAN_STATISTICS, which provides the execution
statistics of each operation in the execution plan for each cached cursor. Also, the
V$SQL_PLAN_STATISTICS_ALL view concatenates information from V$SQL_PLAN with
execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 28
The V$SQL_PLAN Columns

The V$SQL_PLAN Columns
The view contains many of the PLAN_TABLE columns, plus several others. The columns that
are also present in PLAN_TABLE have the same values:
• ADDRESS
• HASH_VALUE
The ADDRESS and HASH_VALUE columns can be used to join with V$SQLAREA to add the
cursor-specific information.
The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be used to join with V$SQL to
add the child cursor–specific information.
The PLAN_HASH VALUE column is a numerical representation of the SQL plan for the cursor.
By comparing one PLAN_HASH_VALUE with another, you can easily identify whether the two
plans are the same or not (rather than comparing the two plans line-by-line).
Note: Since Oracle Database 10g, SQL_HASH_VALUE in V$SESSION has been
complemented with SQL_ID, which you retrieve in many other V$ views. SQL_HASH_VALUE is
a 32-bit value and is not unique enough for large repositories of AWR data. SQL_ID is a 64-bit
hash value, which is more unique, the bottom 32 bits of which are SQL_HASH_VALUE. It is
normally represented as a character string to make it more manageable.
The V$SQL_PLAN Columns
Note: This is only a partial listing of the columns.
HASH_VALUE
Hash value of the parent statement in the
library cache
ADDRESS
Address of the handle to the parent for this cursor
CHILD_NUMBER
Child cursor number using this execution plan
POSITION
Order of processing for all operations that have
the same PARENT_ID
PARENT_ID
ID of the next execution step that operates on
the output of the current step
ID
Number assigned to each step in the
execution plan
PLAN_HASH_VALUE
Numerical representation of the SQL plan for the cursor
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 29
The V$SQL_PLAN_STATISTICS View

The V$SQL_PLAN_STATISTICS View
The V$SQL_PLAN_STATISTICS view provides the actual execution statistics for every
operation in the plan, such as the number of output rows, and elapsed time. All statistics,
except the number of output rows, are cumulative. For example, the statistics for a join
operation also include the statistics for its two inputs. The statistics in
V$SQL_PLAN_STATISTICS are available for cursors that have been compiled with the
STATISTICS_LEVEL initialization parameter set to ALL or using the
GATHER_PLAN_STATISTICS hint.
The V$SQL_PLAN_STATISTICS_ALL view contains memory-usage statistics for row sources
that use SQL memory (sort or hash join). This view concatenates information in V$SQL_PLAN
with execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 30
Links Between Important Dynamic Performance Views

Links Between Important Dynamic Performance Views
V$SQLAREA displays statistics on shared SQL areas and contains one row per SQL string. It
provides statistics on SQL statements that are in memory, parsed, and ready for execution:
• SQL_ID is the SQL identifier of the parent cursor in the library cache.
• VERSION_COUNT is the number of child cursors that are present in the cache under this
parent.
V$SQL lists statistics on shared SQL areas and contains one row for each child of the original
SQL text entered:
• ADDRESS represents the address of the handle to the parent for this cursor.
• HASH_VALUE is the value of the parent statement in the library cache.
• SQL_ID is the SQL identifier of the parent cursor in the library cache.
• PLAN_HASH_VALUE is a numeric representation of the SQL plan for this cursor. By
comparing one PLAN_HASH_VALUE with another, you can easily identify if the two plans
are the same or not (rather than comparing the two plans line-by-line).
• CHILD_NUMBER is the number of this child cursor.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 31
Statistics displayed in V$SQL are normally updated at the end of query execution. However,
for long-running queries, they are updated every five seconds. This makes it easy to see the
impact of long-running SQL statements while they are still in progress.
V$SQL_PLAN contains the execution plan information for each child cursor loaded in the
library cache. The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be used to join
with V$SQL to add the child cursor–specific information.
V$SQL_PLAN_STATISTICS provides execution statistics at the row source level for each
child cursor. The ADDRESS and HASH_VALUE columns can be used to join with V$SQLAREA to
locate the parent cursor. The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be
used to join with V$SQL to locate the child cursor using this area.
V$SQL_PLAN_STATISTICS_ALL contains memory usage statistics for row sources that use
SQL memory (sort or hash join). This view concatenates information in V$SQL_PLAN with
execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA.
V$SQL_WORKAREA displays information about work areas used by SQL cursors. Each SQL
statement stored in the shared pool has one or more child cursors that are listed in the V$SQL
view. V$SQL_WORKAREA lists all work areas needed by these child cursors.
V$SQL_WORKAREA can be joined with V$SQLAREA on (ADDRESS, HASH_VALUE) and with
V$SQL on (ADDRESS, HASH_VALUE, CHILD_NUMBER).
You can use this view to find answers to the following questions:
• What are the top 10 work areas that require the most cache area?
• For work areas allocated in the AUTO mode, what percentage of work areas run using
maximum memory?
V$SQLSTATS displays basic performance statistics for SQL cursors, with each row
representing the data for a unique combination of SQL text and optimizer plan (that is, unique
combination of SQL_ID and PLAN_HASH_VALUE). The column definitions for columns in
V$SQLSTATS are identical to those in the V$SQL and V$SQLAREA views. However, the
V$SQLSTATS view differs from V$SQL and V$SQLAREA in that it is faster, more scalable, and
has a greater data retention (the statistics may still appear in this view, even after the cursor
has been aged out of the shared pool). Note that V$SQLSTATS contains a subset of columns
that appear in V$SQL and V$SQLAREA.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 32
Querying V$SQL_PLAN

Querying V$SQL_PLAN
You can query V$SQL_PLAN using the DBMS_XPLAN.DISPLAY_CURSOR() function to
display the current or last executed statement (as shown in the example). You can pass the
value of SQL_ID for the statement as a parameter to obtain the execution plan for a given
statement. SQL_ID is the SQL_ID of the SQL statement in the cursor cache. You can retrieve
the appropriate value by querying the SQL_ID column in V$SQL or V$SQLAREA. Alternatively,
you could select the PREV_SQL_ID column for a specific session out of V$SESSION. This
parameter defaults to null in which case the plan of the last cursor executed by the session is
displayed. To obtain SQL_ID, execute the following query:
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d
WHERE e.department_id =d.department_id;

SELECT SQL_ID, SQL_TEXT FROM V$SQL
WHERE SQL_TEXT LIKE '%SELECT e.last_name,%' ;

13saxr0mmz1s3 select SQL_id, sql_text from v$SQL …
47ju6102uvq5q SELECT e.last_name, d.department_name …
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
Plan hash value: 2933537672
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100|
| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|
| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|
| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0|
|* 4 | SORT JOIN | | 107 | 1177 | 4 (25|
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
24 rows selected.
SELECT PLAN_TABLE_OUTPUT FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR('47ju6102uvq5q'));
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 33
CHILD_NUMBER is the child number of the cursor to display. If not supplied, the execution plan
of all cursors matching the supplied SQL_ID parameter are displayed. CHILD_NUMBER can be
specified only if SQL_ID is specified.
The FORMAT parameter controls the level of detail for the plan. In addition to the standard
values (BASIC, TYPICAL, SERIAL, ALL, and ADVANCED), there are additional supported
values to display run-time statistics for the cursor:
• IOSTATS: Assuming that the basic plan statistics are collected when SQL statements
are executed (either by using the GATHER_PLAN_STATISTICS hint or by setting the
statistics_level parameter to ALL), this format shows I/O statistics for ALL (or only
for LAST) executions of the cursor.
• MEMSTATS: Assuming that the Program Global Area (PGA) memory management is
enabled (that is, the pga_aggregate_target parameter is set to a nonzero value),
this format allows to display memory management statistics (for example, execution
mode of the operator, how much memory was used, number of bytes spilled to disk, and
so on). These statistics only apply to memory-intensive operations, such as hash joins,
sort or some bitmap operators.
• ALLSTATS: A shortcut for 'IOSTATS MEMSTATS'
• LAST: By default, plan statistics are shown for all executions of the cursor. The LAST
keyword can be specified to see only the statistics for the last execution.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 34
Automatic Workload Repository (AWR)

Automatic Workload Repository (AWR)
The AWR is part of the intelligent infrastructure introduced with Oracle Database 10g. This
infrastructure is used by many components, such as Automatic Database Diagnostic Monitor
(ADDM) for analysis. The AWR automatically collects, processes, and maintains system-
performance statistics for problem-detection and self-tuning purposes and stores the statistics
persistently in the database.
The statistics collected and processed by the AWR include:
• Object statistics that determine both access and usage statistics of database segments
• Time-model statistics based on time usage for activities, displayed in the
V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views
• Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT
views
• SQL statements that produce the highest load on the system, based on criteria, such as
elapsed time, CPU time, buffer gets, and so on
• ASH statistics, representing the history of recent sessions
The database automatically generates snapshots of the performance data once every hour
and collects the statistics in the workload repository. The data in the snapshot interval is then
analyzed by ADDM. The ADDM compares the differences between snapshots to determine
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 35
which SQL statements to capture based on the effect on the system load. This reduces the
number of SQL statements that need to be captured over time.
Note: By using PL/SQL packages, such as DBMS_WORKLOAD_REPOSITORY or Oracle
Enterprise Manager, you can manage the frequency and retention period of SQL that is stored
in the AWR.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 36
Managing AWR with PL/SQL

Managing AWR with PL/SQL
Although the primary interface for managing the AWR is Enterprise Manager, monitoring
functions can be managed with procedures in the DBMS_WORKLOAD_REPOSITORY package.
Snapshots are automatically generated for an Oracle Database; however, you can use
DBMS_WORKLOAD_REPOSITORY procedures to manually create, drop, and modify the
snapshots and baselines that are used by the ADDM. Snapshots and baselines are sets of
historical data for specific time periods that are used for performance comparisons. To invoke
these procedures, a user must be granted the DBA role.
Creating Snapshots
You can manually create snapshots with the CREATE_SNAPSHOT procedure if you want to
capture statistics at times different than those of the automatically generated snapshots. Here
is an example:
Exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ('ALL');
In this example, a snapshot for the instance is created immediately with the flush level
specified to the default flush level of TYPICAL. You can view this snapshot in the
DBA_HIST_SNAPSHOT view.
Dropping Snapshots
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 37
You can drop a range of snapshots using the DROP_SNAPSHOT_RANGE procedure. To view a
list of the snapshot IDs along with database IDs, check the DBA_HIST_SNAPSHOT view. For
example, you can drop the following range of snapshots:
Exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE - (low_snap_id =>
22, high_snap_id => 32, dbid => 3310949047);
In the example, the range of snapshot IDs to drop is specified from 22 to 32. The optional
database identifier is 3310949047. If you do not specify a value for dbid, the local database
identifier is used as the default value.
ASH data that belongs to the time period specified by the snapshot range is also purged when
the DROP_SNAPSHOT_RANGE procedure is called.
Modifying Snapshot Settings
You can adjust the interval and retention of snapshot generation for a specified database ID.
However, note that this can affect the precision of the Oracle diagnostic tools.
The INTERVAL setting specifies how often (in minutes) snapshots are automatically
generated. The RETENTION setting specifies how long (in minutes) snapshots are stored in
the workload repository. To adjust the settings, use the MODIFY_SNAPSHOT_SETTINGS
procedure, as in the following example:
Exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( -retention
=> 43200, interval => 30, dbid => 3310949047);
In this example, the retention period is specified as 43,200 minutes (30 days), and the interval
between each snapshot is specified as 30 minutes. If NULL is specified, the existing value is
preserved. The optional database identifier is 3310949047. If you do not specify a value for
dbid, the local database identifier is used as the default value. You can check the current
settings for your database instance with the DBA_HIST_WR_CONTROL view.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 38
Important AWR Views

Important AWR Views
You can view the AWR data on Oracle Enterprise Manager screens or in AWR reports.
However, you can also view the statistics directly from the following views:
V$ACTIVE_SESSION_HISTORY: This view displays active database session activity, sampled
once every second.
V$ metric views provide metric data to track the performance of the system. The metric views
are organized into various groups, such as event, event class, system, session, service, file,
and tablespace metrics. These groups are identified in the V$METRICGROUP view.
The DBA_HIST views contain historical data stored in the database. This group of views
includes:
• DBA_HIST_ACTIVE_SESS_HISTORY displays the history of the contents of the sampled
in-memory active session history for recent system activity.
• DBA_HIST_BASELINE displays information about the baselines captured in the system.
• DBA_HIST_DATABASE_INSTANCE displays information about the database
environment.
• DBA_HIST_SNAPSHOT displays information about snapshots in the system.
• DBA_HIST_SQL_PLAN displays SQL execution plans.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 39
• DBA_HIST_WR_CONTROL displays the settings for controlling AWR.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 40
Querying the AWR

Querying the AWR
You can use the DBMS_XPLAN.DISPLAY_AWR() function to display all stored plans in the
AWR. In the example in the slide, you pass in a SQL_ID as an argument. SQL_ID is the
SQL_ID of the SQL statement in the cursor cache. The DISPLAY_AWR() function also takes
the PLAN_HASH_VALUE, DB_ID, and FORMAT parameters.
The steps to complete this example are as follows:
1. Execute the SQL statement:
SQL> select /* example */ * from hr.employees natural
join hr.departments;
2. Query V$SQL_TEXT to obtain the SQL_ID:
SQL> select sql_id, sql_text from v$SQL
where sql_text
like '%example%';
SQL_ID SQL_TEXT
------------- -------------------------------------------
F8tc4anpz5cdb select sql_id, sql_text from v$SQL …
454rug2yva18w select /* example */ * from …
Querying the AWR
• Retrieve all execution plans stored for a particular SQL_ID.
• Display all execution plans of all statements containing
“JF.”
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
Plan hash value: 4179021502
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100)| |
| 1 | HASH JOIN | | 11 | 968 | 6 (17)| 00:00:01 |
| 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 2 (0)| 00:00:01 |
| 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%';
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 41
3. Using the SQL_ID, verify that this statement has been captured in the
DBA_HIST_SQLTEXT dictionary view. If the query does not return rows, it indicates that
the statement has not yet been loaded in the AWR.
SQL> SELECT SQL_ID, SQL_TEXT FROM dba_hist_sqltext WHERE SQL_ID
=' 454rug2yva18w';
no rows selected
You can take a manual AWR snapshot rather than wait for the next snapshot (which
occurs every hour). Then check to see if it has been captured in DBA_HIST_SQLTEXT:
SQL> exec dbms_workload_repository.create_snapshot;

PL/SQL procedure successfully completed.

SQL> SELECT SQL_ID, SQL_TEXT FROM dba_hist_sqltext WHERE SQL_ID
=' 454rug2yva18w';
SQL_ID SQL_TEXT
-------------- -------------------------------
454rug2yva18w select /* example */ * from …

4. Use the DBMS_XPLAN.DISPLAY_AWR () function to retrieve the execution plan:
SQL>SELECT PLAN_TABLE_OUTPUT FROM TABLE
(DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w’));
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 42
Generating SQL Reports from AWR Data

Generating SQL Reports from AWR Data
Since Oracle Database 10g, Release 2, it is possible to generate SQL reports from AWR data,
basically, the equivalent to sqrepsql.sql with Statspack. In 10.1.0.4.0, the equivalent to
sprepsql.sql is not available in AWR. However, in 10gR2, the equivalent of
sprepsql.sql is available. In 10gR2, the AWR SQL report can be generated by calling the
$ORACLE_HOME/rdbms/admin/awrsqrpt.sql file.
You can display the plan information in AWR by using the display_awr table function in the
dbms_xplan PL/SQL package.
For example, this displays the plan information for a SQL_ID in AWR:
select * from table(dbms_xplan.display_awr('dvza55c7zu0yv'));
You can retrieve the appropriate value for the SQL statement of interest by querying SQL_ID
in the DBA_HIST_SQLTEXT column.
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: dvza55c7zu0yv
Specify the Report Name …
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 43
SQL Monitoring: Overview

SQL Monitoring: Overview
The SQL monitoring feature is enabled by default when the STATISTICS_LEVEL initialization
parameter is either set to ALL or TYPICAL (the default value).
Additionally, the CONTROL_MANAGEMENT_PACK_ACCESS parameter must be set to
DIAGNOSTIC+TUNING (the default value) because SQL monitoring is a feature of the Oracle
Database Tuning Pack.
By default, SQL monitoring is automatically started when a SQL statement runs parallel, or
when it has consumed at least five seconds of the CPU or I/O time in a single execution.
As mentioned, SQL monitoring is active by default. However, two statement-level hints are
available to force or prevent a SQL statement from being monitored. To force SQL monitoring,
use the MONITOR hint. To prevent the hinted SQL statement from being monitored, use the
NO_MONITOR hint.
You can monitor the statistics for SQL statement execution using the V$SQL_MONITOR and
V$SQL_PLAN_MONITOR views.
After monitoring is initiated, an entry is added to the dynamic performance V$SQL_MONITOR
view. This entry tracks key performance metrics collected for the execution, including the
elapsed time, CPU time, number of reads and writes, I/O wait time, and various other wait
STATISTICS_LEVEL=TYPICAL|ALL
CONTROL_MANAGEMENT_PACK_ACCESS=DIAGNOSTIC+TUNING
+
SQL monitoring
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 44
times. These statistics are refreshed in near real time as the statement executes, generally
once every second.
After the execution ends, monitoring information is not deleted immediately, but is kept in the
V$SQL_MONITOR view for at least one minute. The entry is eventually deleted so its space
can be reclaimed as new statements are monitored.
The V$SQL_MONITOR and V$SQL_PLAN_MONITOR views can be used in conjunction with the
following views to get additional information about the execution that is monitored:
V$SQL, V$SQL_PLAN, V$ACTIVE_SESSION_HISTORY, V$SESSION_LONGOPS, and
V$SESSION
Instead, you can use the SQL monitoring report to view SQL monitoring data.
The SQL monitoring report is also available in a GUI version through Enterprise Manager and
SQL Developer
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 45
SQL Monitoring Report: Example

SQL Monitoring Report: Example
In this example, it is assumed that you SELECT from SALES from a different session than the
one used to print the SQL monitoring report.
The DBMS_SQLTUNE.REPORT_SQL_MONITOR function accepts several input parameters to
specify the execution, the level of detail in the report, and the report type (TEXT, HTML, or
XML). By default, a text report is generated for the last execution that was monitored if no
parameters are specified as shown in the example in the slide.
After the SELECT statement is started, and while it executes, you print the SQL monitoring
report from a second session.
From the report, you can see that the SELECT statement executes currently.
The Global Information section gives you some important information:
• To uniquely identify two executions of the same SQL statement, a composite key called
an execution key is generated. This execution key consists of three attributes, each
corresponding to a column in V$SQL_MONITOR:
- SQL identifier to identify the SQL statement (SQL_ID)
- An internally generated identifier to ensure that this primary key is truly unique
(SQL_EXEC_ID)
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 46
- A start execution time stamp (SQL_EXEC_START)
The report also shows you some important statistics calculated so far.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 47
SQL Monitoring Report: Example

SQL Monitoring Report: Example (continued)
The report then displays the execution path currently used by your statement. SQL monitoring
gives you the display of the current operation that executes in the plan. This enables you to
detect parts of the plan that are the most time consuming, so that you can focus your analysis
on those parts. The running operation is marked by an arrow in the Id column of the report.
The Time Active(s) column shows how long the operation has been active (the delta in
seconds between the first and the last active time).
The Start Active column shows, in seconds, when the operation in the execution plan started
relative to the SQL statement execution start time. In this report, the table access full
operation at Id 2 was the first to start (+1s Start Active) and ran for the first 23 seconds so far.
The Starts column shows the number of times the operation in the execution plan was
executed.
The Rows (Actual) column indicates the number of rows produced, and the Rows (Estim)
column shows the estimated cardinality from the optimizer.
The Activity (percent) and Activity Detail (sample #) columns are derived by joining the
V$SQL_PLAN_MONITOR and V$ACTIVE_SESSION_HISTORY views. Activity (percent) shows
the percentage of database time consumed by each operation of the execution plan. Activity
Detail (sample#) shows the nature of that activity (such as CPU or wait event).
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% |
==================================================================================
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 48
In this report, the Activity Detail (sample #) column shows that most of the database time,
100%, is consumed by operation Id 2 (TABLE ACCESS FULL of SALES). So far, this activity
consists of 4 samples, which are only attributed to CPU.
The last column, Progress, shows progress monitoring information for the operation from the
V$SESSION_LONGOPS view. In this report, it shows that, so far, the TABLE ACCESS FULL
operation is 74% complete. This column only appears in the report after a certain amount of
time, and only for the instrumented row sources.
Note: Not shown by this particular report, the Memory and Temp columns indicate the amount
of memory and temporary space consumed by corresponding operation of the execution plan.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 49
Interpreting an Execution Plan

Interpreting an Execution Plan
Explain plan output is a representation of a tree of row sources.
Each step (line in the execution plan or node in the tree) represents a row source.
The explain plan utility indents nodes to indicate that they are the children of the parent above
it.
The order of the nodes under the parent indicates the order of execution of the nodes within
that level. If two steps are indented at the same level, the first one is executed first.
In the tree format, the leaf at the left on each level of the tree is where the execution starts.
The steps of the execution plan are not performed in the order in which they are numbered.
there is a parent–child relationship between steps.
In PLAN_TABLE and V$SQL_PLAN, the important elements to retrieve the tree structure are
the ID, PARENT_ID, and POSITION columns. In a trace file, these columns correspond to the
id, pid, and pos fields, respectively.
One way to read an execution plan is by converting it into a graph that has a tree structure.
You can start from the top, with id=1, which is the root node in the tree. Next, you must find
the operations that feed this root node. That is accomplished by operations, which have
parent_id or pid with value 1.
Note: The course focuses on serial plans and does not discusses parallel execution plans.
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= 4 (pid=2) (pos=2) parent/child
id= 5 (pid=4) (pos=1) child/leaf
id= 6 (pid=4) (pos=2) child/leaf
id= 7 (pid=1) (pos=2) parent/child
id= 8 (pid=7) (pos=1) child/leaf
id= 9 (pid=7) (pos=2) parent/child
id=10 (pid=9) (pos=1) child/leaf
From
top/down
From left/right
Executed
first
Executed next
Parent/Child
Root/Parent
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 50
To draw plan as a tree, do the following:
1. Take the ID with the lowest number and place it at the top.
2. Look for rows which have a PID (parent) equal to this value.
3. Place these in the tree below the Parent according to their POS values from the lowest
to the highest, ordered from left to right.
4. After all the IDs for a parent have been found, move down to the next ID and repeat the
process, finding new rows with the same PID.
The first thing to determine in an explain plan is which node is executed first. The method in
the slide explains this, but sometimes with complicated plans it is difficult to do this and also
difficult to follow the steps through to the end. Large plans are exactly the same as smaller
ones, but with more entries. The same basic rules apply. You can always collapse the plan to
hide a branch of the tree which does not consume much of the resources.
Standard explain plan interpretation:
1. Start at the top.
2. Move down the row sources until you get to one which produces data, but does not
consume any. This is the start row source.
3. Look at the siblings of this row source. These row sources are executed next.
4. After the children are executed, the parent is executed next.
5. Now that this parent and its children are completed, work back up the tree, and look at
the siblings of the parent row source and its parents. Execute as before.
6. Move back up the plan until all row sources are exhausted.
Standard tree interpretation:
1. Start at the top.
2. Move down the tree to the left until you reach the left node. This is executed first.
3. Look at the siblings of this row source. These row sources are executed next.
4. After the children are executed, the parent is executed next.
5. Now that this parent and its children are completed, work back up the tree, and look at
the siblings of the parent row source and its parents. Execute as before.
6. Move back up the tree until all row sources are exhausted.
If you remember the few basic rules of explain plans and with some experience, you can read
most plans easily.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 51
Execution Plan Interpretation: Example 1

Execution Plan Interpretation: Example 1
You start with an example query to illustrate how to interpret an execution plan. The slide
shows a query with its associated execution plan and the same plan in the tree format.
The query tries to find employees who have salaries outside the range of salaries in the salary
grade table. The query is a SELECT statement from two tables with a subquery based on
another table to check the salary grades.
See the execution order for this query. Based on the example in the slide, and from the
previous slide, the execution order is 3 – 5 – 4 – 2 – 6 – 1:
• 3: The plan starts with a full table scan of EMP (ID=3).
• 5: The rows are passed back to the controlling nested loops join step (ID=2), which
uses them to execute the lookup of rows in the PK_DEPT index in ID=5.
• 4: The ROWIDs from the index are used to lookup the other information from the DEPT
table in ID=4.
• 2: ID=2, the nested loops join step, is executed until completion.
• 6: After ID=2 has exhausted its row sources, a full table scan of SALGRADE in ID=6 (at
the same level in the tree as ID=2, therefore, its sibling) is executed.
• 1: This is used to filter the rows from ID2 and ID6.
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);
--------------------------------------------------
| Id | Operation | Name |
--------------------------------------------------
| 0 | SELECT STATEMENT | |
|* 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 |
--------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 52
Note that children are executed before parents, so although structures for joins must be set up
before the child execution, the children are notated as executed first. Probably, the easiest
way is to consider it as the order in which execution completes, so for the NESTED LOOPS join
at ID=2, the two children {ID=3 and ID=4 (together with its child)} must have completed their
execution before ID=2 can be completed.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 53
Execution Plan Interpretation: Example 1

Execution Plan Interpretation: Example 1 (continued)
The example in the slide is a plan dump from V$SQL_PLAN with STATISTICS_LEVEL set to
ALL. This report shows you some important additional information compared to the output of
the EXPLAIN PLAN command:
• A-Rows corresponds to the number of rows produced by the corresponding row source.
• Buffers corresponds to the number of consistent reads done by the row source.
• Starts indicates how many times the corresponding operation was processed.
For each row from the EMP table, the system gets its ENAME, SAL, JOB, and DEPTNO.
Then the system accesses the DEPT table by its unique index (PK_DEPT) to get DNAME using
DEPTNO from the previous result set.
If you observe the statistics closely, the TABLE ACCESS FULL operation on the EMP table
(ID=3) is started once. However, operations from ID 5 and 4 are started 14 times; once for
each EMP rows. At this step (ID=2), the system gets all ENAME, SAL, JOB, and DNAME.
The system now must filter out employees who have salaries outside the range of salaries in
the salary grade table. To do that, for each row from ID=2, the system accesses the
SALGRADE table using a FULL TABLE SCAN operation to check if the employee’s salary is
outside the salary range. This operation only needs to be done 12 times in this case because
Execution Plan Interpretation: Example 1
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
-------------------------------------

Plan hash value: 1175760222
--------------------------------------------------------------------------------
| 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 |
--------------------------------------------------------------------------------

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 54
at run time the system does the check for each distinct salary, and there are 12 distinct
salaries in the EMP table.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 55
Execution Plan Interpretation: Example 2

Execution Plan Interpretation: Example 2
This query retrieves names, department names, and addresses for employees whose
departments are located in Seattle and who have managers.
For formatting reasons, the explain plan has the ID in the first column, and PID in the second
column. The position is reflected by the indentation. The execution plan shows two nested
loops join operations.
You follow the steps from the previous example:
1. Start at the top. ID=0
2. Move down the row sources until you get to the one, which produces data, but does not
consume any. In this case, ID 0, 1, 2, and 3 consume data. ID=4 is the first row source
that does not consume any. This is the start row source. ID=4 is executed first. The
index range scan produces ROWIDs, which are used to lookup in the LOCATIONS table
in ID=3.
3. Look at the siblings of this row source. These row sources are executed next. The
sibling at the same level as ID=3 is ID=5. Node ID=5 has a child ID=6, which is
executed before it. This is another index range scan producing ROWIDs, which are used
to lookup in the DEPARTMENTS table in ID=5.
Execution Plan Interpretation: Example 2
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 56
4. After the children operation, the parent operation is next. The NESTED LOOPS join at
ID=2 is executed next bringing together the underlying data.
5. Now that this parent and its children are completed, walk back up the tree, and look at
the siblings of the parent row source and its parents. Execute as before. The sibling of
ID=2 at the same level in the plan is ID=7. This has a child ID=8, which is executed
first. The index unique scan produces ROWIDs, which are used to lookup in the
EMPLOYEES table in ID=7.
6. Move back up the plan until all row sources are exhausted. Finally this is brought
together with the NESTED LOOPS at ID=1, which passes the results back to ID=0.
7. The execution order is: 4 – 3 – 6 – 5 – 2 – 8 – 7 – 1 – 0
Here is the complete description of this plan:
The inner nested loops is executed first using LOCATIONS as the driving table, using an index
access on the CITY column. This is because you search for departments in Seattle only.
The result is joined with the DEPARTMENTS table, using the index on the LOCATION_ID join
column; the result of this first join operation is the driving row source for the second nested
loops join.
The second join probes the index on the EMPLOYEE_ID column of the EMPLOYEES table. The
system can do that because it knows (from the first join) the employee ID of all managers of
departments in Seattle. Note that this is a unique scan because it is based on the primary key.
Finally, the EMPLOYEES table is accessed to retrieve the last name.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 57
Execution Plan Interpretation: Example 3

Execution Plan Interpretation: Example 3
See the execution plan in the slide. Try to find the order in which the plan is executed and
deduce what is the join order (order in which the system joins tables). Again, ID is in the first
column and PID in the second column. The position is reflected by the indentation. It is
important to recognize what the join order of an execution plan is, to be able to find your plan
in a 10053 event trace file.
Here is the interpretation of this plan:
• The system first hashes the T3 table (Operation ID=3) into memory.
• Then it hashes the T1 table (Operation ID=5) into memory.
• Then the scan of the T2 table begins (Operation ID=6).
• The system picks a row from T2 and probes T1 (T1.i=T2.i).
• If the row survives, the system probes T3 (T1.i=T3.i).
• If the row survives, the system sends it to next operation.
• The system outputs the maximum value from the previous result set.
In conclusion, the execution order is : 3 – 5 – 6 – 4 – 2 – 1
The join order is: T1 – T2 – T3
Execution Plan Interpretation: Example 3
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
5 4 TABLE ACCESS FULL T1
6 4 TABLE ACCESS FULL T2
4 3
5 6
2
1
Join order is: T1 - T2 - T3
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 58
You can also use Enterprise Manager to understand execution plans, especially because it
displays the Order column.
Note: A special hint was used to make sure T3 would be first in the plan.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 59
Reading More Complex Execution Plans

Reading More Complex Execution Plans
The plan at the left comes from the query (in the slide) on the data dictionary. It is so long that
it is very difficult to apply the previous method to interpret it and locate the first operation.
You can always collapse a plan to make it readable. This is illustrated at the right where you
can see the same plan collapsed. As shown, this is easy to do when using the Enterprise
Manager or SQL Developer graphical interface. You can clearly see that this plan is a UNION
ALL of two branches. Your knowledge about the data dictionary enables you to understand
that the two branches correspond to dictionary-managed tablespaces and locally-managed
ones. Your knowledge about your database enables you to know that there are no dictionary-
managed tablespaces. So, if there is a problem, it must be on the second branch. To get
confirmation, you must look at the plan information and execution statistics of each row source
to locate the part of the plan that consumes most resources. Then, you just need to expand
the branch you want to investigate (where time is being spent). To use this method, you must
look at the execution statistics that are generally found in V$SQL_PLAN_STATISTICS or in
the tkprof reports generated from trace files. For example, tkprof cumulates for each
parent operation the time it takes to execute itself plus the sum of all its child operation time.
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 60
Reviewing the Execution Plan

Reviewing the Execution Plan
When you tune a SQL statement in an online transaction processing (OLTP) environment, the
goal is to drive from the table that has the most selective filter. This means that there are
fewer rows passed to the next step. If the next step is a join, this means fewer rows are joined.
Check to see whether the access paths are optimal. When you examine the optimizer
execution plan, look for the following:
• The plan is such that the driving table has the best filter.
• The join order in each step means that the fewest number of rows are returned to the
next step (that is, the join order should reflect going to the best not-yet-used filters).
• The join method is appropriate for the number of rows being returned. For example,
nested loop joins through indexes may not be optimal when many rows are returned.
• Views are used efficiently. Look at the SELECT list to see whether access to the view is
necessary.
• There are any unintentional Cartesian products (even with small tables).
• Each table is being accessed efficiently: Consider the predicates in the SQL statement
and the number of rows in the table. Look for suspicious activity, such as a full table
scans on tables with large number of rows, which have predicates in the WHERE clause.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 61
Also, a full table scan might be more efficient on a small table, or to leverage a better
join method (for example, hash join) for the number of rows returned.
If any of these conditions are not optimal, consider restructuring the SQL statement or the
indexes available on the tables.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 62
Looking Beyond Execution Plans

Looking Beyond Execution Plans
The execution plan alone cannot differentiate between well-tuned statements and those that
perform poorly. For example, an EXPLAIN PLAN output that shows that a statement uses an
index does not necessarily mean that the statement runs efficiently. Sometimes indexes can
be extremely inefficient.
It is best to use EXPLAIN PLAN to determine an access plan, and then later prove that it is
the optimal plan through testing. When evaluating a plan, you should examine the statement’s
actual resource consumption.
The rest of this course is intended to show you various methods to achieve this.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 63
Quiz

Answer: a
Quiz
A user needs to be granted some specialized privileges to
generate AUTOTRACE statistics.
a. True
b. False
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 64
Quiz

Answer: b
Quiz
An EXPLAIN PLAN command executes the statement and
inserts the plan used by the optimizer into a table.
a. True
b. False
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 65
Quiz

Answer: b
Quiz
Which of the following is not true about a PLAN_TABLE?
a. The PLAN_TABLE is automatically created to hold the
EXPLAIN PLAN output.
b. You cannot create your own PLAN_TABLE.
c. The actual SQL command is not executed.
d. The plan in the PLAN_TABLE may not be the actual
execution plan.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 66
Quiz

Answer: b
Quiz
After monitoring is initiated, an entry is added to the
_______view. This entry tracks key performance metrics
collected for the execution.
a. V$SQL_MONITOR
b. V$PLAN_MONITOR
c. ALL_SQL_MONITOR
d. ALL_SQL_PLAN_MONITOR
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 67
Summary

Summary
In this lesson, you should have learned how to:
• Gather execution plans
• Display execution plans
• Interpret execution plans
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans
Chapter 4 - Page 68
Practice 4: Overview

Practice 4: Overview
This practice covers the following topics:
• Using different techniques to extract execution plans
• Using SQL monitoring
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 1
Application Tracing
Chapter 5

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 2
Application Tracing

Application Tracing
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 3
Objectives

Objectives
After completing this lesson, you should be able to do the
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 4
End-to-End Application Tracing Challenge

End-to-End Application Tracing Challenge
Oracle Database implements tracing by generating a trace file for each server process when
you enable the tracing mechanism.
Tracing a specific client is usually not a problem in the dedicated server model as a single
dedicated process serves a session during its lifetime. All the trace information for the session
can be seen from the trace file belonging to the dedicated server serving it. However, in a
shared server configuration, a client is serviced by different processes from time-to-time. The
trace pertaining to the user session is scattered across different trace files belonging to
different processes. This makes it difficult for you to get a complete picture of the life cycle of a
session.
Moreover, what if you want to consolidate trace information for a particular service for
performance or debugging purposes? This is also difficult because you have multiple clients
using the same service and each generating trace files belonging to the server process
serving it.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 5
End-to-End Application Tracing

End-to-End Application Tracing
End-to-end application tracing simplifies the diagnosis of performance problems in multitier
environments. In multitier environments, a request from an end client is routed to different
database sessions by the middle tier, making it difficult to track a specific client. A client
identifier is used to uniquely trace a specific end client through all tiers to the database server.
You can used end-to-end application tracing to identify the source of an excessive workload,
such as a high-load SQL statement. Also, you can identify what a user’s session does at the
database level to resolve that user's performance problems.
End-to-end application tracing also simplifies management of application workloads by
tracking specific modules and actions in a service. Workload problems can be identified by:
• Client identifier: Specifies an end user based on the logon ID, such as HR
• Service: Specifies a group of applications with common attributes, service-level
thresholds, and priorities; or a single application
• Module: Specifies a functional block within an application
• Action: Specifies an action, such as an INSERT or an UPDATE operation, in a module
• Session: Specifies a session based on a given database session identifier (SID)
The primary interface for end-to-end application tracing is Enterprise Manager. Other tools
listed in the slide are discussed later in this lesson.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 6
Location for Diagnostic Traces

Location for Diagnostic Traces
Starting with Oracle Database 11g, Release 1, Automatic Diagnostic Repository (ADR) is a
file-based repository for database diagnostic data such as traces, incident dumps, packages,
the alert log, Health Monitor reports, core dumps, and so on. The traditional …_DUMP_DEST
initialization parameters are ignored. The ADR root directory is known as the ADR base. Its
location is set by the DIAGNOSTIC_DEST initialization parameter. In the slide, this location is
denoted by $ADR_HOME. However, there is no official environment variable called ADR_HOME.
The table shown in the slide describes the different classes of trace data and dumps that
reside both in Oracle Database 10g (and earlier releases) and in Oracle Database 11g. With
Oracle Database 11g, there is no distinction between foreground and background trace files.
Both types of files go into the $ADR_HOME/trace directory. You can use V$DIAG_INFO to
list some important ADR locations.
All nonincident traces are stored inside the TRACE subdirectory. Starting with Oracle Database
11g, critical error information is dumped into the corresponding process trace files instead of
incident dumps. Incident dumps are placed in files separated from the normal process trace
files.
Note: The main difference between a trace and a dump is that a trace is a continuous output,
such as when SQL tracing is turned on, and a dump is a one-time output in response to an
event, such as an incident. Also, a core dump is a binary memory dump that is port specific.
Location for Diagnostic Traces
Diagnostic Data Previous Location ADR Location
Foreground process
traces
USER_DUMP_DEST $ADR_HOME/trace
Background process
traces
BACKGROUND_DUMP_DEST $ADR_HOME/trace
Alert log data BACKGROUND_DUMP_DEST $ADR_HOME/alert
$ADR_HOME/trace
Core dumps CORE_DUMP_DEST $ADR_HOME/cdump
Incident dumps USER_DUMP_DEST
BACKGROUND_DUMP_DEST
$ADR_HOME/incident/incdir_n
$ADR_HOME/trace
Oracle Database 11g trace – critical error trace
<=
V$DIAG_INFO
DIAGNOSTIC_DEST
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 7
What Is a Service?

What Is a Service?
The concept of a service was first introduced in Oracle8i as a means for the listener to
perform connection load balancing between nodes and instances of a cluster. However, the
concept, definition, and implementation of services have been dramatically expanded. A
service organizes work execution within the database to make it more manageable,
measurable, tunable, and recoverable. A service is a grouping of related tasks within the
database with common functionality, quality expectations, and priority relative to other
services. A service provides a single-system image for managing competing applications that
run within a single instance and across multiple instances and databases.
Services can be configured, administered, enabled, disabled, and measured as a single entity
using standard interfaces, Enterprise Manager, and SRVCTL,.
Services provide availability. Following outages, a service is recovered quickly and
automatically at surviving instances.
Services provide an additional dimension to performance tuning. With services, workloads are
visible and measurable. Tuning by “service and SQL” replaces tuning by “session and SQL” in
the majority of systems where sessions are anonymous and shared.
From a tracing point of view, a service provides a handle that permits capturing trace
information by service name regardless of the session.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 8
Using Services with Client Applications

Using Services with Client Applications
A service name is used by any client connecting to the database server. That service name is
automatically applied to the client actions. Applications can be grouped by services by simply
using a different service name for each application to connect.
Applications and middle-tier connection pools select a service by using the Transparent
Network Substrate (TNS) connection descriptor.
The selected service must match the service that has been created.
The first example in the slide shows the TNS connect descriptor that can be used to access
the ERP service.
The second example shows the thick Java Database Connectivity (JDBC) connection
description using the previously defined TNS connect descriptor.
The third example shows the thin JDBC connection description using the same TNS connect
descriptor.
Using 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)))"
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 9
Tracing Services

Tracing Services
An application can qualify a service by MODULE and ACTION names to identify the important
transactions within the service. This enables you to locate the poorly performing transactions
for categorized workloads. This is important when you monitor performance in systems using
connection pools or transaction processing monitors. For these systems, the sessions are
shared, which makes accountability difficult. SERVICE_NAME, MODULE, ACTION,
CLIENT_IDENTIFIER, and SESSION_ID are actual columns in V$SESSION.
SERVICE_NAME is set automatically at login time based on the connect descriptor, and
SESSION_ID is automatically set by the database when a session is created. MODULE and
ACTION names are set by the application by using the DBMS_APPLICATION_INFO PL/SQL
package or special Oracle Call Interface (OCI) calls. MODULE should be set to a name that is
recognizable by the user for the program that currently executes. Likewise, ACTION should be
set to a specific action or task that a user performs within a module (for example, entering a
new customer). CLIENT_IDENTIFIER can be set using the
DBMS_SESSION.SET_IDENTIFIER procedure.
The traditional method of tracing each session produces trace files with SQL commands that
may contain the trace information for multiple end users or applications. Unless all database
sessions are being traced, some information from the end user sessions may be missed. This
results in a hit-or-miss approach to diagnose problematic SQL.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 10
With the criteria that you provide (SERVICE_NAME, MODULE, or ACTION), specific trace
information is captured in a set of trace files and combined into a single output trace file. This
enables you to produce trace files that contain SQL that is relevant to a specific workload. It is
also possible to do the same for CLIENT_IDs and SESSION_IDs.
Note: DBA_ENABLED_TRACES displays information about enabled traces.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 11
Use Enterprise Manager to Trace Services

Use Enterprise Manager to Trace Services
On the Performance page, you can click the Top Consumers link. The Top Consumers page
is displayed.
The Top Consumers page has several tabs for displaying your database as a single-system
image. The Overview tabbed page contains four pie charts: Top Clients, Top Services, Top
Modules, and Top Actions. Each chart provides a different perspective about the top resource
consumers in your database.
The Top Services tabbed page displays performance-related information for the services that
are defined in your database. On this page, you can enable or disable tracing at the service
level.
Use Enterprise Manager to Trace Services
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 12
Service Tracing: Example

Service Tracing: Example
In the first code box, all sessions that log in under the AP service are traced. A trace file is
created for each session that uses the service, regardless of the module and action. You can
also enable tracing for specific tasks within a service. This is illustrated in the second
example, where all sessions of the AP service that execute the QUERY_DELINQUENT action
within the PAYMENTS module are traced.
Tracing by service, module, and action enable you to focus your tuning efforts on specific
SQL, rather than sifting through trace files with SQL from different programs. Only the SQL
statements that are identified with this MODULE and ACTION are recorded in the trace file. With
this feature, relevant wait events for a specific action can be identified.
You can also start tracing for a particular client identifier as shown by the third example. In this
example, C4 is the client identifier for which SQL tracing is to be enabled. The TRUE argument
specifies that wait information is present in the trace file. The FALSE argument specifies that
bind information is not present in the trace file.
Although not shown in the slide, you can use the CLIENT_ID_TRACE_DISABLE procedure to
disable tracing globally for the database for a given client identifier. To disable tracing, for the
previous example, execute the following command:
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'C4');
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 13
Note: CLIENT_IDENTIFIER can be set using the DBMS_SESSION.SET_IDENTIFIER
procedure.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 14
Session Level Tracing: Example

Session Level Tracing: Example
You can use tracing to debug performance problems. Trace-enabling procedures have been
implemented as part of the DBMS_MONITOR package. These procedures enable tracing
globally for a database.
You can use the DATABASE_TRACE_ENABLE procedure to enable session level SQL tracing
instance-wide. The procedure has the following parameters:
• WAITS: Specifies whether wait information is to be traced
• BINDS: Specifies whether bind information is to be traced
• INSTANCE_NAME: Specifies the instance for which tracing is to be enabled. Omitting
INSTANCE_NAME means that the session-level tracing is enabled for the whole
database.
Use the DATABASE_TRACE_DISABLE procedure to disable SQL tracing for the whole
database or a specific instance.
Similarly, you can use the SESSION_TRACE_ENABLE procedure to enable tracing for a given
database session identifier on the local instance. The SID and SERIAL# information can be
found from V$SESSION.
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 15
Use the SESSION_TRACE_DISABLE procedure to disable the trace for a given database
session identifier and serial number.
Note: SQL Trace involves some overhead, so you usually do not want to enable SQL Trace at
the instance level.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 16
Trace Your Own Session

Trace Your Own Session
Although the DBMS_MONITOR package can be invoked only by a user with the DBA role, any
user can enable SQL tracing for his or her own session by using the DBMS_SESSION
package. The SESSION_TRACE_ENABLE procedure can be invoked by any user to enable
session level SQL tracing for his or her own session. An example is shown in the slide.
You can then use the DBMS_SESSION.SESSION_TRACE_DISABLE procedure to stop
dumping to your trace file.
The TRACEFILE_IDENTIFIER initialization parameter specifies a custom identifier that
becomes part of the Oracle trace file name. You can use such a custom identifier to identify a
trace file simply from its name and without opening it or view its contents. Each time this
parameter is dynamically modified at the session level, the next trace dump written to a trace
file will have the new parameter value embedded in its name. This parameter can only be
used to change the name of the foreground process trace file; the background processes
continue to have their trace files named in the regular format. For foreground processes, the
TRACEID column of the V$PROCESS view contains the current value of this parameter. When
this parameter value is set, the trace file name has the following format:
sid_ora_pid_traceid.trc.
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';
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 17
The trcsess Utility

The trcsess Utility
The trcsess utility consolidates trace output from selected trace files on the basis of several
criteria: session ID, client identifier, service name, action name, and module name. After
trcsess merges the trace information into a single output file, the output file can be
processed by tkprof.
When using the DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE procedure, tracing
information is present in multiple trace files and you must use the trcsess tool to collect it
into a single file.
The trcsess utility is useful for consolidating the tracing of a particular session or service for
performance or debugging purposes.
Tracing a specific session is usually not a problem in the dedicated server model because a
single dedicated process serves a session during its lifetime. All the trace information for the
session can be seen from the trace file belonging to the dedicated server that serves it.
However, tracing a service might become a complex task even in the dedicated server model.
Moreover, in a shared-server configuration, a user session is serviced by different processes
from time-to-time. The trace pertaining to the user session is scattered across different trace
files belonging to different processes. This makes it difficult to get a complete picture of the life
cycle of a session.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 18
Invoking the trcsess Utility

Invoking the trcsess Utility
The syntax for the trcsess utility is shown in the slide, where:
• output specifies the file where the output is generated. If this option is not specified,
standard output is used for the output.
• session consolidates the trace information for the session specified. The session
identifier is a combination of session index and session serial number, such as 21.2371.
You can locate these values in the V$SESSION view.
• clientid consolidates the trace information for the given client identifier.
• service consolidates the trace information for the given service name.
• action consolidates the trace information for the given action name.
• module consolidates the trace information for the given module name.
• <trace file names> is a list of all the trace file names, separated by spaces, in
which trcsess should look for trace information. The wildcard character “*” can be
used to specify the trace file names. If trace files are not specified, all the files in the
current directory are taken as input to trcsess. You can find trace files in ADR.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 19
Note: One of the session, clientid, service, action, or module options must be
specified. If there is more than one option specified, the trace files, which satisfy all the criteria
specified are consolidated into the output file.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 20
The trcsess Utility: Example

The trcsess Utility: Example
The example in the slide illustrates a possible use of the trcsess utility. The example
assumes that you have three different sessions: Two sessions that are traced (left and right),
and one session (center) that enables or disables tracing and concatenates trace information
from the previous two sessions.
The first and second session set their client identifier to the ‘HR session’ value. This is
done using the DBMS_SESSION package. Then, the third session enables tracing for these
two sessions using the DBMS_MONITOR package.
At that point, two new trace files are generated in ADR; one for each session that is identified
with the ‘HR session’ client identifier.
Each traced session now executes its SQL statements. Every statement generates trace
information in its own trace file in ADR.
Then, the third session stops trace generation using the DBMS_MONITOR package, and
consolidates trace information for the ‘HR session’ client identifier in the mytrace.trc
file. The example assumes that all trace files are generated in the
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace directory, which is the default in most
cases.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 21
SQL Trace File Contents

SQL Trace File Contents
As seen already, a SQL trace file provides performance information on individual SQL
statements. It generates the following statistics for each statement:
• 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 data for each SQL statement, and a summary for each trace file
If the cursor for the SQL statement is closed, SQL Trace also provides row source information
that includes:
• Row operations showing the actual execution plan of each SQL statement
• Number of rows, number of consistent reads, number of physical reads, number of
physical writes, and time elapsed for each operation. This is possible only when the
STATISTICS_LEVEL initialization parameter is set to ALL.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 22
Note: Using the SQL Trace facility can have a severe performance impact and may result in
increased system overhead, excessive CPU usage, and inadequate disk space.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 23
SQL Trace File Contents: Example

SQL Trace File Contents: Example
There are multiple types of trace files that can be generated by the Oracle Database. The one
that is referred to in this lesson is generally called a SQL trace file. The slide shows you a
sample output from the mytrace.trc SQL trace file generated by the previous example.
In this type of trace file, you can find (for each statement that was traced) the statement itself,
with some corresponding cursor details. You can see statistic details for each phase of the
statement’s execution: PARSE, EXEC, and FETCH. As you can see, you can have multiple
FETCH for one EXEC depending on the number of rows returned by your query.
Last part of the trace is the execution plan with some cumulated statistics for each row source.
Depending on the way you enabled tracing, you can also obtain information about wait events
and bind variables in the generated trace files.
Generally, you do not try to interpret the trace file itself. This is because you do not get an
overall idea of what your sessions did. For example, one session could have executed the
same statement multiple times at different moments. The corresponding traces are then
scattered across the entire trace file, which makes them hard to find.
Instead, you use another tool, such as tkprof to interpret the contents of the raw trace
information.
SQL Trace File Contents: Example
*** [ Unix process pid: 15911 ]
*** 2010-07-29 13:43:11.327
*** 2010-07-29 13:43:11.327
*** 2010-07-29 13:43:11.327
*** 2010-07-29 13:43:11.327

====================
PARSING IN CURSOR #2 len=23 dep=0 uid=85 oct=3 lid=85 tim=1280410994003145 hv=40
69246757 ad='4cd57ac0' sqlid='f34thrbt8rjt5'
select * from employees
END OF STMT
PARSE #2:c=3000,e=2264,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=1445457117,
tim=1280410994003139
EXEC #2:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1445457117,
tim=1280410994003312
FETCH #2:c=0,e=215,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,plh=1445457117,
tim=1280410994003628
FETCH #2:c=0,e=89,p=0,cr=5,cu=0,mis=0,r=15,dep=0,og=1,plh=1445457117,
tim=1280410994004232

FETCH #2:c=0,e=60,p=0,cr=1,cu=0,mis=0,r=1,dep=0,og=1,plh=1445457117,
tim=1280410994107857
STAT #2 id=1 cnt=107 pid=0 pos=1 obj=73933 op='TABLE ACCESS FULL EMPLOYEES (cr=15
pr=0 pw=0 time=0 us cost=3 size=7383 card=107)'
XCTEND rlbk=0, rd_only=1, tim=1280410994108875
=====================
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 24
Formatting SQL Trace Files: Overview

Formatting SQL Trace Files: Overview
The tkprof utility parses SQL trace files to produce more readable output. Remember that
all the information in tkprof is available from the raw trace file. There is a huge number of
sort options that you can invoke with tkprof at the command prompt. A useful starting point
is the fchela sort option, which orders the output by elapsed time fetching. The resultant file
contains the most time-consuming SQL statement at the start of the file. Another useful
parameter is SYS=NO. This can be used to prevent SQL statements run as the SYS user from
being displayed. This can make the output file much shorter and easier to manage.
After a number of SQL trace files have been generated, you can perform any of the following:
• Run tkprof on each individual trace file, producing a number of formatted output files,
one for each session.
• Concatenate the trace files, and then run tkprof on the result to produce a formatted
output file for the entire instance.
• Run the trcsess command-line utility to consolidate tracing information from several
trace files, then run tkprof on the result.
tkprof does not report COMMITs and ROLLBACKs that are recorded in the trace file.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 25
Note: Set the TIMED_STATISTICS parameter to TRUE when tracing sessions because no
time-based comparisons can be made without this. TRUE is the default value with Oracle
Database 11g.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 26
Invoking the tkprof Utility

Invoking the tkprof Utility
When you enter the tkprof command without any arguments, it generates a usage message
together with a description of all tkprof options. The various arguments are shown in the
slide:
• inputfile: Specifies the SQL trace input file
• outputfile: Specifies the file to which tkprof writes its formatted output
• waits: Specifies whether to record the summary for any wait events found in the trace
file. Values are YES or NO. The default is YES.
• sorts: Sorts traced SQL statements in the descending order of specified sort option
before listing them into the output file. If more than one option is specified, the output is
sorted in the descending order by the sum of the values specified in the sort options. If
you omit this parameter, tkprof lists statements into the output file in the order of first
use.
• print: Lists only the first integer sorted SQL statements from the output file. If you omit
this parameter, tkprof lists all traced SQL statements. This parameter does not affect
the optional SQL script. The SQL script always generates insert data for all traced SQL
statements.
Invoking the tkprof Utility
tkprof inputfile outputfile [waits=yes|no]
[sort=option]
[print=n]
[aggregate=yes|no]
[insert=sqlscriptfile]
[sys=yes|no]
[table=schema.table]
[explain=user/password]
[record=statementfile]
[width=n]
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 27
• aggregate: If set to NO, tkprof does not aggregate multiple users of the same SQL
text.
• insert: Creates a SQL script to store the trace file statistics in the database. tkprof
creates this script with the name you specify for sqlscriptfile. This script creates a
table and inserts a row of statistics for each traced SQL statement into the table.
• sys: Enables and disables the listing of SQL statements issued by the SYS user, or
recursive SQL statements, into the output file. The default value of YES causes tkprof
to list these statements. The value of NO causes tkprof to omit them. This parameter
does not affect the optional SQL script. The SQL script always inserts statistics for all
traced SQL statements, including recursive SQL statements.
• table: Specifies the schema and name of the table into which tkprof temporarily
places execution plans before writing them to the output file. If the specified table
already exists, tkprof deletes all rows in the table, uses it for the EXPLAIN PLAN
statement (which writes more rows into the table), and then deletes those rows. If this
table does not exist, tkprof creates it, uses it, and then drops it. The specified user
must be able to issue INSERT, SELECT, and DELETE statements against the table. If the
table does not already exist, the user must also be able to issue the CREATE TABLE
and DROP TABLE statements. This option allows multiple individuals to run tkprof
concurrently with the same user in the EXPLAIN value. These individuals can specify
different TABLE values and avoid destructively interfering with each other’s processing
on the temporary plan table. If you use the EXPLAIN parameter without the TABLE
parameter, tkprof uses the PROF$PLAN_TABLE table in the schema of the user
specified by the EXPLAIN parameter. If you use the TABLE parameter without the
EXPLAIN parameter, tkprof ignores the TABLE parameter. If no plan table exists,
tkprof creates the PROF$PLAN_TABLE table and then drops it at the end.
• explain: Determines the execution plan for each SQL statement in the trace file and
writes these execution plans to the output file. tkprof determines execution plans by
issuing the EXPLAIN PLAN statement after connecting to the system with the user and
password specified in this parameter. The specified user must have CREATE SESSION
system privileges. tkprof takes longer to process a large trace file if the EXPLAIN
option is used.
• record: Creates a SQL script with the specified file name statementfile with all the
nonrecursive SQL statements in the trace file. This can be used to replay the user
events from the trace file.
• width: An integer that controls the output line width of some tkprof output, such as
the explain plan. This parameter is useful for post-processing of tkprof output.
The input and output files are the only required arguments.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 28
tkprof Sorting Options

tkprof Sorting Options
The table lists all the sort options you can use with the sort argument of tkprof.
tkprof Sorting Options
Sort Option Description
prscnt Number of times parse was called
prscpu CPU time parsing
prsela Elapsed time parsing
prsdsk Number of disk reads during parse
prsqry Number of buffers for consistent read during parse
prscu Number of buffers for current read during parse
prsmis Number of misses in the library cache during parse
execnt Number of executes that were called
execpu CPU time spent executing
exeela Elapsed time executing
exedsk Number of disk reads during execute
exeqry Number of buffers for consistent read during execute
execu Number of buffers for current read during execute
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 29
tkprof Sorting Options

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

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 30
Output of the tkprof Command

Output of the tkprof Command
The tkprof output file lists the statistics for a SQL statement by the SQL processing step.
The step for each row that contains statistics is identified by the value of the call column.
PARSE This step translates the SQL statement into an execution plan and includes
checks for proper security authorization and checks for the existence of
tables, columns, and other referenced objects.
EXECUTE This step is the actual execution of the statement by the Oracle server.
For the INSERT, UPDATE, and DELETE statements, this step modifies the
data (including sorts when needed). For the SELECT statements, this step
identifies the selected rows.
FETCH This step retrieves rows returned by a query and sorts them when needed.
Fetches are performed only for the SELECT statements.
Note: The PARSE value includes both hard and soft parses. A hard parse refers to the
development of the execution plan (including optimization); it is subsequently stored in the
library cache. A soft parse means that a SQL statement is sent for parsing to the database,
but the database finds it in the library cache and only needs to verify things, such as access
rights. Hard parses can be expensive, particularly due to the optimization. A soft parse is
mostly expensive in terms of library cache activity 25
Output of the tkprof Command
• Text of the SQL statement
• Trace statistics (for statement and recursive calls)
separated into three SQL processing steps:
PARSE Translates the SQL statement into an execution plan
EXECUTE Executes the statement
(This step modifies the data for the INSERT, UPDATE,
and DELETE statements.)
FETCH
Retrieves the rows returned by a query
(Fetches are performed only for the SELECT
statements.)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 31
Output of the tkprof Command

Output of the tkprof Command (continued)
The output is explained on the following page.
Sample output is as follows:
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ---
Parse 1 0.03 0.06 0 0 0 0
Execute 1 0.06 0.30 1 3 0 0
Fetch 2 0.00 0.46 0 0 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ---
total 4 0.09 0.83 1 3 0 1
Next to the CALL column, tkprof displays the following statistics for each statement:
• Count: Number of times a statement was parsed, executed, or fetched (Check this
column for values greater than 1 before interpreting the statistics in the other columns.
Unless the AGGREGATE = NO option is used, tkprof aggregates identical statement
executions into one summary table.)
• CPU: Total CPU time in seconds for all parse, execute, or fetch calls
• Elapsed: Total elapsed time in seconds for all parse, execute, or fetch calls
Output of the tkprof Command
There are seven categories of trace statistics:
Count
Number of times the procedure was executed
CPU
Number of seconds to process
Elapsed
Total number of seconds to execute
Disk
Number of physical blocks read
Query
Number of logical buffers read for consistent read
Current
Number of logical buffers read in current mode
Rows
Number of rows processed by the fetch or execute
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 32
• Disk: Total number of data blocks physically read from the data files on disk for all
parse, execute, or fetch calls
• Query: Total number of buffers retrieved in consistent mode for all parse, execute, or
fetch calls (Buffers are usually retrieved in consistent mode for queries.)
• Current: Total number of buffers retrieved in current mode (Buffers typically are
retrieved in current mode for data manipulation language statements. However, segment
header blocks are always retrieved in current mode.)
• Rows: Total number of rows processed by the SQL statement (This total does not
include rows processed by subqueries of the SQL statement. For SELECT statements,
the number of rows returned appears for the fetch step. For the UPDATE, DELETE, and
INSERT statements, the number of rows processed appears for the execute step.)
Note
• DISK is equivalent to physical reads from v$sysstat or AUTOTRACE.
• QUERY is equivalent to consistent gets from v$sysstat or AUTOTRACE.
• CURRENT is equivalent to db block gets from v$sysstat or AUTOTRACE.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 33
Output of the tkprof Command

Output of the tkprof Command (continued)
Recursive Calls
To execute a SQL statement issued by a user, the Oracle server must occasionally issue
additional statements. Such statements are called recursive SQL statements. For example, if
you insert a row in a table that does not have enough space to hold that row, the Oracle
server makes recursive calls to allocate the space dynamically. Recursive calls are also
generated when data dictionary information is not available in the data dictionary cache and
must be retrieved from disk.
If recursive calls occur while the SQL Trace facility is enabled, tkprof marks them clearly as
recursive SQL statements in the output file. You can suppress the listing of recursive calls in
the output file by setting the SYS=NO command-line parameter. Note that the statistics for
recursive SQL statements are always included in the listing for the SQL statement that caused
the recursive call.
Library Cache Misses
tkprof also lists the number of library cache misses resulting from parse and execute steps
for each SQL statement. These statistics appear on separate lines following the tabular
statistics.
Output of the tkprof Command
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: 85
Rows Row Source Operation
------- ---------------------------------------------------
5 TABLE ACCESS BY INDEX ROWID EMPLOYEES (cr=4 pr=1 pw=0 time=0 us …
5 INDEX RANGE SCAN EMP_NAME_IX (cr=2 pr=1 pw=0 time=80 us cost=1 …

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 34
Row Source Operations
These provide the number of rows processed for each operation executed on the rows and
additional row source information, such as physical reads and writes; cr = consistent reads,
w = physical writes, r = physical reads, time = time (in microseconds).
Parsing User ID
This is the ID of the last user to parse the statement.
Row Source Operation
The row source operation shows the data sources for execution of the SQL statement. This is
included only if the cursor has been closed during tracing. If the row source operation does
not appear in the trace file, you may then want to view the output of the EXPLAIN PLAN.
Execution Plan
If you specify the EXPLAIN parameter on the tkprof command line, tkprof uses the
EXPLAIN PLAN command to generate the execution plan of each SQL statement traced.
tkprof also displays the number of rows processed by each step of the execution plan.
Note: Be aware that the execution plan is generated at the time that the tkprof command is
run and not at the time the trace file was produced. This could make a difference if, for
example, an index has been created or dropped since tracing the statements.
Optimizer Mode or Hint
This indicates the optimizer hint that is used during the execution of the statement. If there is
no hint, it shows the optimizer mode that is used.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 35
tkprof Output with No Index: Example

tkprof Output with No Index: Example
The example in the slide shows that the aggregation of results across several executions
(rows) is being fetched from the CUSTOMERS table. It requires 0.12 second of CPU fetch time.
The statement is executed through a full table scan of the CUSTOMERS table, as you can see
in the row source operation of the output.
The statement must be optimized.
Note: If CPU or elapsed values are 0, timed_statistics is not set.
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.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.02 0.10 72 1459 0 1
------- ------ ------- --------- -------- -------- --------- ---------
total 4 0.02 0.10 72 1459 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=1459 pr=72 pw=0 time=0 us)
77 TABLE ACCESS FULL CUSTOMERS (cr=1459 pr=72 pw=0 time=4104 us
cost=405 size=1260 card=90)
...
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 36
tkprof Output with Index: Example

tkprof Output with Index: Example
The results shown in the slide indicate that CPU time was reduced to 0.01 second when an
index was created on the CUST_CITY column. These results may have been achieved
because the statement uses the index to retrieve the data. Additionally, because this example
reexecutes the same statement, most of the data blocks are already in memory. You can
achieve significant improvements in performance by indexing sensibly. Identify areas for
potential improvement using the SQL Trace facility.
Note: Indexes should not be built unless required. Indexes do slow down the processing of
the INSERT, UPDATE, and DELETE commands because references to rows must be added,
changed, or removed. Unused indexes should be removed. However, instead of processing
all the application SQL through EXPLAIN PLAN, you can use index monitoring to identify and
remove any indexes that are not used.
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.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 1 77 0 1
------- ------ -------- ---------- --------- --------- ---------- ----------
total 4 0.00 0.00 1 77 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=77 pr=1 pw=0 time=0 us)
77 TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=77 pr=1 pw=0 time=760 us
cost=85 size=1260 card=90)
77 INDEX RANGE SCAN CUST_CUST_CITY_IDX (cr=2 pr=1 pw=0 time=152 us
cost=1 size=0 card=90)(object id 78183)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 37
Quiz

Answer: b
Quiz
Which command would you use to create a trace file of your
SQL*Plus session in a dedicated server environment?
a. alter session set
tracefile_identifier='mytraceid';
b. EXEC
DBMS_SESSION.SESSION_TRACE_ENABLE(waits =>
TRUE, binds => FALSE);
c. trcsess output=mytrace.trc clientid='HR
session'
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.t
rc
d. tkprof *mytrace*.trc mytrace.txt SYS=NO
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 38
Quiz

Answer: b, c
Quiz
The _____ utility formats the trace file into a readable format.
a. trcsess
b. tkprof
c. SQL Developer
d. SQL*Plus Autotrace
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 39
Quiz

Answer: d
Quiz
In an environment with an applications server that uses a
connection pool, you will use ________ to identify which trace
files need to be combined to get an overall trace of the
application.
a. trcsess
b. tkprof
c. SQL Developer
d. DBMS_APPLICATION_INFO
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 40
Summary

Summary
In this lesson, you should have learned how to:
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 41
Practice 5: Overview


Practice 5: Overview
This practice covers the following topics:
• Creating a service
• Tracing your application using services
• Interpreting trace information using trcsess and tkprof
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 42

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 1
Optimizer Operators
Chapter 6

V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 2
Optimizer Operators

Optimizer Operators
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 3
Objectives

Objectives
This lesson helps you understand the execution plans that use operators related to table and
index access methods.
Objectives
After completing this lesson, you should be able to:
• Describe the SQL operators for tables and indexes
• List the possible access paths
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 4
Row Source Operations

Row Source Operations
A row source is a set of rows returned by a step in the execution plan. The row source can be
a table, view, or result of a join or grouping operation.
You can classify row sources as follows:
• Unary operations: Operations that act on only one input, such as an access path
• Binary operations: Operations that act on two inputs, such as joins
• N-ary operations: Operations that act on several inputs, such as a relational operator
Access paths are ways in which data is retrieved from the database. In general, index access
paths should be used for statements that retrieve a small subset of table rows, while full scans
are more efficient when accessing a large portion of the table. Online transaction processing
(OLTP) applications, which consist of short-running SQL statements with high selectivity, are
often characterized by the use of index access paths. Decision support systems (DSS), on the
other hand, tend to use partitioned tables and perform full scans of the relevant partitions.
Row Source Operations
• Unary operations
– Access Path
• Binary operations
– Joins
• N-ary operations
Ams row source is a set of rows returned by a step in the
execution plan .
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 5
Main Structures and Access Paths

Main Structures and Access Paths
Any row can be located and retrieved with one of the methods mentioned in the slide.
In general, index access paths should be used for statements that retrieve a small subset of
table rows, while full scans are more efficient when accessing a large portion of the table. To
decide on the alternative, the optimizer gives each alternative (execution plan) a cost. The one
with the lower cost is elected.
There are special types of table access paths including clusters, index-organized tables, and
partitions, which have not been mentioned in the slide.
Clusters are an optional method of storing table data. A cluster is a group of tables that share
the same data blocks because they share common columns and are often used together. For
example, the EMP and DEPT table share the DEPTNO column. When you cluster the EMP and
DEPT tables, Oracle physically stores all rows for each department from both the EMP and
DEPT tables in the same data blocks.
Hash clusters are single-table clusters in which rows with the same hash-key values are
stored together. A mathematical hash function is used to select the location of a row within the
cluster. All rows with the same key value are stored together on disk.
The special types of access paths are discussed later in this course.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 6
Full Table Scan

Full Table Scan
A full table scan sequentially reads all rows from a table and filters out those that do not meet
the selection criteria. During a full table scan, all formatted blocks in the table that are under
the high-water mark are scanned even if all the rows have been deleted from the table. Each
block is read only once. The high-water mark indicates the amount of used space, or space
that was formatted to receive data. Each row is examined to determine whether it satisfies the
statement’s WHERE clause using the applicable filter conditions specified in the query.
You can see the filter conditions in the “Predicate Information” section of the explain plan. The
filter to be applied returns only rows where EMP.ENAME='King'.
Because a full table scan reads all the formatted blocks in a table, it reads blocks that are
physically adjacent to each other. This means that performance benefits can be reaped by
utilizing input/output (I/O) calls that read multiple blocks at the same time. The size of the read
call can range from a single block to any number of blocks up to the
DB_FILE_MULTIBLOCK_READ_COUNT init parameter.
Note: In Oracle 6, a full table scan (FTS) could flood the buffer cache because there was no
difference in the way blocks were handled between FTS and other reads. Since Oracle V7,
blocks read by FTS are allowed to occupy only a small percentage of the buffer cache.
Currently, FTS are read into the PGA with direct reads bypassing the buffer cache in most
cases.
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
• Is faster than index
range scans for large amount of data
B B B B B B B B B
...
HWM
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 7
Full Table Scans: Use Cases

Full Table Scans: Use Cases
The optimizer uses a full table scan in any of the following cases:
• Lack of index: If the query is unable to use any existing indexes, it uses a full table scan
(unless a ROWID filter or a cluster access path is available). For example, if there is a
function used on the indexed column in the query, the optimizer cannot use the index
and instead uses a full table scan. If you need to use the index for case-independent
searches, either do not permit mixed-case data in the search columns or create a
function-based index, such as UPPER(last_name) on the search column.
• Large amount of data (low selectivity): If the optimizer thinks that the query accesses
enough blocks in the table, it may use a full table scan even though indexes might be
available.
• Small table: If a table contains less than DB_FILE_MULTIBLOCK_READ_COUNT blocks
under the high-water mark, a full table scan might be cheaper than an index range scan,
regardless of the fraction of tables being accessed or indexes present.
• High degree of parallelism: A high degree of parallelism for a table skews the
optimizer towards full table scans over range scans. Examine the DEGREE column in
ALL_TABLES for the table to determine the degree of parallelism.
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>)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 8
• Full table scan hints: Use the FULL(table alias) hint to instruct the optimizer to
use a full table scan.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 9
ROWID Scan

ROWID Scan
The rowid of a row specifies the data file and data block containing the row and the location of
the row in that block. Locating a row by specifying its rowid is the fastest way to retrieve a
single row because the exact location of the row in the database is specified.
To access a table by rowid, the system first obtains the rowids of the selected rows, either
from the statement’s WHERE clause or through an index scan of one or more of the table’s
indexes. The system then locates each selected row in the table based on its rowid.
Mostly, the optimizer uses rowids after retrieving them from an index (See the “Index Scans”
slides.). The table access might be required for columns in the statement that are not present
in the index. A table access by rowid does not need to follow every index scan. If the index
contains all the columns needed for the statement, table access by rowid might not occur.
Rowids are the system’s internal representation of where data is stored. Accessing data
based on position is not recommended because rows can move around due to row migration
and chaining, and also after export and import.
Note: Due to row migration, a rowid can sometimes point to an address different from the
actual row location, resulting in more than one block being accessed to locate a row. For
example, an update to a row may cause the row to be placed in another block with a pointer in
the original block. The rowid, however, still has only the address of the original block.
ROWID Scan
select * from scott.emp where rowid='AAAQ+LAAEAAAAAfAAJ';
------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 37 | 1|
| 1 | TABLE ACCESS BY USER ROWID| EMP | 1 | 37 | 1|
------------------------------------------------------------------
B B B B B
B
l
o
c
k

6
9
5
9

R
o
w

2
.
Row migration
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 10
Sample Table Scans

Sample Table Scans
A sample table scan retrieves a random sample of data from a simple table or a complex
SELECT statement, such as a statement involving joins and views. This access path is used
when a statement’s FROM clause includes the SAMPLE clause or the SAMPLE BLOCK clause.
To perform a sample table scan when sampling by rows with the SAMPLE clause, the system
reads a specified percentage of rows in the table. To perform a sample table scan when
sampling by blocks with the SAMPLE BLOCK clause, the system reads a specified percentage
of table blocks.
• SAMPLE option: To perform a sample table scan when sampling by rows, the system
reads a specified percentage of rows in the table and examines each of these rows to
determine whether it satisfies the statement’s WHERE clause.
• SAMPLE BLOCK option: To perform a sample table scan when sampling by blocks, the
system reads a specified percentage of the table’s blocks and examines each row in the
sampled blocks to determine whether it satisfies the statement’s WHERE clause.
The sample percent is a number specifying the percentage of the total row or block count to
be included in the sample. The sample value must be in the [0.000001 , 99.999999] range.
This percentage indicates the probability of each row, or each cluster of rows in the case of
block sampling, being selected as part of the sample. It does not mean that the database
retrieves exactly sample_percent of the rows of table.
Sample Table Scans
SELECT * FROM emp SAMPLE BLOCK (10) SEED (1);
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 99 | 2 (0)|
| 1 | TABLE ACCESS SAMPLE| EMP | 4 | 99 | 2 (0)|
---------------------------------------------------------------------
B B B B B
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 11
• SEED seed_value: Specify this clause to instruct the database to attempt to return the
same sample from one execution to the next. seed_value must be an integer between
0 and 4294967295. If you omit this clause, the resulting sample changes from one
execution to the next.
In row sampling, more blocks need to be accessed given a particular sample size, but the
results are usually more accurate. Block samples are less costly, but may be inaccurate; more
so with smaller samples.
Note: Block sampling is possible only during full table scans or index fast full scans. If a more
efficient execution path exists, Oracle Database does not perform block sampling. If you want
to guarantee block sampling for a particular table or index, use the FULL or INDEX_FFS hint.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 12
Indexes: Overview

Indexes: Overview
An index is an optional database object that is logically and physically independent of the
table data. Being independent structures, they require storage space. Just as the index of a
book helps you locate information fast, an Oracle Database index provides a faster access
path to table data. The Oracle Database may use an index to access data that is required by a
SQL statement, or it may use indexes to enforce integrity constraints. The system
automatically maintains indexes when the related data changes. You can create and drop
indexes at any time. If you drop an index, all applications continue to work. However, access
to previously indexed data might be slower. Indexes can be unique or
nonunique.
A composite index, also called a concatenated index, is an index that you create on multiple
columns (up to 32) in a table. Columns in a composite index can appear in any order and
need not be adjacent in the table.
For standard indexes, the database uses B*-tree indexes that are balanced to equalize
access times. B*-tree indexes can be normal, reverse key, descending, or function based.
• B*-tree indexes: They are by far the most common indexes. Similar in construct to a
binary tree, B*-tree indexes provide fast access, by key, to an individual row or range of
rows, normally requiring few reads to find the correct row. However, the “B” in “B*-tree”
does not stand for “binary,” but rather for “balanced.”
Indexes: Overview
Indexes
• 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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 13
• Descending indexes: Descending indexes allow for data to be sorted from “big to
small” (descending) instead of from “small to big” (ascending) in the index structure.
• Reverse key indexes: These are B*-tree indexes whereby the bytes in the key are
reversed. Reverse key indexes can be used to obtain a more even distribution of index
entries throughout an index that is populated with increasing values. For example, if you
use a sequence to generate a primary key, the sequence generates values such as
987500, 987501, 987502, and so on. With a reverse key index, the database logically
indexes 005789, 105789, 205789, and so on, instead of 987500, 987501, and 987502.
Because these reverse keys are now likely to be placed in different locations, this can
reduce contention for particular blocks that may otherwise be targets for contention.
However, only equality predicates can benefit from these indexes.
• Index key compression: The basic concept behind a compressed key index is that
every entry is broken into two—a prefix and a suffix component. The prefix is built on the
leading columns of the concatenated index and has many repeating values. The suffix is
built on the trailing columns in the index key and is the unique component of the index
entry within the prefix. This is not compression in the same manner that ZIP files are
compressed; rather, this is an optional compression that removes redundancies from
concatenated (multicolumn) indexes.
• Function-based indexes: These are B*-tree or bitmap indexes that store the computed
result of a function on a row’s column or columns, and not the column data itself. You
can consider them as indexes on a virtual (derived or hidden) column. In other words, it
is a column that is not physically stored in the table. You can gather statistics on this
virtual column.
• Index-organized tables: These are tables stored in a B*-tree structure. While rows of
data in a heap organized table are stored in an unorganized fashion (data goes
wherever there is available space), data in an IOT is stored and sorted by a primary key.
IOTs behave like regular tables as far as your application is concerned.
• Bitmap indexes: In a normal B*-tree, there is a one-to-one relationship between an
index entry and a row, that is, an index entry points to a row. With bitmap indexes, a
single index entry uses a bitmap to point to many rows simultaneously. They are
appropriate for repetitive data (data with few distinct values relative to the total number
of rows in the table) that is mostly read-only. Bitmap indexes should never be considered
in an OLTP database for concurrency-related issues.
• Bitmap join indexes: A bitmap join index is a bitmap index for the join of two or more
tables. A bitmap join index can be used to avoid actual joins of tables, or to greatly
reduce the volume of data that must be joined, by performing restrictions in advance.
Queries using bitmap join indexes can be sped up using bit-wise operations.
• Application domain indexes: These are indexes you build with packages and store,
either in the database or even outside the database. You tell the optimizer how selective
your index is and how costly it is to execute, and the optimizer decides whether or not to
use your index based on that information.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 14
Normal B*-tree Indexes

Normal B*-tree Indexes
Each B*-tree index has a root block as a starting point. Depending on the number of entries,
there are multiple branch blocks that can have multiple leaf blocks. The leaf blocks contain all
values of the index plus ROWIDs that point to the rows in the associated data segment.
Previous and next block pointers connect the leaf blocks so that they can be traversed from
left to right (and vice versa).
Indexes are always balanced, and they grow from the top down. In certain situations, the
balancing algorithm can cause the B*-tree height to increase unnecessarily. It is possible to
reorganize indexes. This is done by the ALTER INDEX … REBUILD | COALESCE command.
The internal structure of a B*-tree index allows rapid access to the indexed values. The
system can directly access rows after it has retrieved the address (the ROWID) from the index
leaf blocks.
Note: The maximum size of a single index entry is approximately one-half of the data block
size.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 15
Index Scans

Index Scans
An index scan can be one of the following types:
A row is retrieved by traversing the index, using the indexed column values specified by the
statement’s WHERE clause. An index scan retrieves data from an index based on the value of
one or more columns in the index. To perform an index scan, the system searches the index
for the indexed column values accessed by the statement. If the statement accesses only
columns of the index, the system reads the indexed column values directly from the index,
rather than from the table.
The index contains not only the indexed value, but also the rowids of rows in the table that
have the value. Therefore, if the statement accesses other columns in addition to the indexed
columns, the system can find the rows in the table by using either a table access by rowid or a
cluster scan.
Note: The graphic shows a case where four rows are retrieved from the table using their
rowids obtained by the index scan.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 16
Index Unique Scan

Index Unique Scan
An index unique scan returns, at most, a single ROWID. The system performs a unique scan if
a statement contains a UNIQUE or a PRIMARY KEY constraint that guarantees that only a
single row is accessed. This access path is used when all the columns of a unique (B*-tree)
index are specified with equality conditions.
Key values and ROWIDs are obtained from the index, and table rows are obtained using
ROWIDs.
You can look for access conditions in the “Predicate Information” section of the execution plan
(The execution plan is dealt with in detail in the lesson titled “Interpreting Execution Plans.”).
Here the system accesses only matching rows for which EMPNO=9999.
Note: Filter conditions filter rows after the fetch operation and output the filtered rows.
Index Unique Scan
create unique index PK_EMP on EMP(empno)
select * from emp where empno = 9999;
index UNIQUE Scan PK_EMP
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 17
Index Range Scan

Index Range Scan
An index range scan is a common operation for accessing selective data. It can be bounded
(on both sides) or unbounded (on one or both sides). Data is returned in the ascending order
of index columns. Multiple rows with identical values are sorted in the ascending order by
ROWID.
The optimizer uses a range scan when it finds one or more leading columns of an index
specified in conditions (the WHERE clause), such as col1 = :b1, col1 < :b1, col1 >
:b1, and any combination of the preceding conditions.
Wildcard searches (col1 like '%ASD') should not be in a leading position, as this does
not result in a range scan.
Range scans can use unique or nonunique indexes. Range scans can avoid sorting when
index columns constitute the ORDER BY/GROUP BY clause and the indexed columns are NOT
NULL as otherwise they are not considered.
An index range scan descending is identical to an index range scan, except that the data is
returned in the descending order. The optimizer uses index range scan descending when an
order by descending clause can be satisfied by an index.
Index Range Scan
create index I_DEPTNO on EMP(deptno);
select /*+ INDEX(EMP I_DEPTNO) */ *
from emp where deptno = 10 and sal > 1000;
Index Range SCAN I_DEPTNO
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 18
In the example in the slide, using index I_DEPTNO, the system accesses rows for which
EMP.DEPTNO=10. It gets their ROWIDs, fetches other columns from the EMP table, and finally,
applies the EMP.SAL >1000 filter from these fetched rows to output the final result.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 19
Index Range Scan: Descending

Index Range Scan: Descending
In addition to index range scans in ascending order, which are described in the previous slide,
the system is also able to scan indexes in the reverse order as illustrated by the graphic in the
slide.
The example retrieves rows from the EMP table by descending order on the DEPTNO column.
You can see the DESCENDING operation row source for ID 2 in the execution plan that
materialized this type of index scans.
Note: By default an index range scan is done in the ascending order.
Index Range Scan: Descending
select * from emp where deptno>20 order by deptno desc;
Index Range SCAN IDX
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 20
Descending Index Range Scan

Descending Index Range Scan
A descending index range scan is identical to an index range scan, except that the data is
returned in descending order. Descending indexes allow for data to be sorted from “big to
small” (descending) instead of “small to big” (ascending) in the index structure. Usually, this
scan is used when ordering data in a descending order to return the most recent data first, or
when seeking a value less than a specified value as in the example in the slide.
The optimizer uses descending index range scan when an order by descending clause can be
satisfied by a descending index.
The INDEX_DESC(table_alias index_name) hint can be used to force this access path
if possible.
Note: The system treats descending indexes as function-based indexes. The columns marked
DESC are stored in a special descending order in the index structure that is reversed again
using the SYS_OP_UNDESCEND function.
Descending Index Range Scan
drop index I_Deptno;
create index IX_D on EMP(deptno desc);
select * from emp where deptno <30;
Index Range SCAN IX_D
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 21
Index Range Scan: Function-Based

Index Range Scan: Function-Based
A function-based index can be stored as B*-tree or bitmap structures. These indexes include
columns that are either transformed by a function, such as the UPPER function, or included in
an expression, such as col1 + col2. With a function-based index, you can store
computation-intensive expressions in the index.
Defining a function-based index on the transformed column or expression allows that data to
be returned using the index when that function or expression is used in a WHERE clause or an
ORDER BY clause. This allows the system to bypass computing the value of the expression
when processing SELECT and DELETE statements. Therefore, a function-based index can be
beneficial when frequently-executed SQL statements include transformed columns, or
columns in expressions, in a WHERE or ORDER BY clause.
For example, function-based indexes defined with the UPPER(column_name) or
LOWER(column_name) keywords allow non-case-sensitive searches, such as shown in the
slide.
Index Range Scan: Function-Based
create index IX_FBI on EMP(UPPER(ename));
select * from emp where upper(ENAME) like 'A%';
Index Range SCAN IX_FBI
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 22
Index Full Scan

Index Full Scan
A full scan is available if a predicate references one of the columns in the index. The predicate
does not need to be an index driver (leading column). A full scan is also available when there
is no predicate, if both the conditions are met:
• All the columns in the table referenced in the query are included in the index.
• At least one of the index columns is not null.
A full scan can be used to eliminate a sort operation because the data is ordered by the index
key.
Note: An index full scan reads index using single-block input/output (I/O) (unlike a fast full
index scan).
Index Full Scan
create index I_DEPTNO on EMP(deptno);
select *
from emp
where sal > 1000 and deptno is not null
order by deptno;
index Full Scan I_DEPTNO
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 23
Index Fast Full Scan

Index Fast Full Scan
Index fast full scans are an alternative to full table scans when the index contains all the
columns that are needed for the query and at least one column in the index key has a NOT
NULL constraint. A fast full scan accesses the data in the index itself without accessing the
table.
It cannot be used to eliminate a sort operation because the data is not ordered by the index
key. It can be used for the min/avg/sum aggregate functions. In this case, the optimizer must
know that all table rows are represented in the index; at least one NOT NULL column.
This operation reads the entire index using multiblock reads (unlike a full index scan). Fast full
index scans cannot be performed against bitmap indexes. A fast full scan is faster than a
normal full index scan because it can use multiblock I/O just as a table scan.
You can specify fast full index scans with the OPTIMIZER_FEATURES_ENABLE initialization
parameter or the INDEX_FFS hint as shown in the slide example.
Note: Index fast full scans are used against an index when it is rebuilt offline.
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;
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 24
Index Skip Scan

Index Skip Scan
Index skip scans improve index scans by skipping blocks that could never contain keys
matching the filter column values. Scanning index blocks is often faster than scanning table
data blocks. Skip scanning can happen when the initial (leading) column of the composite
index is not specified in a query. Suppose that there is a concatenated index on the GENDER
and AGE columns in the EMPLOYEES table. This example illustrates how skip scanning is
processed to answer the query in the slide.
The system starts from the root of the index [R] and proceeds to the left branch block [B1].
From there, the system identifies a first entry to be F16, goes to the left leaf [L1], and starts to
scan it because it could contain A25 (that is, where the “gender” is before “F” in the alphabet).
The server identifies that this is not possible because the first entry is F10. It is thus not
possible to find an entry such as A25 in this leaf, so it can be skipped.
Backtracking to the first branch block [B1], the server identifies that the next subtree (F16)
does not need to be scanned because the next entry in [B1] is F20. Because the server is
certain that it is not possible to find a 25 between F16 and F20, the second leaf block [L2] can
be skipped.
Returning to [B1], the server finds that the next two entries have a common prefix of F2. This
identifies possible subtrees to scan. The system knows that these subtrees are ordered by
age.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 25
So the third and fourth leaf blocks [L3–L4] are scanned and some values are retrieved. By
looking at the fourth entry in the first branch block [B1], the system determines that it is no
longer possible to find an F2x entry. Thus, it is not necessary to scan that subtree [L5].
The same process continues with the right part of this index. Note that out of a total of 10 leaf
blocks, only five are scanned.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 26
Index Skip Scan: Example

Index Skip Scan: Example
The example in the slide finds employees who have salary less than 1500 using an index skip
scan.
It is assumed that there is a concatenated index on the DEPTNO and SAL columns.
As you can see, the query does not have a predicate on the DEPTNO leading column. This
leading column only has some discrete values, that is, 10, 20 and 30.
Skip scanning lets a composite index be split logically into smaller subindexes. The number of
logical subindexes is determined by the number of distinct values in the initial column.
The system pretends that the index is really three little index structures hidden inside one big
one. In the example, it is three index structures:
• where deptno = 10
• where deptno = 20
• where deptno = 30
The output is ordered by DEPTNO.
Note: Skip scanning is advantageous if there are few distinct values in the leading column of
the composite index and many distinct values in the nonleading key of the index.
Index Skip Scan: Example
create index IX_SS on EMP(DEPTNO,SAL);
select /*+ index_ss(EMP IX_SS) */ * from emp where SAL < 1500;
Index on (DEPTNO, SAL)
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 27
Index Join Scan

Index Join Scan
An index join is a hash join of several indexes that together contain all the table columns that
are referenced in the query. If an index join is used, no table access is needed because all the
relevant column values can be retrieved from the indexes. An index join cannot be used to
eliminate a sort operation.
The index join is not a real join operation (note that the example is a single table query), but is
built using index accesses followed by a join operation on rowid. The example in the slide
assumes that you have two separate indexes on the ENAME and SAL columns of the EMP
table.
Note: You can specify an index join with the INDEX_JOIN hint as shown in the example.
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 28
B*-tree Indexes and Nulls

B*-tree Indexes and Nulls
It is a common mistake to forget about nulls when dealing with B*-tree indexes. Single-column
B*-tree indexes do not store null values and so indexes on nullable columns cannot be used
to drive queries unless there is something that eliminates the null values from the query.
In the slide example, you create a table containing a nullable column called COL1, and COL2,
which cannot have null values. One index is built on top of each column.
The first query, retrieves all COL1 values. Because COL1 is nullable, the index cannot be used
without a predicate. Hinting the index on COL1 (nullind1) to force index utilization makes no
difference because COL1 is nullable. Because you only search for COL1 values, there is no
need to read the table itself.
However, with the second query, the effect of the predicate against COL1 is to eliminate nulls
from the data returned from the column. This allows the index to be used.
The third query can directly use the index because the corresponding column is declared NOT
NULL at table-creation time.
Note: The index could also be used by forcing the column to return only NOT NULL values
using the COL1 IS NOT NULL predicate.
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);
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 29
Using Indexes: Considering Nullable Columns

Using Indexes: Considering Nullable Columns
Some queries look as if they should use an index to compute a simple count of rows in the
table. This is typically more efficient that scanning the table. But the index to be used must not
be built on a column that can contain null values. Single-column B*-tree indexes never store
null values, so the rows are not represented in the index, and thus, do not contribute to the
COUNT being computed, for example.
In the example in the slide, there is a unique index on the SSN column of the PERSON table.
The SSN column is defined as allowing null values, and creating a unique index on it does
nothing to change that. This index is not used when executing the count query in the slide.
Any rows with null for SSN are not represented in the index, so the count across the index is
not necessarily accurate. This is one reason why it is better to create a primary key rather
than a unique index. A primary key column cannot contain null values. In the slide, after the
unique index is dropped in the place of designating a primary key, the index is used to
compute the row count.
Note: The PRIMARY KEY constraints combine a NOT NULL constraint and a unique
constraint in a single declaration.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 30
Index-Organized Tables

Index-Organized Tables
An index-organized table (IOT) is a table physically stored in a concatenated index structure.
The key values (for the table and the B*-tree index) are stored in the same segment. An IOT
contains:
• Primary key values
• Other (non-key) column values for the row
The B*-tree structure, which is based on the primary key of the table, is organized in the same
way as an index. The leaf blocks in this structure contain the rows instead of the ROWIDs. This
means that the rows in the IOT are always maintained in the order of the primary key.
You can create additional indexes on IOTs. The primary key can be a composite key.
Because large rows of an IOT can destroy the dense and efficient storage of the B*-tree
structure, you can store part of the row in another segment, which is called an overflow area.
Index-organized tables provide fast key-based access to table data for queries involving exact
match and range searches. Changes to the table data result only in updating the index
structure. Also, storage requirements are reduced because key columns are not duplicated in
the table and index. The remaining non-key columns are stored in the index structure. IOTs
are particularly useful when you use applications that must retrieve data based on a primary
key and have only a few, relatively short non-key columns.
Index-Organized Tables
Indexed
access on table
ROWID
Accessing
index-organized table
Row header
Non-key columns
Key column
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 31
Note: The descriptions mentioned here are correct if no overflow segments exist. Overflow
segments should be used with long rows.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 32
Index-Organized Table Scans

Index-Organized Table Scans
Index-organized tables are just like indexes. They use the same access paths that you saw for
normal indexes.
The major difference from a heap-organized table is that there is no need to access both an
index and a table to retrieve indexed data.
Note: SYS_IOT_TOP_75664 is the system-generated name of the segment used to store the
IOT structure. You can retrieve the link between the table name and the segment from
USER_INDEXES with these columns: INDEX_NAME, INDEX_TYPE, TABLE_NAME.
Index-Organized Table Scans
select * from iotemp where empno=9999;
select * from iotemp where sal>1000;
create table iotemp
( empno number(4) primary key, ename varchar2(10) not null,
job varchar2(9), mgr number(4), hiredate date,
sal number(7,2) not null, comm number(7,2), deptno number(2))
organization index;
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 33
Bitmap Indexes

Bitmap Indexes
In a B*-tree, there is a one-to-one relationship between an index entry and a row; an index
entry points to a row. A bitmap index is organized as a B*-tree index but, with bitmap indexes,
a single index entry uses a bitmap to point to many rows simultaneously. If a bitmap index
involves more than one column, there is a bitmap for every possible combination. Each bitmap
header stores start and end ROWIDs. Based on these values, the system uses an internal
algorithm to map bitmaps onto ROWIDs. This is possible because the system knows the
maximum possible number of rows that can be stored in a system block. Each position in a
bitmap maps to a potential row in the table even if that row does not exist. The contents of that
position in the bitmap for a particular value indicate whether that row has that value in the
bitmap columns. The value stored is 1 if the row values match the bitmap condition; otherwise
it is 0. Bitmap indexes are widely used in data warehousing environments. These
environments typically have large amounts of data and ad hoc queries, but no concurrent data
manipulation language (DML) transactions because when locking a bitmap, you lock many
rows in the table at the same time. For such applications, bitmap indexing provides reduced
response time for large classes of ad hoc queries, reduced storage requirements compared to
other indexing techniques, dramatic performance gains even on hardware with a relatively
small number of CPUs or a small amount of memory, and efficient maintenance during
parallel DML and loads.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 34
Note: Unlike most other types of indexes, bitmap indexes include rows that have NULL
values. Indexing of nulls can be useful for some types of SQL statements, such as queries
with the aggregate function COUNT. The IS NOT NULL predicate can also benefit from bitmap
indexes. Although bitmaps are compressed internally, they are split in multiple leaves if the
number of rows increases.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 35
Bitmap Index Access: Examples

Bitmap Index Access: Examples
The examples in the slide illustrate two possible access paths for bitmap indexes—BITMAP
INDEX SINGLE VALUE and BITMAP INDEX RANGE SCAN—depending on the type of
predicate you use in the queries.
The first query scans the bitmap for country “FR” for positions containing a “1.” Positions with
a “1” are converted into ROWIDs and have their corresponding rows returned for the query.
In some cases (such as a query counting the number of rows with COUNTRY FR), the query
might simply use the bitmap itself and count the number of 1s (not needing the actual rows).
This is illustrated in the following example:
SELECT count(*) FROM PERF_TEAM WHERE country>'FR';
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 | 2 (0)|
| 1 | SORT AGGREGATE | | 1 | 3 | |
| 2 | BITMAP CONVERSION COUNT | | 1 | 3 | 2 (0)|
| 3 | BITMAP INDEX RANGE SCAN| IX_B2 | | | |
Bitmap Index Access: Examples
SELECT * FROM PERF_TEAM WHERE country='FR';
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 45 |
| 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';
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 45 |
| 1 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | |
| 3 | BITMAP INDEX RANGE SCAN | IX_B2 | | |
---------------------------------------------------------------------
Predicate: 3 - access("COUNTRY">'FR') filter("COUNTRY">'FR')
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 36
----------------------------------------------------------------------------
Predicate: 3 - access("COUNTRY">'FR') filter("COUNTRY">'FR')
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 37
Combining Bitmap Indexes: Examples

Combining Bitmap Indexes: Examples
Bitmap indexes are the most effective for queries that contain multiple conditions in the WHERE
clause. Rows that satisfy some, but not all, conditions are filtered out before the table itself is
accessed. This improves response time, often dramatically. As the bitmaps from bitmap
indexes can be combined quickly, it is usually best to use single-column bitmap indexes.
Due to fast bit-and, bit-minus, and bit-or operations, bitmap indexes are efficient when:
• Using IN (value_list)
• Predicates are combined with AND or OR
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 38
Combining Bitmap Index Access Paths

Combining Bitmap Index Access Paths
Bitmap indexes can be used efficiently when a query combines several possible values for a
column or when two separately-indexed columns are used.
In some cases, a WHERE clause might reference several separately indexed columns as in the
examples shown in the slide.
If both the COUNTRY and GENDER columns have bitmap indexes, a bit-and operation on the
two bitmaps quickly locates the rows that you look for. The more complex the compound
WHERE clauses become, the more benefit you get from bitmap indexing.
Combining Bitmap Index Access Paths
SELECT * FROM PERF_TEAM WHERE country in ('FR','DE');
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
| 0 | SELECT STATEMENT | | 1 | 45 |
| 1 | INLIST ITERATOR | | | |
| 2 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 |
| 3 | BITMAP CONVERSION TO ROWIDS| | | |
| 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';
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
| 0 | SELECT STATEMENT | | 1 | 45 |
| 1 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | |
| 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')
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 39
Bitmap Operations

Bitmap Operations
The slide summarizes all the possible bitmap operations. The following operations have not
been explained so far:
• BITMAP CONVERSION FROM ROWID: B*-tree index converted by the optimizer into
BITMAP (cost is lower than other methods) to make these efficient bitmaps comparison
operations available. After the bitmap comparison has been done, the resultant bitmap is
converted back into ROWIDs (BITMAP CONVERSION TO ROWIDS) to perform the data
lookup.
• BITMAP MERGE merges several bitmaps resulting from a range scan into one bitmap.
• BITMAP MINUS is a dual operator that takes the second bitmap operation and negates
it by changing ones to zeros, and zeros to ones. The bitmap minus operation can then
be performed as a BITMAP AND operation using this negated bitmap. This would
typically be the case with the following combination of predicates: C1=2 and C2<>6.
• BITMAP KEY ITERATION takes each row from a table row source and finds the
corresponding bitmap from a bitmap index. This set of bitmaps is then merged into one
bitmap in a BITMAP MERGE operation.
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 40
Bitmap Join Index

Bitmap Join Index
In addition to a bitmap index on a single table, you can create a bitmap join index. A bitmap
join index is a bitmap index for the join of two or more tables. A bitmap join index is a space-
efficient way of reducing the volume of data that must be joined by performing the join in
advance. Note: Bitmap join indexes are much more efficient in storage than materialized join
views. For a row source example, see the lesson titled “Case Study: Star Transformation.”
Here, you create a new bitmap join index named cust_sales_bji on the SALES table. The
key of this index is the CUST_CITY column of the CUSTOMERS table. This example assumes
that there is an enforced primary key constraint on CUSTOMERS to ensure that what is stored
in the bitmap reflects the reality of the data in the tables. The CUST_ID column is the primary
key of CUSTOMERS, but is also a foreign key inside SALES, although not required.
The FROM and WHERE clause in the CREATE statement allow the system to make the link
between the two tables. They represent the join condition between the two tables. The middle
part of the graphic shows you a theoretical implementation of this bitmap join index. Each
entry or key in the index represents a possible city found in the CUSTOMERS table. A bitmap is
then associated to one particular key. Each bit in a bitmap corresponds to one row in the
SALES table. In the first key in the slide (Rognes), you see that the first row in the SALES table
corresponds to a product sold to a Rognes customer, while the second bit is not a product
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 41
sold to a Rognes customer. By storing the result of a join, the join can be avoided completely
for SQL statements using a bitmap join index.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 42
Composite Indexes

Composite Indexes
A composite index is also referred to as a concatenated index because it concatenates
column values together to form the index key value. In the illustration in the slide, the MAKE
and MODEL columns are concatenated together to form the index. It is not required that the
columns in the index are adjacent. And, you can include up to 32 columns in the index, unless
it is a bitmap composite index, in which case the limit is 30.
Composite indexes can provide additional advantages over single-column indexes:
• Improved selectivity: Sometimes two or more columns or expressions, each with poor
selectivity, can be combined to form a composite index with higher selectivity.
• Reduced I/O: If all columns selected by a query are in a composite index, the system
can return these values from the index without accessing the table.
A composite index is mainly useful when you often have a WHERE clause that references all,
or the leading portion of the columns in the index. If some keys are used in WHERE clauses
more frequently, and you decided to create a composite index, be sure to create the index so
that the more frequently selected keys constitute a leading portion for allowing the statements
that use only these keys to use the index.
Note: It is also possible for the optimizer to use a concatenated index even though your query
does not reference a leading part of that index. This is possible since index skip scans and
fast full scans were implemented.
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 |
-----------------------------------------------------------------
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 43
Invisible Index: Overview

Invisible Index: Overview
An invisible index is an index that is ignored by the optimizer unless you explicitly set the
OPTIMIZER_USE_INVISIBLE_INDEXES initialization parameter to TRUE at the session or
system level. The default value for this parameter is FALSE.
Making an index invisible is an alternative to making it unusable or dropping it. Using invisible
indexes, you can perform the following actions:
• Test the removal of an index before dropping it.
• Use temporary index structures for certain operations or modules of an application
without affecting the overall application.
Unlike unusable indexes, an invisible index is maintained during DML statements.
Invisible Index: Overview
INVISIBLE
Index
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
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 44
Invisible Indexes: Examples

Invisible Indexes: Examples
When an index is invisible, the optimizer selects plans that do not use the index. If there is no
discernible drop in performance, you can drop the index. You can also create an index initially
as invisible, perform testing, and then determine whether to make the index visible.
You can query the VISIBILITY column of the *_INDEXES data dictionary views to
determine whether the index is VISIBLE or INVISIBLE.
Note: For all the statements given in the slide, it is assumed that
OPTIMIZER_USE_INVISIBLE_INDEXES is set to FALSE.
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;
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 45
Guidelines for Managing Indexes

Guidelines for Managing Indexes
• Create indexes after inserting table data: Data is often inserted or loaded into a table
using either the SQL*Loader or an import utility. It is more efficient to create an index for
a table after inserting or loading the data.
• Index the correct tables and columns: Use the following guidelines for determining
when to create an index:
- Create an index if you frequently want to retrieve less than 15% of the rows in a
large table.
- To improve performance on joins of multiple tables, index the columns used for
joins.
- Small tables do not require indexes.
• Columns suitable for indexing: Some columns are strong candidates for indexing:
- Values are relatively unique in the column.
- There is a wide range of values (good for regular indexes).
- There is a small range of values (good for bitmap indexes).
- The column contains many nulls, but queries often select all rows having a value.
• Columns not suitable for indexing:
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 46
- There are many nulls in the column and you do not search on the not null values.
- The LONG and LONG RAW columns cannot be indexed.
- Virtual columns: You can create unique or nonunique indexes on virtual columns.
• Order index columns for performance: The order of columns in the CREATE INDEX
statement can affect query performance. In general, specify the most frequently used
columns first.
• Limit the number of indexes for each table: A table can have any number of indexes.
However, the more indexes there are, the more overhead is incurred as the table is
modified. Thus, there is a trade-off between the speed of retrieving data from a table and
the speed of updating the table.
• Drop indexes that are no longer required.
• Specify the tablespace for each index: If you use the same tablespace for a table and
its index, it can be more convenient to perform database maintenance, such as
tablespace backup.
• Consider parallelizing index creation: You can parallelize index creation, just as you
can parallelize table creation. This speeds up index creation. However, an index created
with an INITIAL value of 5M and a parallel degree of 12 consumes at least 60 MB of
storage during index creation.
• Consider creating indexes with NOLOGGING: You can create an index and generate
minimal redo log records by specifying NOLOGGING in the CREATE INDEX statement.
Because indexes created using NOLOGGING are not archived, perform a backup after
you create the index. Note that NOLOGGING is the default in a NOARCHIVELOG
database.
• Consider costs and benefits of coalescing or rebuilding indexes: Improper sizing or
increased growth can produce index fragmentation. To eliminate or reduce
fragmentation, you can rebuild or coalesce the index. But before you perform either task,
weigh the costs and benefits of each option, and select the one that works best for your
situation.
• Consider cost before disabling or dropping constraints: Because unique and
primary keys have associated indexes, you should factor in the cost of dropping and
creating indexes when considering whether to disable or drop a UNIQUE or PRIMARY
KEY constraint. If the associated index for a UNIQUE key or PRIMARY KEY constraint is
extremely large, you can save time by leaving the constraint enabled rather than
dropping and re-creating the large index. You also have the option of explicitly specifying
that you want to keep or drop the index when dropping or disabling a UNIQUE or
PRIMARY KEY constraint.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o
m
)

h
a
s

a

n
o
n
-
t
r
a
n
s
f
e
r
a
b
l
e

l
i
c
e
n
s
e
t
o

u
s
e

t
h
i
s

S
t
u
d
e
n
t

G
u
i
d
e

U
n
a
u
t
h
o
r
i
z
e
d

r
e
p
r
o
d
u
c
t
i
o
n

o
r

d
i
s
t
r
i
b
u
t
i
o
n

p
r
o
h
i
b
i
t
e
d


C
o
p
y
r
i
g
h
t
©

2
0
1
0
,

O
r
a
c
l
e

a
n
d
/
o
r

i
t
s

a
f
f
i
l
i
a
t
e
s


Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 47
Investigating Index Usage

Investigating Index Usage
You may often run a SQL statement expecting a particular index to be used, and it is not. This can be
because the optimizer is unaware of some information, or because it should not use the index.
Functions
If you apply a function to the indexed column in the WHERE clause, the index cannot be used; the index
is based on column values without the effect of the function. For example, the following statement does
not use an index on the salary column:
SELECT * FROM employees WHERE 1.10*salary > 10000
If you want an index to be used in this case, you can create a function-based index. Function-based
indexes were covered under “Index Range Scan: Function-Based” earlier in this lesson.
Data Type Mismatch
If there is a data type mismatch between the indexed column and the compared value, the index is not
used. This is due to the implicit data type conversion. For example, if the SSN column is of the
VARCHAR2 type, the following does not use the index on SSN:
SELECT * FROM person WHERE SSN = 123456789
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.
V
i
j
a
i

S
a
h
u

(
s
a
h
u
v
i
j
a
y
2
1
@
g
m
a
i
l

c
o