Professional Documents
Culture Documents
6 Oracle Database 11g SQL Tuning Workshop
6 Oracle Database 11g SQL Tuning Workshop
D69160
Edition 2.0
October 2010
D52163GC20
Student Guide
Tuning Workshop
SYSTOOLS
SYSTOOLS
SYSTOOLS
Disclaimer
This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and
SYSTOOLS
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.
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:
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
SYSTOOLS
Author
James Spiller, Tulika Srivastava
SYSTOOLS
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Table of Contents
Exploring the Oracle Database Architecture .................................................................................................1-1
SYSTOOLS
Exploring the Oracle Database Architecture ..................................................................................................1-2
Objectives ......................................................................................................................................................1-3
Oracle Database Server Architecture: Overview ............................................................................................1-4
Connecting to the Database Instance ............................................................................................................1-5
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Summary ........................................................................................................................................................2-38
Practice 2: Overview ......................................................................................................................................2-39
Introduction to the Optimizer ..........................................................................................................................3-1
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
The AUTOTRACE Syntax ..............................................................................................................................4-22
AUTOTRACE: Examples ...............................................................................................................................4-23
AUTOTRACE: Statistics .................................................................................................................................4-24
SYSTOOLS
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
SYSTOOLS
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
SYSTOOLS
tkprof Output with Index: Example .................................................................................................................5-36
Quiz................................................................................................................................................................5-37
Summary ........................................................................................................................................................5-40
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Nested Loops Join: Prefetching .....................................................................................................................7-7
Nested Loops Join: 11g Implementation ........................................................................................................7-8
Sort Merge Join ..............................................................................................................................................7-9
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Star Transformation Plan: Example 2 ............................................................................................................9-18
Star Transformation Hints ..............................................................................................................................9-19
Bitmap Join Indexes: Join Model 1.................................................................................................................9-20
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
SYSTOOLS
Bind Variables in Enterprise Manager ............................................................................................................11-8
Bind Variables in SQL Developer ...................................................................................................................11-9
Bind Variable Peeking ....................................................................................................................................11-10
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Practice 13: Overview ....................................................................................................................................13-21
Automating SQL Tuning ..................................................................................................................................14-1
Automating SQL Tuning .................................................................................................................................14-2
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Hints for Join Orders ......................................................................................................................................16-22
Hints for Join Operations ................................................................................................................................16-23
Additional Hints ..............................................................................................................................................16-25
SYSTOOLS
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
SYSTOOLS
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
SYSTOOLS
SYSTOOLS
SYSTOOLS
Preface
Profile
SYSTOOLS
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
Related Publications
Oracle Publications
Title Part Number
Oracle Database SQL Reference 11g Release 2 (11.2) E10592-04
SYSTOOLS
Oracle Database Performance Tuning Guide 11g Release 2 (11.2)E10821-05
Oracle SQL Developer User's Guide Release 2.1 E15222-02
SYSTOOLS
Typographic Conventions
The following two lists explain Oracle University typographical conventions for words that
appear within regular text or within code samples.
Convention SYSTOOLS
1. Typographic Conventions for words within regular text
SYSTOOLS
courses and Oracle SQL Reference Manual
manuals;
emphasized Do not save changes to the database.
words or phrases;
placeholders or Enter hostname, where hostname is the
variables host on which the password is to be changed
Quotation Lesson or module This subject is covered in Lesson 3, “Working with
marks title referenced Objects.”
within a course
SYSTOOLS
italic
Initial cap Forms triggers Form module: ORD
Trigger level: S_ITEM.QUANTITY
item
Trigger name: When-Validate-Item
. . .
Lowercase Column names, . . .
table names OG_ACTIVATE_LAYER
Filenames, (OG_GET_LAYER ('prod_pie_layer'))
PL/SQL objects . . .
SELECT last_name
FROM employees;
Bold Text that must be CREATE USER scott
entered by a user IDENTIFIED BY tiger;
SYSTOOLS
(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.
Notations:
(N) = Navigator
(M) = Menu
(T) = Tab
(B) = Button
(I) = Icon
(H) = Hyperlink
SYSTOOLS
(ST) = Sub Tab
SYSTOOLS
xiv
Oracle Database 11g: SQL Tuning Workshop Table of Contents
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
Objectives
This lesson provides an overview of the Oracle Database server architecture. You learn about
physical and logical structures and about the various components.
SYSTOOLS
SYSTOOLS
Oracle Database Server Architecture: Overview
SGA
SYSTOOLS Database
SYSTOOLS
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.
SYSTOOLS
Connecting to the Database Instance
Connection
SYSTOOLS
User Server SGA
SQL> Select … process process
Dedicated
User Server Server host
SYSTOOLS
•
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
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
SYSTOOLS
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:
SYSTOOLS
can connect to the same Oracle Database instance several times.
SYSTOOLS
SYSTOOLS
Oracle Database Memory Structures: Overview
Java Streams
pool pool
…
Server Server Background
SYSTOOLS
process process process
Aggregated
… …
PGA
Server
Database
process
buffer
cache
SYSTOOLS DBWn
Database writer
Data files process
SYSTOOLS
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.
Server
process Redo log
buffer
SYSTOOLS LGWR
Log writer
Redo log process
files
SYSTOOLS
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.
Shared Pool
SYSTOOLS
cache (row cache)
– Control structures
— Locks Control
structures
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
SYSTOOLS
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.
SYSTOOLS
Processing a DML Statement: Example
Database
2 4
2 buffer cache
Data Server Redo log
files process 3 buffer
Shared pool
5
Control 1 Library cache
files
SYSTOOLS
User
process
Redo
log files
SYSTOOLS
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).
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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
COMMIT Processing: Example
Database
buffer cache
Data Server Redo log
files process 1 buffer
SGA
Shared pool
3
Control Library cache
files
SYSTOOLS
User
process
Redo
log files LGWR 2
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Large Pool
SYSTOOLS
– Parallel execution
– Recovery Manager
– Shared server
I/O buffer
Response
queue
Free
memory
Request
queue
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
SYSTOOLS
• 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.
• Shared server: In a shared server architecture, the session memory for each client
process is included in the shared pool.
SYSTOOLS
SYSTOOLS
SYSTOOLS
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.
•
SYSTOOLS
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.
Background Process
Database
SGA Redo log
buffer Shared pool
buffer
cache
SYSTOOLS
CKPT PMON SMON DBWn LGWR ARCn
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
SYSTOOLS
• 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
• 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
SYSTOOLS
• Manageability monitoring process (MMON): Performs manageability-related
background tasks
• Memory Manager background process (MMAN): Used to manage SGA and PGA
SYSTOOLS
SYSTOOLS
SYSTOOLS
Automatic Shared Memory Management
SYSTOOLS
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.
SYSTOOLS
Automated SQL Execution Memory Management
Server
process
Server
process
… Background
process
Aggregated
… PGA …
SYSTOOLS
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.
SYSTOOLS
Automatic Memory Management
MMAN
Streams pool
Buffer cache
Shared pool
SYSTOOLS
Large pool
Other SGA
Untunable
Java pool
SQL areas
Private
Free
PGA
MEMORY_TARGET + STATISTICS_LEVEL
SYSTOOLS
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.
SYSTOOLS
Parameter file Backup files Archived redo log
files
SYSTOOLS
• 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.
• 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.
SYSTOOLS
• 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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Logical and Physical Database Structures
Database
Only 1 with
bigfile
tablespaces
Schema Tablespace Data file
0, 1, or many
Undo tablespaces
never have 0 Segment
SYSTOOLS
Extent
Oracle data
OS block
block
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
SYSTOOLS
to simplify some administrative operations. You may have a tablespace for different
applications.
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,
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
clusters, and database links. In general, schema objects include everything that your
application creates in the database.
Data Blocks
SYSTOOLS
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
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,
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
Segment Extents Data
blocks
Disk
blocks
SYSTOOLS
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.
SYSTOOLS
SYSTEM and SYSAUX Tablespaces
SYSTOOLS
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).
SYSTOOLS
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.
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 1: Overview
SYSTOOLS
Practice 1: Overview
SYSTOOLS
SYSTOOLS
Chapter 2 - Page 2
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
Objectives
This lesson gives you an understanding of the tuning process and the different components of
an Oracle Database that may require tuning.
SYSTOOLS
SYSTOOLS
Reasons for Inefficient SQL Performance
SYSTOOLS
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
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
4
WHERE to_char(salary) = :sal
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
SYSTOOLS
This is better queried as:
SELECT * FROM employees
WHERE salary = TO_NUMBER(:sal)
SYSTOOLS
SYSTOOLS
SYSTOOLS
Performance Monitoring Solutions
Fore-
Automatic
60 min
Snapshots
Snapshots ADDM
Alerts AST
Statspack
SYSTOOLS
ASH: Active Session History
ADDM
results AWR report
SYSTOOLS
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.
SYSTOOLS
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
SYSTOOLS
Note: Accessing Enterprise Manager or tools discussed here may require additional licenses
and certain privileges generally reserved for database administrators.
SYSTOOLS
SYSTOOLS
Monitoring and Tuning Tools: Overview
Base/
SYSTOOLS
Optimizer SQL Service
Segment Histograms Metrics ASH
statistics statistics statistics Compared
statistics periods
System
Wait Time OS ASH
Session Alerts
model model statistics report
statistics
Note
•
SYSTOOLS
SPA stands for SQL Performance Analyzer.
SYSTOOLS
EM Performance Pages for Reactive Tuning
Wait
class Top Top Top Top Top Top Top
SYSTOOLS
details SQL Sessions Services Modules Actions Files Objects
SPA
SYSTOOLS
SYSTOOLS
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.
SYSTOOLS
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
discovered by the optimizer will be stored in the SQL plan history, but will not be used until
they are approved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
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:
SYSTOOLS
• 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.
SYSTOOLS
CPU and Wait Time Tuning Dimensions
CPU
time Possibly
needs SQL Scalable
tuning application
SYSTOOLS
Scalable Needs No gain achieved
application instance/RAC by adding
tuning CPUs/nodes
Wait
time
SYSTOOLS
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.
SYSTOOLS
Scalability with Application Design,
Implementation, and Configuration
SYSTOOLS
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Common Mistakes on Customer Systems
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
SYSTOOLS
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
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
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
SYSTOOLS
instead of reactively. These are discussed in more detail in the following slides.
SYSTOOLS
Simplicity in Application Design
SYSTOOLS
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.
•
•
SYSTOOLS
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.
Data Modeling
SYSTOOLS
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.
SYSTOOLS
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.
Table Design
SYSTOOLS
– Partitioning
• Focus on business-critical tables
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.
SYSTOOLS
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.
Index Design
SYSTOOLS
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
SYSTOOLS
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.
Using Views
SYSTOOLS
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
SYSTOOLS
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.
SYSTOOLS
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
SYSTOOLS
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.
• 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
SYSTOOLS
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
SYSTOOLS
SYSTOOLS
SYSTOOLS
– Object references
– Bind variables
SYSTOOLS
(OCI) calls.
• 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
SYSTOOLS
with a schema name.
SYSTOOLS
Performance Checklist
SYSTOOLS
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.
SYSTOOLS
•
• 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.
SYSTOOLS
Development Environments: Overview
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
SYSTOOLS
•
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.
SYSTOOLS
SQL Developer
SYSTOOLS
• 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.
SYSTOOLS
• 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.
• For more information about how to use SQL*Plus, see the SQL*Plus User's Guide and
Reference.
SYSTOOLS
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b, c
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 2: Overview
SYSTOOLS
Practice 2: Overview
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
Structured Query Language
SYSTOOLS
COMMIT COMMENT
ROLLBACK
SAVEPOINT SessionCS
SET TRANSACTION
ALTER SESSION
SystemCS SET ROLE
ALTER SYSTEM
SYSTOOLS
• 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.
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.
SYSTOOLS
SYSTOOLS
SYSTOOLS Shared
SQL area
Shared
SQL area
SYSTOOLS
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.
SGA
SYSTOOLS
Shared Shared
SQL area SQL area
Library cache Java pool
Buffer cache
Data dictionary Result cache Other
cache
Redo log SHARED_POOL
buffer Streams pool
SYSTOOLS
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.
SYSTOOLS
SQL Statement Processing: Overview
PARSE
yes yes
query? describe? DESCRIBE
no no
no yes
more?
DEFINE
no yes
more?
yes
no yes
reparse? bind? BIND
no
no yes
more?
PARALLELIZE
SYSTOOLS
EXECUTE
yes
query? FETCH
no
CLOSE
SYSTOOLS
SYSTOOLS
SQL Statement Processing: Steps
SYSTOOLS
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
Steps 3 and 4: Describe and Define
SYSTOOLS
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
SYSTOOLS
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.
SYSTOOLS
Steps 5 and 6: Bind and Parallelize
SYSTOOLS
– DELETE
– CREATE
– ALTER
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
SYSTOOLS
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 7 Through 9
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
SQL Statement Processing PL/SQL: Example
SYSTOOLS
SQL> variable r number
SQL> execute :r := dbms_sql.execute(:c1);
SQL> variable r number
SQL> execute :r := dbms_sql.close_cursor(:c1);
SYSTOOLS
against a remote database.
SYSTOOLS
SQL Statement Parsing: Overview
Privileges check
Private Parse
SQL area Allocate private SQL Area call
Parsed representation
SYSTOOLS
Existing shared No Parse operation
(Hard parse) (Optimization)
SQL area?
Allocate shared SQL area
Yes (Soft parse)
Shared
Execute statement SQL area
SYSTOOLS
• 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.
• 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.
SYSTOOLS
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
SYSTOOLS
SYSTOOLS
Schema
How to retrieve these rows? information
Possible access paths
Read
Use the
index. 1 each row
and check.
SYSTOOLS
Statistics Which one is faster? 2
SYSTOOLS
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.
Schema
How to retrieve these rows? information
Possible access paths
Read
Use the
index. 1 each row
and check.
SYSTOOLS
Statistics Which one is faster? 2
SYSTOOLS
SYSTOOLS
Optimization During Hard Parse Operation
Optimizer
Transformer
Statistics
Estimator Dictionary
CBO
Plan Generator
Shared
SQL area
SYSTOOLS
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.
SYSTOOLS
Transformer: OR Expansion Example
SELECT *
FROM emp
WHERE job = 'CLERK' OR deptno = 10;
• Equivalent transformed query:
SELECT *
FROM emp
SYSTOOLS
WHERE job = 'CLERK'
UNION ALL
SELECT *
FROM emp
WHERE deptno = 10 AND job <> 'CLERK';
SYSTOOLS
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.
SYSTOOLS
Transformer: Subquery Unnesting Example
SELECT accounts.*
SYSTOOLS
FROM accounts, customers
WHERE accounts.custno = customers.custno;
SYSTOOLS
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.
SYSTOOLS
Transformer: View Merging Example
SYSTOOLS
SELECT empno
FROM emp
WHERE deptno = 10 AND empno > 7800;
SYSTOOLS
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.
• SYSTOOLS
Transformer: Predicate Pushing Example
Original query: Index
SYSTOOLS
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 );
SYSTOOLS
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.
SYSTOOLS
Transformer: Transitivity Example
SELECT *
FROM emp, dept
WHERE emp.deptno = 20 AND emp.deptno = dept.deptno;
• Equivalent transformed query:
SELECT *
FROM emp, dept
SYSTOOLS
WHERE emp.deptno = 20 AND emp.deptno = dept.deptno
AND dept.deptno = 20;
SYSTOOLS
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.
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
SYSTOOLS
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.
Estimator: Selectivity
SYSTOOLS
– 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,…)
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
SYSTOOLS
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.
Note: It is important to have histograms in columns that contain values with large variations in
the number of duplicates (data skew).
SYSTOOLS
SYSTOOLS
Estimator: Cardinality
SYSTOOLS
– 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)
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.
SYSTOOLS
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: Cost
SYSTOOLS
#SRds*sreadtim + #MRds*mreadtim + #CPUCycles/cpuspeed
Cost=
sreadtim
#SRds: Number of single block reads Sreadtim: Single block read time
#MRds: Number of multiblock reads Mreadtim: Multiblock read time
#CPUCycles: Number of CPU Cycles Cpuspeed: Millions instructions per second
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
SYSTOOLS
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).
Plan Generator
SYSTOOLS
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 |
+----------------------------------------------------------------+
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
SYSTOOLS
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.”
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Controlling the Behavior of the Optimizer
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
SYSTOOLS
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
SYSTOOLS
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
SYSTOOLS
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
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.
SYSTOOLS
• 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
SYSTOOLS
SYSTOOLS
SYSTOOLS
Controlling the Behavior of the Optimizer
SYSTOOLS
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.
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,
SYSTOOLS
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.
SYSTOOLS
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
SYSTOOLS
- 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.
SYSTOOLS
Optimizer Features and Oracle Database Releases
SYSTOOLS
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
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: d
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 3: Overview
SYSTOOLS
Practice 3: Overview
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
What Is an Execution Plan?
SYSTOOLS
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
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
The EXPLAIN PLAN results help you determine whether the optimizer selects a particular
execution plan, such as nested loops join.
SYSTOOLS
SYSTOOLS
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
• 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
SYSTOOLS
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
SYSTOOLS
SYSTOOLS
SYSTOOLS
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:
SYSTOOLS
• 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.
SYSTOOLS
The EXPLAIN PLAN Command
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
The EXPLAIN PLAN Command
SYSTOOLS
SYSTOOLS
The EXPLAIN PLAN Command: Example
Explained.
SQL>
SYSTOOLS
Note: The EXPLAIN PLAN command does not actually
execute the statement.
SYSTOOLS
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d
WHERE e.department_id =d.department_id;
PLAN_TABLE
SYSTOOLS
PLAN_TABLE
SYSTOOLS
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
SYSTOOLS
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.
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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Displaying from PLAN_TABLE: Typical
Explained.
SYSTOOLS
| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
SYSTOOLS
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
stored in PLAN_TABLE for the last statement explained. This script uses the DISPLAY table
function from the DBMS_XPLAN package.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Displaying from PLAN_TABLE: ALL
SYSTOOLS
---------------------------------------------------
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]
SYSTOOLS
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
SYSTOOLS
SYSTOOLS
SYSTOOLS
The EXPLAIN PLAN Command
SYSTOOLS
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.
SYSTOOLS
Displaying from PLAN_TABLE: ADVANCED
SYSTOOLS
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
*/
SYSTOOLS
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).
SYSTOOLS
Explain Plan Using SQL Developer
SYSTOOLS
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).
AUTOTRACE
SYSTOOLS
AUTOTRACE
SYSTOOLS
using bind peeking (recursive EXPLAIN PLAN)
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.
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
The AUTOTRACE Syntax
EXPLAIN
STATISTICS
SYSTOOLS
SHOW AUTOTRACE
SYSTOOLS
• 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.
AUTOTRACE: Examples
SYSTOOLS
AUTOTRACE: Examples
SYSTOOLS
SQL> set autotrace on statistics
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.
SYSTOOLS
• 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: Statistics
SYSTOOLS
AUTOTRACE: Statistics
SQL> show autotrace
Statistics
--------------------------------------------------------
1334 recursive calls
0 db block gets
686 consistent gets
394 physical reads
SYSTOOLS
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
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
SYSTOOLS
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.
SYSTOOLS
• 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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
AUTOTRACE Using SQL Developer
SYSTOOLS
SYSTOOLS
Using the V$SQL_PLAN View
SYSTOOLS
– ADDRESS, HASH_VALUE, and CHILD_NUMBER
SYSTOOLS
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.
SYSTOOLS
The V$SQL_PLAN Columns
SYSTOOLS
ID Number assigned to each step in the
execution plan
PLAN_HASH_VALUE Numerical representation of the SQL plan for the cursor
SYSTOOLS
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.
SYSTOOLS
The V$SQL_PLAN_STATISTICS View
SYSTOOLS
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
SYSTOOLS
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.
V$SQLSTATS
Estimated statistics
for each row source
V$SQL_PLAN
Execution statistics
for each row source
SYSTOOLS V$SQL_PLAN_STATISTICS
V$SQL_PLAN_STATISTICS_ALL
SYSTOOLS
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.
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.
SYSTOOLS
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
SYSTOOLS
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.
SYSTOOLS
Querying V$SQL_PLAN
SYSTOOLS
Querying V$SQL_PLAN
SYSTOOLS
|* 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.
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,
SYSTOOLS
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;
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.
SYSTOOLS
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
SYSTOOLS
•
keyword can be specified to see only the statistics for the last execution.
SYSTOOLS
SYSTOOLS
Automatic Workload Repository (AWR)
SYSTOOLS
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.
SYSTOOLS
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
SYSTOOLS
Enterprise Manager, you can manage the frequency and retention period of SQL that is stored
in the AWR.
SYSTOOLS
• Dropping snapshots:
SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE –
(low_snap_id => 22, high_snap_id => 32, dbid => 3310949047);
SYSTOOLS
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
SYSTOOLS
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
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:
SYSTOOLS
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
SYSTOOLS
=> 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.
SYSTOOLS
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
•
SYSTOOLS Querying the AWR
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
SQL_ID 454rug2yva18w
--------------------
select /* example */ * from hr.employees natural join hr.departments
----------------------------------------------------------------------------------
| 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 |
SYSTOOLS
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
SYSTOOLS
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 …
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
SYSTOOLS
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
SYSTOOLS
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’));
SYSTOOLS
SYSTOOLS
Generating SQL Reports from AWR Data
SYSTOOLS
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.
SYSTOOLS
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.
SQL monitoring
Every
second V$SQL_MONITOR
V$SQL_PLAN_MONITOR
SYSTOOLS
DBMS_SQLTUNE.REPORT_SQL_MONITOR
V$SQL
V$SQL_PLAN
V$ACTIVE_SESSION_HISTORY
V$SESSION_LONGOPS
V$SESSION
SYSTOOLS
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
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
SYSTOOLS
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:
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Monitoring Report: Example
Global Information
Status : EXECUTING
Instance ID : 1
Session ID : 125
SQL ID : fazrk33ng71km
SQL Execution ID : 16777216
Plan Hash Value : 1047182207
SYSTOOLS
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 |
------------------------------------------------------------
SYSTOOLS
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)
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Monitoring Report: Example
==================================================================================
Starts | Rows | Activity | Activity Detail | Progress |
SYSTOOLS
| (Actual) | (percent) | (sample #) | |
1 | | | | |
1 | | | | |
1 | 42081K | 100.00 | Cpu (4) | 74% |
==================================================================================
SYSTOOLS
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).
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.
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
id= 1 SYSTOOLS
(pid= )
Interpreting an Execution Plan
root/parent
Transform it into a tree.
SYSTOOLS
Parent/Child top/down Parent/Child
From left/right
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
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
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
Execution Plan Interpretation: Example 1
--------------------------------------------------
| Id | Operation | Name | FILTER 1
--------------------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | FILTER | |
| 2 | NESTED LOOPS | | NESTED
| 3 | TABLE ACCESS FULL | EMP | LOOPS 2 6
| 4 | TABLE ACCESS BY INDEX ROWID| DEPT |
|* 5 | INDEX UNIQUE SCAN | PK_DEPT |
TABLE ACCESS FULL
|* 6 | TABLE ACCESS FULL | SALGRADE | SALGRADE
--------------------------------------------------
3 4
SYSTOOLS
TABLE ACCESS
Predicate Information (identified by operation id): BY ROWID
--------------------------------------------------- DEPT
TABLE ACCESS FULL
EMP
1 - filter( NOT EXISTS
(SELECT 0 FROM "SALGRADE" "SALGRADE" WHERE
5
"HISAL">=:B1 AND "LOSAL"<=:B2))
5 - access("DEPT"."DEPTNO"="EMP"."DEPTNO")
INDEX UNIQUE SCAN
6 - filter("HISAL">=:B1 AND "LOSAL"<=:B2) PK_DEPT
SYSTOOLS
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.
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
SYSTOOLS
execution before ID=2 can be completed.
SYSTOOLS
SYSTOOLS
Execution Plan Interpretation: Example 1
SQL> alter session set statistics_level=ALL;
no rows selected
SYSTOOLS
--------------------------------------------------------------------------------
|* 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 |
--------------------------------------------------------------------------------
…
SYSTOOLS
• 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
at run time the system does the check for each distinct salary, and there are 12 distinct
salaries in the EMP table.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Execution Plan Interpretation: Example 2
0 SELECT STATEMENT
1 0 NESTED LOOPS 1
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 2 7
SYSTOOLS
7 1 TABLE ACCESS BY INDEX ROWID EMPLOYEES
8 7 INDEX UNIQUE SCAN EMP_EMP_ID_PK
3 5 8
4 6
SYSTOOLS
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.
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
SYSTOOLS
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.
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
Execution Plan Interpretation: Example 3
0 SELECT STATEMENT
1 SORT AGGREGATE 1
2 1 HASH JOIN
3 2 TABLE ACCESS FULL T3
4 2 HASH JOIN
5
6
4
4
TABLE ACCESS FULL T1
TABLE ACCESS FULL T2
2
3 4
SYSTOOLS 5 6
•
•
•
SYSTOOLS
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
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.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Reading More Complex Execution Plans
SYSTOOLS
Collapse using indentation
and
focus on operations consuming most resources.
SYSTOOLS
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.
SYSTOOLS
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:
SYSTOOLS
• 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.
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
SYSTOOLS
indexes available on the tables.
SYSTOOLS
SYSTOOLS
Looking Beyond Execution Plans
SYSTOOLS
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.
SYSTOOLS
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.
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 4: Overview
SYSTOOLS
Practice 4: Overview
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 1
Chapter 5
Application Tracing
Application Tracing
Application Tracing
Chapter 5 - Page 2
Application Tracing
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 3
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
End-to-End Application Tracing Challenge
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 4
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
End-to-End Application Tracing
SYSTOOLS
– Enterprise Manager
– DBMS_APPICATION_INFO, DBMS_SERVICE,
DBMS_MONITOR, DBMS_SESSION
– SQL Trace and trcsess utility
– tkprof
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 5
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
DIAGNOSTIC_DEST
Location for Diagnostic Traces
Incident dumps
SYSTOOLS
USER_DUMP_DEST $ADR_HOME/incident/incdir_n
BACKGROUND_DUMP_DEST
V$DIAG_INFO
$ADR_HOME/trace <= Oracle Database 11g trace – critical error trace
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 6
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
What Is a Service?
SYSTOOLS
• Is a handle for capturing trace information
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
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 7
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Using Services with Client Applications
url="jdbc:oracle:oci:@ERP"
SYSTOOLS
url="jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=mynode)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))"
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 8
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Tracing Services
SYSTOOLS
– SESSION_ID
– SERVICE_NAMES
– MODULE
– ACTION
– Combination of SERVICE_NAME, MODULE, ACTION
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,
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 9
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
Note: DBA_ENABLED_TRACES displays information about enabled traces.
SYSTOOLS
Application Tracing
Chapter 5 - Page 10
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Use Enterprise Manager to Trace Services
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 11
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(-
'AP', 'PAYMENTS', 'QUERY_DELINQUENT');
SYSTOOLS
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.
SYSTOOLS
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');
Application Tracing
Chapter 5 - Page 12
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 13
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Session Level Tracing: Example
EXEC dbms_monitor.DATABASE_TRACE_DISABLE();
SYSTOOLS
EXEC dbms_monitor.SESSION_TRACE_DISABLE(session_id
=>27, serial_num=>60);
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 14
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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
SYSTOOLS
the instance level.
SYSTOOLS
Application Tracing
Chapter 5 - Page 15
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• Disabling trace:
EXEC DBMS_SESSION.SESSION_TRACE_DISABLE();
SYSTOOLS
alter session set
tracefile_identifier='mytraceid';
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 16
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
The trcsess Utility
Client Client Client Clients
SYSTOOLS
trcsess TRCSESS
Report
file
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 17
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Invoking the trcsess Utility
SYSTOOLS TRCSESS
Consolidated
trace file
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 18
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 19
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
The trcsess Utility: Example
exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE( -
client_id=>'HR session', waits => FALSE, -
binds => FALSE); Third session
…
select * from employees;
SYSTOOLS
…
exec DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE( -
client_id => 'HR session');
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 20
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
•
SYSTOOLS
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
SYSTOOLS
• 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing
Chapter 5 - Page 21
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 22
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
SQL Trace File Contents: Example
SYSTOOLS
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
=====================
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 23
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Formatting SQL Trace Files: Overview
SYSTOOLS
Consolidated Concatenated
trace file tkprof trace file
Report
file
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 24
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 25
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Invoking the tkprof Utility
SYSTOOLS
[explain=user/password]
[record=statementfile]
[width=n]
SYSTOOLS
• 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.
Application Tracing
Chapter 5 - Page 26
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• 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
SYSTOOLS
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
SYSTOOLS
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.
•
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 27
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
tkprof Sorting Options
SYSTOOLS
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
SYSTOOLS
Application Tracing
Chapter 5 - Page 28
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
tkprof Sorting Options
SYSTOOLS
fchrow Number of rows fetched
userid User ID of user that parsed the cursor
SYSTOOLS
Application Tracing
Chapter 5 - Page 29
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Output of the tkprof Command
SYSTOOLS
FETCH Retrieves the rows returned by a query
(Fetches are performed only for the SELECT
statements.)
SYSTOOLS
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
Application Tracing
Chapter 5 - Page 30
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Output of the tkprof Command
SYSTOOLS
Current
Rows
Number of logical buffers read in current mode
SYSTOOLS
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
Application Tracing
Chapter 5 - Page 31
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• 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
SYSTOOLS
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.)
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.
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 32
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
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
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 33
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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.
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
SYSTOOLS
example, an index has been created or dropped since tracing the statements.
SYSTOOLS
Application Tracing
Chapter 5 - Page 34
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
tkprof Output with No Index: Example
SYSTOOLS
------- ---------------------------------------------------
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)
...
SYSTOOLS
The statement must be optimized.
Note: If CPU or elapsed values are 0, timed_statistics is not set.
Application Tracing
Chapter 5 - Page 35
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
tkprof Output with Index: Example
SYSTOOLS
------- ---------------------------------------------------
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)
SYSTOOLS
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.
Application Tracing
Chapter 5 - Page 36
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
rc SYSTOOLS
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.t
Answer: b
SYSTOOLS
Application Tracing
Chapter 5 - Page 37
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b, c
SYSTOOLS
Application Tracing
Chapter 5 - Page 38
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: d
SYSTOOLS
Application Tracing
Chapter 5 - Page 39
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 40
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Practice 5: Overview
SYSTOOLS
Practice 5: Overview
SYSTOOLS
SYSTOOLS
Application Tracing
Chapter 5 - Page 41
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Application Tracing
Chapter 5 - Page 42
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 1
Chapter 6
Optimizer Operators
Optimizer Operators
Optimizer Operators
Chapter 6 - Page 2
Optimizer Operators
Objectives
SYSTOOLS
Objectives
SYSTOOLS
Objectives
This lesson helps you understand the execution plans that use operators related to table and
index access methods.
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 3
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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
SYSTOOLS
• 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.
Optimizer Operators
Chapter 6 - Page 4
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Main Structures and Access Paths
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 5
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 6
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 7
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• Full table scan hints: Use the FULL(table alias) hint to instruct the optimizer to
use a full table scan.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 8
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
ROWID Scan
SYSTOOLS
ROWID Scan
------------------------------------------------------------------
| 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
SYSTOOLS
Block 6959–Row 2
Row migration
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 9
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 99 | 2 (0)|
| 1 | TABLE ACCESS SAMPLE| EMP | 4 | 99 | 2 (0)|
---------------------------------------------------------------------
SYSTOOLS
B B B B B
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 10
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• 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.
SYSTOOLS
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.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 11
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Indexes: Overview
SYSTOOLS
– Key compression
– Reverse key
– Ascending, descending
• Domain indexes: Specific to an application or cartridge
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
SYSTOOLS
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.”
Optimizer Operators
Chapter 6 - Page 12
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• 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
SYSTOOLS
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
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 13
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Root
Branch
SYSTOOLS
Key column length
Leaf Key column value
rowid
Table data retrieved by using rowid
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 14
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Index Scans
• Range (Descending)
• Skip
• Full and fast full
• Index join
B : block
Table EMP
SYSTOOLS
B B B B B B
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 15
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 16
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 17
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 18
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Index Range Scan: Descending
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 19
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Descending Index Range Scan
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 20
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Index Range Scan: Function-Based
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 21
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
select *
from emp
where sal > 1000 and deptno is not null
order by deptno; index Full Scan I_DEPTNO
SYSTOOLS
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.
SYSTOOLS
• 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).
Optimizer Operators
Chapter 6 - Page 22
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SH R L L L B L L B ... L
discard discard discard
SYSTOOLS
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.
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 23
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Min F16 F20 F26 F30 M10 M16 M20 M26 M30
F10 F16 F20 F26 F30 M10 M16 M20 M26 M30
F11 F17 F21 F27 F31 M11 M17 M21 M27 M31
F12 F18 F22 F28 F32 M12 M18 M22 M28 M32
SYSTOOLS
F13 F19 F23 F29 F33 M13 M19 M23 M29 M33
F14 F24 F34 M14 M24 M34
F15 F25 F35 M15 M25 M35
L1 L2 L3 L4 L5 L6 L7 L8 L9 L10
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 24
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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].
SYSTOOLS
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.
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 25
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
select /*+ index_ss(EMP IX_SS) */ * from emp where SAL < 1500;
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 26
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 27
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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,
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 28
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Using Indexes: Considering Nullable Columns
SYSTOOLS
SSN N
SELECT /*+ INDEX(person) */ COUNT(*) FROM
FNAME Y
LNAME N person;
SELECT STATEMENT |
SORT AGGREGATE |
PERSON INDEX FAST FULL SCAN| PK_SSN
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 29
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Index-Organized Tables
ROWID
Key column
Row header
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
SYSTOOLS
• 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.
Optimizer Operators
Chapter 6 - Page 30
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Note: The descriptions mentioned here are correct if no overflow segments exist. Overflow
segments should be used with long rows.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 31
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Index-Organized Table Scans
create table iotemp
( empno number(4) primary key, ename varchar2(10) not null,
SYSTOOLS
select * from iotemp where sal>1000;
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 32
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Bitmap Indexes
Table
Block 11
Block 12
SYSTOOLS
<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 End Bitmap
ROWID ROWID
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 33
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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
SYSTOOLS
number of rows increases.
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 34
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Bitmap Index Access: Examples
SYSTOOLS
---------------------------------------------------------------------
| 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')
SYSTOOLS
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 | | | |
Optimizer Operators
Chapter 6 - Page 35
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
----------------------------------------------------------------------------
Predicate: 3 - access("COUNTRY">'FR') filter("COUNTRY">'FR')
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 36
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Combining Bitmap Indexes: Examples
FR 0 0 1 1 1 1 0 0 0 0 0 0
OR 0 1 1 1 1 1 0 0 0 0 0
DE 0 1 0 0 0 0 0 0 0 0 0 0
F 0 0 1 1 1 1 0 0 0 0 0 0
SYSTOOLS AND
M 1 1 1 0 1 1 0 1 0 1 1 1
0 0 1 0 1 1 0 0 0 0 0
SYSTOOLS
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
Optimizer Operators
Chapter 6 - Page 37
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Combining Bitmap Index Access Paths
SYSTOOLS
| 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')
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 38
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Bitmap Operations
SYSTOOLS
• BITMAP MERGE
• BITMAP AND/OR
• BITMAP MINUS
• BITMAP KEY ITERATION
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 39
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
10.8000.3
<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…>
SYSTOOLS
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
Optimizer Operators
Chapter 6 - Page 40
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 41
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Composite Indexes
select *
from cars
where make = 'CITROËN' and model = '2CV';
-----------------------------------------------------------------
| Id | Operation | Name |
SYSTOOLS
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS |
|* 2 | INDEX RANGE SCAN | CARS_MAKE_MODEL_IDX |
-----------------------------------------------------------------
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.
•
SYSTOOLS
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators
Chapter 6 - Page 42
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
VISIBLE INVISIBLE
Index Index
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE
SYSTOOLS
Data view point
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 43
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
ALTER INDEX ind1 VISIBLE;
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 44
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Guidelines for Managing Indexes
•
SYSTOOLS
Consider costs and benefits of coalescing or rebuilding
indexes.
Consider cost before disabling or dropping constraints.
-
SYSTOOLS
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:
Optimizer Operators
Chapter 6 - Page 45
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
- 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.
SYSTOOLS
• 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.
SYSTOOLS
• 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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 46
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
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
SYSTOOLS
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.
Optimizer Operators
Chapter 6 - Page 47
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Old Statistics
The statistics are considered by the optimizer when deciding whether to use an index. If they
are outdated, they may influence the optimizer to make poor decisions about indexes.
SYSTOOLS
Null Columns
If a column can contain nulls, it may prevent the use of an index on that column. This is
covered later in this lesson.
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 48
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 49
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 50
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: c
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 51
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 52
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Practice 6: Overview
SYSTOOLS
Practice 6: Overview
SYSTOOLS
SYSTOOLS
Optimizer Operators
Chapter 6 - Page 53
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Optimizer Operators
Chapter 6 - Page 54
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Chapter 7 - Page 2
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
Objectives
This lesson helps you understand the execution plans related to join operations.
SYSTOOLS
Join Methods
SYSTOOLS
FROM dept d JOIN emp e USING (deptno) Join predicate
WHERE e.job = 'ANALYST' OR e.empno = 9999; Nonjoin predicate
SELECT e.ename,d.dname
FROM emp e, dept d
WHERE e.deptno = d.deptno AND Join predicate
(e.job = 'ANALYST' OR e.empno = 9999); Nonjoin predicate
Join Methods
A row source is a set of data that can be accessed in a query. It can be a table, an index, a
nonmergeable view, or even the result set of a join tree consisting of many different objects.
A join predicate is a predicate in the WHERE clause that combines the columns of two of the
tables in the join.
SYSTOOLS
A nonjoin predicate is a predicate in the WHERE clause that references only one table.
A join operation combines the output from two row sources (such as tables or views) and
returns one resulting row source (data set). The optimizer supports different join methods
such as the following:
• Nested loop join: Useful when small subsets of data are being joined and if the join
condition is an efficient way of accessing the second table
• Sort-merge join: Can be used to join rows from two independent sources. Hash joins
generally perform better than sort-merge joins. On the other hand, sort-merge joins can
perform better than hash joins if one or two row sources are already sorted.
• Hash join: Used for joining large data sets. The optimizer uses the smaller of two tables
or data sources to build a hash table on the join key in memory. It then scans the larger
table, probing the hash table to find the joined rows. This method is best used when the
smaller table fits in the available memory. The cost is then limited to a single read pass
over the data for the two tables.
Note: The slide shows you the same query using both the American National Standards
SYSTOOLS
Institute (ANSI) and non-ANSI join syntax. The ANSI syntax is the first example.
SYSTOOLS
IS
• Joining rows are then returned. For each
Inner
SYSTOOLS
| 0 | SELECT STATEMENT | | 2 | 4 |
| 1 | NESTED LOOPS | | 2 | 4 |
| 2 | TABLE ACCESS FULL | EMP | 2 | 2 |
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 1 |
| 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 | |
---------------------------------------------------------------------
2 - filter("E"."ENAME" LIKE 'A%')
4 - access("E"."DEPTNO"="D"."DEPTNO")
SYSTOOLS
Any nonjoin predicates on the inner table are considered after this initial retrieval, unless a
composite index combining both the join and the nonjoin predicate is used.
The code to emulate a nested loop join might look as follows:
for r1 in (select rows from EMP that match single table predicate) loop
for r2 in (select rows from DEPT that match current row from EMP) loop
output values from current row of EMP and current row of DEPT
end loop
end loop
The optimizer uses nested loop joins when joining small number of rows, with a good driving
condition between the two tables. You drive from the outer loop to the inner loop, so the order
of tables in the execution plan is important. Therefore, you should use other join methods
when two independent row sources are joined.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
TAF TAR
Driving
IRS
Inner
SYSTOOLS
| 0 | SELECT STATEMENT | | 2 | 84 | 5
| 1 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 22 | 1
| 2 | NESTED LOOPS | | 2 | 84 | 5
|* 3 | TABLE ACCESS FULL | EMP | 2 | 40 | 3
|* 4 | INDEX RANGE SCAN | IDEPT | 1 | | 0
---------------------------------------------------------------------
3 - filter("E"."ENAME" LIKE 'A%')
4 - access("E"."DEPTNO"="D"."DEPTNO")
SYSTOOLS
This optimization is only available when the inner access path is index range scan and not if
the inner access path is index unique scan.
The prefetching mechanism is used by table lookup. When an index access path is chosen
and the query cannot be satisfied by the index alone, the data rows indicated by the ROWID
also must be fetched. This ROWID to data row access (table lookup) is improved using data
block prefetching, which involves reading an array of blocks which are pointed at by an array
of qualifying ROWIDs.
Without data block prefetching, accessing a large number of rows using a poorly clustered B*-
tree index could be expensive. Each row accessed by the index would likely be in a separate
data block and thus would require a separate I/O operation.
With data block prefetching, the system delays data blocks reads until multiple rows specified
by the underlying index are ready to be accessed and then retrieves multiple data blocks
simultaneously, rather than reading a single data block at a time.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Nested Loops Join: 11g Implementation
NL
SYSTOOLS
Nested Loops Join: 11g Implementation
Oracle Database 11g introduces a new way of performing joins with NESTED LOOPS
operators. With this NESTED LOOPS implementation, the system first performs a NESTED
LOOPS join between the other table and the index. This produces a set of ROWIDs that you
can use to look up the corresponding rows from the table with the index. Instead of going to
the table for each ROWID produced by the first NESTED LOOPS join, the system batches up
SYSTOOLS
the ROWIDs and performs a second NESTED LOOPS join between the ROWIDs and the table.
This ROWID batching technique improves performance as the system only reads each block in
the inner table once.
•
SYSTOOLS Sort Merge Join
MJ
SYSTOOLS
Sort Merge Join
In a sort merge join, there is no concept of a driving table. A sort merge join is executed as
follows:
1. Get the first data set, using any access and filter predicates, and sort it on the join
columns.
SYSTOOLS
2. Get the second data set, using any access and filter predicates, and sort it on the join
columns.
3. For each row in the first data set, find the start point in the second data set and scan
until you find a row that does not join.
The merge operation combines the two sorted row sources to retrieve every pair of rows that
contain matching values for the columns used in the join predicate.
If one row source has already been sorted in a previous operation (there is an index on the
join column, for example), the sort merge operation skips the sort on that row source. When
you perform a merge join, you must fetch all rows from the two row sources before to return
the first row to the next operation. Sorting could make this join technique expensive, especially
if sorting cannot be performed in memory.
The optimizer can select a sort merge join over a hash join for joining large amounts of data if
any of the following conditions are true:
SYSTOOLS
condition (but not a nonequality), such as <, <=, >, or >=.
SYSTOOLS
Hash Join
SYSTOOLS
Hash Join
To perform a hash join between two row sources, the system reads the first data set and
builds an array of hash buckets in memory. A hash bucket is little more than a location that
acts as the starting point for a linked list of rows from the build table. A row belongs to a hash
bucket if the bucket number matches the result that the system gets by applying an internal
hashing function to the join column or columns of the row.
SYSTOOLS
The system starts to read the second set of rows, using whatever access mechanism is most
appropriate for acquiring the rows, and uses the same hash function on the join column or
columns to calculate the number of the relevant hash bucket. The system then checks to see
if there are any rows in that bucket. This is known as probing the hash table.
If there are no rows in the relevant bucket, the system can immediately discard the row from
the probe table.
If there are some rows in the relevant bucket, the system does an exact check on the join
column or columns to see if there is a proper match. Any rows that survive the exact check
can immediately be reported (or passed on to the next step in the execution plan). So, when
you perform a hash join, you must fetch all rows from the smallest row source to return the
first row to next operation.
Note: Hash joins are performed only for equijoins, and are most useful when joining large
amount of data.
Cartesian Join
SYSTOOLS
Cartesian Join
A Cartesian join is used when one or more of the tables does not have any join conditions to
any other tables in the statement. The optimizer joins every row from one data source with
every row from the other data source, creating the Cartesian product of the two sets.
A Cartesian join can be seen as a nested loop with no elimination; the first row source is read
and then for every row, all the rows are returned from the other row source.
SYSTOOLS
Note: Cartesian join is generally not desirable. However, it is perfectly acceptable to have one
with single-row row source (guaranteed by a unique index, for example) joined to some other
table.
Join Types
SYSTOOLS
Join Types
Join operation types include the following:
• Join (equijoin and nonequijoin): Returns rows that match predicate join
• Outer join: Returns rows that match predicate join and row when no match is found
• Semi join: Returns rows that match the EXISTS subquery. Find one match in the inner
SYSTOOLS
table, then stop search.
• Anti join: Returns rows with no match in the NOT IN subquery. Stop as soon as one
match is found.
• Star join: This is not a join type, but just a name for an implementation of a performance
optimization to better handle the fact and dimension model.
Antijoin and semijoin are considered to be join types, even though the SQL constructs that
cause them are subqueries. Antijoin and semijoin are internal optimizations algorithms used to
flatten subquery constructs in such a way that they can be resolved in a join-like way.
SYSTOOLS
Equijoins and Nonequijoins
The join condition determines whether a join is an equijoin or a nonequijoin. An equijoin is a
join with a join condition containing an equality operator. When a join condition relates two
tables by an operator other than equality, it is a nonequijoin.
Equijoins are the most commonly used. An example each of an equijoin and a nonequijoin are
shown in the slide. Nonequijoins are less frequently used.
SYSTOOLS
To improve SQL efficiency, use equijoins whenever possible. Statements that perform
equijoins on untransformed column values are the easiest to tune.
Note: If you have a nonequijoin, a hash join is not possible.
Outer Joins
SYSTOOLS
FROM emp e, dept d FROM emp e, dept d
WHERE e.deptno(+)=d.deptno;
WHERE e.deptno(+)=d.deptno;
2
3
Outer Joins
The simple join is the most commonly used within the system. Other joins open up extra
functionality, but have much more specialized uses. The outer join operator is placed on the
deficient side of the query. In other words, it is placed against the table that has the missing
join information. Consider EMP and DEPT. There may be a department that has no employees.
If EMP and DEPT are joined together, this particular department would not appear in the output
SYSTOOLS
because there is no row that matches the join condition for that department. By using the
outer join, the missing department can be displayed.
1. Merge Outer joins: By default, the optimizer uses MERGE OUTER JOIN.
2. Outer join with nested loops: The left/driving table is always the table whose rows are
being preserved (DEPT in the example). For each row from DEPT, look for all matching
rows in EMP. If none is found, output DEPT values with null values for the EMP columns. If
rows are found, output DEPT values with these EMP values.
3. Hash Outer joins: The left/outer table whose rows are being preserved is used to build
the hash table, and the right/inner table is used to probe the hash table. When a match
is found, the row is output and the entry in the hash table is marked as matched to a
row. After the inner table is exhausted, the hash table is read over once again, and any
rows that are not marked as matched are output with null values for the EMP columns.
The system hashes the table whose rows are not being preserved, and then reads the
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
table whose rows are being preserved, probing the hash table to see whether there was
a row to join to.
Note: You can also use the ANSI syntax for full, left, and right outer joins (not shown in the
SYSTOOLS
slide).
SYSTOOLS
Semijoins
SYSTOOLS Semijoins
SYSTOOLS
Semijoins
Semijoins return a result when you hit the first joining record. A semijoin is an internal way of
transforming an EXISTS subquery into a join. However, you cannot see this occur anywhere.
Semijoins return rows that match an EXISTS subquery without duplicating rows from the left
side of the predicate when multiple rows on the right side satisfy the criteria of the subquery.
SYSTOOLS
In the above diagram, for each DEPT record, only the first matching EMP record is returned as
a join result. This prevents scanning huge numbers of duplicate rows in a table when all you
are interested in is if there are any matches.
When the subquery is not unnested, a similar result could be achieved by using a FILTER
operation and scanning a row source until a match is found, then returning it.
Note: A semijoin can always use a Merge join. The optimizer may choose nested-loop, or
hash joins methods to perform semijoins as well.
Antijoins
SYSTOOLS Antijoins
SYSTOOLS
emp WHERE deptno IS NOT NULL);
EMP DEPT
Antijoins
Antijoins return rows that fail to match (NOT IN) the subquery at the right side. For example,
an antijoin can select a list of departments which do not have any employee.
The optimizer uses a merge antijoin algorithm for NOT IN subqueries by default. However, if
the HASH_AJ or NL_AJ hints are used and various required conditions are met, the NOT IN
uncorrelated subquery can be changed. Although antijoins are mostly transparent to the user,
SYSTOOLS
it is useful to know that these join types exist and could help explain unexpected performance
changes between releases.
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: d
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 7: Overview
SYSTOOLS
Practice 7: Overview
SYSTOOLS
SYSTOOLS
Chapter 8 - Page 2
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
Objectives
This lesson helps you understand the execution plans that use common operators of other
access methods.
SYSTOOLS
Clusters
SYSTOOLS Clusters
SYSTOOLS
Unclustered ORDERS and
ORDER_ITEMS tables
Clustered ORDERS and
ORDER_ITEMS tables
Clusters
Clusters are an optional method for 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 ORDERS and ORDER_ITEMS table share the ORDER_ID column. When you
cluster the ORDERS and ORDER_ITEMS tables, the system physically stores all rows for each
order from both the ORDERS and ORDER_ITEMS tables in the same data blocks.
SYSTOOLS
Cluster index: A cluster index is an index defined specifically for a cluster. Such an index
contains an entry for each cluster key value. To locate a row in a cluster, the cluster index is
used to find the cluster key value, which points to the data block associated with that cluster
key value. Therefore, the system accesses a given row with a minimum of two I/Os.
Hash clusters: Hashing is an optional way of storing table data to improve the performance
of data retrieval. To use hashing, you create a hash cluster and load tables into the cluster.
The system physically stores the rows of a table in a hash cluster and retrieves them
according to the results of a hash function. The key of a hash cluster (just as the key of an
index cluster) can be a single column or composite key. To find or store a row in a hash
cluster, the system applies the hash function to the row’s cluster key value; the resulting hash
value corresponds to a data block in the cluster, which the system then reads or writes on
behalf of the issued statement.
Note: Hash clusters are a better choice than using an indexed table or index cluster when a
table is queried frequently with equality queries.
SYSTOOLS
SYSTOOLS
SYSTOOLS
When Are Clusters Useful?
• Index clusters allow row data from one or more tables that share a cluster key value to
be stored in same block. You can locate these rows using a cluster index, which has one
entry per cluster key value and not for each row. Therefore, the index is smaller and less
costly to access for finding multiple rows. The rows with the same key are in a small
group of blocks. This means that in an index cluster the clustering factor is very good
SYSTOOLS
and provides clustering for data from multiple tables sharing the same join key. The
smaller index and smaller group of blocks reduce the cost of access by reducing block
visits to the buffer cache. Index clusters are useful when the size of the tables is not
known in advance (For example: Creating a new table rather than converting an existing
one whose size is stable) because a cluster bucket is only created after a cluster key
value is used. They are also useful for all filter operations or searches. Note that full
table scans do not perform well on a table in a multiple table cluster as it has more
blocks than the table would have if created as a heap table.
• Hash clusters allow row data from one or more tables that share a cluster key value to
be stored in same block. You can locate these rows using a system-provided or user-
provided hashing function or using the cluster key value assuming that this is already
evenly distributed making the access to a row faster than using index clusters. Table
rows with the same cluster key values hash into the same cluster buckets and can be
stored in the same block or small group of blocks.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
When Are Clusters Useful? (continued)
• This means that in a hash cluster the clustering factor is also very good and a row may
be accessed by its key with one block visit only and without needing an index. Hash
clusters allocate all the storage for all the hash buckets when the cluster is created, so
they may waste space. They also do not perform well other than on equality searches or
nonequality searches. Like index clusters if they contain multiple tables, full scans are
SYSTOOLS
more expensive for the same reason.
• Single-table hash clusters are similar to a hash cluster, but are optimized in the block
structures for access to a single table, thereby providing the fastest possible access to a
row other than by using a rowid filter. As they only have one table, full scans, if they
happen, cost as much as they would in a heap table.
• Sorted hash clusters are designed to reduce costs of accessing ordered data by using a
hashing algorithm on the hash key. Accessing the first row matching the hash key may
be less costly than using an IOT for a large table because it saves the cost of a B*-tree
probe. All the rows that match on a particular hash key (For example: Account number)
are stored in the cluster in the order of the sort key or keys (For example: Phone calls),
thereby, eliminating the need for a sort to process the order by clause. These clusters
are very good for batch reporting, billing, and so on.
SYSTOOLS
containing rows with that hash value.
The second one assumes that a cluster index was used to cluster both the EMP and DEPT
tables. In this case, a cluster scan is used to retrieve, from a table stored in an indexed
cluster, all rows that have the same cluster key value. In an indexed cluster, all rows with the
same cluster key value are stored in the same data block. To perform a cluster scan, the
system first obtains the ROWID of one of the selected rows by scanning the cluster index. The
system then locates the rows based on this ROWID.
Note: You see examples of how to create clusters in the labs for this lesson.
Sorting Operators
SYSTOOLS
• If you want ordered results, always use ORDER BY.
Sorting Operators
Sort operations result when users specify an operation that requires a sort. Commonly
encountered operations include the following:
• SORT AGGREGATE does not involve a sort. It retrieves a single row that is the result of
applying a group function to a group of selected rows. Operations such as COUNT and
SYSTOOLS
MIN are shown as SORT AGGREGATE.
• SORT UNIQUE sorts output rows to remove duplicates. It occurs if a user specifies a
DISTINCT clause or if an operation requires unique values for the next step.
• SORT JOIN happens during a sort-merge join, if the rows need to be sorted by the join
key.
• SORT GROUP BY is used when aggregates are computed for different groups in the
data. The sort is required to separate the rows into different groups.
• SORT ORDER BY is required when the statement specifies an ORDER BY that cannot be
satisfied by one of the indexes.
• HASH GROUP BY hashes a set of rows into groups for a query with a GROUP BY clause.
• HASH UNIQUE hashes a set of rows to eliminate duplicates. It occurs if a user specifies
a DISTINCT clause or if an operation requires unique values for the next step. This is
similar to SORT UNIQUE.
SYSTOOLS
Note: Several SQL operators cause implicit sorts (or hashes since Oracle Database 10g,
Release 2), such as DISTINCT, GROUP BY, UNION, MINUS, and INTERSECT. However, do
not rely on these SQL operators to return ordered rows. If you want to have rows ordered, use
the ORDER BY clause.
SYSTOOLS
SYSTOOLS
Buffer Sort Operator
The BUFFER SORT operator uses a temporary table or a sort area in memory to store
intermediate data. However, the data is not necessarily sorted.
The BUFFER SORT operator is needed if there is an operation that needs all the input data
before it can start. (See “Cartesian Join.”)
SYSTOOLS
So BUFFER SORT uses the buffering mechanism of a traditional sort, but it does not do the
sort itself. The system simply buffers the data, in the User Global Area (UGA) or Program
Global Area (PGA), to avoid multiple table scans against real data blocks.
The whole sort mechanism is reused, including the swap to disk when not enough sort area
memory is available, but without sorting the data.
The difference between a temporary table and a buffer sort is as follows:
• A temporary table uses System Global Area (SGA).
• A buffer sort uses UGA.
Inlist Iterator
SYSTOOLS
Inlist Iterator
It is used when a query contains an IN clause with values or multiple equality predicates on
the same column linked with ORs.
The INLIST ITERATOR operator iterates over the enumerated value list, and every value is
executed separately.
SYSTOOLS
The execution plan is identical to the result of a statement with an equality clause instead of
IN, except for one additional step. The extra step occurs when INLIST ITERATOR feeds the
equality clause with unique values from the list.
You can view this operator as a FOR LOOP statement in PL/SQL. In the example in the slide,
you iterate the index probe over two values: 1 and 2.
Also, it is a function that uses an index, which is scanned for each value in the list. An
alternative handling is UNION ALL of each value or a FILTER of the values against all the
rows, this is significantly more efficient.
The optimizer uses an INLIST ITERATOR when an IN clause is specified with values, and
the optimizer finds a selective index for that column. If there are multiple OR clauses using the
same index, the optimizer selects this operation rather than CONCATENATION or UNION ALL,
because it is more efficient.
View Operator
SYSTOOLS
View Operator
Each query produces a variable set of data in the form of a table. A view simply gives a name
to this set of data.
When views are referenced in a query, the system can handle them in two ways. If a number
of conditions are met, they can be merged into the main query. This means that the view text
is rewritten as a join with the other tables in the query. Views can also be left as standalone
SYSTOOLS
views and selected from directly as in the case of a table. Predicates can also be pushed into
or pulled out of the views as long as certain conditions are met.
When a view is not merged, you can see the VIEW operator. The view operation is executed
separately. All rows from the view are returned, and the next operation can be done.
Sometimes a view cannot be merged and must be executed independently in a separate
query block. In this case, you can also see the VIEW operator in the explain plan. The VIEW
keyword indicates that the view is executed as a separate query block. For example, views
containing GROUP BY functions cannot be merged.
The second example in the slide shows a nonmergeable inline view. An inline view is basically
a query within the FROM clause of your statement.
Basically, this operator collects all rows from a query block before they can be processed by
higher operations in the plan.
SYSTOOLS
Count Stop Key Operator
COUNT STOPKEY limits the number of rows returned. The limitation is expressed by the
ROWNUM expression in the WHERE clause. It terminates the current operation when the count is
reached.
Note: The cost of this operator depends on the number of occurrences of the values you try to
SYSTOOLS
retrieve. If the value appears very frequently in the table, the count is reached quickly. If the
value is very infrequent, and there are no indexes, the system has to read most of the table’s
blocks before reaching the count.
SYSTOOLS
Min/Max and First Row Operators
SYSTOOLS
Min/Max and First Row Operators
FIRST ROW retrieves only the first row selected by a query. It stops accessing the data after
the first value is returned. This is an optimization introduced in Oracle 8i and it works with the
index range scan and the index full scan.
In the example in the slide, it is assumed that there is an index on the quantity_on_hand
SYSTOOLS
column.
SYSTOOLS
SYSTOOLS
FILTER Operations
SYSTOOLS
FILTER Operations
SYSTOOLS 2
FILTER Operations
A FILTER operation is any operation that discards rows returned by another step, but is not
involved in retrieving the rows itself. All sorts of operations can be filters, including subqueries
and single table predicates.
In the example 1, FILTER applies to the groups that are created by the GROUP BY operation.
SYSTOOLS
In the example 2, FILTER is almost used in the same way as NESTED LOOPS. DEPT is
accessed once, and for each row from DEPT, EMP is accessed by its index on DEPTNO. This
operation is done as many times as the number of rows in DEPT.
The FILTER operation is applied, for each row, after DEPT rows are fetched. The FILTER
discards rows for the inner query returned at least one row (select 1 from emp e where
e.deptno=d.deptno) is TRUE.
Concatenation Operation
--------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 696 |
| 1 | CONCATENATION | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| EMP | 4 | 348 |
| 3 | INDEX RANGE SCAN | I_SAL | 2 | |
| 4 | TABLE ACCESS BY INDEX ROWID| EMP | 4 | 348 |
| 5 | INDEX RANGE SCAN | I_DEPTNO | 2 | |
SYSTOOLS
--------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("SAL"=2)
4 - filter(LNNVL("SAL"=2))
5 - access("DEPTNO"=1)
Concatenation Operation
CONCATENATION concatenates the rows returned by two or more row sets. This works like
UNION ALL and does not remove duplicate rows.
It is used with OR expansions. However, OR does not return duplicate rows, so for each
component after the first, it appends a negation of the previous components (LNNVL):
SYSTOOLS
CONCATENATION
- BRANCH 1 - SAL=2
- BRANCH 2 - DEPTNO = 1 AND NOT row in Branch 1
The LNNVL function is generated by the OR clause to process this negation.
The LNNVL() function returns TRUE, if the predicate is NULL or FALSE.
So filter (LNNVL(SAL=2)) returns all rows for which SAL != 2 or SAL is NULL.
Note: The explain plan in the slide is from Oracle Database 11g Release 1.
SYSTOOLS
UNION [ALL], INTERSECT, MINUS
INTERSECTION
SORT UNIQUE NOSORT
1 3 4
INTERSECT INDEX FULL SCAN
SORT UNIQUE 2 3 5
INDEX FAST FULL SCAN
SYSTOOLS
MINUS
SORT UNIQUE NOSORT
MINUS 1 3 4
INDEX FULL SCAN
SORT UNIQUE 2 3 5
INDEX FAST FULL SCAN
SYSTOOLS
the sets, eliminating duplicates. Subrow sources are executed or optimized individually.
This is very similar to sort-merge-join processing: Full rows are sorted and matched.
• MINUS: Operation accepting two sets of rows and returning rows appearing in the first
set, but not in the second, eliminating duplicates. Subrow sources are executed or
optimized individually. Similar to INTERSECT processing. However, instead of match-
and-return, it is match-and-exclude.
• UNION: Operation accepting two sets of rows and returning the union of the sets,
eliminating duplicates. Subrow sources are executed or optimized individually. Rows
retrieved are concatenated and sorted to eliminate duplicate rows.
• UNION ALL: Operation accepting two sets of rows and returning the union of the sets,
and not eliminating duplicates. The expensive sort operation is not necessary. Use
UNION ALL if you know you do not have to deal with duplicates.
SYSTOOLS
Result Cache Operator
The SQL query result cache enables explicit caching of query result sets and query fragments
in database memory. A dedicated memory buffer stored in the shared pool can be used for
storing and retrieving the cached results. The query results stored in this cache become
invalid when data in the database objects that are accessed by the query is modified.
Although the SQL query cache can be used for any query, good candidate statements are the
SYSTOOLS
ones that need to access a very high number of rows to return only a fraction of them. This is
mostly the case for data warehousing applications.
If you want to use the query result cache and the RESULT_CACHE_MODE initialization
parameter is set to MANUAL, you must explicitly specify the RESULT_CACHE hint in your query.
This introduces the ResultCache operator into the execution plan for the query. When you
execute the query, the ResultCache operator looks up the result cache memory to check
whether the result for the query already exists in the cache. If it exists, the result is retrieved
directly out of the cache. If it does not yet exist in the cache, the query is executed, the result
is returned as output, and is also stored in the result cache memory.
If the RESULT_CACHE_MODE initialization parameter is set to FORCE, and you do not want to
store the result of a query in the result cache, you must then use the NO_RESULT_CACHE hint
in your query.
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 8: Overview
SYSTOOLS
Practice 8: Overview
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
The Star Schema Model
Dimension/Lookup table
PROD_NAME DAY_NAME
PROD_DESC PROD_ID CALENDAR_YEAR
TIME_ID
CHANNEL_ID
SALES
CUSTOMERS CHANNELS
SYSTOOLS
AMOUNT_SOLD
QUANTITY_SOLD
CUST_ID CHANNEL_ID
CUST_GENDER
Measures CHANNEL_DESC
CUST_CITY CHANNEL_CLASS
Fact >> Dimension
SYSTOOLS
smaller dimension tables (or lookup tables), each of which contains information about the
entries for a particular attribute in the fact table. A star query is a join between a fact table and
a number of dimension tables. Each dimension table is joined to the fact table using a primary
key to foreign key join, but the dimension tables are not joined to each other. The cost-based
optimizer (CBO) recognizes star queries and generates efficient execution plans for them. A
typical fact table contains keys and measures. For example, in the Sales History schema, the
sales fact table contains the quantity_sold, amount, and cost measures, and the
cust_id, time_id, prod_id, channel_id, and promo_id keys. The dimension tables are
customers, times, products, channels, and promotions. The products dimension
table, for example, contains information about each product number that appears in the fact
table.
Note: It is easy to generalize this model to include more than one fact table.
SALES
CUSTOMERS
SYSTOOLS
COUNTRIES
CHANNELS
SYSTOOLS
products table, a product_category table, and a product_manufacturer table in a
snowflake schema or, as shown in the slide, you can normalize the customers table using
the countries table. While this saves space, it increases the number of dimension tables
and requires more foreign key joins. The result is more complex queries and reduced query
performance.
Note: It is suggested that you select a star schema over a snowflake schema unless you have
a clear reason to choice the snowflake schema.
0
1
1
0
s.channel_id = ch.channel_id AND
SYSTOOLS
c.cust_state_province = 'CA' AND
ch.channel_desc IN ('Internet','Catalog') AND
t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
SYSTOOLS
SYSTOOLS
Execution Plan Without Star Transformation
-------------------------------------------
SYSTOOLS
2 - access("S"."CHANNEL_ID"="CH"."CHANNEL_ID")
3 - filter("CH"."CHANNEL_DESC"='Catalog' OR
"CH"."CHANNEL_DESC"='Internet')
CUSTOMERS SALES 4 - access("S"."TIME_ID"="T"."TIME_ID")
5 - filter("T"."CALENDAR_QUARTER_DESC"='1999-Q1'
OR "T"."CALENDAR_QUARTER_DESC"='1999-Q2')
6 - access("S"."CUST_ID"="C"."CUST_ID")
7 - filter("C"."CUST_STATE_PROVINCE"='CA')
SYSTOOLS
trimmed down by the other parent joins in the execution plan.
Star Transformation
SYSTOOLS
Star Transformation
To get the best possible performance for star queries, it is important to follow some basic
guidelines:
• A bitmap index should be built on each of the foreign key columns of the fact table or
tables.
SYSTOOLS
• The STAR_TRANSFORMATION_ENABLED initialization parameter should be set to TRUE.
This enables an important optimizer feature for star queries. It is set to FALSE by default
for backwards compatibility.
When a data warehouse satisfies these conditions, the majority of the star queries that run in
the data warehouse use a query execution strategy known as star transformation. Star
transformation provides very efficient query performance for star queries.
Star transformation is a powerful optimization technique that relies on implicitly rewriting (or
transforming) the SQL of the original star query. The end user never needs to know any of the
details about the star transformation. The system’s CBO automatically selects star
transformation where appropriate. The optimizer creates an execution plan that processes a
star query using two basic phases:
• The first phase retrieves exactly the necessary rows from the fact table (the result set).
Because this retrieval utilizes bitmap indexes, it is very efficient.
• The second phase joins this result set to the dimension tables. This operation is called a
semijoin.
Note: At least three tables are used in the query (two dimensions and one fact).
SYSTOOLS
SYSTOOLS
SYSTOOLS
Star Transformation: Considerations
SYSTOOLS
Star Transformation: Considerations
Star transformation is not supported for tables with any of the following characteristics:
• Queries with a table hint that is incompatible with a bitmap access path
• Queries that contain bind variables
• Tables with too few bitmap indexes. There must be a bitmap index on a fact table
SYSTOOLS
column for the optimizer to generate a subquery for it.
• Remote fact tables. However, remote dimension tables are allowed in the subqueries
that are generated.
• Antijoined tables
• Tables that are already used as a dimension table in a subquery
• Tables that are really unmerged views, which are not view partitions
SYSTOOLS
Star Transformation: Rewrite Example
Phase 1
SYSTOOLS
0
1
1
0
AND channel_id IN(SELECT channel_id
FROM channels
WHERE channel_desc IN
('Internet','Catalog'));
SYSTOOLS
essentially the rewritten query in the slide.
Note: The SQL in the slide is a theoretical SQL statement that represents what goes on in
phase I.
SYSTOOLS
Retrieving Fact Rows from One Dimension
Phase 1
BITMAP
KEY
ITERATION
SYSTOOLS
Dimension
Table
Access
Fact Table
Bitmap
Access
SYSTOOLS
BITMAP KEY ITERATION makes each key coming from its left input a lookup key for the
index on its right input, and returns all bitmaps fetched by that index. Note that its left input
supplies join keys from the dimension table in this case.
The last step in this tree merges all fetched bitmaps from the previous steps. This merge
operation produces one bitmap that can be described as representing the rows of the fact
table that join with the rows of interest from the dimension table.
Note: BITMAP_MERGE_AREA_SIZE plays an important role in tuning the performance of this
operation when using the shared server mode. The system does not recommend using the
BITMAP_MERGE_AREA_SIZE parameter unless the instance is configured with the shared
server option. The system recommends that you enable automatic sizing of SQL working
areas by setting PGA_AGGREGATE_TARGET instead. BITMAP_MERGE_AREA_SIZE is retained
for backward compatibility.
SYSTOOLS
Retrieving Fact Rows from All Dimensions
Intermediate Phase 1
BITMAP
AND
SYSTOOLS
MERGE 1
…
MERGE
…
MERGE n
SYSTOOLS
all the bitmaps generated for each dimension. The resulting bitmap can be described as
representing the rows from the fact table that are known to join with all the qualified dimension
rows.
Note: Until now, only fact bitmap indexes and dimension tables were used. To further access
the fact table, the system must convert the generated bitmap to a rowids set.
SYSTOOLS
Joining the Intermediate Result Set
with Dimensions
Phase 2
Dimension n
Table Hash Join
Access
Dimension i
Table
SYSTOOLS
Hash Join
Access
SYSTOOLS
a star query, this might not be always true, as this is evaluated by the CBO.
SYSTOOLS
Star Transformation Plan: Example 1
SORT GROUP BY
SYSTOOLS
BUFFER SORT
TABLE ACCESS FULL TIMES
BITMAP INDEX RANGE SCAN SALES_TIMES_BX
…
TABLE ACCESS FULL CHANNELS
TABLE ACCESS FULL TIMES
SYSTOOLS
SYSTOOLS
Star Transformation: Further Optimization
…
SYSTOOLS
LOAD AS SELECT
TABLE ACCESS FULL
SYS_TEMP_0FD9D6720_BEBDC
CUSTOMERS
filter("C"."CUST_STATE_PROVINCE"='CA')
SYSTOOLS
temporary tables containing information needed for both phases. This decision is made if the
cost for creating a temporary table, consisting of the result set for both the predicate and the
join columns on the dimension table, is cheaper than accessing the dimension table twice. In
the previous execution plan example, the TIMES and CHANNELS tables are very small, and
accessing them using a full table scan has a very small cost.
The creation of these temporary tables and the data insertion are shown in the execution plan.
The name of those temporary tables is system-generated and varies. In the slide, you see an
extract from an execution plan using temporary tables for the CUSTOMERS table.
Note: Temporary tables are not used by star transformation under the following conditions:
• The database is in read-only mode.
• The star query is part of a transaction that is in serializable mode.
• STAR_TRANSFORMATION_ENABLED is set to TEMP_DISABLE.
SYSTOOLS
Using Bitmap Join Indexes
The volume of data that must be joined can be reduced if the join indexes used have already
been precalculated.
In addition, the join indexes, which contain multiple dimension tables can eliminate bitwise
operations, which are necessary in the star transformation with existing bitmap indexes.
SYSTOOLS
Finally, bitmap join indexes are much more efficient in storage than materialized join views
(MJVs), which do not compress rowids of the fact tables.
Assume that you have created the additional index structure mentioned in the slide.
Note: Since the SALES table is partitioned the bitmap join index will also be partitioned
therefore the LOCAL keyword is required.
SYSTOOLS
Star Transformation Plan: Example 2
SYSTOOLS
BITMAP INDEX RANGE SCAN SALES_CHANNELS_BX
BITMAP OR
BITMAP INDEX SINGLE VALUE SALES_Q_BJX
BITMAP INDEX SINGLE VALUE SALES_Q_BJX
TABLE ACCESS FULL CHANNELS
TABLE ACCESS FULL TIMES
SYSTOOLS
bitmap index scan for the times dimension has no subselect in the rewritten query for phase
1. This is because the join predicate information on times.calendar_quarter_desc can
be satisfied with the sales_q_bjx bitmap join index.
Note that access to the join index is done twice because the corresponding query’s predicate
is t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
SYSTOOLS
containing more than one fact table.
SYSTOOLS
reasonable to do so. If no subqueries are generated, there is no transformed query, and
the best plan for the untransformed query is used, regardless of the hint.
• The FACT hint is used in the context of the star transformation to indicate to the
transformation that the hinted table should be considered as a fact table and all other
tables regardless of their size are considered as dimensions.
• The NO_FACT hint is used in the context of the star transformation to indicate to the
transformation that the hinted table should not be considered as a fact table.
Note: The FACT and NO_FACT hints might be useful only in case there are more than one fact
table accessed in the star query.
SYSTOOLS
Bitmap Join Indexes: Join Model 1
d f
CREATE BITMAP INDEX bji ON f(d.c1)
FROM f, d
SYSTOOLS
WHERE d.pk = f.fk;
SELECT sum(f.facts)
FROM d, f
WHERE d.pk = f.fk AND d.c1 = 1;
SYSTOOLS
Similar to the materialized join view, a bitmap join index precomputes the join and stores it as
a database object. The difference is that a materialized join view materializes the join into a
table while a bitmap join index materializes the join into a bitmap index.
Note: C1 is the indexed column in the dimension table.
SYSTOOLS
Bitmap Join Indexes: Join Model 2
d f
CREATE BITMAP INDEX bjx ON f(d.c1,d.c2)
FROM f, d
SYSTOOLS
WHERE d.pk = f.fk;
SELECT sum(f.facts)
FROM d, f
WHERE d.pk = f.fk AND d.c1 = 1 AND d.c2 = 1;
SYSTOOLS
This is due to the fact that D.C1 is the leading part of the BJX.
SYSTOOLS
Bitmap Join Indexes: Join Model 3
d1 f d2
CREATE BITMAP INDEX bjx ON f(d1.c1,d2.c1)
FROM f, d1, d2
SYSTOOLS
WHERE d1.pk = f.fk1 AND d2.pk = f.fk2;
SELECT sum(f.sales)
FROM d1, f, d2
WHERE d1.pk = f.fk1 AND d2.pk = f.fk2 AND
d1.c1 = 1 AND d2.c1 = 2;
SYSTOOLS
SYSTOOLS
Bitmap Join Indexes: Join Model 4
d1 d2 f
CREATE BITMAP INDEX bjx ON f(d1.c1)
FROM f, d1, d2
SYSTOOLS
WHERE d1.pk = d2.c2 AND d2.pk = f.fk;
SELECT sum(f.sales)
FROM d1, d2, f
WHERE d1.pk = d2.c2 AND d2.pk = f.fk AND
d1.c1 = 1;
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a, c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Practice 9: Overview
SYSTOOLS
Practice 9: Overview
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 1
Chapter 10
Optimizer Statistics
Optimizer Statistics
Optimizer Statistics
Chapter 10 - Page 2
Optimizer Statistics
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 3
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Optimizer Statistics
SYSTOOLS
Optimizer Statistics
SYSTOOLS
– Manually gathered by the user with DBMS_STATS
Optimizer Statistics
Optimizer statistics describe details about the database and the objects in the database.
These statistics are used by the query optimizer to select the best execution plan for each
SQL statement.
Because the objects in a database change constantly, statistics must be regularly updated so
that they accurately describe these database objects. Statistics are maintained automatically
SYSTOOLS
by Oracle Database, or you can maintain the optimizer statistics manually using the
DBMS_STATS package.
Optimizer Statistics
Chapter 10 - Page 4
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
• System statistics
– I/O performance and utilization
– CPU performance and utilization
SYSTOOLS
optimization and are stored in the data dictionary. These statistics should not be confused with
performance statistics visible through V$ views.
Optimizer Statistics
Chapter 10 - Page 5
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Table Statistics (DBA_TAB_STATISTICS)
SYSTOOLS
– Statistics status (STALE_STATS)
SYSTOOLS
This is the number of used data blocks. Block count in combination with
DB_FILE_MULTIBLOCK_READ_COUNT gives the base table access cost.
AVG_ROW_LEN
This is the average length of a row in the table in bytes.
STALE_STATS
This tells you if statistics are valid on the corresponding table.
Note: There are three other statistics: EMPTY_BLOCKS, AVE_ROW_LEN, and CHAIN_CNT
that are not used by the optimizer, and not gathered by the DBMS_STATS procedures. If
these are required the ANALYZE command must be used.
Optimizer Statistics
Chapter 10 - Page 6
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Index Statistics (DBA_IND_STATISTICS)
SYSTOOLS
the index appears (AVG_LEAF_BLOCKS_PER_KEY)
– Average number of data blocks in the table pointed to by a
distinct value in the index
(AVG_DATA_BLOCKS_PER_KEY)
– Number of rows in the index (NUM_ROWS)
SYSTOOLS
BLEVEL
This is used to calculate the cost of leaf block lookups. It indicates the depth of the index from
its root block to its leaf blocks. A depth of "0" indicates that the root block and leaf block are
the same.
LEAF_BLOCKS
This is used to calculate the cost of a full index scan.
CLUSTERING_FACTOR
This measures the order of the rows in the table based on the values of the index. If the value
is near the number of blocks, the table is very well ordered. In this case, the index entries in a
single leaf block tend to point to the rows in the same data blocks. If the value is near the
number of rows, the table is very randomly ordered. In this case, it is unlikely that the index
entries in the same leaf block point to rows in the same data blocks.
Optimizer Statistics
Chapter 10 - Page 7
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
STALE_STATS
This tells you if the statistics are valid in the corresponding index.
DISTINCT_KEYS
SYSTOOLS
This is the number of distinct indexed values. For indexes that enforce UNIQUE and PRIMARY
KEY constraints, this value is the same as the number of rows in the table.
AVG_LEAF_BLOCKS_PER_KEY
This is the average number of leaf blocks in which each distinct value in the index appears,
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 8
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
DBA_IND_STATISTICS.CLUSTERING_FACTOR
SYSTOOLS
A B C
Number of blocks (3) index range scan path
A A A B B B C C C
Block 1 Block 2 Block 3
Only need to read one block to retrieve all As
SYSTOOLS
could be spread out over a larger number of blocks. This is called the index clustering factor.
The cost formula of an index range scan uses the level of the B*-tree, the number of leaf
blocks, the index selectivity, and the clustering factor. A clustering factor indicates that the
individual rows are concentrated within fewer blocks in the table. A high clustering factor
indicates that the individual rows are scattered more randomly across the blocks in the table.
Therefore, a high clustering factor means that it costs more to use an index range scan to
fetch rows by ROWID because more blocks in the table need to be visited to return the data. In
real-life scenarios, it appears that the clustering factor plays an important role in determining
the cost of an index range scan simply because the number of leaf blocks and the height of
the B*-tree are relatively small compared to the clustering factor and table’s selectivity.
Note: If you have more than one index on a table, the clustering factor for one index might be
small while at the same time the clustering factor for another index might be large. An attempt
to reorganize the table to improve the clustering factor for one index can cause degradation of
the clustering factor of the other index.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics
Chapter 10 - Page 9
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
The clustering factor is computed and stored in the CLUSTERING_FACTOR column of the
DBA_INDEXES view when you gather statistics on the index. The way it is computed is
relatively easy. You read the index from left to right, and for each indexed entry, you add one
to the clustering factor if the corresponding row is located in a different block than the one
SYSTOOLS
from the previous row. Based on this algorithm, the smallest possible value for the clustering
factor is the number of blocks, and the highest possible value is the number of rows.
The example in the slide shows how the clustering factor can affect cost. Assume the
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 10
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Column Statistics (DBA_TAB_COL_STATISTICS)
SYSTOOLS
Column Statistics (DBA_TAB_COL_STATISTICS)
NUM_DISTINCT is used in selectivity calculations, for example, 1/Number of Distinct Values
LOW_VALUE and HIGH_VALUE: The cost-based optimizer (CBO) assumes uniform distribution
of values between low and high values for all data types. These values are used to determine
range selectivity.
SYSTOOLS
NUM_NULLS helps with selectivity of nullable columns and the IS NULL and IS NOT NULL
predicates.
DENSITY is only relevant for histograms. It is used as the selectivity estimate for nonpopular
values. It can be thought of as the probability of finding one particular value in this column.
The calculation depends on the histogram type.
NUM_BUCKETS is the number of buckets in histogram for the column.
HISTOGRAM indicates the existence or type of the histogram: NONE, FREQUENCY, HEIGHT
BALANCED
Optimizer Statistics
Chapter 10 - Page 11
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Histograms
SYSTOOLS Histograms
SYSTOOLS
values and a different approach is used:
– Frequency histogram (#distinct values ≤ #buckets)
– Height-balanced histogram (#buckets < #distinct values)
• They are stored in DBA_TAB_HISTOGRAMS.
Histograms
A histogram captures the distribution of different values in a column, so it yields better
selectivity estimates. Having histograms on columns that contain skewed data or values with
large variations in the number of duplicates help the query optimizer generate good selectivity
estimates and make better decisions regarding index usage, join orders, and join methods.
Without histograms, a uniform distribution is assumed. If a histogram is available on a column,
SYSTOOLS
the estimator uses it instead of the number of distinct values.
When creating histograms, Oracle Database uses two different types of histogram
representations depending on the number of distinct values found in the corresponding
column. When you have a data set with less than 254 distinct values, and the number of
histogram buckets is not specified, the system creates a frequency histogram. If the number of
distinct values is greater than the required number of histogram buckets, the system creates a
height-balanced histogram.
You can find information about histograms in these dictionary views: DBA_TAB_HISTOGRAMS,
DBA_PART_HISTOGRAMS, and DBA_SUBPART_HISTOGRAMS
Note: Gathering histogram statistics is the most resource-consuming operation in gathering
statistics.
Optimizer Statistics
Chapter 10 - Page 12
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Frequency Histograms
Cumulative cardinality
40000 # rows for column value
ENDPOINT 30000
NUMBER 20000
10000
SYSTOOLS
0
1 3 5 7 10 16 27 32 39 49
Frequency Histograms
For the example in the slide, assume that you have a column that is populated with 40,001
numbers. You only have ten distinct values: 1, 3, 5, 7, 10, 16, 27, 32, 39, and 49. Value 10 is
the most popular value with 16,293 occurrences.
When the requested number of buckets equals (or is greater than) the number of distinct
values, you can store each different value and record exact cardinality statistics. In this case,
SYSTOOLS
in DBA_TAB_HISTOGRAMS, the ENDPOINT_VALUE column stores the column value and the
ENDPOINT_NUMBER column stores the cumulative row count including that column value,
because this can avoid some calculation for range scans. The actual row counts are derived
from the endpoint values if needed. The actual number of row counts is shown by the curve in
the slide for clarity; only the ENDPOINT_VALUE and ENDPOINT_NUMBER columns are stored
in the data dictionary.
Optimizer Statistics
Chapter 10 - Page 13
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Viewing Frequency Histograms
SYSTOOLS
WHERE table_name = 'INVENTORIES' and column_name = 'WAREHOUSE_ID'
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- --------------
36 1
213 2
261 3
…
SYSTOOLS
To view the histogram itself, you can query the USER_HISTOGRAMS view. You can see both
ENDPOINT_NUMBER that corresponds to the cumulative frequency of the corresponding
ENDPOINT_VALUE, which represents, in this case, the actual value of the column data.
In this case, the warehouse_id is 1 and there are 36 rows with warehouse_id = 1. There
are 177 rows with warehouse_id = 2 so the sum of rows so far (36+177) is the cumulative
frequency of 213.
Note: The DBMS_STATS package is dealt with later in the lesson.
Optimizer Statistics
Chapter 10 - Page 14
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Height-Balanced Histograms
SYSTOOLSHeight-Balanced Histograms
Popular value
1 7 10 10 32 49
ENDPOINT VALUE Same number
of rows per bucket
SYSTOOLS 0 1 2
ENDPOINT NUMBER: Bucket number
Height-Balanced Histograms
In a height-balanced histogram, the ordered column values are divided into bands so that
each band contains approximately the same number of rows. The histogram tells you values
of the endpoints of each band. In the example in the slide, assume that you have a column
that is populated with 40,001 numbers. There will be 8,000 values in each band. You only
have ten distinct values: 1, 3, 5, 7, 10, 16, 27, 32, 39, and 49. Value 10 is the most popular
SYSTOOLS
value with 16,293 occurrences. When the number of buckets is less than the number of
distinct values, ENDPOINT_NUMBER records the bucket number and ENDPOINT_VALUE
records the column value that corresponds to this endpoint. In the example, the number of
rows per bucket is one-fifth of the total number of rows, that is 8000. Based on this
assumption, value 10 appears between 8000 and 24000 times. So you are sure that value 10
is a popular value.
This type of histogram is good for equality predicates on popular value, and range predicates.
The number of rows per bucket is not recorded because this can be derived from the total
number of values and the fact that all the buckets contain an equal number of values. In this
example, value 10 is a popular value because it spans multiple endpoint values. To save
space, the histogram does not actually store duplicated buckets. In the example in the slide,
bucket 2 (with endpoint value 10) would not be recorded in DBA_TAB_HISTOGRAMS for that
reason.
Optimizer Statistics
Chapter 10 - Page 15
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Viewing Height-Balanced Histograms
SYSTOOLS
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- --------------
0 0
1 27
2 42
3 57
…
SYSTOOLS
To view the histogram itself, you can query the USER_HISTOGRAMS view. You can see that
the ENDPOINT_NUMBER corresponds to the bucket number, and ENDPOINT_VALUE
corresponds to values of the endpoints end.
Note: The DBMS_STATS package is dealt with later in the lesson.
Optimizer Statistics
Chapter 10 - Page 16
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Histogram Considerations
SYSTOOLSHistogram Considerations
SYSTOOLS
• Do not use histograms unless they substantially improve
performance.
Histogram Considerations
Histograms are useful only when they reflect the current data distribution of a given column.
The data in the column can change as long as the distribution remains constant. If the data
distribution of a column changes frequently, you must recompute its histogram frequently.
Histograms are useful when you have a high degree of data skew in the columns for which
you want to create histograms.
SYSTOOLS
However, there is no need to create histograms for columns which do not appear in a WHERE
clause of a SQL statement. Similarly, there is no need to create histograms for columns with
uniform distribution.
In addition, for columns declared as UNIQUE, histograms are useless because the selectivity
is obvious. Also, the maximum number of buckets is 254, which can be lower depending on
the actual number of distinct column values. Histograms can affect performance and should
be used only when they substantially improve query plans. For uniformly distributed data, the
optimizer can make fairly accurate guesses about the cost of executing a particular statement
without the use of histograms.
Note: Character columns have some exceptional behavior as histogram data is stored only for
the first 32 bytes of any string.
Optimizer Statistics
Chapter 10 - Page 17
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Multicolumn Statistics: Overview
VEHICLE
S(MAKE Λ MODEL)=S(MAKE)xS(MODEL)
select
dbms_stats.create_extended_stats('jfv','vehicle','(make,model)')
from dual;
2
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns size 1 for columns (make,model) size 3'); 3
SYS_STUF3GLKIOP5F4B0BTTCFTMX0W
SYSTOOLS VEHICLE
DBA_STAT_EXTENSIONS
MAKE MODEL
4
S(MAKE Λ MODEL)=S(MAKE,MODEL)
SYSTOOLS
When DYNAMIC_SAMPLING is set to level 4, the query optimizer uses dynamic sampling
to estimate the selectivity of complex predicates involving several columns from the
same table. However, the sample size is very small and increases parsing time. As a
result, the sample is likely to be statistically inaccurate and may cause more harm than
good.
In all other cases, the optimizer assumes that the values of columns used in a complex
predicate are independent of each other. It estimates the selectivity of a conjunctive predicate
by multiplying the selectivity of individual predicates. This approach results in underestimation
of the selectivity if there is a correlation between the columns. To circumvent this issue,
Oracle Database 11g allows you to collect, store, and use the following statistics to capture
functional dependency between two or more columns (also called groups of columns): number
of distinct values, number of nulls, frequency histograms, and density.
Optimizer Statistics
Chapter 10 - Page 18
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
For example, consider a VEHICLE table in which you store information about cars. The MAKE
and MODEL columns are highly correlated, in that MODEL determines MAKE. This is a strong
dependency, and both columns should be considered by the optimizer as highly correlated.
You can signal that correlation to the optimizer by using the CREATE_EXTENDED_STATS
SYSTOOLS
function as shown in the example in the slide, and then compute the statistics for all columns
(including the ones for the correlated groups that you created).
The optimizer only uses multicolumn statistics with equality predicates.
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 19
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
VEHICLE VEHICLE
MODEL Still possible MODEL
Recommended
VEHICLE
select MODEL
dbms_stats.create_extended_stats(
SYSTOOLS
'jfv','vehicle','(upper(model))')
from dual;
SYS_STU3FOQ$BDH0S_14NGXFJ3TQ50
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns size 1 for columns (upper(model)) size 3');
SYSTOOLS
The query optimizer has been extended to better handle such predicates in limited cases
where functions preserve the data distribution characteristics of the column and thus allow the
optimizer to use the columns statistics. An example of such a function is TO_NUMBER.
Further enhancements have been made to evaluate built-in functions during query
optimization to derive better selectivity using dynamic sampling. Finally, the optimizer collects
statistics on virtual columns created to support function-based indexes.
However, these solutions are either limited to a certain class of functions or work only for
expressions used to create function-based indexes. By using expression statistics in Oracle
Database 11g, you can use a more general solution that includes arbitrary user-defined
functions and does not depend on the presence of function-based indexes. As shown in the
example in the slide, this feature relies on the virtual column infrastructure to create statistics
on expressions of columns.
Optimizer Statistics
Chapter 10 - Page 20
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Gathering System Statistics
SYSTOOLS
– DBMS_STATS.SET_SYSTEM_STATS
– DBMS_STATS.GET_SYSTEM_STATS
• GATHERING_MODE:
– NOWORKLOAD|INTERVAL
– START|STOP
SYSTOOLS
you can capture statistics in the interval of time when the system has the most common
workload. For example, database applications can process online transaction processing
(OLTP) transactions during the day and run OLAP reports at night. You can gather statistics
for both states and activate appropriate OLTP or OLAP statistics when needed. This allows
the optimizer to generate relevant costs with respect to the available system resource plans.
When the system generates system statistics, it analyzes system activity in a specified period
of time. Unlike the table, index, or column statistics, the system does not invalidate already
parsed SQL statements when system statistics get updated. All new SQL statements are
parsed using new statistics.
It is highly recommended that you gather system statistics. System statistics are gathered in a
user-defined time frame with the DBMS_STATS.GATHER_SYSTEM_STATS routine. You can also
set system statistics values explicitly using DBMS_STATS.SET_SYSTEM_STATS. Use
DBMS_STATS.GET_SYSTEM_STATS to verify system statistics.
Optimizer Statistics
Chapter 10 - Page 21
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
When you use the GATHER_SYSTEM_STATS procedure, you should specify the
GATHERING_MODE parameter:
• NOWORKLOAD: This is the default. This mode captures characteristics of the I/O system.
SYSTOOLS
Gathering may take a few minutes and depends on the size of the database. During this
period the system estimates the average read seek time and transfer speed for the I/O
system. This mode is suitable for all workloads. It is recommended that you run
GATHER_SYSTEM_STATS ('noworkload') after you create the database and
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 22
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Gathering System Statistics: Example
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS(
First night interval => 120,
stattab => 'mystats', statid => 'OLAP');
EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS(
Next days stattab => 'mystats', statid => 'OLTP');
SYSTOOLS
Then, system statistics are collected during the night. Gathering ends after 120 minutes and is
stored in the mystats table.
Generally, the syntax in the slide is used to gather system statistics. Before invoking the
GATHER_SYSTEM_STATS procedure with the INTERVAL parameter specified, you must
activate job processes using a command, such as SQL> alter system set
job_queue_processes = 1;.
Note: In Oracle Database 11g Release 2, the default value of job_queue_processes is
1000. You can also invoke the same procedure with different arguments to enable manual
gathering instead of using jobs.
If appropriate, you can switch between the statistics gathered. Note that it is possible to
automate this process by submitting a job to update the dictionary with appropriate statistics.
During the day, a job may import the OLTP statistics for the daytime run, and during the night,
another job imports the online analytical processing (OLAP) statistics for the nighttime run.
Optimizer Statistics
Chapter 10 - Page 23
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Gathering System Statistics: Example
SYSTOOLS
Gathering System Statistics: Example (continued)
The example in the previous slide shows how to collect system statistics with jobs by using
the internal parameter of the DBMS_STATS.GATHER_SYSTEM_STATS procedure. To collect
system statistics manually, another parameter of this procedure can be used as shown in the
slide.
SYSTOOLS
First, you must start the system statistics collection, and then you can end the collection
process at any time after you are certain that a representative workload has been generated
on the instance.
The example collects system statistics and stores them directly in the data dictionary.
Optimizer Statistics
Chapter 10 - Page 24
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Mechanisms for Gathering Statistics
SYSTOOLS
# of distinct values 100
Table cardinality 100
Remote table cardinality 2000
SYSTOOLS
perform dynamic sampling. These include remote tables and external tables. In those cases
and also when dynamic sampling has been disabled, the optimizer uses default values for its
statistics.
Optimizer Statistics
Chapter 10 - Page 25
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Optimizer SYSTOOLS
Statistic Preferences: Overview
Statement level
Database level
Global level
CASCADE DEGREE
ESTIMATE_PERCENT METHOD_OPT
NO_INVALIDATE GRANULARITY
PUBLISH INCREMENTAL
STALE_PERCENT
set_global_prefs
set_database_prefs
SYSTOOLS
set_schema_prefs
set_table_prefs
gather_*_stats
exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13');
SYSTOOLS
your own options. For example, the feature that automatically tries to determine adequate
sample size (ESTIMATE_PERCENT=AUTO_SAMPLE_SIZE) does not work well against
columns that contain data with very high frequency skews. The only way to get around this
issue was to manually specify the sample size in your own script.
The Statistic Preferences feature in Oracle Database 11g introduces flexibility so that you can
rely more on the automated statistics-gathering feature to maintain the optimizer statistics
when some objects require settings that are different from the database default.
This feature allows you to associate the statistics-gathering options that override the default
behavior of the GATHER_*_STATS procedures and the automated Optimizer Statistics
Gathering task at the object or schema level. You can use the DBMS_STATS package to
manage the gathering statistics options shown in the slide.
You can set, get, delete, export, and import those preferences at the table, schema, database,
and global levels. Global preferences are used for tables that do not have preferences,
Optimizer Statistics
Chapter 10 - Page 26
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
whereas database preferences are used to set preferences on all tables. The preference
values that are specified in various ways take precedence from the outer circles to the inner
ones (as shown in the slide).
SYSTOOLS
In the graphic in the slide, the last three highlighted options are new in Oracle Database 11g,
Release 1:
• CASCADE gathers statistics on the indexes as well. Index statistics gathering is not
parallelized.
SYSTOOLS
• STALE_PERCENT is used to determine the threshold level at which an object is
considered to have stale statistics. The value is a percentage of rows modified since the
last statistics gathering. The example changes the 10 percent default to 13 percent for
SH.SALES only.
• DEGREE determines the degree of parallelism used to compute statistics. The default for
degree is null, which means use the table default value specified by the DEGREE clause
in the CREATE TABLE or ALTER TABLE statement. Use the constant
DBMS_STATS.DEFAULT_DEGREE to specify the default value based on the initialization
parameters. The AUTO_DEGREE value determines the degree of parallelism
automatically. This is either 1 (serial execution) or DEFAULT_DEGREE (the system
default value based on the number of CPUs and initialization parameters), depending on
the size of the object.
• METHOD_OPT is a SQL string used to collect histogram statistics. The default value is
FOR ALL COLUMNS SIZE AUTO.
GRANULARITY is the granularity of statistics to collect for partitioned tables.
SYSTOOLS
•
Optimizer Statistics
Chapter 10 - Page 27
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
When to Gather Statistics Manually
SYSTOOLS
part of the batch operation.
– External tables, system statistics, fixed objects
– New objects: Gather statistics right after object creation.
SYSTOOLS
statistics on tables that are significantly modified during the day may become stale. There are
typically two types of such objects:
• Volatile tables that are modified significantly during the course of the day
• Objects that are the target of large bulk loads that add 10% or more to the object’s total
size between statistics-gathering intervals
For external tables, statistics are only collected manually using GATHER_TABLE_STATS.
Sampling on external tables is not supported, so the ESTIMATE_PERCENT option should be
explicitly set to null. Because data manipulation is not allowed against external tables, it is
sufficient to analyze external tables when the corresponding file changes. Other areas in
which statistics need to be manually gathered are the system statistics and fixed objects, such
as the dynamic performance tables. These statistics are not automatically gathered.
Optimizer Statistics
Chapter 10 - Page 28
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Manual Statistics Gathering
SYSTOOLS
– Indexes, tables, columns, partitions
– Object, schema, or database
• Gather statistics either serially or in parallel
• Gather/Set system statistics (currently not possible in EM)
SYSTOOLS
DBMS_STATS gathers only statistics needed for optimization; it does not gather other
statistics. For example, the table statistics gathered by DBMS_STATS include the number of
rows, number of blocks currently containing data, and average row length, but not the number
of chained rows, average free space, or number of unused data blocks.
Note: Do not use the COMPUTE and ESTIMATE clauses of the ANALYZE statement to collect
optimizer statistics. These clauses are supported solely for backward compatibility and may
be removed in a future release. The DBMS_STATS package collects a broader, more accurate
set of statistics, and gathers statistics more efficiently. You may continue to use the ANALYZE
statement for other purposes not related to the optimizer statistics collection:
• To use the VALIDATE or LIST CHAINED ROWS clauses
• To collect information on free list blocks
Optimizer Statistics
Chapter 10 - Page 29
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Manual Statistics Collection: Factors
SYSTOOLS
– GATHER_SCHEMA_STATS
– GATHER_DICTIONARY_STATS
– GATHER_DATABASE_STATS
– GATHER_SYSTEM_STATS
SYSTOOLS
• Determining the correct sample sizes
• Determining the degree of parallelism to speed up queries on large objects
• Determining if histograms should be created on columns with skewed data
• Determining whether changes on objects cascade to any dependent indexes
Optimizer Statistics
Chapter 10 - Page 30
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Managing Statistics Collection: Example
SYSTOOLS
dbms_stats.set_param('CASCADE',
'DBMS_STATS.AUTO_CASCADE');
dbms_stats.set_param('ESTIMATE_PERCENT','5');
dbms_stats.set_param('DEGREE','NULL');
SYSTOOLS
You can use the SET_PARAM procedure in DBMS_STATS to set default values for parameters
of all DBMS_STATS procedures. The second example in the slide shows this usage. You can
also use the GET_PARAM function to get the current default value of a parameter.
Note: Granularity of statistics to collect is pertinent only if the table is partitioned. This
parameter determines at which level statistics should be gathered. This can be at the partition,
subpartition, or table level.
Optimizer Statistics
Chapter 10 - Page 31
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Optimizer Dynamic Sampling: Overview
SYSTOOLS
– The OPTIMIZER_DYNAMIC_SAMPLING parameter
– The OPTIMIZER_FEATURES_ENABLE parameter
– The DYNAMIC_SAMPLING hint
– The DYNAMIC_SAMPLING_EST_CDN hint
SYSTOOLS
algorithm that can lead to a suboptimal execution plan. You can use dynamic sampling to:
• Estimate single-table predicate selectivities when collected statistics cannot be used or
are likely to lead to significant errors in estimation
• Estimate table cardinality for tables and relevant indexes without statistics or for tables
whose statistics are too outdated to be reliable
You control dynamic sampling with the OPTIMIZER_DYNAMIC_SAMPLING initialization
parameter. The DYNAMIC_SAMPLING and DYNAMIC_SAMPLING_EST_CDN hints can be used to
further control dynamic sampling.
Note: The OPTIMIZER_FEATURES_ENABLE initialization parameter turns off dynamic sampling if
set to a version prior to 9.2.
Optimizer Statistics
Chapter 10 - Page 32
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Optimizer Dynamic Sampling at Work
SYSTOOLS
– Sampling time is a small fraction of the execution time
– Query is executed many times
– You believe a better plan can be found
SYSTOOLS
certain number of blocks is read by the dynamic sampling query.
For a query that normally completes quickly (in less than a few seconds), you do not want to
incur the cost of dynamic sampling. However, dynamic sampling can be beneficial under any
of the following conditions:
• A better plan can be found using dynamic sampling.
• The sampling time is a small fraction of total execution time for the query.
• The query is executed many times.
Note: Dynamic sampling can be applied to a subset of a single table’s predicates and
combined with standard selectivity estimates of predicates for which dynamic sampling is not
done.
Optimizer Statistics
Chapter 10 - Page 33
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
OPTIMIZER_DYNAMIC_SAMPLING
SYSTOOLS
OPTIMIZER_DYNAMIC_SAMPLING
SYSTOOLS
• "2" samples all unanalyzed tables
• The higher the value the more aggressive application of
sampling
• Dynamic sampling is repeatable if no update activity
OPTIMIZER_DYNAMIC_SAMPLING
You control dynamic sampling with the OPTIMIZER_DYNAMIC_SAMPLING parameter, which can
be set to a value from "0" to "10." A value of "0" means dynamic sampling is not done.
A value of "1" means dynamic sampling is performed on all unanalyzed tables if the following
criteria are met:
SYSTOOLS
• There is at least one unanalyzed table in the query.
• This unanalyzed table is joined to another table or appears in a subquery or
nonmergeable view.
• This unanalyzed table has no indexes.
• This unanalyzed table has more blocks than the default number of blocks that would be
used for dynamic sampling of this table. This default number is 32.
The default value is "2" if OPTIMIZER_FEATURES_ENABLE is set to 10.0.0 or higher. At this
level, the system applies dynamic sampling to all unanalyzed tables. The number of blocks
sampled is two times the default number of dynamic sampling blocks (32).
Increasing the value of the parameter results in more aggressive application of dynamic
sampling, in terms of both the type of tables sampled (analyzed or unanalyzed) and the
amount of I/O spent on sampling.
Optimizer Statistics
Chapter 10 - Page 34
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Note: Dynamic sampling is repeatable if no rows have been inserted, deleted, or updated in
the table being sampled since the previous sample operation.
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 35
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Locking Statistics
SYSTOOLS
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;
Locking Statistics
Starting with Oracle Database 10g, you can lock statistics on a specified table with the
LOCK_TABLE_STATS procedure of the DBMS_STATS package. You can lock statistics on a
table without statistics or set them to NULL using the DELETE_*_STATS procedures to
prevent automatic statistics collection so that you can use dynamic sampling on a volatile
table with no statistic. You can also lock statistics on a volatile table at a point when it is fully
SYSTOOLS
populated so that the table statistics are more representative of the table population.
You can also lock statistics at the schema level by using the LOCK_SCHEMA_STATS
procedure. You can query the STATTYPE_LOCKED column in the {USER | ALL |
DBA}_TAB_STATISTICS view to determine whether the statistics on the table are locked.
You can use the UNLOCK_TABLE_STATS procedure to unlock the statistics on a specified
table.
You can set the value of the FORCE parameter to TRUE to overwrite the statistics even if they
are locked. The FORCE argument is found in the following DBMS_STATS procedures:
DELETE_*_STATS, IMPORT_*_STATS, RESTORE_*_STATS, and SET_*_STATS.
Note: When you lock the statistics on a table, all the dependent statistics are considered
locked. This includes table statistics, column statistics, histograms, and dependent index
statistics.
Optimizer Statistics
Chapter 10 - Page 36
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Restoring Statistics
SYSTOOLS
• Statistics are purged
– When STATISTICS_LEVEL is set to TYPICAL or ALL
automatically
– After 31 days or time defined by
DBMS_STATS.ALTER_STATS_HISTORY_RETENTION
Restoring Statistics
Old versions of statistics are saved automatically whenever statistics in dictionary are modified
with the DBMS_STATS procedures. You can restore statistics using RESTORE procedures of
DBMS_STATS package. These procedures use a time stamp as an argument and restore
statistics as of that time stamp. This is useful when newly collected statistics lead to sub-
optimal execution plans and the administrator wants to revert to the previous set of statistics.
SYSTOOLS
Note: the ANALYZE command does not store old statistics.
There are dictionary views that can be used to determine the time stamp for restoration of
statistics. The views *_TAB_STATS_HISTORY views (ALL, DBA, or USER) contain a history of
table statistics modifications. For the example in the slide the timestamp was determined by:
select stats_update_time from dba_tab_stats_history
where table_name = 'INVENTORIES'
The database purges old statistics automatically at regular intervals based on the statistics
history retention setting and the time of the recent analysis of the system. You can configure
retention using the DBMS_STATS .ALTER_STATS_HISTORY_RETENTION procedure. The
default value is 31 days, which means that you would be able to restore the optimizer
statistics to any time in last 31 days.
Optimizer Statistics
Chapter 10 - Page 37
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Export and Import Statistics
expdp impdp
SYSTOOLS
EXPORT_*_STATS IMPORT_*_STATS
SYSTOOLS
procedure DBMS_STATS.CREATE_STAT_TABLE creates the statistics table. After table
creation, you can export statistics from the data dictionary into the statistics table using the
DBMS_STATS.EXPORT_*_STATS procedures. You can then import statistics using the
DBMS_STATS.IMPORT_*_STATS procedures.
The optimizer does not use statistics stored in a user-owned table. The only statistics used by
the optimizer are the statistics stored in the data dictionary. To have the optimizer use the
statistics in a user-owned tables, you must import those statistics into the data dictionary using
the statistics import procedures.
To move statistics from one database to another, you must first export the statistics on the first
database, then copy the statistics table to the second database, using the Data Pump Export
and Import utilities or other mechanisms, and finally import the statistics into the second
database.
Optimizer Statistics
Chapter 10 - Page 38
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b, c
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 39
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
e. System statistics
Answer: a, c, e
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 40
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
SYSTOOLS Quiz
SYSTOOLS
f. Allow the DYNAMIC_SAMPLING parameter to default.
Answer: a, b, f
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 41
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 42
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
SYSTOOLS
Practice 10: Overview
SYSTOOLS
SYSTOOLS
Optimizer Statistics
Chapter 10 - Page 43
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Optimizer Statistics
Chapter 10 - Page 44
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Chapter 11 - Page 2
Using Bind Variables
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
Cursor Sharing and Different Literal Values
Cursor sharing
SYSTOOLS
Library cache
SYSTOOLS
using a bind variable rather than a literal, there will be one shared cursor, with one execution
plan.
However, depending on the literal value provided, different execution plans might be
generated by the optimizer. For example, there might be several JOBS, where MIN_SALARY is
greater than 12000. Alternatively, there might be very few JOBS that have a MIN_SALARY
greater than 18000. This difference in data distribution could justify the addition of an index so
that different plans can be used depending on the value provided in the query. This is
illustrated in the slide. As you can see, the first and third queries use the same execution plan,
but the second query uses a different one.
From a performance perspective, it is good to have separate cursors. However, this is not
very economic because you could have shared cursors for the first and last queries in this
example.
Note: In the case of the example in the slide, V$SQL.PLAN_HASH_VALUE is identical for the
first and third query.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Cursor Sharing and Bind Variables
Cursor sharing
SYSTOOLS
Library cache
SYSTOOLS
MIN_SALARY column of the JOBS table. Instead of issuing three different statements, issue a
single statement that uses a bind variable. At execution time, the same execution plan is
used, the given value is substituted for the variable.
However, from a performance perspective, this is not the best situation because you get best
performance two times out of three. On the other hand, this is very economic because you just
need one shared cursor in the library cache to execute all the three statements.
COUNT(*)
----------
30
SYSTOOLS
PL/SQL procedure successfully completed.
COUNT(*)
----------
2
SYSTOOLS
In the example in the slide, the first count is selected while SA_REP is assigned to the
variable. The result is 30. Then, AD_VP is assigned to the variable, and the resulting count is
2.
SYSTOOLS
Bind Variables in Enterprise Manager
SYSTOOLS
with a colon. The order in which variables are referred to defines which variable gets which
value. The first variable referred to gets the first value, the second variable gets the second
value, and so on. If you change the order in which variables are referenced in the statement,
you may need to change the value list to match that order.
SYSTOOLS
Bind Variables in SQL Developer
SYSTOOLS
First time
you execute
Plan A
SYSTOOLS
min_sal=12000
Next time
you execute
SYSTOOLS
values is selected. The optimizer does this by peeking at the value in the bind variable. When
the SQL statement is hard parsed, the optimizer evaluates the value for each bind variable,
and uses that as input in determining the best plan. After the execution is determined the first
time you parsed the query, it is reused when you execute the same statement regardless of
the bind values used.
This feature was introduced in Oracle9i Database, Release 2. Oracle Database 11g changes
this behavior.
1 min_sal=12000
2 min_sal=18000
3 min_sal=7500
SYSTOOLS
Plan A
One plan not always appropriate for all bind values
SYSTOOLS
where the selectivity of a particular index varies extremely depending on the column value.
For low selectivity, a full table scan may be faster. For high selectivity, an index range scan
may be more appropriate. As shown in the slide, plan A may be good for the first and third
values of min_sal, but it may not be the best for the second one. Suppose there are very few
MIN_SALARY values that are above 18000, and plan A is a full table scan. It is probable that a
full table scan is not a good plan for the second execution, in that case.
So bind variables are beneficial in that they cause more cursor sharing to happen, and thus
reduce parsing of SQL. But, as in this case, it is possible that they cause a suboptimal plan to
be chosen for some of the bind variable values. This is a good reason for not using bind
variables for decision support system (DSS) environments, where the parsing of the query is a
very small percentage of the work done when submitting a query. The parsing may take
fractions of a second, but the execution may take minutes or hours. To execute with a slower
plan is not worth the savings gained in parse time.
SYSTOOLS
Cursor Sharing Enhancements
SYSTOOLS
• Not similar: Possible different execution plans for different
literal values
SQL> SELECT * FROM employees
2 WHERE department_id = 50;
SYSTOOLS
should be tested against your applications before you decide to enable it or not. That is why
Oracle9i extends this feature by sharing only statements considered as similar. That is, only
when the optimizer has the guarantee that the execution plan is independent of the literal
value used. For example, consider a query, where EMPLOYEE_ID is the primary key:
SQL> SELECT * FROM employees WHERE employee_id = 153;
The substitution of any value would produce the same execution plan. It would, therefore, be
safe for the optimizer to generate only one plan for different occurrences of the same
statement executed with different literal values.
On the other hand, assume that the same EMPLOYEES table has a wide range of values in its
DEPARTMENT_ID column. For example, department 50 could contain over one third of all
employees and department 70 could contain just one or two.
See the two queries:
SQL> SELECT * FROM employees WHERE department_id = 50;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
full table (or fast full index) scan, or it could use a simple index range scan.
SYSTOOLS
SYSTOOLS
The CURSOR_SHARING Parameter
SYSTOOLS
• The CURSOR_SHARING_EXACT hint
SYSTOOLS
• SIMILAR: Causes sharing for safe literals only
In earlier releases, you could select only the EXACT or the FORCE option. Setting the value to
SIMILAR causes the optimizer to examine the statement to ensure that replacement occurs
only for safe literals. It can then use information about the nature of any available index
(unique or nonunique) and statistics collected on the index or underlying table, including
histograms.
The value of CURSOR_SHARING in the initialization file can be overridden with an ALTER
SYSTEM SET CURSOR_SHARING or an ALTER SESSION SET CURSOR_SHARING
command.
The CURSOR_SHARING_EXACT hint causes the system to execute the SQL statement without
any attempt to replace literals by bind variables.
SYSTOOLS
Forcing Cursor Sharing: Example
SYSTOOLS System-generated
bind variable
SYSTOOLS
Note: Adaptive cursor sharing may also apply, and might generate a second child cursor in
this case.
SYSTOOLS
Adaptive Cursor Sharing: Overview
SYSTOOLS
– Provides an automated mechanism that cannot be turned off
SYSTOOLS
hard parses. Oracle9i Database was the first attempt to introduce a compromise solution by
allowing similar SQL statements using different literal values to be shared. For statements
using bind variables, Oracle9i also introduced the concept of bind peeking. To benefit from
bind peeking, it is assumed that cursor sharing is intended and that different invocations of the
statement are supposed to use the same execution plan. If different invocations of the
statement would significantly benefit from different execution plans, bind peeking is of no use
in generating good execution plans.
To address this issue as much as possible, Oracle Database 11g introduces adaptive cursor
sharing. This feature is a more sophisticated strategy designed to not share the cursor blindly,
but generate multiple plans per SQL statement with bind variables if the benefit of using
multiple execution plans outweighs the parse time and memory usage overhead. However,
because the purpose of using bind variables is to share cursors in memory, a compromise
must be found regarding the number of child cursors that need to be generated.
System SYSTOOLS
Adaptive Cursor Sharing: Architecture
Bind-sensitive cursor
11
:1=A & :2=B S(:1)=0.15 ∧ S(:2)=0.0025 :1=C & :2=D S(:1)=0.18 ∧ S(:2)=0.003
Merged selectivity cubes No need Second selectivity cube Need new plan
SYSTOOLS
for new plan
H
a
r
GB GB H
a
r
0.009 . GB GB
d HJ HJ HJ HJ
d
4 P
a
0.004 . HJ HJ
P HJ HJ 3
a
r r
s Cubes merged s
e e
0.28 0.3
:1=G & :2=H S(:1)=0.28 ∧ S(:2)=0.004 :1=E & :2=F S(:1)=0.3 ∧ S(:2)=0.009
SYSTOOLS
stored about the predicate containing the bind variables, including the predicate
selectivity. In the slide example, the predicate selectivity that would be stored is a cube
centered around (0.15,0.0025). Because of the initial hard parse, an initial execution
plan is determined using the peeked binds. After the cursor is executed, the bind values
and the execution statistics of the cursor are stored in that cursor.
During the next execution of the statement when a new set of bind values is used, the system
performs a usual soft parse, and finds the matching cursor for execution. At the end of
execution, execution statistics are compared with the ones currently stored in the cursor. The
system then observes the pattern of the statistics over all the previous runs (see
V$SQL_CS_… views in the slide that follows) and decides whether or not to mark the cursor
as bind aware.
2. On the next soft parse of this query, if the cursor is now bind aware, bind-aware cursor
matching is used. Suppose the selectivity of the predicate with the new set of bind
values is now (0.18,0.003). Because selectivity is used as part of bind-aware cursor
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
matching, and because the selectivity is within an existing cube, the statement uses the
existing child cursor’s execution plan to run.
3. On the next soft parse of this query, suppose that the selectivity of the predicate with the
SYSTOOLS
new set of bind values is now (0.3,0.009). Because that selectivity is not within an
existing cube, no child cursor match is found. So the system does a hard parse, which
generates a new child cursor with a second execution plan in that case. In addition, the
new selectivity cube is stored as part of the new child cursor. After the new child cursor
SYSTOOLS
SYSTOOLS
SYSTOOLS
Adaptive Cursor Sharing: Views
SYSTOOLS
every predicate containing a bind
variable and whose selectivity is used in
the cursor sharing checks
SYSTOOLS
which the optimizer peeked at bind variable values when computing predicate
selectivities and where a change in a bind variable value may lead to a different plan is
called bind sensitive.
• IS_BIND_AWARE: Indicates if a cursor is bind aware; value YES | NO. A cursor in the
cursor cache that has been marked to use bind-aware cursor sharing is called bind
aware.
• V$SQL_CS_HISTOGRAM: Shows the distribution of the execution count across a three-
bucket execution history histogram.
• V$SQL_CS_SELECTIVITY: Shows the selectivity cubes or ranges stored in a cursor for
every predicate containing a bind variable and whose selectivity is used in the cursor
sharing checks. It contains the text of the predicates and the selectivity range low and
high values.
SYSTOOLS
track of the rows processed, buffer gets, and CPU time. The PEEKED column has the
value YES if the bind set was used to build the cursor, and NO otherwise.
SYSTOOLS
SYSTOOLS
Adaptive Cursor Sharing: Example
Selectivity
Plan A Plan B
SYSTOOLS
'SA_REP' 'AD_ASST'
SYSTOOLS
are different for each of these values’ queries. The AD_ASST query results in an index range
scan because there are so few rows with that value. The SA_REP query results in a full table
scan because so many of the rows have that value, it is more efficient to read the entire table.
But, as it is, using a bind variable causes the same execution plan to be used for both of the
values, at first. So, even though there exist different and better plans for each of these values,
they use the same plan.
After several executions of this query using a bind variable, the system considers the query
bind aware, at which point it changes the plan based on the bound value. This means the best
plan is used for the query, based on the bind variable value.
SYSTOOLS
Interacting with Adaptive Cursor Sharing
SYSTOOLS
application until all plans are loaded in the cursor cache.
– Manually load the cursor cache into the corresponding plan
baseline.
SYSTOOLS
• When using the SPM automatic plan capture, the first plan captured for a SQL statement
with bind variables is marked as the corresponding SQL plan baseline. If another plan is
found for that same SQL statement (which maybe the case with adaptive cursor
sharing), it is added to the SQL statements plan history and marked for verification. It will
not be used immediately. So even though adaptive cursor sharing has come up with a
new plan based on a new set of bind values, SPM does not let it be used until the plan
has been verified. Thus reverting to10g behavior, only the plan generated based on the
first set of bind values is used by all subsequent executions of the statement. One
possible workaround is to run the system for some time with automatic plan capture set
to False, and after the cursor cache has been populated with all the plans a SQL
statement with bind has, load the entire plan directly from the cursor cache into the
corresponding SQL plan baseline. By doing this, all the plans for a single SQL statement
are marked as SQL baseline plans by default. Refer to the lesson titled "SQL Plan
Management" for more information.
Quiz
SYSTOOLS Quiz
SYSTOOLS
f. Every different literal value requires parsing.
Answer: a, c, f
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
f. False
Answer: c
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
SYSTOOLS
Practice 11: Overview
SYSTOOLS
SYSTOOLS
Chapter 12 - Page 2
SQL Tuning Advisor
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
Tuning SQL Statements Automatically
SYSTOOLS
Tuning SQL Statements Automatically
Tuning SQL statements automatically is the capability of the query optimizer to automate the
entire SQL tuning process. This automatic process replaces manual SQL tuning, which is a
complex, repetitive, and time-consuming function. SQL Tuning Advisor exposes the features
of SQL tuning to the user. The enhanced query optimizer has two modes:
• In the normal mode, the optimizer compiles SQL and generates an execution plan. The
SYSTOOLS
normal mode of the optimizer generates a reasonable execution plan for the vast
majority of SQL statements. In the normal mode, the optimizer operates with very strict
time constraints, usually a fraction of a second, during which it must find a good
execution plan.
• In the tuning mode, the optimizer performs additional analysis to check whether the
execution plan produced under the normal mode can be further improved. The output of
the query optimizer in the tuning mode is not an execution plan, but a series of actions,
along with their rationale and expected benefit (for producing a significantly superior
plan). When called under tuning mode, the optimizer is referred to as Automatic Tuning
Optimizer (ATO). The tuning performed by ATO is called system SQL tuning.
Under the tuning mode, the optimizer can take several minutes to tune a single statement.
ATO is meant to be used for complex and high-load SQL statements that have a nontrivial
impact on the entire system.
SYSTOOLS
Application Tuning Challenges
SYSTOOLS
ADDM
High-load
SQL SQL Tuning
Advisor
SYSTOOLS
high-load SQL statements that are identified by ADDM may represent a very small percentage
of the total SQL workload, the task of tuning them is still highly complex and requires a high
level of expertise.
Also, the SQL tuning activity is a continuous task because the SQL workload can change
relatively often when new application modules are deployed.
SQL Tuning Advisor, introduced with Oracle Database 10g, is designed to replace the manual
tuning of SQL statements. SQL statements that consume high resources (such as CPU, I/O,
and temporary space) are good candidates for SQL Tuning Advisor. The advisor receives one
or more SQL statements as input and then provides advice on how to optimize the execution
plan, a rationale for the advice, estimated performance benefits, and the actual command to
implement the advice. You accept the advice, thereby tuning the SQL statements. With the
introduction of SQL Tuning Advisor, you can now let the Oracle optimizer tune the SQL code
for you.
SYSTOOLS
SQL Analysis SQL Tuning
optimization Advisor Restructure SQL.
mode
SYSTOOLS
recommendations are not implemented.
• SQL Profiling: ATO verifies its own estimates and collects auxiliary information to
remove estimation errors. It also collects auxiliary information in the form of customized
optimizer settings, such as first rows and all rows, based on the past execution history of
the SQL statement. It builds a SQL Profile using the auxiliary information and makes a
recommendation to create it. When a SQL Profile is created, the profile enables the
query optimizer, under normal mode, to generate a well-tuned plan.
• Access Path Analysis: ATO explores whether a new index can be used to significantly
improve access to each table in the query, and when appropriate makes
recommendations to create such indexes.
• SQL Structure Analysis: Here, ATO tries to identify SQL statements that lend
themselves to bad plans, and makes relevant suggestions to restructure them. The
suggested restructuring can be syntactic as well as semantic changes to the SQL code.
SYSTOOLS
Stale or Missing Object Statistics
EXEC DBMS_STATS.GATHER_TABLE_STATS(
SYSTOOLS
ownname=>'SH', tabname=>'CUSTOMERS',
estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
•
SYSTOOLS
Auxiliary information in the form of statistics for objects with no statistics, and statistic
adjustment factor for objects with stale statistics
Recommendations to gather relevant statistics for objects with stale or no statistics
For optimal results, you gather statistics when recommended and then rerun Automatic
Tuning Optimizer. However, you may be hesitant to accept this recommendation immediately
because of the impact it could have on other queries in the system.
SYSTOOLS
• ATO builds a profile if statistics were generated:
exec :profile_name := -
dbms_sqltune.accept_sql_profile( -
task_name =>'my_sql_tuning_task');
SYSTOOLS
enough, a correction factor is applied. Another method of estimate validation involves the
execution of a fragment of the SQL statement. The partial execution method is more efficient
than the sampling method when the respective predicates provide efficient access paths. ATO
picks the appropriate estimate validation method.
ATO also uses the past execution history of the SQL statement to determine correct settings.
For example, if the execution history indicates that a SQL statement is only partially executed
the majority of times, ATO uses the FIRST_ROWS optimization as opposed to ALL_ROWS.
ATO builds a SQL Profile if it has generated auxiliary information either during Statistics
Analysis or during SQL Profiling. When a SQL Profile is built, it generates a user
recommendation to create a SQL Profile.
In this mode, ATO can recommend the acceptance of the generated SQL Profile to activate it.
SYSTOOLS
Plan Tuning Flow and SQL Profile Creation
Use
SYSTOOLS
No application
code change Optimizer Output
(Normal mode)
Database Well-tuned
users plan
SYSTOOLS
information is not exposed through regular dictionary views. After creation of a SQL Profile,
every time the corresponding SQL statement is compiled in normal mode, the query optimizer
uses the SQL Profile to produce a well-tuned plan.
The slide shows the process flow of the creation and use of a SQL Profile. The process
consists of two separate phases. They are system SQL tuning phase and regular optimization
phase. During the system SQL tuning phase, you select a SQL statement for system tuning
and run SQL Tuning Advisor by using either Database Control or the command-line interface.
SQL Tuning Advisor invokes ATO to generate tuning recommendations, possibly with a SQL
Profile. If a SQL Profile is built, you can accept it. When it is accepted, the SQL Profile is
stored in the data dictionary. In the next phase, when an end user issues the same SQL
statement, the query optimizer (under normal mode) uses the SQL Profile to build a well-tuned
plan. The use of the SQL Profile remains completely transparent to the end user and does not
require changes to the application source code.
Generate
profiles
SQL Tuning
High load Advisor
SYSTOOLS ADDM
SYSTOOLS
have accumulated over a long period of time. In such cases, a new SQL Profile needs to be
built to replace the old one.
For example, when a SQL Profile becomes outdated, the performance of the corresponding
SQL statement may become noticeably worse. In such a case, the corresponding SQL
statement may start showing up as high-load or top SQL, thus becoming again a target for
system SQL Tuning. In such a situation, ADDM again captures the statement as high-load
SQL. If that happens, you can decide to re-create a new profile for that statement.
Significant
performance
SQL
gain Workload
Access
Advisor
Comprehensive
SYSTOOLS
index
Indexes analysis
Indexes
CREATE INDEX JFV.IDX$_00002 on JFV.TEST("C");
SYSTOOLS
Because ATO does not perform an analysis of how its index recommendations are going to
affect the entire SQL workload, it recommends running the Access Advisor on the SQL
statement along with a representative SQL workload. The Access Advisor collects advice
given on each statement of a SQL workload and consolidates it into global advice for the
entire SQL workload.
The Access Path Analysis can make the following recommendations:
• Create new indexes if they provide significantly superior performance.
• Run SQL Access Advisor to perform a comprehensive index analysis based on
application workload.
Restructured
SQL statement
SQL constructs
SYSTOOLS
Type mismatch and
indexes
Design mistakes
SQL Tuning
Advisor
SYSTOOLS
recommendation may be very similar, but not precisely equivalent to the original query. For
example, the NOT EXISTS and NOT IN constructors are similar, but not exactly the same.
Therefore, you have to decide whether the recommendation is valid. For this reason, ATO
does not automatically rewrite the query, but gives advice instead.
The following categories of problems are detected by the SQL Structure Analysis:
• Use of SQL constructors such as NOT IN instead of NOT EXISTS, or UNION instead of
UNION ALL
• Use of predicates involving indexed columns with data-type mismatch that prevents the
use of the index
• Design mistakes (such as Cartesian products)
SYSTOOLS
SQL Tuning Advisor: Usage Model
AWR
SYSTOOLS
Cursor cache
Filter
Custom
SYSTOOLS
• SQL statements from Automatic Workload Repository (AWR): A user can select any set
of SQL statements captured by AWR. This can be done using snapshots or baselines.
• Custom workload: A user can create a custom workload consisting of statements of
interest to the user. These may be statements that are not in cursor cache and are not
high-load to be captured by ADDM or AWR. For such statements, a user can create a
custom workload and tune it using the advisor.
SQL statements from cursor cache, AWR, and custom workload can be filtered and ranked
before they are input to SQL Tuning Advisor.
For a multistatement input, an object called SQL Tuning Set (STS) is provided. An STS stores
multiple SQL statements along with their execution information:
• Execution context: Parsing schema name and bind values
• Execution statistics: Average elapsed time and execution count
Note: Another STS can be a possible source for STS creation.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Database Control and SQL Tuning Advisor
SYSTOOLS
page, you find links to various other pages. You click the Top Activity link to open the Top
Activity page.
SYSTOOLS
Running SQL Tuning Advisor: Example
SYSTOOLS
is known to consume a significant proportion of one or more system resources. You can
use this page to launch SQL Tuning Advisor on a selected high-load SQL statement.
• Tuning top SQL statements: Another SQL source is the list of top SQL statements.
This is shown in the slide. You can identify the list of top SQL statements by looking at
their cumulative execution statistics based on a selected time window. The user can
select one or more top SQL statements identified by their SQL IDs, and then click
Schedule SQL Tuning Advisor.
• Tuning a SQL Tuning Set: It is also possible to look at various STSs created by
different users. An STS could have been created from a list of top SQL statements, by
selecting SQL statements from a range of snapshots created by AWR, or by selecting
customized SQL statements.
SYSTOOLS
Schedule SQL Tuning Advisor
SYSTOOLS
One of the important options is to select the scope of the tuning task. If you select the Limited
option, SQL Tuning Advisor produces recommendations based on statistics check, access
path analysis, and SQL structure analysis. No SQL Profile recommendation is generated with
Limited scope. If you select the Comprehensive option, SQL Tuning Advisor performs all of
the Limited scope actions, and invokes the optimizer under SQL Profiling mode to build a SQL
Profile if applicable. With the Comprehensive option, you can also specify a time limit for the
tuning task, which by default is 30 minutes. Another useful option is to run the tuning task
immediately or schedule it to be run at a later time.
When the task is submitted, the Processing page appears. When the task is complete, the
Recommendations page appears.
Implementing Recommendations
SYSTOOLS
Implementing Recommendations
SYSTOOLS
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a, b, d
SQL Tuning Advisor in comprehensive mode recommends all except deleting indexes. SQL
Tuning Advisor focuses on one SQL statement at a time. An entire workload must be
considered to determine if deleting an index will help performance.
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
SYSTOOLS
Practice 12: Overview
SYSTOOLS
SYSTOOLS
Chapter 13 - Page 2
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor
SYSTOOLS
SYSTOOLS
SYSTOOLS
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Access Advisor: Overview
SYSTOOLS
No expertise
required Component
Workload of CBO
Provides
implementation
script
SYSTOOLS
As part of the manageability improvements in Oracle Database 10g and 11g, SQL Access
Advisor has been introduced to address this critical need.
SQL Access Advisor identifies and helps resolve performance problems relating to the
execution of SQL statements by recommending which indexes, materialized views,
materialized view logs, or partitions to create, drop, or retain. It can be run from Database
Control or from the command line by using PL/SQL procedures.
SQL Access Advisor takes an actual workload as input, or the Advisor can derive a
hypothetical workload from the schema. It then recommends the access structures for faster
execution path. It provides the following advantages:
• Does not require you to have expert knowledge
• Bases decision making on rules that actually reside in the cost-based optimizer (CBO)
• Is synchronized with the optimizer and Oracle database enhancements
• Is a single advisor covering all aspects of SQL access methods
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Access Advisor: Usage Model
SQL cache
Workload
Hypothetical
STS
Filter
Options
SYSTOOLS
Indexes Materialized Materialized Partitioned
views views log objects
SYSTOOLS
• SQL Tuning Sets, from the workload repository
SQL Access Advisor also provides powerful workload filters that you can use to target the
tuning. For example, a user can specify that the advisor should look at only the 30 most
resource-intensive statements in the workload, based on optimizer cost. For the given
workload, the advisor then does the following:
• Simultaneously considers index solutions, materialized view solutions, partition
solutions, or combinations of all three
• Considers storage for creation and maintenance costs
• Does not generate drop recommendations for partial workloads
• Optimizes materialized views for maximum query rewrite usage and fast refresh
• Recommends materialized view logs for fast refresh
• Recommends partitioning for tables, indexes, and materialized views
SYSTOOLS
SYSTOOLS
Possible Recommendations
SYSTOOLS
Modify an existing materialized view log to add new columns YES YES
or clauses.
Partition an existing unpartitioned table or index. YES YES
Possible Recommendations
SQL Access Advisor carefully considers the overall impact of recommendations and makes
recommendations by using only the known workload and supplied information. Two workload
analysis methods are available:
• Comprehensive: With this approach, SQL Access Advisor addresses all aspects of
tuning partitions, materialized views, indexes, and materialized view logs. It assumes
SYSTOOLS
that the workload contains a complete and representative set of application SQL
statements.
• Limited: Unlike the comprehensive workload approach, a limited workload approach
assumes that the workload contains only problematic SQL statements. Thus, advice is
sought for improving the performance of a portion of an application environment.
When comprehensive workload analysis is chosen, SQL Access Advisor forms a better set of
global tuning adjustments, but the effect may be a longer analysis time. As shown in the table,
the chosen workload approach determines the type of recommendations made by the advisor.
Note: Partition recommendations can work on only those tables that have at least 10,000
rows, and workloads that have some predicates and joins on columns of the NUMBER or DATE
type. Partitioning recommendations can be generated only on these types of columns. In
addition, partitioning recommendations can be generated only for single-column interval and
hash partitions. Interval partitioning recommendations can be output as range syntax, but
interval is the default. Hash partitioning is done to leverage only partitionwise joins.
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Access Advisor Session: Initial Options
SYSTOOLS
On the SQL Access Advisor: Initial Options page, you can select a template or task from
which to populate default options before starting the wizard.
Note: The SQL Access Advisor may be interrupted while generating recommendations,
thereby allowing the results to be reviewed.
For general information about using SQL Access Advisor, see the "Overview of the SQL
Access Advisor" section in the lesson titled "SQL Access Advisor" of the Oracle Data
Warehousing Guide.
SYSTOOLS
SQL Access Advisor Session: Initial Options
SYSTOOLS
SYSTOOLS
SQL Access Advisor: Workload Source
SYSTOOLS
SQL Tuning Set that holds your statements.
• Hypothetical Workload: This option provides a schema that allows the advisor to
search for dimension tables and produce a workload. This is very useful to initially
design your schema.
Using the Filter Options section, you can further filter your workload source. Filter options are:
• Resource Consumption: Number of statements ordered by Optimizer Cost, Buffer Gets,
CPU Time, Disk Reads, Elapsed Time, Executions
• Users
• Tables
• SQL Text
• Module IDs
• Actions
SYSTOOLS
SQL Access Advisor: Recommendation Options
SYSTOOLS
modes affect the quality of recommendations as well as the length of time required for
processing. In Comprehensive Mode, the Advisor searches a large pool of candidates
resulting in recommendations of the highest quality. In Limited Mode, the advisor performs
quickly, limiting the candidate recommendations by working on the highest-cost statements
only.
Note: You can click Advanced Options to show or hide options that allow you to set space
restrictions, tuning options, and default storage locations.
SYSTOOLS
SQL Access Advisor: Schedule and Review
SYSTOOLS
SYSTOOLS
page to show statement counts and recommendation action counts.
SYSTOOLS
SQL Access Advisor: Results and Implementation
SYSTOOLS
implementation.
If you click the ID for a particular recommendation, you are taken to the Recommendations
page that displays all actions for the specified recommendation and, optionally, to modify the
tablespace name of the statement. When you complete any changes, click OK to apply the
changes. On the Recommendations page, you can view the full text of an action by clicking
the link in the Action field for the specified action. You can view the SQL for all actions in the
recommendation by clicking Show SQL.
The SQL Statements page (not shown here) gives you a chart and a corresponding table that
lists SQL statements initially ordered by the largest cost improvement. The top SQL statement
is improved the most by implementing its associated recommendation.
The Details page shows you the workload and task options that were used when the task was
created. This page also gives you all journal entries that were logged during the task
execution.
You can also schedule the implementation of the recommendations by clicking the Schedule
Implementation button.
SYSTOOLS
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: a, d
SYSTOOLS
Quiz
SYSTOOLS Quiz
SYSTOOLS
Answer: b
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
SYSTOOLS
Practice 13: Overview
SYSTOOLS
SYSTOOLS
Chapter 14 - Page 2
Automating SQL Tuning
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Tuning Loop
SQL Tuning
Automatic High load Advisor 4
Generate
SQL profiles.
SYSTOOLS2
ADDM
3
Run SQL Tuning Advisor.
SYSTOOLS
cases, the advisor makes specific suggestions for speeding up SQL performance, but it
leaves the responsibility of implementing the recommendations to the user.
In addition to SQL Tuning Advisor, Oracle Database 10g has an automated process to identify
high-load SQL statements in your system. This is done by ADDM, which automatically
identifies high-load SQL statements that are good candidates for tuning.
However, major issues still remain: Although it is true that ADDM identifies some SQL that
should be tuned, users must manually look at ADDM reports and run SQL Tuning Advisor on
the reports for tuning.
Top SQL 2
SQL Tuning
SYSTOOLS
Reports
SYSTOOLS
Oracle Database 11g is as follows:
• Step 1: Based on the AWR Top SQL identification (SQLs that were top in four different
time periods: the past week, any day in the past week, any hour in the past week, or
single response time), Automatic SQL Tuning targets for automatic tuning.
• Steps 2 and 3: While the Automatic SQL Tuning task executes during the maintenance
window, the previously identified SQL statements are automatically tuned by invoking
SQL Tuning Advisor. As a result, SQL profiles are created for them if needed. However,
before making any decision, the new profile is carefully tested.
• Step 4: At any point in time, you can request a report about these automatic tuning
activities. You then have the option of checking the tuned SQL statements to validate or
remove the automatic SQL profiles that were generated.
SYSTOOLS
Not considered for
auto implementation
Automatic Tuning Process
Existing N 3X Y
Accept profile
Indexes profile? benefit?
N
Y
3X N
Ignore new profile.
SYSTOOLS
benefit?
Stale
stats Y
Replace profile.
GATHER_STATS_JOB
SYSTOOLS
In Oracle Database 11g, the performance improvement factor has to be at least three before a
SQL profile is implemented. As we have already mentioned, the Automatic SQL Tuning
process implements only SQL profile recommendations automatically. Other
recommendations (to create new indexes, refresh stale statistics, or restructure SQL
statements) are generated as part of the SQL tuning process, but are not implemented. These
are left for you to review and implement manually, as appropriate.
Here is a short description of the automatic tuning process in general:
Tuning is performed on a per-statement basis. Because only SQL profiles can be
implemented, there is no need to consider the effect of such recommendations on the
workload as a whole. For each statement (in the order of importance), the tuning process
carries out each of the following steps:
1. Tune the statement by using SQL Tuning Advisor. Look for a SQL profile and, if it is
found, verify that the base optimizer statistics are current for it.
2. If a SQL profile is recommended, perform the following:
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
A. Test the new SQL profile by executing the statement with and without it.
B. When a SQL profile is generated and it causes the optimizer to pick a different
execution plan for the statement, the advisor must decide whether to implement the
SYSTOOLS
SQL profile. It makes its decision according to the flowchart in the slide. Although
the benefit thresholds here apply to the sum of CPU and input/output (I/O) time, SQL
profiles are not accepted when there is degradation in either statistic. So the
requirement is that there is a three-time improvement in the sum of CPU and I/O
SYSTOOLS
SYSTOOLS
SYSTOOLS
Automatic SQL Tuning Controls
SYSTOOLS
– Test-execute mode disabled to save time
– Maximum number of SQL profiles automatically implemented
per execution as well as overall
– Task execution expiration period
SYSTOOLS
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'MAX_SQL_PROFILES_PER_EXEC', 50);
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'MAX_AUTO_SQL_PROFILES', 10002);
The last three parameters in this example are supported only for the Automatic SQL Tuning
task. You can also use parameters such as LOCAL_TIME_LIMIT or TIME_LIMIT, which are
valid parameters for the traditional SQL tuning tasks. An important example is to disable test-
execute mode (to save time) and to use only execution plan costs to decide about the
performance. The TEST_EXECUTE parameter setting determines whether the advisor actually
executes the statement and how much time it uses to execute.
In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources
that it is allowed to use.
SYSTOOLS
On the Automated Maintenance Tasks page, you see the predefined tasks. You then access
each task by clicking the corresponding link to get more information about the task itself
(illustrated in the slide). When you click either the Automatic SQL Tuning link or the latest
execution icon (the green area on the timeline), the Automatic SQL Tuning Result Summary
page opens.
Note: The execution time shown in this example is very small.
SYSTOOLS
Configuring Automatic SQL Tuning
SYSTOOLS
By default, Automatic SQL Tuning executes on all predefined maintenance windows in
MAINTENANCE_WINDOW_GROUP. You can disable it for specific days in the week. On this
page, you can also edit each Window to change its characteristics. You can do so by clicking
Edit Window Group.
To navigate to the Automatic SQL Tuning Settings page, click the Configure button on the line
corresponding to Automatic SQL Tuning in the Task Settings section.
On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the
slide. By default, "Automatic Implementation of SQL Profiles" is not selected.
Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using
DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop
Automatic SQL Tuning.
SYSTOOLS
Automatic SQL Tuning: Result Summary
SYSTOOLS
Customized is used; it shows you the latest run. You can select All to cover all executions of
the task so far. Users can request it for any time period over the past month, because that is
the amount of time for which the advisor persists its tuning history. You then generate the
report by clicking View Report.
On the “Breakdown by Finding Type” chart, you can clearly see that only SQL profiles can be
implemented. Although many more profiles were recommended, not all of them were
automatically implemented for the reasons that have already been explained. Similarly,
recommendations for index creation and other types are not implemented. However, the
advisor keeps historical information about all the recommendations if you want to implement
them later.
In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart,
which shows you the before-and-after DB Time for implemented profiles and other
recommendations.
SYSTOOLS
Automatic SQL Tuning: Result Details
SYSTOOLS
From this page, you can either drill down to the SQL statement itself by clicking its
corresponding SQL ID link, or you can select one of the SQL statements and click the View
Recommendations button to have more details about the recommendation for that statement.
Note: The benefit percentage shown for each recommendation is calculated using the formula
benefit% = (time_old - time_new)/(time_old). With this formula, you can see that a three-time
benefit (for example, time_old = 100, time_new = 33) corresponds to 66%. So the system
implements any profiles with benefits over 66%. According to this formula, 98% is a 50-times
benefit.
SYSTOOLS
Automatic SQL Tuning Result Details: Drilldown
SYSTOOLS
In the slide, you see that the statement was tuned by Automatic SQL Tuning and that the
associated profile was automatically implemented.
SYSTOOLS
Automatic SQL Tuning Considerations
SYSTOOLS
Automatic SQL Tuning Considerations
Automatic SQL Tuning does not seek to solve every SQL performance issue occurring on a
system. It does not consider the following types of SQL:
• Ad hoc or rarely repeated SQL statements: If a SQL statement is not executed multiple
times in the same form, the advisor ignores it. SQL statements that do not repeat within
a week are also not considered.
•
•
SYSTOOLS
Parallel queries
Long-running queries (after creating a profile): If a query takes too long to run after being
SQL profiled, it is not practical to test-execute and, therefore, it is ignored by the advisor.
Note that this does not mean that the advisor ignores all long-running queries. If the
advisor can find a SQL profile that causes a query that once took hours to run in
minutes, it could be accepted because test-execution is still possible. The advisor would
execute the old plan just long enough to determine that it is worse than the new one, and
then would terminate test-execution without waiting for the old plan to finish, thereby
switching the order of execution.
• Recursive SQL statements
• DMLs, such as INSERT SELECT or CREATE TABLE AS SELECT
With the exception of truly ad hoc SQL, these limitations apply to Automatic SQL Tuning only.
Such statements can still be tuned by manually running SQL Tuning Advisor.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Quiz
SYSTOOLS Quiz
SYSTOOLS
d. Automatically implements any recommended SQL profiles
Answer: a, c
The default settings for Automatic SQL Tuning task is to tune the top SQL statements after
prioritizing them based on the AWR Top SQL identification (SQLs that were top in four
different time periods: the past week, any day in the past week, any hour in the past week, or
single response time).
The time limit is 1200 seconds per statement by default (20 minutes).
SYSTOOLS
Work must stop when the window closes. If any SQL statements remain, they must wait for
the next maintenance window.
Any SQL profiles that are generated are not implemented by default, but you can change the
configuration so that they are automatically implemented.
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
SYSTOOLS
Practice 14: Overview
SYSTOOLS
SYSTOOLS
Chapter 15 - Page 2
SQL Plan Management
Objectives
SYSTOOLS
Objectives
SYSTOOLS
SYSTOOLS
SYSTOOLS
Maintaining SQL Performance
SYSTOOLS
Maintaining SQL Performance
Any number of factors that influence the optimizer can change over time. The challenge is to
maintain the SQL performance levels in spite of the changes.
Optimizer statistics change for many reasons. Managing the changes to SQL performance
despite the changes to statistics is the task of the DBA.
SYSTOOLS
Some SQL statements on any system will stand out as high-resource consumers. It is not
always the same statements. The performance of these statements must be tuned, without
having to change the code. SQL profiles provide the means to control the performance of
these statements.
SQL plan baselines are the key objects that SQL Plan Management uses to prevent unverified
change to SQL execution plans. When SQL Plan Management is active, there will not be
drastic changes in performance even as the statistics change or as the database version
changes. Until a new plan is verified to produce better performance than the current plan, it
will not be considered by the optimizer. This in effect freezes the SQL plan.
SQL Outlines have been used in past versions. They are still available for backward
compatibility, but Outlines are deprecated in favor of SQL Plan Management.
SYSTOOLS
SQL Plan Management: Overview
SYSTOOLS
SQL Plan Management: Overview
Potential performance risk occurs when the SQL execution plan changes for a SQL
statement.
A SQL plan change can occur due to a variety of reasons such as optimizer version, optimizer
statistics, optimizer parameters, schema definitions, system settings, and SQL profile creation.
Various plan control techniques are available in the Oracle Database to address performance
SYSTOOLS
regressions due to plan changes. The oldest is the use of hints in the SQL code to force a
specific access path. Stored outlines allowed the hints to be stored separate from the code
and modified. Both of these techniques focused on making the plan static. SQL profiles
created by the SQL Tuning Advisor allow the optimizer to collect and store additional statistics
that will guide the choice of a plan; if the plan becomes inefficient, the Tuning Advisor can be
invoked to produce a new profile.
SQL Plan Management automatically controls SQL plan evolution by maintaining what is
called “SQL plan baselines.” With this feature enabled, a newly generated SQL plan can join a
SQL plan baseline only if it has been proven that doing so will not result in performance
regression. So, during the execution of a SQL statement, only a plan that is part of the SQL
plan baseline can be used. As described later in this lesson, SQL plan baselines can be
automatically loaded or can be seeded using SQL tuning sets. Various scenarios are covered
later in this lesson.
The main benefit of the SQL Plan Management feature is performance stability of the system
by avoiding plan regressions. In addition, it saves the DBA time that is often spent in
identifying and analyzing SQL performance regressions and finding workable solutions.
SYSTOOLS
SYSTOOLS
SYSTOOLS
SQL Plan Baseline: Architecture
SYSAUX
SQL management base
HJ HJ
HJ
SYSTOOLS
HJ HJ
HJ Automatic
SQL tuning
task
SYSTOOLS
or executed again after it has been logged. After a SQL statement is recognized as
repeatable, various plans generated by the optimizer are maintained as a plan history
containing relevant information (such as SQL text, outline, bind variables, and compilation
environment) that is used by the optimizer to reproduce an execution plan.
The DBA may also add plans to the SQL plan baseline by manual seeding a set of SQL
statements.
A plan history contains different plans generated by the optimizer for a SQL statement over
time. However, only some of the plans in the plan history may be accepted for use. For
example, a new plan generated by the optimizer is not normally used until it has been verified
not to cause a performance regression. Plan verification is done by default as part of the
Automatic SQL Tuning task running as an automated task in a maintenance window.
An Automatic SQL Tuning task targets only high-load SQL statements. For those statements,
it automatically implements actions such as making a successfully verified plan an accepted
plan. A set of acceptable plans constitutes a SQL plan baseline. The very first plan generated
for a SQL statement is obviously acceptable for use; therefore, it forms the original plan
baseline. Any new plans subsequently found by the optimizer are part of the plan history but
not part of the plan baseline initially.
SYSTOOLS
The statement log, plan history, and plan baselines are stored in the SQL management base
(SMB), which also contains SQL profiles. The SMB is part of the database dictionary and is
stored in the SYSAUX tablespace. The SMB has automatic space management (for example,
SYSTOOLS
SYSTOOLS
GB
1 HJ
HJ
GB
HJ
HJ
GB
2 HJ
HJ
GB
B
HJ
3 A
HJ
SYSTOOLS
Plan history
Staging
table
4
GB Cursor
HJ cache
HJ
DBA
SYSTOOLS
repeatable SQL statements and automatic creation of plan history for such statements.
This is illustrated in the graphic on the left in the slide, where the first generated SQL
plan is automatically integrated into the original SQL plan baseline when it becomes a
repeating SQL statement.
• Bulk loading: Uses the DBMS_SPM package, which enables you to manually manage
SQL plan baselines. With procedures from this package, you can load SQL plans into a
SQL plan baseline directly from the cursor cache ( A ) using
LOAD_PLANS_FROM_CURSOR_CACHE or from an existing SQL tuning set (STS) (B)
using LOAD_PLANS_FROM_SQLSET. For a SQL statement to be loaded into a SQL plan
baseline from an STS, the plan for the SQL statement needs to be stored in the STS.
DBMS_SPM.ALTER_SQL_PLAN_BASELINE enables you to enable and disable a
baseline plan and change other plan attributes. To move baselines between databases,
use the DBMS_SPM.*_STGTAB_BASELINE procedures to create a staging table, and to
export and import baseline plans from a staging table. The staging table can be moved
between databases using the Data Pump Export and Import utilities.
SYSTOOLS
SYSTOOLS
Automatic GB
SQL Tuning
HJ
HJ
DBA GB
HJ
HJ
>?
SYSTOOLSSQL
Tuning
Advisor
SYSTOOLS
to the performance of one plan selected from the SQL plan baseline and ensuring that it
delivers better performance.
There are two ways to evolve SQL plan baselines:
• By using the DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE function: An example is
shown in the slide. The function returns a report that tells you whether some of the
existing history plans were moved to the plan baseline. The example specifies a specific
plan in the history to be tested. The function also allows verification without accepting
the plan.
• By running SQL Tuning Advisor: SQL plan baselines can be evolved by manually or
automatically tuning SQL statements using SQL Tuning Advisor. When SQL Tuning
Advisor finds a tuned plan and verifies its performance to be better than a plan chosen
from the corresponding SQL plan baseline, it makes a recommendation to accept a SQL
profile. When the SQL profile is accepted, the tuned plan is added to the corresponding
SQL plan baseline.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Important Baseline SQL Plan Attributes
GB
GB
Enabled but HJ Enabled and
not accepted HJ
HJ
accepted
HJ
SYSTOOLS
8.062E+18 SYS_SQL_e23f select.. SQL_PLAN_f4gy… AUTO-CAPTURE YES YES NO YES
…
SYSTOOLS
CAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning
Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTO-
SQLTUNE).
• ENABLED and ACCEPTED: Both the ENABLED and ACCEPTED attributes must be set to
YES or the plan is not considered by the optimizer. The ENABLED attribute means that
the plan is enabled for use by the optimizer. The ACCEPTED attribute means that the
plan was validated as a good plan, either automatically by the system or manually when
the user changes it to ACCEPTED. When a plan status changes to ACCEPTED, it will
continue to be ACCEPTED until DBMS_SPM.ALTER_SQL_PLAN_BASELINE() is used to
change its status. An ACCEPTED plan can be temporarily disabled by removing the
ENABLED setting.
• FIXED means that the optimizer considers only those plans and not other plans. For
example, if you have 10 baseline plans and three of them are marked FIXED, the
optimizer uses only the best plan from these three, ignoring all the others. A SQL plan
baseline is said to be FIXED if it contains at least one enabled fixed plan. If new plans
are added to a fixed SQL plan baseline, these new plans cannot be used until they are
manually declared as FIXED. You can look at each plan’s attributes by using the
SYSTOOLS
DBA_SQL_PLAN_BASELINES view, as shown in the slide. You can then use the
DBMS_SPM.ALTER_SQL_PLAN_BASELINE function to change some of them. You can
also remove plans or a complete plan history by using the
SYSTOOLS
SYSTOOLS
Yes
Plan history
No Plan
GB
baseline
GB
HJ GB
… GB
Plan part HJ HJ HJ
HJ
HJ Yes of baseline? HJ HJ
No
SYSTOOLS
Select baseline plan
with lowest best cost.
GB GB GB GB
Yes No
HJ HJ < HJ HJ
HJ HJ HJ HJ
SYSTOOLS
TRUE (default value). Each time a SQL statement is compiled, the optimizer first uses the
traditional cost-based search method to build a best-cost plan. Then it tries to find a matching
plan in the SQL plan baseline. If a match is found, it proceeds as usual. If no match is found, it
first adds the new plan to the plan history, then calculates the cost of each accepted plan in
the SQL plan baseline, and picks the one with the lowest cost. The accepted plans are
reproduced using the outline that is stored with each of them. So the effect of having a SQL
plan baseline for a SQL statement is that the optimizer always selects one of the accepted
plans in that SQL plan baseline.
With SQL Plan Management, the optimizer can produce a plan that could be either a best-cost
plan or a baseline plan. This information is dumped in the other_xml column of the
plan_table upon explain plan. However, the optimizer can only use an accepted and
enabled baseline plan.
SYSTOOLS
Note: The Stored Outline feature is deprecated. To preserve backward compatibility, if a
stored outline for a SQL statement is active for the user session, the statement is compiled
using the stored outline. In addition, a plan generated by the optimizer using a stored outline is
not stored in the SMB even if automatic plan capture has been enabled for the session.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Possible SQL Plan Manageability Scenarios
Database Upgrade New Application Deployment
GB GB GB GB
HJ HJ HJ HJ
HJ HJ HJ HJ
No plan No plan
regressions regressions
DBA
SYSTOOLS
GB GB
HJ HJ
Well- GB
tuned HJ HJ HJ
plan HJ Well-tuned Baseline
plan plans
staging table
Oracle Database 10g Development database
SYSTOOLS
optimizer version.
• New application deployment: The deployment of a new application module means the
introduction of new SQL statements into the system. The software vendor can ship the
application software along with the appropriate SQL plan baselines for the new SQL
being introduced. Because of the plan baselines, the new SQL statements will initially
run with the plans that are known to give good performance under a standard test
configuration. However, if the customer system configuration is very different from the
test configuration, the plan baselines can be evolved over time to produce better
performance.
In both scenarios, you can use the automatic SQL plan capture after manual loading to make
sure that only better plans will be used for your applications in the future.
Note: In all scenarios in this lesson, assume that OPTIMIZER_USE_SQL_PLAN_BASELINES
is set to TRUE.
GB GB
HJ HJ
HJ HJ
Regressing
statements No plan
After O_F_E=11 regressions
change
optimizer_features_enable
SYSTOOLS GB
HJ
HJ
GB
HJ
HJ
GB
HJ
HJ
Well-tuned
plans
Oracle Database 10g
SYSTOOLS
set the optimizer_features_enable initialization parameter back to 11.2.0 and rerun
SQL Performance Analyzer for the STS.
SQL Performance Analyzer produces a report that lists a SQL statement whose plan has
regressed from 10g to 11g. For those SQL statements that are shown by SQL Performance
Analyzer to incur performance regression due to the new optimizer version, you can capture
their plans using an STS and then load them into the SMB.
This method represents the best form of the plan-seeding process because it helps prevent
performance regressions while preserving performance improvements upon database
upgrade.
SYSTOOLS
Loading a SQL Plan Baseline Automatically
Oracle Database 11g No plan
regressions
Oracle Database 11g No plan
regressions
optimizer_features_enable=10.2.0.2 optimizer_features_enable=11.1.0.1
optimizer_capture_sql_plan_baselines=true optimizer_capture_sql_plan_baselines=true
Plan baseline
SYSTOOLS
GB GB GB
GB
GB Well- HJ HJ HJ
HJ
HJ tuned HJ HJ HJ
HJ
HJ plans
SYSTOOLS
During this initial time period, because of the O_F_E parameter setting, the optimizer is able to
reproduce pre–Oracle Database 11g plans for a majority of the SQL statements. Because
automatic SQL plan capture is also enabled during this period, the pre–Oracle Database 11g
plans produced by the optimizer are captured as SQL plan baselines.
When the initial time period ends, you can remove the setting of O_F_E to take advantage of
the new optimizer version while incurring minimal or no plan regressions due to the plan
baselines. Regressed plans will use the previous optimizer version; nonregressed statements
will benefit from the new optimizer version.
SYSTOOLS
Purging SQL Management Base Policy
DBA_SQL_MANAGEMENT_CONFIG
53
SYSTOOLS
1% 10% 20% 50% space
SYSTOOLS
If SMB space exceeds the defined percentage limit, warnings are written to the alert log.
Warnings are generated weekly until the SMB space limit is increased, the size of SYSAUX is
increased, or the size of SMB is decreased by purging some of the SQL management objects
(such as SQL plan baselines or SQL profiles).
The space management of SQL plan baselines is done proactively using a weekly purging
task. The task runs as an automated task in the maintenance window. Any plan that has not
been used for more than 53 weeks is purged. However, you can configure SMB and change
the unused plan retention period to a value between 5 weeks and 523 weeks (a little more
than 10 years). To do so, use the DBMS_SPM.CONFIGURE procedure.
You can look at the current configuration settings for the SMB by examining the
DBA_SQL_MANAGEMENT_CONFIG view. In addition, you can manually purge the SMB by
using the DBMS_SPM.DROP_SQL_PLAN_BASELINE function (as shown in the example in the
slide).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Enterprise Manager and SQL Plan Baselines
SYSTOOLS
To navigate to this page, click the Server tab, and then click the SQL Plan Control entry in the
Query Optimizer section.
Quiz
SYSTOOLS Quiz
SYSTOOLS
d. Does not develop an execution plan; it uses enabled plans
in the baselines
e. Develops plans and adds them to the baselines as verified
Answer: b
The optimizer always develops an execution plan. Then it compares the plan with accepted
plans in the SQL baseline. If an accepted baseline exists, the baseline is used. If the plan
developed by the optimizer is different, it is stored in the plan history, but it is not part of the
baseline until it is verified and marked as accepted.
SYSTOOLS
Summary
SYSTOOLS Summary
SYSTOOLS
SYSTOOLS
SYSTOOLS
Practice 15: Overview
Using SQL Plan Management
SYSTOOLS
SYSTOOLS
Chapter 16 - Page 2
Using Optimizer Hints
Objectives
SYSTOOLS
Objectives
SYSTOOLS
– Views
SYSTOOLS
SYSTOOLS
Optimizer Hints: Overview
SYSTOOLS
comment about that hint.
SYSTOOLS
optimal execution plan. This is illustrated in the slide example where you force the optimizer to
use the EMPFIRSTNAME_IDX index to retrieve the data. As you can see, you can use
comments in a SQL statement to pass instructions to the optimizer.
The plus sign (+) causes the system to interpret the comment as a list of hints. The plus sign
must follow immediately after the comment delimiter. No space is permitted.
Hints should be used sparingly, and only after you have collected statistics on the relevant
tables and evaluated the optimizer plan without hints using the EXPLAIN PLAN statement.
Changing database conditions as well as query performance enhancements in subsequent
releases can have a significant impact on how hints in your code affect performance.
In addition, the use of hints involves extra code that must be managed, checked, and
controlled.
Types of Hints
SYSTOOLS
Types of Hints
Single-table: Single-table hints are specified on one table or view. INDEX and USE_NL are
examples of single-table hints.
Multitable: Multitable hints are like single-table hints, except that the hint can specify one or
more tables or views. LEADING is an example of a multitable hint.
SYSTOOLS
Query block: Query block hints operate on single query blocks. STAR_TRANSFORMATION
and UNNEST are examples of query block hints.
Statement: Statement hints apply to the entire SQL statement. ALL_ROWS is an example of a
statement hint.
Note: USE_NL(table1 table2) is not considered a multitable hint because it is actually a
shortcut for USE_NL(table1) and USE_NL(table2).
Specifying Hints
SYSTOOLS
MERGE
SELECT
INSERT --+ hint
UPDATE comment
text
DELETE
Specifying Hints
Hints apply to the optimization of only the block of the statement in which they appear. A
statement block is:
• A simple MERGE, SELECT, INSERT, UPDATE, or DELETE statement
• A parent statement or a subquery of a complex statement
SYSTOOLS
• A part of a compound query using set operators (UNION, MINUS, INTERSECT)
For example, a compound query consisting of two component queries combined by the
UNION operator has two blocks, one for each component query. For this reason, hints in the
first component query apply only to its optimization, not to the optimization of the second
component query.
SYSTOOLS
• The optimizer ignores hints specified incorrectly without
raising errors.
SYSTOOLS
• Hints apply to only the statement block in which they appear and override instance- or
session-level parameters.
• If a SQL statement uses aliases, hints must reference the aliases rather than the table
names.
The Oracle optimizer ignores incorrectly specified hints. However, be aware of the following
situations:
• You never get an error message.
• Other (correctly) specified hints in the same comment are considered.
• The Oracle optimizer also ignores combinations of conflicting hints.
Hint Recommendations
SYSTOOLS
Hint Recommendations
• Use hints as a last remedy when tuning SQL statements.
• Hints may prevent the optimizer from using better execution plans.
• Hints may become less valid (or even invalid) when the database structure or contents
change.
SYSTOOLS
SYSTOOLS
/
SYSTOOLS
0 UPDATE STATEMENT Optimizer=ALL_ROWS (Cost=3 …)
1 0 UPDATE OF 'PRODUCTS'
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'PRODUCTS' (TABLE) (Cost…)
3 2 INDEX (RANGE SCAN) OF 'PRODUCTS_PROD_CAT_IX' (INDEX)
(cost…)
4 1 TABLE ACCESS (BY INDEX ROWID) OF 'PRODUCTS' (TABLE) (Cost…)
5 4 INDEX (UNIQUE SCAN) OF 'PRODUCTS_PK' (INDEX (UNIQUE))
(Cost=0 …)
The hint shown in the example works only if an index called PRODUCTS_PROD_CAT_IX exists
on the PRODUCTS table in the PROD_CATEGORY column.
Hint Categories
SYSTOOLS
Hint Categories
Most of these hints are discussed in the following slides. Many of these hints accept the table
and index names as arguments.
Note: Hints for parallel execution is not covered in this course.
SYSTOOLS
SYSTOOLS
Optimization Goals and Approaches
SYSTOOLS
Note: The ALTER SESSION... SET OPTIMIZER_MODE
statement does not affect SQL that is run from within PL/SQL.
SYSTOOLS
to select the plan that returns the first n rows most efficiently. The FIRST_ROWS hint, which
optimizes for the best plan to return the first single row, is retained for backward compatibility
and plan stability. The optimizer ignores this hint SELECT statement blocks that include any
blocking operations, such as sorts or groupings. Such statements cannot be optimized for
best response time because Oracle Database must retrieve all rows accessed by the
statement before returning the first row. If you specify this hint in any such statement, the
database optimizes for best throughput.
If you specify either the ALL_ROWS or the FIRST_ROWS(n) hint in a SQL statement, and if the
data dictionary does not have statistics about tables accessed by the statement, then the
optimizer uses default statistical values to estimate the missing statistics and to subsequently
select an execution plan.
If you specify hints for access paths or join operations along with either the ALL_ROWS or
FIRST_ROWS(n) hint, the optimizer gives precedence to the access paths and join operations
specified by the hints.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Note: The FIRST_ROWS hints are probably the most useful hints.
SYSTOOLS
SYSTOOLS
SYSTOOLS
INDEX_ASC Scans an index in ascending order
INDEX_COMBINE Explicitly chooses a bitmap access path
SYSTOOLS
The table name in the hint should not include the schema name if the schema name is
present in the statement.
FULL: The FULL hint explicitly selects a full table scan for the specified table. For example:
SELECT /*+ FULL(e) */ employee_id, last_name
FROM hr.employees e WHERE last_name LIKE 'K%';
The Oracle server performs a full table scan on the employees table to execute this
statement, even if there is an index on the last_name column that is made available by the
condition in the WHERE clause.
CLUSTER: The CLUSTER hint instructs the optimizer to use a cluster scan to access the
specified table. This hint applies only to clustered tables.
HASH: The HASH hint instructs the optimizer to use a hash scan to access the specified table.
This hint applies only to tables stored in a table cluster.
ROWID: The ROWID hint explicitly chooses a table scan by ROWID for the specified table.
INDEX: The INDEX hint explicitly chooses an index scan for the specified table. You can use
the INDEX hint for domain, B*-tree, bitmap, and bitmap join indexes. However, it is better if
SYSTOOLS
you use INDEX_COMBINE rather than INDEX for bitmap indexes because it is a more versatile
hint. This hint can optionally specify one or more indexes.
If this hint specifies a single available index, the optimizer performs a scan on this index. The
optimizer does not consider a full table scan or a scan on another index on the table.
SYSTOOLS
ascending order of their indexed values. Because the server’s default behavior for a range
scan is to scan index entries in the ascending order of their indexed values, this hint does not
specify anything more than the INDEX hint. However, you might want to use the INDEX_ASC
hint to specify ascending range scans explicitly, should the default behavior change.
INDEX_COMBINE: The INDEX_COMBINE hint explicitly chooses a bitmap access path for the
table. If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer uses a
Boolean combination of bitmap indexes that has the best cost estimate for the table. If certain
indexes are given as arguments, the optimizer tries to use some Boolean combination of
those particular bitmap indexes.
For example:
SELECT /*+INDEX_COMBINE(customers cust_gender_bix cust_yob_bix)*/ *
FROM customers WHERE cust_year_of_birth < 70 AND cust_gender = 'M';
Note: For INDEX, INDEX_FFS, and INDEX_SS, there are counter hints, NO_INDEX,
NO_INDEX_FFS, and NO_INDEX_SS, respectively to avoid using those paths.
SYSTOOLS
SYSTOOLS
Hints for Access Paths (continued)
INDEX_JOIN: The INDEX_JOIN hint explicitly instructs the optimizer to use an index join as
an access path. For the hint to have a positive effect, a sufficiently small number of indexes
must exist that contain all the columns required to resolve the query.
For example, the following query uses an index join to access the employee_id and
SYSTOOLS
department_id columns, both of which are indexed in the employees table:
SELECT /*+index_join(employees emp_emp_id_pk emp_department_ix)*/
employee_id, department_id
FROM hr.employees WHERE department_id > 50;
INDEX_DESC: The INDEX_DESC hint instructs the optimizer to use a descending index scan
for the specified table. If the statement uses an index range scan and the index is ascending,
the system scans the index entries in the descending order of their indexed values. In a
partitioned index, the results are in the descending order within each partition. For a
descending index, this hint effectively cancels out the descending order, resulting in a scan of
the index entries in the ascending order. The INDEX_DESC hint explicitly chooses an index
scan for the specified table.
For example:
SYSTOOLS
any of the specified indexes. Other indexes that are not specified in the list are still
considered.
• If this hint specifies no indexes, the optimizer does not consider a scan on any index on
the table. This behavior is the same as a NO_INDEX hint that specifies a list of all
available indexes for the table.
The NO_INDEX hint applies to function-based, B*-tree, bitmap, or domain indexes. If a
NO_INDEX hint and an index hint (INDEX, INDEX_ASC, INDEX_DESC, INDEX_COMBINE, or
INDEX_FFS) both specify the same indexes, then both the NO_INDEX hint and the index hint
are ignored for the specified indexes and the optimizer considers the specified indexes.
For example:
SELECT /*+NO_INDEX(employees emp_empid)*/ employee_id
FROM employees WHERE employee_id > 200;
SYSTOOLS
SYSTOOLS
The INDEX_COMBINE Hint: Example
SYSTOOLS
The INDEX_COMBINE Hint: Example
The INDEX_COMBINE hint is designed for bitmap index operations. Remember the following:
• If certain indexes are given as arguments for the hint, the optimizer tries to use some
combination of those particular bitmap indexes.
• If no indexes are named in the hint, all indexes are considered to be hinted.
SYSTOOLS
• The optimizer always tries to use hinted indexes, whether or not it considers them to be
cost effective.
In the example in the slide, suppose that all the three columns that are referenced in the
WHERE predicate of the statement in the slide (CUST_MARITAL_STATUS, CUST_GENDER, and
CUST_YEAR_OF_BIRTH) have a bitmap index. When you enable AUTOTRACE, the execution
plan of the statement might appear as shown in the next slide.
SYSTOOLS
The INDEX_COMBINE Hint: Example
SYSTOOLS
| 8 | BITMAP INDEX SINGLE VALUE| CUST_GENDER_BIX
SYSTOOLS
• BITMAP AND: Computes the bitwise AND of two bitmaps
• BITMAP INDEX SINGLE VALUE: Looks up the bitmap for a single key
• BITMAP INDEX RANGE SCAN: Retrieves bitmaps for a value range
• BITMAP MERGE: Merges several bitmaps resulting from a range scan into one (using a bitwise
AND operator)
SYSTOOLS
Hints for Query Transformation
SYSTOOLS
UNNEST
surrounding query block
NO_UNNEST Turns off unnesting
SYSTOOLS
query to be transformed into a compound query using the UNION ALL set operator. Generally,
this transformation occurs only if the cost of the query using the concatenations is cheaper
than the cost without them. The USE_CONCAT hint disables IN-list processing.
NO_EXPAND: The NO_EXPAND hint prevents the cost-based optimizer from considering OR-
expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the
optimizer considers using OR expansion and uses this method if it decides that the cost is
lower than not using it.
REWRITE: The REWRITE hint instructs the optimizer to rewrite a query in terms of materialized
views, when possible, without cost consideration. Use the REWRITE hint with or without a view
list. This course does not deal with Materialized Views.
UNNEST: The UNNEST hint instructs the optimizer to unnest and merge the body of the
subquery into the body of the query block that contains it, allowing the optimizer to consider
them together when evaluating access paths and joins.
SYSTOOLS
Hints for Query Transformation
SYSTOOLS
NO_FACT Indicates that the hinted table should
not be considered as a fact table
SYSTOOLS
subquery is not correlated.
When the MERGE hint is used without an argument, it should be placed in the view query
block. When MERGE is used with the view name as an argument, it should be placed in the
surrounding query.
NO_MERGE: The NO_MERGE hint causes the Oracle server not to merge views that can be
merged. This hint gives the user more influence over the way in which the view is accessed.
When the NO_MERGE hint is used without an argument, it should be placed in the view query
block. When NO_MERGE is used with the view name as an argument, it should be placed in the
surrounding query.
STAR_TRANSFORMATION: The STAR_TRANSFORMATION hint causes the optimizer to use the
best plan in which the transformation has been used. Without the hint, the optimizer could
make a cost-based decision to use the best plan that is generated without the transformation,
instead of the best plan for the transformed query.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Even if the hint is given, there is no guarantee that the transformation will take place. The
optimizer generates the subqueries only if it seems reasonable to do so. If no subqueries are
generated, there is no transformed query, and the best plan for the untransformed query is
used regardless of the hint.
SYSTOOLS
FACT: The FACT hint is used in the context of the star transformation to indicate to the
transformation that the hinted table should be considered as a fact table.
NO_FACT: The NO_FACT hint is used in the context of the star transformation to indicate to the
SYSTOOLS
SYSTOOLS
SYSTOOLS
Hints for Join Orders
The following hints are used to suggest join orders:
ORDERED: The ORDERED hint causes the Oracle server to join tables in the order in which they
appear in the FROM clause. If you omit the ORDERED hint from a SQL statement performing a
join, the optimizer selects the order in which to join the tables. You might want to use the
SYSTOOLS
ORDERED hint to specify a join order if you know something that the optimizer does not know
about the number of rows that are selected from each table. With a nested loops example, the
most precise method is to order the tables in the FROM clause in the order of the keys in the
index, with the large table at the end. Then use the following hints:
/*+ ORDERED USE_NL(FACTS) INDEX(facts fact_concat) */
Here, facts is the table and fact_concat is the index. A more general method is to use the
STAR hint.
LEADING: The LEADING hint instructs the optimizer to use the specified set of tables as the
prefix in the execution plan. The LEADING hint is ignored if the tables specified cannot be
joined first in the order specified because of dependencies in the join graph. If you specify two
or more LEADING hints on different tables, all the hints are ignored. If you specify the
ORDERED hint, it overrides all LEADING hints.
SYSTOOLS
USE_HASH Joins the specified table using a hash join
NO_USE_HASH Does not use hash join
DRIVING_SITE Instructs the optimizer to execute the query at
a different site than that selected by the
database
SYSTOOLS
The Oracle server uses these hints when the referenced table is forced to be the inner table of
a join; the hints are ignored if the referenced table is the outer table.
USE_NL: The USE_NL hint causes the Oracle server to join each specified table to another
row source with a nested loops join, using the specified table as the inner table. If you want to
optimize the statement for best response time or for the minimal elapsed time that is
necessary to return the first row selected by the query, rather than for best throughput, then
you can force the optimizer to select a nested loop join by using the USE_NL hint.
USE_NL_WITH_INDEX: The USE_NL_WITH_INDEX hint is similar to the USE_NL hint.
However, if no index is specified, the optimizer must be able to use some index with at least
one join predicate as the index key. If an index is specified, the optimizer must be able to use
that index with at least one join predicate as the index key.
NO_USE_NL: The NO_USE_NL hint causes the optimizer to exclude the nested loops join.
However, in some cases tables can only be joined using nested loops. In such cases, the
optimizer ignores the hint for those tables.
In many cases, a nested loop join returns the first row faster than a sort-merge join does. A
SYSTOOLS
nested loop join can return the first row after reading the first selected row from one table and
the first matching row from the other and combining them. But a sort-merge join cannot return
the first row until after reading and sorting all selected rows of both tables and then combining
the first rows of each sorted row source.
SYSTOOLS
another row source by using a sort-merge join, as in the following example:
SELECT /*+USE_MERGE(employees departments)*/ * FROM employees,
departments WHERE employees.department_id =
departments.department_id;
NO_USE_MERGE: The NO_USE_MERGE hint causes the optimizer to exclude the sort-merge
join to join each specified table to another row source using the specified table as the inner
table.
USE_HASH: The USE_HASH hint causes the Oracle server to join each specified table with
another row source using a hash join, as in the following example:
SELECT /*+USE_HASH(l l2) */ l.order_date, l.order_id,
l2.product_id, SUM(l2.unit_price*quantity)
FROM oe.orders l, oe.order_items l2
WHERE l.order_id = l2.order_id
GROUP BY l2.product_id, l.order_date, l.order_id;
Here is another example:
SYSTOOLS
SELECT /*+use_hash(employees departments)*/ *
FROM hr.employees, hr.departments
WHERE employees.department_id = departments.department_id;
NO_USE_HASH: The NO_USE_HASH hint causes the optimizer to exclude the hash join to join
each specified table to another row source using the specified table as the inner table.
DRIVING_SITE: This hint instructs the optimizer to execute the query at a different site than
that selected by the database. This hint is useful if you are using distributed query optimization
to decide on which site a join should be executed.
Additional Hints
SYSTOOLS
PUSH_SUBQ
DYNAMIC_SAMPLING Controls dynamic sampling to
improve server performance
Additional Hints
APPEND: The APPEND hint lets you enable direct-path INSERT if your database runs in serial
mode. Your database is in serial mode if you are not using Enterprise Edition. Conventional
INSERT is the default in serial mode, and direct-path INSERT is the default in parallel mode.
In direct-path INSERT, data is appended to the end of the table rather than using existing
space currently allocated to the table. As a result, direct-path INSERT can be considerably
SYSTOOLS
faster than the conventional INSERT.
Note: In Enterprise Edition, a session must be placed in parallel mode for direct-path insert to
be the default.
NOAPPEND: The NOAPPEND hint disables direct-path INSERT by disabling parallel mode for
the duration of the INSERT statement. (Conventional INSERT is the default in serial mode,
and direct-path INSERT is the default in parallel mode.)
CURSOR_SHARING_EXACT: The Oracle server can replace literals in SQL statements with
bind variables if it is safe to do so. This is controlled with the CURSOR_SHARING startup
parameter. The CURSOR_SHARING_EXACT hint causes this behavior to be disabled. In other
words, the Oracle server executes the SQL statement without any attempt to replace literals
with bind variables.
CACHE: The CACHE hint instructs the optimizer to place the blocks retrieved for the table in the
corresponding hot part of the buffer cache when a full table scan is performed. This hint is
useful for small lookup tables.
SYSTOOLS
The CACHE and NOCACHE hints affect system statistics table scans (long tables) and table
scans (short tables), as shown in the V$SYSSTAT data dictionary view.
PUSH_PRED: The PUSH_PRED hint instructs the optimizer to push a join predicate into the
view.
SYSTOOLS
Consider the following example:
SELECT /*+ dynamic_sampling(1) */ * FROM ...
This example enables dynamic sampling if all the following conditions are true:
• There is more than one table in the query.
• At least one table has not been analyzed and has no indexes.
• The optimizer determines that a relatively expensive table scan is required for the table
that has not been analyzed.
SYSTOOLS
Additional Hints
SYSTOOLS
query duration
SYSTOOLS
RESULT_CACHE: The RESULT_CACHE hint instructs the database to cache the results of the
current query or query fragment in memory and then to use the cached results in future
executions of the query or query fragment.
NO_RESULT_CACHE: The optimizer caches query results in the result cache if the
RESULT_CACHE_MODE initialization parameter is set to FORCE. In this case, the
NO_RESULT_CACHE hint disables such caching for the current query.
OPT_PARAM: The OPT_PARAM hint lets you set an initialization parameter for the duration of
the current query only. This hint is valid only for the following parameters:
OPTIMIZER_DYNAMIC_SAMPLING, OPTIMIZER_INDEX_CACHING,
OPTIMIZER_INDEX_COST_ADJ, OPTIMIZER_SECURE_VIEW_MERGING, and
STAR_TRANSFORMATION_ENABLED
SYSTOOLS
Hints and Views
You should not use hints in or on views because views can be defined in one context and
used in another; such hints can result in unexpected plans. In particular, hints in views are
handled differently from hints on views depending on whether or not the view is mergeable
into the top-level query.
SYSTOOLS
View Optimization
The statement is normally transformed into an equivalent statement that accesses the view’s
base tables. The optimizer can use one of the following techniques to transform the
statement:
• Merge the view’s query into the referencing query block in the accessing statement.
• Push the predicate of the referencing query block inside the view.
When these transformations are impossible, the view’s query is executed and the result is
accessed as if it were a table. This appears as a VIEW step in execution plans.
Mergeable Views
The optimizer can merge a view into a referencing query block if the view definition does not
contain the following:
• Set operators (UNION, UNION ALL, INTERSECT, MINUS)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Hints and Mergeable Views
Optimization-approach and goal hints can occur in a top-level query or in views:
SYSTOOLS
statement), all access-method and join hints in the view are preserved when the view is
merged with the top-level query.
• For views that are not subqueries, access-method and join hints in the view are
preserved only if the top-level query references no other tables or views (that is, if the
FROM clause of the SELECT statement contains only the view).
SYSTOOLS
FROM
SYSTOOLS
SELECT /*+ index(v.c cust_credit_limit_idx) */
v.cust_last_name, v.cust_credit_limit
city_view v
WHERE cust_credit_limit > 5000;
SYSTOOLS
The table hints can be transformed into global hints by using an extended table specification
syntax that includes view names with the table name as shown in the slide. In addition, an
optional query block name can precede the table specification.
For example, by using the global hint structure, you can avoid the modification of a view with
the specification of an index hint in the body of view.
Note: If a global hint references a table name or alias that is used twice in the same query (for
example, in a UNION statement), the hint applies to only the first instance of the table (or
alias).
SYSTOOLS
Specifying a Query Block in a Hint
SYSTOOLS
|* 2 | TABLE ACCESS FULL| DEPT | 1 | 21 | 3 (0)|
|* 3 | TABLE ACCESS FULL| EMP | 3 | 60 | 3 (0)|
---------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$DB579D14
2 - SEL$DB579D14 / DEPT@STRANGE
3 - SEL$DB579D14 / E@SEL$1
SYSTOOLS
an identifier that specifies a query block in the query. The queryblock identifier can either be
system-generated or user-specified. When you specify a hint in the query block itself to which
the hint applies, you do not have to specify the @queryblock syntax.
The slide gives you an example. You can see that the SELECT statement uses an inline view.
The corresponding query block is given the name strange through the use of the QB_NAME
hint.
The example assumes that there is an index on the DEPTNO column of the DEPT table so that
the optimizer would normally choose that index to access the DEPT table. However, because
you specify the FULL hint to apply to the strange query block in the main query block, the
optimizer does not use the index in question. You can see that the execution plan exhibits a
full table scan on the DEPT table. In addition, the output of the plan clearly shows the system-
generated names for each query block in the original query.
SYSTOOLS
Specifying a Full Set of Hints
SYSTOOLS
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;
SYSTOOLS
necessarily use that hint because the optimizer might have determined that the requested
index cannot be used due to the join methods and access paths that were selected by the
optimizer.
In the example, the LEADING hint specifies the exact join order to be used. The join methods
to be used on the different tables are also specified.
Summary
SYSTOOLS Summary
SYSTOOLS
– Views
Summary
In this lesson, you should have learned about additional optimizer settings and hints.
By using hints, you can influence the optimizer at the statement level. Use hints as a last
remedy when tuning SQL statements. There are several hint categories, one of which
includes hints for access-path methods.
SYSTOOLS
To specify a hint, use the hint syntax in the SQL statement.
SYSTOOLS
Practice Appendix B: Overview
SYSTOOLS
SYSTOOLS
Chapter 17 - Page 2
Using SQL Developer
Objectives
SYSTOOLS
Objectives
SYSTOOLS
• Create and save reports
Objectives
In this appendix, you are introduced to the graphical tool called SQL Developer. You learn
how to use SQL Developer for your database development tasks. You learn how to use SQL
Worksheet to execute SQL statements and SQL scripts.
SYSTOOLS
SYSTOOLS
What Is Oracle SQL Developer?
SYSTOOLS
SQL Developer
SYSTOOLS
• 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 by using standard Oracle database
authentication. When connected, you can perform operations on objects in the database.
The SQL Developer tightly integrates with Developer Migration Workbench that provides
users with a single point to browse database objects and data in third-party databases, and to
migrate from these databases to an Oracle database. You can also connect to schemas for
selected third-party (non-Oracle) databases such as MySQL, Microsoft SQL Server, and
Microsoft Access, and you can view metadata and data in these databases.
Additionally, SQL Developer includes support for Oracle Application Express 3.0.1 (Oracle
APEX).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SYSTOOLS
Specifications of SQL Developer
SYSTOOLS
veloper/index.html
SYSTOOLS
Home is required. SQL Developer does not require an installer and you need to simply unzip
the downloaded file. With SQL Developer, users can connect to Oracle Databases 9.2.0.1 and
later, and all Oracle database editions including Express Edition.
Note
For Oracle Database versions earlier than Oracle Database 11g Release 2, you will have to
download and install SQL Developer. SQL Developer 2.1 is the current version and is freely
downloadable from the following link:
http://www.oracle.com/technology/products/database/sql_developer
/index.html.
For instructions on how to install SQL Developer 2.1, you can visit the following link:
http://download.oracle.com/docs/cd/E15846_01/index.htm
Files
You must define a
connection to start using
SQL Developer for
running SQL queries on a
database schema.
SYSTOOLS
SQL Developer 2.1 Interface
The SQL Developer 2.1 interface contains three main navigation tabs, from left to right:
• Connections tab: By using this tab, you can browse database objects and users to
which you have access.
• Files tab: Identified by the Files folder icon, this tab enables you to access files from
SYSTOOLS
your local machine without having to use the File > Open menu. This tab does not
appear by default, Use the View > Files menu to activate it.
• Reports tab: Identified by the Reports icon, this tab enables you to run predefined
reports or create and add your own reports.
Menus
The following menus contain standard entries, plus entries for features specific to SQL
Developer:
SYSTOOLS
• View: Contains options that affect what is displayed in the SQL Developer interface
• Navigate: Contains options for navigating to various panes and for executing
subprograms
SYSTOOLS
SYSTOOLS
SYSTOOLS
Creating a Database Connection
SYSTOOLS
By default, the tnsnames.ora file is located in the $ORACLE_HOME/network/admin
directory, but it can also be in the directory specified by the TNS_ADMIN environment variable
or registry value. You can use network service names defined in the tnsnames.ora file to
specify service names for you connections.
Note: On Windows, if the tnsnames.ora file exists but its connections are not being used by
SQL Developer, define TNS_ADMIN as a system environment variable.
Using the Connection dialog menu you can select Create Local connections which will create
a connection for every open account on the local database.
You can export connections to an XML file that you can reuse later.
You can create additional connections as different users to the same database or to connect
to the different databases.
SYSTOOLS
Creating a Database Connection
SYSTOOLS
Creating a Database Connection (continued)
To create a database connection, perform the following steps:
1. On the Connections tabbed page, right-click Connections and select New Connection.
2. In the New/Select Database Connection window, enter the connection name. Enter the
username and password of the schema that you want to connect to.
a) From the Role drop-down list, you can select either default or SYSDBA. (You
SYSTOOLS
choose SYSDBA for the sys user or any user with database administrator
privileges.)
b) You can select the connection type as:
- Basic: In this type, enter the host name and SID for the database you want to
connect to. Port is already set to 1521. Or you can also choose to enter the
Service name directly if you use a remote database connection.
- TNS: You can select any one of the database aliases imported from the
tnsnames.ora file.
- LDAP: You can look up database services in Oracle Internet Directory which
is a component of Oracle Identity Management.
- Advanced: You can define a custom JDBC URL to connect to the database.
c) Click Test to ensure that the connection has been set correctly.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
d) Click Connect
If you select the Save Password check box, the password is saved to an XML file. So,
after you close the SQL Developer connection and open it again, you are not prompted
SYSTOOLS
for the password.
3. The connection gets added in the Connections Navigator. You can expand the
connection to view the database objects and view object definitions—for example,
dependencies, details, statistics, and so on.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Browsing Database Objects
After you create a database connection, you can use the Connections Navigator to browse
through many objects in a database schema including Tables, Views, Indexes, Packages,
Procedures, Triggers, and Types.
You can see the definition of the objects broken into tabs of information that is pulled out of
the data dictionary. For example, if you select a table in the Navigator, the details about
SYSTOOLS
columns, constraints, grants, statistics, triggers, and so on are displayed on an easy-to-read
tabbed page.
If you want to see the definition of the EMPLOYEES table as shown in the slide, perform the
following steps:
1. Expand the Connections node in the Connections Navigator.
2. Expand Tables.
3. Click EMPLOYEES. By default, the Columns tab is selected. It shows the column
description of the table. Using the Data tab, you can view the table data and also enter
new rows, update data, and commit these changes to the database.
SYSTOOLS
Displaying the Table Structure
SYSTOOLS
Displaying the Table Structure
In SQL Developer, you can also display the structure of a table using the DESCRIBE
command. The result of the command is a display of column names and data types as well as
an indication if a column must contain data.
SYSTOOLS
Browsing Files
SYSTOOLS
Browsing Database Objects
You can use the File Navigator to browse and open system files.
• To view the files navigator, click the Files tab, or select View > Files.
• To view the contents of a file, double-click a file name to display its contents in the SQL
worksheet area.
SYSTOOLS
SYSTOOLS
Creating a Schema Object
SQL Developer supports the creation of any schema object by executing a SQL statement in
SQL Worksheet. Alternatively, you can create objects using the context menus. When
created, you can edit the objects using an edit dialog box or one of the many context-sensitive
menus.
As new objects are created or existing objects are edited, the DDL for those adjustments is
SYSTOOLS
available for review. An Export DDL option is available if you want to create the full DDL for
one or more objects in the schema.
The slide shows how to create a table using the context menu. To open a dialog box for
creating a new table, right-click Tables and select New Table. The dialog boxes to create and
edit database objects have multiple tabs, each reflecting a logical grouping of properties for
that type of object.
SYSTOOLS
Creating a New Table: Example
SYSTOOLS
The example in the slide shows how to create the DEPENDENTS table by selecting the
Advanced check box.
To create a new table, perform the following steps:
1. In the Connections Navigator, right-click Tables.
2. Select New TABLE.
3. In the Create Table dialog box, select Advanced.
4. Specify column information.
5. Click OK.
Although it is not required, you should also specify a primary key by using the Primary Key tab
in the dialog box. Sometimes, you may want to edit the table that you have created; to do so,
right-click the table in the Connections Navigator and select Edit.
SYSTOOLS
Select SQL Worksheet
from the Tools menu,
Click the Open SQL
Worksheet icon.
or
SYSTOOLS
You can specify actions that can be processed by the database connection associated with
the worksheet, such as:
• Creating a table
• Inserting data
• Creating and editing a trigger
• Selecting data from a table
• Saving the selected data to a file
You can display a SQL Worksheet by using one of the following:
• Select Tools > SQL Worksheet.
• Click the Open SQL Worksheet icon.
1 3 5 7 9
SYSTOOLS
Using the SQL Worksheet (continued)
You may want to use the shortcut keys or icons to perform certain tasks such as executing a
SQL statement, running a script, and viewing the history of SQL statements that you have
executed. You can use the SQL Worksheet toolbar that contains icons to perform the
following tasks:
1. Execute Statement: Executes the statement where the cursor is located in the Enter
SYSTOOLS
SQL Statement box. You can use bind variables in the SQL statements, but not
substitution variables.
2. Run Script: Executes all statements in the Enter SQL Statement box by using the Script
Runner. You can use substitution variables in the SQL statements, but not bind
variables.
3. Autotrace: Generates trace information for the statement
4. Execute Explain Plan: Generates the execution plan, which you can see by clicking the
Explain tab
5. Commit: Writes any changes to the database and ends the transaction
6. Rollback: Discards any changes to the database, without writing them to the database,
and ends the transaction
7. Unshared SQL Worksheet: Create a unshared SQL Worksheet
8. Change Case: Step through: To Uppercase, and Lower Case, and Initial Capitalization
9. Clear: Erases the statement or statements in the Enter SQL Statement box
10. SQL History: Displays a dialog box with information about SQL statements that you
SYSTOOLS
have executed
SYSTOOLS
Enter SQL
statements.
SYSTOOLS
The SQL Worksheet currently supports a number of SQL*Plus commands. Commands not
supported by the SQL Worksheet are ignored and are not sent to the Oracle database.
Through the SQL Worksheet, you can execute SQL statements and some of the SQL*Plus
commands.
You can display a SQL Worksheet by using any of the following two options:
• Select Tools > SQL Worksheet.
• Click the Open SQL Worksheet icon.
SYSTOOLS
Executing SQL Statements
The example in the slide shows the difference in output for the same query when the Run
Statement command (Ctrl+Enter key) is used versus the output when Run Script (F5 key) is
used.
SYSTOOLS
1
SYSTOOLS
Click the Save icon to
Saving SQL Scripts
SYSTOOLS
Saving SQL Scripts
You can save your SQL statements from the SQL Worksheet into a text file. To save the
contents of the Enter SQL Statement box, follow these steps:
1. Click the Save icon or use the File > Save menu item.
2. In the Windows Save dialog box, enter a file name and the location where you want the
SYSTOOLS
file saved.
3. Click Save.
After you save the contents to a file, the Enter SQL Statement window displays a tabbed page
of your file contents. You can have multiple files open at the same time. Each file displays as
a tabbed page.
Script Pathing
You can select a default path to look for scripts and to save scripts. Under Tools >
Preferences > Database > Worksheet Parameters, enter a value in the “Select default path to
look for scripts” field.
SYSTOOLS
Executing Saved Script Files: Method 1
SYSTOOLS
Executing Saved Script Files: Method 1
To open a script file and display the code in the SQL Worksheet area, perform the following:
1. In the files navigator, select (or navigate to) the script file that you want to open.
2. Double-click to open. The code of the script file is displayed in the SQL Worksheet area.
3. Select a connection from the connection drop-down list.
SYSTOOLS
4. To run the code, click the Run Script (F5) icon on the SQL Worksheet toolbar. If you
have not selected a connection from the connection drop-down list, a connection dialog
box will appear. Select the connection you want to use for the script execution.
Alternatively, you can also:
1. Select File > Open. The Open dialog box is displayed.
2. In the Open dialog box, select (or navigate to) the script file that you want to open.
3. Click Open. The code of the script file is displayed in the SQL Worksheet area.
4. Select a connection from the connection drop-down list.
5. To run the code, click the Run Script (F5) icon on the SQL Worksheet toolbar. If you
have not selected a connection from the connection drop-down list, a connection dialog
box will appear. Select the connection you want to use for the script execution.
SYSTOOLS
Executing Saved Script Files: Method 2
SYSTOOLS
The results from running the file are displayed on the Script Output tabbed page. You can also
save the script output by clicking the Save icon on the Script Output tabbed page. The
Windows Save dialog box appears and you can identify a name and location for your file.
After
formatting
SYSTOOLS
Formatting the SQL Code
You may want to beautify the indentation, spacing, capitalization, and line separation of the
SQL code. SQL Developer has a feature for formatting SQL code.
To format the SQL code, right-click in the statement area and select Format SQL.
In the example in the slide, before formatting, the SQL code has the keywords not capitalized
SYSTOOLS
and the statement not properly indented. After formatting, the SQL code is beautified with the
keywords capitalized and the statement properly indented.
Using Snippets
SYSTOOLS
Using Snippets
You may want to use certain code fragments when you use the SQL Worksheet or create or
edit a PL/SQL function or procedure. SQL Developer has the feature called Snippets.
Snippets are code fragments such as SQL functions, Optimizer hints, and miscellaneous
PL/SQL programming techniques. You can drag snippets into the Editor window.
To display Snippets, select View > Snippets.
SYSTOOLS
The Snippets window is displayed at the right side. You can use the drop-down list to select a
group.
Editing the
snippet
SYSTOOLS
Using Snippets: Example
To insert a Snippet into your code in a SQL Worksheet or in a PL/SQL function or procedure,
drag the snippet from the Snippets window into the desired place in your code. Then you can
edit the syntax so that the SQL function is valid in the current context. To see a brief
description of a SQL function in a tool tip, place the cursor over the function name.
The example in the slide shows that CONCAT(char1, char2)is dragged from the Character
SYSTOOLS
Functions group in the Snippets window. Then the CONCAT function syntax is edited and the
rest of the statement is added as in the following:
SELECT CONCAT(first_name, last_name)
FROM employees;
SYSTOOLS
Debugging Procedures and Functions
SYSTOOLS
options to set breakpoints,
and to perform the step
into and step over tasks.
SYSTOOLS
• Step Over bypasses the next method and goes to the next statement after the method.
• Step Into goes to the first statement in the next method.
• Step Out leaves the current method and goes to the next statement.
• Step to End of Method goes to the last statement of the current method.
• Pause halts execution but does not exit, thus allowing you to resume execution.
• Terminate halts and exits the execution. You cannot resume execution from this point;
instead, to start running or debugging from the beginning of the function or procedure,
click the Run or Debug icon on the Source tab toolbar.
• Garbage Collection removes invalid objects from the cache in favor of more frequently
accessed and more valid objects.
These options are also available as icons on the debugging toolbar.
Database Reporting
SYSTOOLS
Database Reporting
SQL Developer provides many reports about the database and its objects. These reports can
be grouped into the following categories:
• About Your Database reports
• Database Administration reports
SYSTOOLS
• Table reports
• PL/SQL reports
• Security reports
• XML reports
• Jobs reports
• Streams reports
• All Objects reports
• Data Dictionary reports
• User-Defined reports
To display reports, click the Reports tab at the left side of the window. Individual reports are
displayed in tabbed panes at the right side of the window; and for each report, you can select
(using a drop-down list) the database connection for which to display the report. For reports
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
about objects, the objects shown are only those visible to the database user associated with
the selected database connection, and the rows are usually ordered by Owner. You can also
create your own user-defined reports.
SYSTOOLS
SYSTOOLS
SYSTOOLS
Creating a User-Defined Report
SYSTOOLS
Organize reports in folders.
SYSTOOLS
information for the report. Then click Apply.
In the example in the slide, the report name is specified as emp_sal. An optional description
is provided indicating that the report contains details of employees with salary >= 10000.
The complete SQL statement for retrieving the information to be displayed in the user-defined
report is specified in the SQL box. You can also include an optional tool tip to be displayed
when the cursor stays briefly over the report name in the Reports navigator display.
You can organize user-defined reports in folders, and you can create a hierarchy of folders
and subfolders. To create a folder for user-defined reports, right-click the User Defined
Reports node or any folder name under that node and select Add Folder. Information about
user-defined reports, including any folders for these reports, is stored in a file named
UserReports.xml under the directory for user-specific information.
External Tools
SYSTOOLS 2
SYSTOOLS
1. From the Tools menu, select External Tools.
2. In the External Tools dialog box, perform the following:
A. Click New to invoke the wizard to add new tools.
B. Click Delete to remove any tool from the list.
C. Click Edit to invoke the wizard to modify the availability and parameters of the
selected tool.
Setting Preferences
SYSTOOLS
Setting Preferences
You can customize many aspects of the SQL Developer interface and environment by
modifying SQL Developer preferences according to your preferences and needs. To modify
SQL Developer preferences, select Tools, then Preferences.
The preferences are grouped into the following categories:
SYSTOOLS
• Environment
• Accelerators (keyboard shortcuts)
• Code Editors
• Database
• Debugger
• Documentation
• Extensions
• File Types
• Migration
• PL/SQL Compilers
• PL/SQL Debugger, and so on
SYSTOOLS
Resetting the SQL Developer Layout
SYSTOOLS
windowinglayout.xml.
3. Go to the directory which has windowinglayout.xml and delete it.
4. Restart SQL Developer.
Summary
SYSTOOLS Summary
SYSTOOLS
Summary
SQL Developer is a free graphical tool to simplify database development tasks. Using SQL
Developer, you can browse, create, and edit database objects. You can use SQL Worksheet
to run SQL statements and scripts. SQL Developer enables you to create and save your own
special set of reports for repeated use.
SYSTOOLS