Oracle Database 11g SQL Tuning Workshop.pdf
March 24, 2017 | Author: juanarru | Category: N/A
Short Description
Download Oracle Database 11g SQL Tuning Workshop.pdf...
Description
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
b fera
s
n a r t n-
Oracle Database no 11g: SQL a Tuning eฺ hasWorkshop
d
ahu
) Gui m o Student t c enGuide ฺ l i a d m Stu g 1@ this 2 y ja use i v u to sah
(
S
D52163GC20 Edition 2.0 October 2010 D69160
ns e c li
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Disclaimer This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract.
le
Trademark Notice
b fera
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
s
n a r t n-
Vij
no a has uideฺ ) Technical Contributors and Reviewers m tG o c ฺ l Abhinav Gupta, Branislav Valny, ClintonaShaffer, Donna i en Keesling, Ira Singer, Howard Bradley, d u Sean Kim, Sue Harper, Teria Kidd gm t S @ s 1 hi 2 t y e This book was published s Oracle Tutor ija using: u v u o t ah s ( hu a S ai Author James Spiller, Tulika Srivastava
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Table of Contents Exploring the Oracle Database Architecture .................................................................................................1-1 Exploring the Oracle Database Architecture ..................................................................................................1-2 Objectives ......................................................................................................................................................1-3 Oracle Database Server Architecture: Overview ............................................................................................1-4 Connecting to the Database Instance ............................................................................................................1-5 Oracle Database Memory Structures: Overview ............................................................................................1-7 Database Buffer Cache ..................................................................................................................................1-8 Redo Log Buffer .............................................................................................................................................1-9 Shared Pool ...................................................................................................................................................1-10 Processing a DML Statement: Example .........................................................................................................1-11 COMMIT Processing: Example ......................................................................................................................1-13 Large Pool ......................................................................................................................................................1-14 Java Pool and Streams Pool ..........................................................................................................................1-16 Program Global Area (PGA) ..........................................................................................................................1-17 Background Process ......................................................................................................................................1-18 Automatic Shared Memory Management .......................................................................................................1-20 Automated SQL Execution Memory Management .........................................................................................1-21 Automatic Memory Management ...................................................................................................................1-22 Database Storage Architecture ......................................................................................................................1-23 Logical and Physical Database Structures .....................................................................................................1-25 Segments, Extents, and Blocks......................................................................................................................1-27 SYSTEM and SYSAUX Tablespaces.............................................................................................................1-28 Quiz................................................................................................................................................................1-29 Summary ........................................................................................................................................................1-32 Practice 1: Overview ......................................................................................................................................1-33
le
b fera
s
n a r t n-
Vija
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e s ija.............................................................................................................................2-1 Introduction to SQL Tuning u v u o t h Tuning ............................................................................................................................2-2 Introduction toaSQL s Objectives( ......................................................................................................................................................2-3 hu for Inefficient SQL Performance ......................................................................................................2-4 Reasons a S i
Inefficient SQL: Examples ..............................................................................................................................2-6 Performance Monitoring Solutions .................................................................................................................2-8 Monitoring and Tuning Tools: Overview .........................................................................................................2-10 EM Performance Pages for Reactive Tuning .................................................................................................2-11 Tuning Tools: Overview .................................................................................................................................2-12 SQL Tuning Tasks: Overview.........................................................................................................................2-14 CPU and Wait Time Tuning Dimensions ........................................................................................................2-15 Scalability with Application Design, Implementation, and Configuration ........................................................2-16 Common Mistakes on Customer Systems .....................................................................................................2-17 Proactive Tuning Methodology .......................................................................................................................2-19 Simplicity in Application Design......................................................................................................................2-20 Data Modeling ................................................................................................................................................2-21 Table Design ..................................................................................................................................................2-22 Index Design ..................................................................................................................................................2-23 Using Views ...................................................................................................................................................2-24 SQL Execution Efficiency ...............................................................................................................................2-25 Writing SQL to Share Cursors ........................................................................................................................2-27 Performance Checklist ...................................................................................................................................2-29 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents i
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
Development Environments: Overview ..........................................................................................................2-30 What Is Oracle SQL Developer? ....................................................................................................................2-31 Coding PL/SQL in SQL*Plus ..........................................................................................................................2-32 Quiz................................................................................................................................................................2-34 Summary ........................................................................................................................................................2-38 Practice 2: Overview ......................................................................................................................................2-39 Introduction to the Optimizer ..........................................................................................................................3-1 Introduction to the Optimizer ..........................................................................................................................3-2 Objectives ......................................................................................................................................................3-3 Structured Query Language ...........................................................................................................................3-4 SQL Statement Representation .....................................................................................................................3-6 SQL Statement Implementation .....................................................................................................................3-7 SQL Statement Processing: Overview ...........................................................................................................3-8 SQL Statement Processing: Steps .................................................................................................................3-9 Step 1: Create a Cursor .................................................................................................................................3-10 Step 2: Parse the Statement ..........................................................................................................................3-11 Steps 3 and 4: Describe and Define...............................................................................................................3-12 Steps 5 and 6: Bind and Parallelize ...............................................................................................................3-13 Steps 7 Through 9..........................................................................................................................................3-14 SQL Statement Processing PL/SQL: Example ..............................................................................................3-15 SQL Statement Parsing: Overview.................................................................................................................3-16 Why Do You Need an Optimizer? ..................................................................................................................3-18 Optimization During Hard Parse Operation ....................................................................................................3-20 Transformer: OR Expansion Example............................................................................................................3-21 Transformer: Subquery Unnesting Example ..................................................................................................3-22 Transformer: View Merging Example .............................................................................................................3-23 Transformer: Predicate Pushing Example ......................................................................................................3-24 Transformer: Transitivity Example..................................................................................................................3-25 Cost-Based Optimizer ....................................................................................................................................3-26 Estimator: Selectivity ......................................................................................................................................3-27 Estimator: Cardinality .....................................................................................................................................3-29 Estimator: Cost...............................................................................................................................................3-30 Plan Generator ...............................................................................................................................................3-31 Controlling the Behavior of the Optimizer .......................................................................................................3-32 Optimizer Features and Oracle Database Releases ......................................................................................3-37 Quiz................................................................................................................................................................3-38 Summary ........................................................................................................................................................3-41 Practice 3: Overview ......................................................................................................................................3-42
le
b fera
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
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.
Oracle Database 11g: SQL Tuning Workshop Table of Contents ii
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
The EXPLAIN PLAN Command .....................................................................................................................4-18 Displaying from PLAN_TABLE: ADVANCED .................................................................................................4-19 Explain Plan Using SQL Developer................................................................................................................4-20 AUTOTRACE .................................................................................................................................................4-21 The AUTOTRACE Syntax ..............................................................................................................................4-22 AUTOTRACE: Examples ...............................................................................................................................4-23 AUTOTRACE: Statistics .................................................................................................................................4-24 AUTOTRACE Using SQL Developer .............................................................................................................4-26 Using the V$SQL_PLAN View .......................................................................................................................4-27 The V$SQL_PLAN Columns ..........................................................................................................................4-28 The V$SQL_PLAN_STATISTICS View..........................................................................................................4-29 Links Between Important Dynamic Performance Views .................................................................................4-30 Querying V$SQL_PLAN .................................................................................................................................4-32 Automatic Workload Repository (AWR) .........................................................................................................4-34 Managing AWR with PL/SQL .........................................................................................................................4-36 Important AWR Views ....................................................................................................................................4-38 Querying the AWR .........................................................................................................................................4-40 Generating SQL Reports from AWR Data ......................................................................................................4-42 SQL Monitoring: Overview .............................................................................................................................4-43 SQL Monitoring Report: Example...................................................................................................................4-45 Interpreting an Execution Plan .......................................................................................................................4-49 Execution Plan Interpretation: Example 1 ......................................................................................................4-51 Execution Plan Interpretation: Example 2 ......................................................................................................4-55 Execution Plan Interpretation: Example 3 ......................................................................................................4-57 Reading More Complex Execution Plans .......................................................................................................4-59 Reviewing the Execution Plan ........................................................................................................................4-60 Looking Beyond Execution Plans ...................................................................................................................4-62 Quiz................................................................................................................................................................4-63 Summary ........................................................................................................................................................4-67 Practice 4: Overview ......................................................................................................................................4-68
le
b fera
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Application Tracing..........................................................................................................................................5-1 Application Tracing.........................................................................................................................................5-2 Objectives ......................................................................................................................................................5-3 End-to-End Application Tracing Challenge ....................................................................................................5-4 End-to-End Application Tracing......................................................................................................................5-5 Location for Diagnostic Traces .......................................................................................................................5-6 What Is a Service? .........................................................................................................................................5-7 Using Services with Client Applications .........................................................................................................5-8 Tracing Services ............................................................................................................................................5-9 Use Enterprise Manager to Trace Services ...................................................................................................5-11 Service Tracing: Example ..............................................................................................................................5-12 Session Level Tracing: Example ....................................................................................................................5-14 Trace Your Own Session ...............................................................................................................................5-16 The trcsess Utility ...........................................................................................................................................5-17 Invoking the trcsess Utility ..............................................................................................................................5-18 The trcsess Utility: Example ...........................................................................................................................5-20 SQL Trace File Contents ................................................................................................................................5-21 SQL Trace File Contents: Example ................................................................................................................5-23 Formatting SQL Trace Files: Overview ..........................................................................................................5-24
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents iii
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
Invoking the tkprof Utility ................................................................................................................................5-26 tkprof Sorting Options ....................................................................................................................................5-28 Output of the tkprof Command .......................................................................................................................5-30 tkprof Output with No Index: Example ............................................................................................................5-35 tkprof Output with Index: Example .................................................................................................................5-36 Quiz................................................................................................................................................................5-37 Summary ........................................................................................................................................................5-40 Practice 5: Overview ......................................................................................................................................5-41 Optimizer Operators ........................................................................................................................................6-1 Optimizer Operators .......................................................................................................................................6-2 Objectives ......................................................................................................................................................6-3 Row Source Operations .................................................................................................................................6-4 Main Structures and Access Paths ................................................................................................................6-5 Full Table Scan ..............................................................................................................................................6-6 Full Table Scans: Use Cases .........................................................................................................................6-7 ROWID Scan..................................................................................................................................................6-9 Sample Table Scans ......................................................................................................................................6-10 Indexes: Overview..........................................................................................................................................6-12 Normal B*-tree Indexes ..................................................................................................................................6-14 Index Scans ...................................................................................................................................................6-15 Index Unique Scan .........................................................................................................................................6-16 Index Range Scan..........................................................................................................................................6-17 Index Range Scan: Descending .....................................................................................................................6-19 Descending Index Range Scan ......................................................................................................................6-20 Index Range Scan: Function-Based...............................................................................................................6-21 Index Full Scan ..............................................................................................................................................6-22 Index Fast Full Scan ......................................................................................................................................6-23 Index Skip Scan .............................................................................................................................................6-24 Index Skip Scan: Example .............................................................................................................................6-26 Index Join Scan..............................................................................................................................................6-27 B*-tree Indexes and Nulls ..............................................................................................................................6-28 Using Indexes: Considering Nullable Columns ..............................................................................................6-29 Index-Organized Tables .................................................................................................................................6-30 Index-Organized Table Scans ........................................................................................................................6-32 Bitmap Indexes ..............................................................................................................................................6-33 Bitmap Index Access: Examples ....................................................................................................................6-35 Combining Bitmap Indexes: Examples ...........................................................................................................6-37 Combining Bitmap Index Access Paths .........................................................................................................6-38 Bitmap Operations .........................................................................................................................................6-39 Bitmap Join Index...........................................................................................................................................6-40 Composite Indexes ........................................................................................................................................6-42 Invisible Index: Overview ...............................................................................................................................6-43 Invisible Indexes: Examples ...........................................................................................................................6-44 Guidelines for Managing Indexes ...................................................................................................................6-45 Investigating Index Usage ..............................................................................................................................6-47 Quiz................................................................................................................................................................6-49 Summary ........................................................................................................................................................6-52 Practice 6: Overview ......................................................................................................................................6-53
le
b fera
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Optimizer: Join Operators ...............................................................................................................................7-1 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents iv
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer: Join Operators ..............................................................................................................................7-2 Objectives ......................................................................................................................................................7-3 Join Methods ..................................................................................................................................................7-4 Nested Loops Join .........................................................................................................................................7-6 Nested Loops Join: Prefetching .....................................................................................................................7-7 Nested Loops Join: 11g Implementation ........................................................................................................7-8 Sort Merge Join ..............................................................................................................................................7-9 Hash Join .......................................................................................................................................................7-11 Cartesian Join ................................................................................................................................................7-12 Join Types ......................................................................................................................................................7-13 Equijoins and Nonequijoins ............................................................................................................................7-14 Outer Joins .....................................................................................................................................................7-15 Semijoins .......................................................................................................................................................7-17 Antijoins .........................................................................................................................................................7-18 Quiz................................................................................................................................................................7-19 Summary ........................................................................................................................................................7-23 Practice 7: Overview ......................................................................................................................................7-24
ble a r Other Optimizer Operators ..............................................................................................................................8-1 fe s n Other Optimizer Operators .............................................................................................................................8-2 tra Objectives ......................................................................................................................................................8-3 n no Clusters ..........................................................................................................................................................8-4 a When Are Clusters Useful? ............................................................................................................................8-6 has uideฺ Cluster Access Path: Examples .....................................................................................................................8-8 ) om nt G Sorting Operators ...........................................................................................................................................8-9 c ฺ l Buffer Sort Operator .......................................................................................................................................8-11 ai tude m g sS Inlist Iterator ...................................................................................................................................................8-12 @ 1 View Operator ................................................................................................................................................8-13 hi 2 t y e Count Stop Key Operator s ija...............................................................................................................................8-14 u v u o Min/Max and First Row Operators ..................................................................................................................8-15 t h aOperations s Other N-Array ..............................................................................................................................8-16 ( hu Operations ........................................................................................................................................8-17 FILTER a S ai Concatenation Operation ...............................................................................................................................8-18
Vij
e
ns e c li
UNION [ALL], INTERSECT, MINUS ..............................................................................................................8-19 Result Cache Operator ..................................................................................................................................8-20 Quiz................................................................................................................................................................8-21 Summary ........................................................................................................................................................8-25 Practice 8: Overview ......................................................................................................................................8-26
Case Study: Star Transformation ...................................................................................................................9-1 Case Study: Star Transformation ...................................................................................................................9-2 Objectives ......................................................................................................................................................9-3 The Star Schema Model ................................................................................................................................9-4 The Snowflake Schema Model.......................................................................................................................9-5 Star Query: Example ......................................................................................................................................9-6 Execution Plan Without Star Transformation .................................................................................................9-7 Star Transformation .......................................................................................................................................9-8 Star Transformation: Considerations ..............................................................................................................9-10 Star Transformation: Rewrite Example ..........................................................................................................9-11 Retrieving Fact Rows from One Dimension ...................................................................................................9-12 Retrieving Fact Rows from All Dimensions ....................................................................................................9-13 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents v
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
Joining the Intermediate Result Set with Dimensions ...................................................................................9-14 Star Transformation Plan: Example 1 ............................................................................................................9-15 Star Transformation: Further Optimization .....................................................................................................9-16 Using Bitmap Join Indexes .............................................................................................................................9-17 Star Transformation Plan: Example 2 ............................................................................................................9-18 Star Transformation Hints ..............................................................................................................................9-19 Bitmap Join Indexes: Join Model 1.................................................................................................................9-20 Bitmap Join Indexes: Join Model 2.................................................................................................................9-21 Bitmap Join Indexes: Join Model 3.................................................................................................................9-22 Bitmap Join Indexes: Join Model 4.................................................................................................................9-23 Quiz................................................................................................................................................................9-24 Summary ........................................................................................................................................................9-27 Practice 9: Overview ......................................................................................................................................9-28 Optimizer Statistics..........................................................................................................................................10-1 Optimizer Statistics ........................................................................................................................................10-2 Objectives ......................................................................................................................................................10-3 Optimizer Statistics ........................................................................................................................................10-4 Types of Optimizer Statistics ..........................................................................................................................10-5 Table Statistics (DBA_TAB_STATISTICS) ....................................................................................................10-6 Index Statistics (DBA_IND_STATISTICS) .....................................................................................................10-7 Index Clustering Factor ..................................................................................................................................10-9 Column Statistics (DBA_TAB_COL_STATISTICS) ........................................................................................10-11 Histograms .....................................................................................................................................................10-12 Frequency Histograms ...................................................................................................................................10-13 Viewing Frequency Histograms......................................................................................................................10-14 Height-Balanced Histograms .........................................................................................................................10-15 Viewing Height-Balanced Histograms ............................................................................................................10-16 Histogram Considerations ..............................................................................................................................10-17 Multicolumn Statistics: Overview ....................................................................................................................10-18 Expression Statistics: Overview .....................................................................................................................10-20 Gathering System Statistics ...........................................................................................................................10-21 Gathering System Statistics: Example ...........................................................................................................10-23 Mechanisms for Gathering Statistics ..............................................................................................................10-25 Statistic Preferences: Overview .....................................................................................................................10-26 When to Gather Statistics Manually ...............................................................................................................10-28 Manual Statistics Gathering ...........................................................................................................................10-29 Manual Statistics Collection: Factors .............................................................................................................10-30 Managing Statistics Collection: Example .......................................................................................................10-31 Optimizer Dynamic Sampling: Overview ........................................................................................................10-32 Optimizer Dynamic Sampling at Work............................................................................................................10-33 OPTIMIZER_DYNAMIC_SAMPLING.............................................................................................................10-34 Locking Statistics ...........................................................................................................................................10-36 Restoring Statistics ........................................................................................................................................10-37 Export and Import Statistics ...........................................................................................................................10-38 Quiz................................................................................................................................................................10-39 Summary ........................................................................................................................................................10-42 Practice 10: Overview ....................................................................................................................................10-43
le
b fera
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Using Bind Variables .......................................................................................................................................11-1 Using Bind Variables ......................................................................................................................................11-2 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents vi
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
Objectives ......................................................................................................................................................11-3 Cursor Sharing and Different Literal Values ...................................................................................................11-4 Cursor Sharing and Bind Variables ................................................................................................................11-6 Bind Variables in SQL*Plus ............................................................................................................................11-7 Bind Variables in Enterprise Manager ............................................................................................................11-8 Bind Variables in SQL Developer ...................................................................................................................11-9 Bind Variable Peeking ....................................................................................................................................11-10 Cursor Sharing Enhancements ......................................................................................................................11-12 The CURSOR_SHARING Parameter ............................................................................................................11-14 Forcing Cursor Sharing: Example ..................................................................................................................11-15 Adaptive Cursor Sharing: Overview ...............................................................................................................11-16 Adaptive Cursor Sharing: Architecture ...........................................................................................................11-17 Adaptive Cursor Sharing: Views.....................................................................................................................11-19 Adaptive Cursor Sharing: Example ................................................................................................................11-21 Interacting with Adaptive Cursor Sharing .......................................................................................................11-22 Quiz................................................................................................................................................................11-23 Summary ........................................................................................................................................................11-26 Practice 11: Overview ....................................................................................................................................11-27
le
b fera
s
n a r t n-
SQL Tuning Advisor ........................................................................................................................................12-1 SQL Tuning Advisor .......................................................................................................................................12-2 Objectives ......................................................................................................................................................12-3 Tuning SQL Statements Automatically...........................................................................................................12-4 Application Tuning Challenges .......................................................................................................................12-5 SQL Tuning Advisor: Overview ......................................................................................................................12-6 Stale or Missing Object Statistics ...................................................................................................................12-7 SQL Statement Profiling .................................................................................................................................12-8 Plan Tuning Flow and SQL Profile Creation ...................................................................................................12-9 SQL Tuning Loop ...........................................................................................................................................12-10 Access Path Analysis .....................................................................................................................................12-11 SQL Structure Analysis ..................................................................................................................................12-12 SQL Tuning Advisor: Usage Model ................................................................................................................12-13 Database Control and SQL Tuning Advisor ...................................................................................................12-14 Running SQL Tuning Advisor: Example .........................................................................................................12-15 Schedule SQL Tuning Advisor .......................................................................................................................12-16 Implementing Recommendations ...................................................................................................................12-17 Compare Explain Plan ...................................................................................................................................12-18 Quiz................................................................................................................................................................12-19 Summary ........................................................................................................................................................12-21 Practice 12: Overview ....................................................................................................................................12-22
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
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.
Oracle Database 11g: SQL Tuning Workshop Table of Contents vii
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Results ........................................................................................................................13-15 SQL Access Advisor: Results and Implementation ........................................................................................13-16 Quiz................................................................................................................................................................13-18 Summary ........................................................................................................................................................13-20 Practice 13: Overview ....................................................................................................................................13-21 Automating SQL Tuning ..................................................................................................................................14-1 Automating SQL Tuning .................................................................................................................................14-2 Objectives ......................................................................................................................................................14-3 SQL Tuning Loop ...........................................................................................................................................14-4 Automatic SQL Tuning ...................................................................................................................................14-5 Automatic Tuning Process .............................................................................................................................14-6 Automatic SQL Tuning Controls .....................................................................................................................14-8 Automatic SQL Tuning Task ..........................................................................................................................14-9 Configuring Automatic SQL Tuning ................................................................................................................14-10 Automatic SQL Tuning: Result Summary.......................................................................................................14-11 Automatic SQL Tuning: Result Details ...........................................................................................................14-12 Automatic SQL Tuning Result Details: Drilldown ...........................................................................................14-13 Automatic SQL Tuning Considerations ..........................................................................................................14-14 Quiz................................................................................................................................................................14-15 Summary ........................................................................................................................................................14-16 Practice 14: Overview ....................................................................................................................................14-17
le
b fera
s
n a r t n-
no a SQL Plan Management ....................................................................................................................................15-1 as ideฺ h ) SQL Plan Management ..................................................................................................................................15-2 m t Gu o c Objectives ......................................................................................................................................................15-3 ilฺ den a Maintaining SQL Performance .......................................................................................................................15-4 m Stu g SQL Plan Management: Overview .................................................................................................................15-5 @ this 1....................................................................................................................15-7 SQL Plan Baseline: Architecture 2 y ja .........................................................................................................................15-9 se i Loading SQL Plan Baselines u v to huBaselines.........................................................................................................................15-11 Evolving SQLa Plan s Important(Baseline SQL Plan Attributes .........................................................................................................15-12 u Selection ........................................................................................................................................15-14 hPlan SQL a S i
Vija
Possible SQL Plan Manageability Scenarios .................................................................................................15-16 SQL Performance Analyzer and SQL Plan Baseline Scenario .....................................................................15-17 Loading a SQL Plan Baseline Automatically ..................................................................................................15-18 Purging SQL Management Base Policy .........................................................................................................15-19 Enterprise Manager and SQL Plan Baselines ................................................................................................15-20 Quiz................................................................................................................................................................15-21 Summary ........................................................................................................................................................15-22 Practice 15: Overview Using SQL Plan Management ....................................................................................15-23
Using Optimizer Hints ......................................................................................................................................16-1 Using Optimizer Hints ....................................................................................................................................16-2 Objectives ......................................................................................................................................................16-3 Optimizer Hints: Overview ..............................................................................................................................16-4 Types of Hints ................................................................................................................................................16-5 Specifying Hints .............................................................................................................................................16-6 Rules for Hints................................................................................................................................................16-7 Hint Recommendations ..................................................................................................................................16-8 Optimizer Hint Syntax: Example.....................................................................................................................16-9 Hint Categories ..............................................................................................................................................16-10 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents viii
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
Optimization Goals and Approaches ..............................................................................................................16-11 Hints for Access Paths ...................................................................................................................................16-13 The INDEX_COMBINE Hint: Example ...........................................................................................................16-17 Hints for Query Transformation ......................................................................................................................16-19 Hints for Join Orders ......................................................................................................................................16-22 Hints for Join Operations ................................................................................................................................16-23 Additional Hints ..............................................................................................................................................16-25 Hints and Views .............................................................................................................................................16-28 Global Table Hints..........................................................................................................................................16-30 Specifying a Query Block in a Hint .................................................................................................................16-31 Specifying a Full Set of Hints .........................................................................................................................16-32 Summary ........................................................................................................................................................16-33 Practice Appendix B: Overview ......................................................................................................................16-34 Using SQL Developer ......................................................................................................................................17-1 Using SQL Developer ....................................................................................................................................17-2 Objectives ......................................................................................................................................................17-3 What Is Oracle SQL Developer? ....................................................................................................................17-4 Specifications of SQL Developer....................................................................................................................17-5 SQL Developer 2.1 Interface ..........................................................................................................................17-6 Creating a Database Connection ...................................................................................................................17-8 Browsing Database Objects ...........................................................................................................................17-11 Displaying the Table Structure .......................................................................................................................17-12 Browsing Files ................................................................................................................................................17-13 Creating a Schema Object .............................................................................................................................17-14 Creating a New Table: Example.....................................................................................................................17-15 Using the SQL Worksheet ..............................................................................................................................17-16 Executing SQL Statements ............................................................................................................................17-20 Saving SQL Scripts ........................................................................................................................................17-21 Executing Saved Script Files: Method 1.........................................................................................................17-22 Executing Saved Script Files: Method 2.........................................................................................................17-23 Formatting the SQL Code ..............................................................................................................................17-24 Using Snippets ...............................................................................................................................................17-25 Using Snippets: Example ...............................................................................................................................17-26 Debugging Procedures and Functions ...........................................................................................................17-27 Database Reporting .......................................................................................................................................17-28 Creating a User-Defined Report .....................................................................................................................17-30 External Tools ................................................................................................................................................17-31 Setting Preferences........................................................................................................................................17-32 Resetting the SQL Developer Layout .............................................................................................................17-33 Summary ........................................................................................................................................................17-34
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents ix
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
n a r t ns
S ahu ( no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah b fera ns e c li
Preface
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Profile Before You Begin This Course Before you begin this course, you should be familiar with SQL Language statements, and have taken the Oracle Database 11g: Introduction to SQL course or have equivalent experience. It is also recommended that you have taken the Oracle Database 11g: SQL Fundamentals I course. How This Course Is Organized Oracle Database 11g: SQL Tuning Workshop is an instructor-led course featuring lectures and hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts and skills that are introduced.
e
Related Publications Oracle Publications Title
ble a r Part Number fe s n a
tr n no Oracle Database Performance Tuning Guide 11g Release 2 (11.2)E10821-05 a ฺ Oracle SQL Developer User's Guide Release 2.1 has uideE15222-02 ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( u h a S i a Oracle Database SQL Reference 11g Release 2 (11.2)
E10592-04
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents xi
ns e c li
Typographic Conventions The following two lists explain Oracle University typographical conventions for words that appear within regular text or within code samples.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
1. Typographic Conventions for words within regular text Convention Courier new,
Initial cap
Italic
Object or Term User input; commands; column, table, and schema names; functions; PL/SQL objects; paths Triggers; user interface object names, such as button names Titles of courses and manuals; emphasized words or phrases; placeholders or variables Lesson or module title referenced within a course
Example Use the SELECT command to view information stored in the LAST_NAME column of the EMPLOYEES table. Enter 300.
e
Log in as scott Assign a When-Validate-Item trigger to the ORD block. Click the Cancel button. For more information on the subject see Oracle SQL Reference Manual
le
b fera
s
n a r t n-
Vija
no a Do not save changes toathe eฺ h s database. d i ) u m where G o Enter hostname, hostname is the t c n is to be changed lฺ depassword host a oni which the m Stisucovered in Lesson 3, “Working with g Quotation This subject is 1@ Objects.” marks h 2 t y ja use i v to for words within code samples huConventions a 2. Typographic s ( u h Object or term Example Sa i Convention Uppercase
Lowercase italic Initial cap
Commands, functions Syntax variables
SELECT employee_id FROM employees CREATE ROLE role
Forms triggers
Form module: ORD Trigger level: S_ITEM.QUANTITY item Trigger name: When-Validate-Item . . . . . . OG_ACTIVATE_LAYER (OG_GET_LAYER ('prod_pie_layer')) . . . SELECT last_name FROM employees; CREATE USER scott IDENTIFIED BY tiger;
Lowercase
Column names, table names Filenames, PL/SQL objects
Bold
Text that must be entered by a user
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents xii
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
3. Typographic Conventions for Oracle Application Navigation Paths This course uses simplified navigation paths, such as the following example, to direct you through Oracle Applications. (N) Invoice > Entry > Invoice Batches Summary (M) Query > Find (B) Approve This simplified path translates to the following: 1. (N) From the Navigator window, select Invoice then Entry then Invoice Batches Summary. 2. (M) From the menu, select Query then Find. 3. (B) Click the Approve button. Notations: (N) = Navigator (M) = Menu (T) = Tab (B) = Button (I) = Icon (H) = Hyperlink (ST) = Sub Tab
e
le
b fera
s
n a r t n-
Vija
no a 4. Typographic Conventions for Oracle Application Paths s Help eSystem ฺ a h d i you perform to find ) Guactions This course uses a “navigation path” convention to represent m o pertinent information in the Oracle Applications ฺc HelpeSystem. nt l i a d The following help navigation path, for mexample— tu g S (Help) General Ledger > Journals > Enter Journals is 1@ ofthactions: 2 —represents the following sequence y e ja of utheshelp i v 1. In the navigation frame system window, expand the General Ledger entry. u o t h a 2. Under(s the General Ledger entry, expand Journals. u h Journals, select Enter Journals. 3. Under i Sa 4.
Review the Enter Journals topic that appears in the document frame of the help system window.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents xiii
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database 11g: SQL Tuning Workshop Table of Contents xiv
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
b fera
s
n a r t n-
Exploring the no Oracle a Database eฺ has Architecture
d
ahu
) Gui m o Chapter c en1t ฺ l i ma Stud g 1@ this 2 y ja use i v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Exploring the Oracle Database Architecture
i a j i V
Exploring the Oracle Database Architecture
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this lesson, you should be able to: • List the major architectural components of Oracle Database server • Explain memory structures • Describe background processes • Correlate logical and physical storage structures
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h This a lesson provides an overview of the Oracle Database server architecture. You learn about S i physical and logical structures and about the various components. a Objectives
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 3
Oracle Database Server Architecture: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Oracle Database Server Architecture: Overview Instance SGA
e
BGP1
BGP2
BGP3
BGPn
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ Database l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Oracle Database server consists of an Oracle Database and one or more Oracle Database An S i a instances. An instance consists of memory structures and background processes. Every time Oracle Database Server Architecture: Overview
an instance is started, a shared memory area called the System Global Area (SGA) is allocated and the background processes are started. The SGA contains data and control information for one Oracle Database instance.
The background processes consolidate functions that would otherwise be handled by multiple Oracle Database server programs running for each user process. They may asynchronously perform input/output (I/O) and monitor other Oracle Database processes to provide increased parallelism for better performance and reliability. The database consists of physical files and logical structures discussed later in this lesson. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting access to the logical storage structures. Note: Oracle Real Application Clusters (Oracle RAC) comprises two or more Oracle Database instances running on multiple clustered computers that communicates with each other by means of an interconnect and access the same Oracle Database.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 4
Connecting to the Database Instance
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Connecting to the Database Instance •
•
User process
Connection: Bidirectional network pathway between a user process on a client or middle tier and an oracle process on the server Session: Representation of a specific login by a user
User process
Listener process
Connection
Dispatcher
Shared Server
D000
S000
le
b fera
s
n a r t n-
Vij
no a as ideฺ h ) User m t Gu o c ilฺ den database user) a Session (Specific connected m Stu g 1@ this 2 y ja use i v to hu a s ( to the Database Instance Connecting u h a users connect to an Oracle Database server, they are connected to an Oracle When S i a Database instance. The database instance services those users by allocating other memory SQL> Select …
User process
Server process
Dedicated Server
SGA
Server host
areas in addition to the SGA, and starting other processes in addition to the Oracle Database background processes: •
User processes sometimes called client or foreground processes are created to run the software code of an application program. Most environments have separate machines for the client processes. A user process also manages communication with a corresponding server process through a program interface.
•
Oracle Database server creates server processes to handle requests from connected user processes. A server process communicates with the user process and interacts with the instance and the database to carry out requests from the associated user process.
An Oracle Database instance can be configured to vary the number of user processes for each server process. In a dedicated server configuration, a server process handles requests for a single user process. A shared server configuration enables many user processes to share a small number of shared server processes, minimizing the number of server processes and maximizing the use Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 5
e
ns e c li
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The Oracle Database server runs a listener that is responsible for handling network connections. The application connects to the listener that creates a dedicated server process or handles the connection to a dispatcher.
i a j i V
Connections and sessions are closely related to user processes, but are very different in meaning: •
A connection is a communication pathway between a user process and an Oracle Database instance. A communication pathway is established by using available interprocess communication mechanisms (on a computer that runs both the user process and Oracle Database) or network software (when different computers run the database application and Oracle Database, and communicate through a network).
•
A session represents the state of a current database user login to the database instance. For example, when a user starts SQL*Plus, the user must provide a valid database username and password, and then a session is established for that user. A session lasts from the time a user connects until the user disconnects or exits the database application.
le
s
b fera
Note: Multiple sessions can be created and exist concurrently for a single Oracle database user using the same username. For example, a user with the username/password of HR/HR can connect to the same Oracle Database instance several times.
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 6
e
ns e c li
Oracle Database Memory Structures: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Oracle Database Memory Structures: Overview SGA Database buffer cache
Redo log buffer Java pool
Shared pool
Large pool
Streams pool
e
le
Server process
Server process
…
b fera
ns e c li
s
n a r t n-
Background process
no a has uideฺ ) G … om n…Aggregated t PGA c ฺ l i e ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a Database allocates memory structures for various purposes. For example, memory Oracle S i a stores the program code that is run, data that is shared among users, and private data areas Oracle Database Memory Structures: Overview
for each connected user. Two basic memory structures are associated with an instance: •
•
System Global Area (SGA): The SGA is shared by all server and background processes. The SGA includes the following data structures: -
Database buffer cache: Caches blocks of data retrieved from the database files
-
Redo log buffer: Caches recovery information before writing it to the physical files
-
Shared pool: Caches various constructs that can be shared among sessions
-
Large pool: Optional area used for certain operations, such as Oracle backup and recovery operations, and I/O server processes
-
Java pool: Used for session-specific Java code and data in the Java Virtual Machine (JVM)
-
Streams pool: Used by Oracle Streams to store information about the capture and apply processes
Program Global Areas (PGA): Memory regions that contain data and control information about a server or background process. A PGA is suballocated from the aggregated PGA area. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 7
Database Buffer Cache
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Database Buffer Cache • • •
Is a part of the SGA Holds copies of data blocks that are read from data files Is shared by all concurrent processes SGA Server process
e
Database buffer cache
le
b fera
ns e c li
s
n a r t n-
no a eฺ hasDBWn d i ) m t Gu o c writer ilฺ denDatabase a Data files process u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a database buffer cache is the portion of the SGA that holds copies of data blocks that are The S i a read from data files. All users concurrently connected to the instance share access to the Database Buffer Cache database buffer cache.
The first time an Oracle Database server process requires a particular piece of data, it searches for the data in the database buffer cache. If the process finds the data already in the cache (a cache hit), it can read the data directly from memory. If the process cannot find the data in the cache (a cache miss), it must copy the data block from a data file on disk into a buffer in the cache before accessing the data. Accessing data through a cache hit is faster than data access through a cache miss. The buffers in the cache are managed by a complex algorithm that uses a combination of least recently used (LRU) lists and touch count. The DBWn (Database Writers) processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk when necessary.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 8
Redo Log Buffer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Redo Log Buffer • •
Is a circular buffer in the SGA (based on the number of CPUs) Contains redo entries that have the information to redo changes made by operations, such as DML and DDL SGA Server process
e
le
Redo log buffer
b fera
ns e c li
s
n a r t n-
no a eฺ hasLGWR d i ) m t Gu o c ilฺ den Log writer a Redo logm process tu g S files @ s 1 hi 2 t y e ija us v u to sah
Vij
( u h a redo log buffer is a circular buffer in the SGA that holds information about changes made The S i a to the database. This information is stored in redo entries. Redo entries contain the Redo Log Buffer
information necessary to reconstruct (or redo) changes that are made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations. Redo entries are used for database recovery, if necessary.
Redo entries are copied by Oracle Database server processes from the user’s memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The LGWR (log writer) background process writes the redo log buffer to the active redo log file (or group of files) on disk. LGWR is a background process that is capable of asynchronous I/O. Note: Depending on the number of CPUs on your system, there may be more than one redo log buffer. They are automatically allocated.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 9
Shared Pool
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Shared Pool • •
Is part of the SGA Contains:
Server process
– Library cache —
Shared parts of SQL and PL/SQL statements
– Data dictionary cache – Result cache:
e
SGA
le
rab Data e SQL queries f Result scache dictionary n a PL/SQL functions Library cache r -t cache n o Control structures n a Locks Control has uideฺ structures ) om nt G c ฺ l Shared pool ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
ns e c li
— —
–
(row cache)
—
h
a s ( u
Shared Pool
ahshared pool portion of the SGA contains the following main parts: The S i ija • The library cache includes the sharable parts of SQL statements, PL/SQL procedures
V
and packages. It also contains control structures such as locks.
•
The data dictionary is a collection of database tables containing reference information about the database. The data dictionary is accessed so often by Oracle Database that two special locations in memory are designated to hold dictionary data. One area is called the data dictionary cache, also known as the row cache, and the other area is called the library cache. All Oracle Database server processes share these two caches for access to data dictionary information.
•
The result cache is composed of the SQL query result cache and the PL/SQL function result cache. This cache is used to store results of SQL queries or PL/SQL functions to speed up their future executions.
•
Control structures are essentially lock structures.
Note: In general, any item in the shared pool remains until it is flushed according to a modified LRU algorithm.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 10
Processing a DML Statement: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Processing a DML Statement: Example Database
SGA
DBWn
2
2 Data files
Server process
4
Database buffer cache
3
Redo log buffer Shared pool
e
le
Vija
rab e 1 f Library cache Control s n files a r -t n User o n process a has uideฺ ) Redo om nt G c ฺ log files l ai tude m g sS @ 1 hi 2 t y e ija us v u to a Processing ahDML Statement: Example s ( u The steps involved in executing a data manipulation language (DML) statement are: h a S i 5
ns e c li
1. The server process receives the statement and checks the library cache for any shared SQL area that contains a similar SQL statement. If a shared SQL area is found, the server process checks the user’s access privileges to the requested data, and the existing shared SQL area is used to process the statement. If not, a new shared SQL area is allocated for the statement, so that it can be parsed and processed.
2. If the data and undo segment blocks are not already in the buffer cache, the server process reads them from the data files into the buffer cache. The server process locks the rows that are to be modified. 3. The server process records the changes to be made to the data buffers as well as the undo changes. These changes are written to the redo log buffer before the in-memory data and undo buffers are modified. This is called write-ahead logging. 4. The undo segment buffers contain values of the data before it is modified. The undo buffers are used to store the before image of the data so that the DML statements can be rolled back, if necessary. The data buffers record the new values of the data. 5. The user gets the feedback from the DML operation (such as how many rows were affected by the operation).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 11
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 12
ns e c li
COMMIT Processing: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
COMMIT Processing: Example Database
SGA
DBWn
Database buffer cache Data files
Server process
Redo log SGA buffer
1
Shared pool
e
le
rab e f Library cache Control s n files a r -t n User o n process a has uideฺ ) Redo om nt G c ฺ log files l 2 ai tude m g sS @ 1 hi 2 t y e ija us v u to sah 3
ns e c li
LGWR
Vij
( u h a COMMIT is issued, the following steps are performed: When S i a COMMIT Processing: Example
1. The server process places a commit record, along with the system change number (SCN), in the redo log buffer. The SCN is a number monotonically incremented and is unique within the database. It is used by Oracle Database as an internal time stamp to synchronize data and to provide read consistency when data is retrieved from the data files. Using the SCN enables Oracle Database to perform consistency checks without depending on the date and time of the operating system.
2. The LGWR background process performs a contiguous write of all the redo log buffer entries up to and including the commit record to the redo log files. After this point, Oracle Database can guarantee that the changes are not lost even if there is an instance failure. 3. If modified blocks are still in the SGA, and if no other session is modifying them, then the database removes lock-related transaction information from the blocks. This process is known as commit cleanout. 4. The server process provides feedback to the user process about the completion of the transaction. Note: If not done already, DBWn eventually writes the actual changes back to disk based on its own internal timing mechanism. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 13
Large Pool
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Large Pool •
Provides large memory allocations for: – Session memory for the shared server and Oracle XA interface – Parallel execution buffers – I/O server processes Server process – Oracle Database backup and restore operations
•
Optional pool better suited when using the following:
SGA
e
le
b fera
ns e c li
s
n a r t n-
Free no memory I/O buffer a eฺ Request has Response d i ) m t Guqueue queue o c ilฺ den Large pool a m Stu g 1@ this 2 y ja use i v u to sah
– Parallel execution – Recovery Manager – Shared server
Vij
( u h a can configure an optional memory area called the large pool to provide large memory You S i a allocations for: Large Pool
•
Session memory for the shared server, the Oracle XA interface (used where transactions interact with more than one database), or parallel execution buffers
•
I/O server processes
•
Oracle Database backup and restore operations
By allocating the above memory components from the large pool, Oracle Database can use the shared pool primarily for caching the shared part of SQL and PL/SQL constructs. The shared pool was originally designed to store SQL and PL/SQL constructs. Using the large pool avoids fragmentation issues associated with having large and small allocations sharing the same memory area. Unlike the shared pool, the large pool does not have an LRU list. You should consider configuring a large pool if your instance uses any of the following: •
Parallel execution: Parallel query uses shared pool memory to cache parallel execution message buffers.
•
Recovery Manager: Recovery Manager uses the shared pool to cache I/O buffers during backup and restore operations. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 14
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
Shared server: In a shared server architecture, the session memory for each client process is included in the shared pool.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 15
ns e c li
Java Pool and Streams Pool
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Java Pool and Streams Pool • •
Java pool memory is used in server memory for all session-specific Java code and data in the JVM. Streams pool memory is used exclusively by Oracle Streams to: – –
Store buffered queue messages Provide memory for Oracle Streams processes
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nStreams t G pool Java pool c ฺ l i e ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a pool memory is used for all session-specific Java code and data in the JVM. Java pool Java S i a memory is used in different ways, depending on the mode in which Oracle Database runs. Java Pool and Streams Pool
Oracle Streams enables the propagation and management of data, transactions and events in a data stream either within a database, or from one database to another. The Streams pool is used exclusively by Oracle Streams. The Streams pool stores buffered queue messages, and it provides memory for Oracle Streams capture and apply processes. Note: A detailed discussion of Java programming and Oracle Streams is beyond the scope of this course.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 16
Program Global Area (PGA)
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Program Global Area (PGA) •
PGA is a memory area that contains: – Session information – Cursor information – SQL execution work areas: — — — —
• •
Sort area Hash join area Bitmap merge area Bitmap create area
Server process
User Global Area (UGA) Stack Space
User Session Data
Cursor Status
SQL Area
le
b fera
ns
Work area size influences SQL performance.-tra on managed. n Work areas can be automatically or manually a
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a PGA can be compared to a temporary countertop workspace used by a file clerk (the The S i a server process) to perform a function on behalf of a customer (client process). The clerk
Vij
Program Global Area (PGA)
clears a section of the countertop, uses the workspace to store details about the customer’s request, and then gives up the space when the work is done. Generally, the PGA memory is divided into the following areas: •
Session memory is the memory allocated to hold a session’s variables (logon information) and other information related to the session. For a shared server, the session memory is shared and not private.
•
Cursors are handles to private memory structures of specific SQL statements
•
SQL work areas are allocated to support memory-intensive operators, such as the ones listed in the slide. Generally, bigger work areas can significantly improve the performance of a particular operator at the cost of higher memory consumption.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 17
e
ns e c li
Background Process
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Background Process
RCBG
MMON
CJQ0
QMNn
MMAN
e
Database buffer cache
SGA
Redo log buffer
le
Shared pool
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah CKPT
PMON
SMON
DBWn
LGWR
ARCn
Vij
( u h a background processes commonly seen in non-RAC, non-ASM environments can include The S i a the following: Background Process
•
Database writer process (DBWn): Asynchronously writes modified (dirty) buffers in the database buffer cache to disk
•
Log writer process (LGWR): Writes the recovery information called redo information in the log buffer to a redo log file on disk
•
Checkpoint process (CKPT): Records checkpoint information in control files and each data file header
•
System Monitor process (SMON): Performs recovery at instance startup and cleans up unused temporary segments
•
Process monitor process (PMON): Performs process recovery when a user process fails
•
Result cache background process (RCBG): Used to maintain the result cache in the shared pool
•
Job queue process (CJQ0): Runs user jobs used in batch processing through the Scheduler Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 18
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Archiver processes (ARCn): Copies redo log files to a designated storage device after a log switch has occurred
•
Queue monitor processes (QMNn): Monitors the Oracle Streams message queues
•
Manageability monitoring process (MMON): Performs manageability-related background tasks
•
Memory Manager background process (MMAN): Used to manage SGA and PGA memory components automatically
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 19
ns e c li
Automatic Shared Memory Management
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic Shared Memory Management SGA_TARGET + STATISTICS_LEVEL SGA
Shared pool Java pool
Streams pool
Fixed SGA
Large pool
Database buffer cache
Redo log buffer
e
le
b fera
ns e c li
s
n a r t n-
no a Which size to choose? has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Automatically tuned SGA components
Vij
( u h a can use the Automatic Shared Memory Management (ASMM) feature to enable the You S i a database to automatically determine the size of each of these memory components within the Automatic Shared Memory Management limits of the total SGA size.
The system uses an SGA size parameter (SGA_TARGET) that includes all the memory in the SGA, including all the automatically sized components, manually sized components, and any internal allocations during startup. ASMM simplifies the configuration of the SGA by enabling you to specify a total memory amount to be used for all SGA components. The Oracle Database then periodically redistributes memory between the automatically tuned components, according to workload requirements. Note: You must set STATISTICS_LEVEL to TYPICAL or ALL to use ASMM.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 20
Automated SQL Execution Memory Management
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automated SQL Execution Memory Management
PGA_AGGREGATE_TARGET Server process
…
Server process
Aggregated … PGA …
Background process
e
le
b fera
ns e c li
s
n a r t n-
no a Which size to choose? has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a feature provides an automatic mode for allocating memory to working areas in the PGA. This S i a You can use the PGA_AGGREGATE_TARGET parameter to specify the total amount of memory Automated SQL Execution Memory Management
that should be allocated to the PGA areas of the instance’s sessions. In automatic mode, working areas that are used by memory-intensive operators (sorts and hash joins) can be automatically and dynamically adjusted.
This feature offers several performance and scalability benefits for decision support system (DSS) workloads and mixed workloads with complex queries. The overall system performance is maximized, and the available memory is allocated more efficiently among queries to optimize both throughput and response time. In particular, the savings that are gained from improved use of memory translate to better throughput at high loads. Note: In earlier releases of Oracle Database server, you had to manually specify the maximum work area size for each type of SQL operator, such as sort or hash join. This proved to be very difficult because the workload changes constantly. Although the current release of Oracle Database supports this manual PGA memory management method that might be useful for specific sessions, it is recommended that you leave automatic PGA memory management enabled.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 21
Automatic Memory Management
• • •
Sizing of each memory component is vital for SQL execution performance. It is difficult to manually size each component. Automatic memory management automates memory allocation of each SGA component and aggregated PGA.
e
le
b fera
MMAN
ns e c li
s
n a r t nUntunable PGA
Private SQL areas
Buffer cache
Large pool
Shared pool
Java pool Streams pool
Other SGA
no a has uideฺ ) om nt G c ฺ l ai t+uSTATISTICS_LEVEL de MEMORY_TARGET m g sS @ 1 hi 2 t y e ija us v u to sah Free
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic Memory Management
Vij
( u h a seen already, the size of the various memory areas of the instance directly impacts the As S i a speed of SQL processing. Depending on the database workload, it is difficult to size those Automatic Memory Management components manually.
With Automatic Memory Management, the system automatically adapts the size of each memory’s components to your workload memory needs. Set your MEMORY_TARGET initialization parameter for the database instance and the MMAN background process automatically tunes to the target memory size, redistributing memory as needed between the internal components of the SGA and between the SGA and the aggregated PGAs. The Automatic Shared Memory Management feature uses the SGA memory broker that is implemented by two background processes Manageability Monitor (MMON) and Memory Manager (MMAN). Statistics and memory advisory data are periodically captured in memory by MMON. MMAN coordinates the sizing of the memory components according to MMON decisions. Note: Currently, this mechanism is only implemented on Linux, Solaris, HP-UX, AIX, and Windows.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 22
Database Storage Architecture
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Database Storage Architecture
Control file
Data files
e
Online redo log files
le
b fera
ns e c li
Vij
s n a r -t redo log Parameter file Backup files Archived n o n files a s ฺ ha uide ) om nt G c ฺ l ai tude m g s S Alert log and trace files Password file @ 1 hi 2 t y e ija us v u to h a s ( Storage Architecture Database u h a files that constitute an Oracle database are organized into the following: The S i a •
Control file: Contain data about the database itself (that is, physical database structure information). These files are critical to the database. Without them, you cannot open data files to access the data in the database.
•
Data files: Contain the user or application data of the database, as well as metadata and the data dictionary
•
Online redo log files: Allow for instance recovery of the database. If the database server crashes and does not lose any data files, the instance can recover the database with the information in these files.
The following additional files are important for the successful running of the database: •
Parameter file: Is used to define how the instance is configured when it starts up
•
Password file: Allows sysdba, sysoper, and sysasm to connect remotely to the database and perform administrative tasks
•
Backup files: Are used for database recovery. You typically restore a backup file when a media failure or user error has damaged or deleted the original file.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 23
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Archived redo log files: Contain an ongoing history of the data changes (redo) that are generated by the instance. Using these files and a backup of the database, you can recover a lost data file. That is, archive logs enable the recovery of restored data files.
•
Trace files: Each server and background process can write to an associated trace file. When an internal error is detected by a process, the process dumps information about the error to its trace file. Some of the information written to a trace file is intended for the developer, whereas other information is for Oracle Support Services.
•
Alert log file: These are special trace entries. The alert log of a database is a chronological log of messages and errors. Each instance has one alert log file. It is recommended that you review this periodically.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 24
ns e c li
Logical and Physical Database Structures
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Logical and Physical Database Structures Logical
Physical
Database
Schema
Tablespace
Only 1 with bigfile tablespaces
Data file
e
0, 1, or many Undo tablespaces never have 0
le
b fera
Segment
ns e c li
s
n a r t n-
no a has uideฺ ) Oracle data om nt G c OS block ฺ l i block e a d m Stu g 1@ this 2 y ja use i v u to sah Extent
Vij
( u h a database has logical structures and physical structures. The S i a Logical and Physical Database Structures
Tablespaces
A database is divided into logical storage units called tablespaces, which group related logical structures together. For example, tablespaces commonly group all of an application’s objects to simplify some administrative operations. You may have a tablespace for different applications. Databases, Tablespaces, and Data Files The relationship among databases, tablespaces, and data files is illustrated in the slide. Each database is logically divided into one or more tablespaces. One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace. If it is a TEMPORARY tablespace instead of a tablespace containing data, the tablespace has a temporary file. Schemas A schema is a collection of database objects that are owned by a database user. Schema objects are the logical structures that directly refer to the database’s data. Schema objects include structures, such as tables, views, sequences, stored procedures, synonyms, indexes, Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 25
clusters, and database links. In general, schema objects include everything that your application creates in the database.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Data Blocks At the finest level of granularity, an Oracle database’s data is stored in data blocks. One data block corresponds to a specific number of bytes of physical database space on the disk. A data block size is specified for each tablespace when it is created. A database uses and allocates free database space in Oracle data blocks. Extents The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks (obtained in a single allocation) that are used to store a specific type of information.
e
Vij
ns e c The level of logical database storage above an extent is called a segment. A segment is a lset i e l of extents that are allocated for a certain logical structure. Different types of segments include: ab rsegment, e • Data segments: Each nonclustered, non-index-organized table has a data f s n with the exception of external tables and global temporary tables that have no segments, a r -t All of the table’s and partitioned tables in which each table has one or more segments. n o n data is stored in the extents of its data segment. For a partitioned table, each partition a has a data segment. Each cluster has a data segment. The data of s ฺ every table in the a e h d cluster is stored in the cluster’s data segment. ) Gui m o • Index segments: Each index has anฺc segment nt that stores all of its data. For a il anindex e a partitioned index, each partition has index segment. d m Stu g • Undo segments: One UNDO is created for each database instance. This @ tablespace is segments 1 h 2 t tablespace contains numerous undo to temporarily store undo information. y e a j s i The information an undo segment is used to generate read-consistent database udatabase vand, induring u o t information recovery, to roll back uncommitted transactions for h a s ( users. u a • h Temporary segments: Temporary segments are created by the Oracle Database when S a SQL statement needs a temporary work area to complete execution. When the ai Segments
statement finishes execution, the temporary segment’s extents are returned to the instance for future use. Specify either a default temporary tablespace for every user, or a default temporary tablespace that is used across the database.
The Oracle Database dynamically allocates space. When the existing extents of a segment are full, additional extents are added. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on the disk.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 26
Segments, Extents, and Blocks
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Segments, Extents, and Blocks • • • •
Segments exist in a tablespace. Segments are collections of extents. Extents are collections of data blocks. Data blocks are mapped to disk blocks.
e
le
b fera
ns e c li
s
n a r t n-
no a as ideฺ h ) u Segment Extents m Data G o t blocks c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
Disk blocks
Vij
( u h a Database objects, such as tables and indexes are stored as segments in tablespaces. Each S i a segment contains one or more extents. An extent consists of contiguous data blocks, which Segments, Extents, and Blocks
means that each extent can exist only in one data file. Data blocks are the smallest unit of I/O in the database. When the database requests a set of data blocks from the operating system (OS), the OS maps this to an actual file system or disk block on the storage device. Because of this, you do not need to know the physical address of any of the data in your database. This also means that a data file can be striped or mirrored on several disks. The size of the data block can be set at the time of database creation. The default size of 8 KB is adequate for most databases. If your database supports a data warehouse application that has large tables and indexes, a larger block size may be beneficial. If your database supports a transactional application in which reads and writes are random, specifying a smaller block size may be beneficial. The maximum block size depends on your OS. The minimum Oracle block size is 2 KB; it should rarely (if ever) be used. You can have tablespaces with a nonstandard block size. For details, see the Oracle Database Administrator’s Guide.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 27
SYSTEM and SYSAUX Tablespaces
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SYSTEM and SYSAUX Tablespaces •
• •
The SYSTEM and SYSAUX tablespaces are mandatory tablespaces that are created at the time of database creation. They must be online. The SYSTEM tablespace is used for core functionality (for example, data dictionary tables). The auxiliary SYSAUX tablespace is used for additional database components (such as the Enterprise Manager ble ra Repository). sfe
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a Oracle Database must contain a SYSTEM tablespace and a SYSAUX tablespace, which Each S i a
Vij
SYSTEM and SYSAUX Tablespaces
are automatically created when the database is created. The system default is to create a smallfile tablespace. You can also create bigfile tablespaces, which enable the Oracle database to manage ultra large files (up to 8 exabytes in size).
A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is always online when the database is open. It stores tables that support the core functionality of the database, such as the data dictionary tables. The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX tablespace stores many database components, and it must be online for the correct functioning of all database components. Note: The SYSAUX tablespace may be taken offline for performing tablespace recovery, whereas this is not possible in the case of the SYSTEM tablespace. Neither of them may be made read-only.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 28
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The first time an Oracle Database server process requires a particular piece of data, it searches for the data in the: a. Database Buffer Cache b. PGA c. Redo Log Buffer d. Shared Pool
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 29
le
b fera
s
n a r t n-
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Which of the following is not a database logical structure? a. Tablespace b. Data File c. Schema d. Segment
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 30
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The SYSAUX tablespace is used for core functionality and the SYSTEM tablespace is used for additional database components such as the Enterprise Manager Repository. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 31
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • List the major architectural components of the Oracle Database server • Explain memory structures • Describe background processes • Correlate logical and physical storage structures
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 32
le
b fera
s
n a r t n-
e
ns e c li
Practice 1: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 1: Overview
i a j i V
This practice covers the following topics: • Listing the different components of an Oracle Database server • Looking at some instance and database components directly on your machine
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 33
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Exploring the Oracle Database Architecture Chapter 1 - Page 34
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
Introduction noto SQL Tuning
a ฺ s a Chapterh2 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Introduction to SQL Tuning
i a j i V
Introduction to SQL Tuning
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this lesson, you should be able to: • Describe what attributes of a SQL statement can make it perform poorly • List the Oracle tools that can be used to tune SQL • List the tuning tasks
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h This a lesson gives you an understanding of the tuning process and the different components of S i an Oracle Database that may require tuning. a Objectives
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 3
Reasons for Inefficient SQL Performance
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Reasons for Inefficient SQL Performance • • • •
Stale or missing optimizer statistics Missing access structures Suboptimal execution plan selection Poorly constructed SQL
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a statements can perform poorly for a variety of reasons: SQL S i a Reasons for Inefficient SQL Performance •
Stale optimizer statistics: SQL execution plans are generated by the cost-based optimizer (CBO). For CBO to effectively choose the most efficient plan, it needs accurate information on the data volume and distribution of tables and indexes referenced in the queries. Without accurate optimizer statistics, the CBO can easily be mislead and generate suboptimal execution plans.
•
Missing access structures: Absence of access structures, such as indexes, materialized views, and partitions is a common reason for poor SQL performance. The right set of access structures can improve SQL performance by several orders of magnitude.
•
Suboptimal execution plan selection: The CBO can sometimes select a suboptimal execution plan for a SQL statement. This happens for most part because of incorrect estimates of some attributes of that SQL statement, such as its cost, cardinality, or predicate selectivity.
•
Poorly constructed SQL: If the SQL statement is designed poorly, there is not much that the optimizer can do to improve its performance. A missing join condition leading to a Cartesian product, or the use of more expensive SQL constructs like UNION in place of UNION ALL, are just a couple of examples of inefficient SQL design. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 4
These four main causes of poor SQL optimization can have a drastic impact on performance.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: Additional reasons for poor performance might be connected with hardware-related issues, such as memory, I/Os, CPUs, and so on.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 5
ns e c li
Inefficient SQL: Examples
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Inefficient SQL: Examples
1
SELECT COUNT(*) FROM products p WHERE prod_list_price < 1.15 * (SELECT avg(unit_cost) FROM costs c WHERE c.prod_id = p.prod_id)
2
SELECT * FROM job_history jh, employees e WHERE substr(to_char(e.employee_id),2) = substr(to_char(jh.employee_id),2)
3
SELECT * FROM orders WHERE order_id_char = 1205
4
SELECT * FROM employees WHERE to_char(salary) = :sal
e
le
b fera
ns e c li
s
n a r t n-
no a s eฺ SELECT * FROM parts_old ) ha d i m t Gu 5 UNION o c ilฺ den SELECT * FROM parts_new a m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a slide shows five examples of possibly poorly constructed SQL that could easily result in The S i a inefficient execution. Inefficient SQL: Examples
1. This is a common business question type. The query determines how many products have list prices less than 15% above the average cost of the product. This statement has a correlated subquery, which means that the subquery is run for every row found in the outer query. The query is better written as: SELECT COUNT(*) FROM products p, (SELECT prod_id, AVG(unit_cost) ac FROM costs GROUP BY prod_id) c WHERE p.prod_id = c.prod_id AND p.prod_list_price < 1.15 * c.ac 2. This query applies functions to the join columns, restricting the conditions where indexes can be used. Use a simple equality, if you can. Otherwise, a function-based index may be necessary. 3. This query has a condition that forces implicit data type conversion; the ORDER_ID_CHAR column is a character type, and the constant is a numeric type. You should make the literal match the column type. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 6
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
4. The fourth query uses a data type conversion function in it to make the data types match in the comparison. The problem here is that the TO_CHAR function is applied to the column value, rather than to the constant. This means that the function is called for every row in the table. It would be better to convert the literal once, and not convert the column. This is better queried as: SELECT * FROM employees WHERE salary = TO_NUMBER(:sal) 5. The UNION operator, as opposed to the UNION ALL operator, ensures that there are no duplicate rows in the result set. However, this requires an extra step, a unique sort, to eliminate any duplicates. If you know that there are no rows in common between the two UNIONed queries, use UNION ALL instead of UNION. This eliminates the unnecessary sort.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 7
ns e c li
Performance Monitoring Solutions
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Performance Monitoring Solutions Foreground
Automatic In-memory statistics
60 min
MMON
SGA
AWR
ASH Snapshots
ADDM
Snapshots
AST
Alerts
e
le
b fera
ns e c li
s
Statspack
n a r t n-
Vija
no a AWR report s ฺ a e h d ) Gui m o ASH: Active Session History ilฺc dent AWR: Automatic Workload Repository a mMonitor tu ADDM: Automatic Database Diagnostic g S 1@ this 2 y ja use i v to hu a s ( Monitoring Solutions Performance u h a Workload Repository (AWR): It collects, processes, and maintains performance i SAutomatic ADDM results
statistics for problem detection and self-tuning purposes. This data is both in memory and stored in the database. The gathered data can be displayed in both reports and views.
Active Session History (ASH): It provides sampled session activity in the instance. Active sessions are sampled every second and are stored in a circular buffer in SGA. Snapshots: Snapshots are sets of historical data for specific time periods that are used for performance comparisons by ADDM. AWR compares the difference between snapshots to determine which SQL statements to capture based on the effect on the system load. This reduces the number of SQL statements that must be captured over time. Automatic Database Diagnostic Monitor (ADDM) In addition to the classical reactive tuning capabilities of previous releases, such as Statspack, SQL trace files, and performance views, Oracle Database 10g introduced new methodologies to monitor your database in two categories: •
Proactive monitoring: -
Automatic Database Diagnostic Monitor (ADDM) automatically identifies bottlenecks within the Oracle Database. Additionally, working with other Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 8
manageability components, ADDM makes recommendations on the options available for fixing these bottlenecks. Oracle Database 11g further automates the SQL tuning process by identifying problematic SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL profile recommendations to tune the statement without requiring user intervention. This automation uses the AUTOTASK framework through a new task called Automatic SQL Tuning Task that runs every night by default.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
-
i a j i V
•
Reactive monitoring: -
Server-generated alerts: The Oracle Database can automatically detect problematic situations. In reaction to a detected problem, the Oracle Database sends you an alert message with possible remedial action.
-
The Oracle Database has powerful new data sources and performance-reporting capabilities. Enterprise Manager provides an integrated performance management console that uses all relevant data sources. Using a drill-down method, you can manually identify bottlenecks with just a few mouse clicks.
le
b fera
New data sources are introduced to capture important information about your database’s health—for example, new memory statistics (for current diagnostics) as well as statistics history stored in Automatic Workload Repository (AWR).
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Note: Accessing Enterprise Manager or tools discussed here may require additional licenses and certain privileges generally reserved for database administrators.
ahu
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 9
e
ns e c li
Monitoring and Tuning Tools: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Monitoring and Tuning Tools: Overview Services
Alert log
tkprof
SQL traces
Perf views
Statspack
EM Metric AWR perf base reports pages line
Direct ADDM Hang SGA analyzer and advisors monitor
SPA
le SQL b a r fe report
trcsess
Optimizer statistics
SQL statistics
AWR baseline
Base/ Segment statistics
s n a r -t nService
Vij
no statistics Compared a periods s ฺ a e ) h Guid m System ASH Time lฺco OS nt Alerts Wait Session i e report model statistics a model d statistics m Stu g 1@ this 2 y ja use i v to hu a s ( and Tuning Tools: Overview Monitoring u h a Oracle Database 10g, Release 2, you can generate SQL reports from AWR data Since S i a ($ORACLE_HOME/rdbms/admin/awrsqrpt.sql), basically, the equivalent to Histograms
Metrics
ASH
sqrepsql.sql in Statspack.
Note •
SPA stands for SQL Performance Analyzer.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 10
e
ns e c li
EM Performance Pages for Reactive Tuning
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
EM Performance Pages for Reactive Tuning ASH Report
Home
Run ADDM
Performance
Nonidle wait classes
Top Activity
Top Consumers
Duplicate Blocking Hang Instance SQL Sessions Analysis Locks
Instance Activity
AWR Baselines
le
Wait class details
b fera
Top SQL
Top Sessions
Top Services
Top Modules
s n a Top r n-t Objects
Top Actions
Top Files
no a SPA as ideฺ h ) u SQL Wait SQL m Enable/Disable G System View o t Enable/Disable Tuning c event Tuning ฺ n l statistics i SQL trace file e Advisor histograms Sets maaggregation tud SQL trace g S 1@ this 2 y ja use i v to hu a s ( EM Performance Pages for Reactive Tuning u h a are cases where real-time problem diagnosis must be performed. An irate user calls There S i a you, or you see a sudden spike in the activity of the system on the monitor. The Enterprise
Vij
Manager (EM) Performance pages use the same data sources as AWR and ADDM to display information about the running of the database and the host system in a manner that is easily absorbed and allows for rapid manual drilldown to the source of the problem.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 11
e
ns e c li
Tuning Tools: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Tuning Tools: Overview • • • • • • •
Automatic Database Diagnostic Monitor (ADDM) SQL Tuning Advisor SQL Tuning Sets SQL Access Advisor SQL Performance Analyzer SQL Monitoring SQL Plan Management
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Automatic Database Diagnostic Monitor: Continually analyzes the performance data that is S i a collected from the database instance Tuning Tools: Overview
SQL Tuning Advisor: Analyzes SQL statements that have been identified as problematic, in an effort to retune them. By default, this is an automated task. You can also, at any time, run the SQL Tuning Advisor on a specific SQL workload to look for ways to improve performance. SQL Tuning Sets: Serve as a repository for sets of SQL statements. For example, the SQL Tuning Advisor can run against a workload that is represented by a SQL Tuning Set. They can even be transported from database to database, to perform analysis on different machines. SQL Access Advisor: Analyzes a SQL statement, and provides advice on materialized views, indexes, materialized view logs, and partitions SQL Performance Analyzer: Automates the process of assessing the overall effect of a change, such as upgrading a database or adding new indexes, on the full SQL workload by identifying performance divergence for each statement SQL Monitoring: Enables you to monitor the performance of SQL statements while they execute SQL Plan Management (SPM): Can be used to control execution plan evolution. By creating a SQL baseline, SPM will allow only approved execution plans to be used. Other plans Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 12
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
discovered by the optimizer will be stored in the SQL plan history, but will not be used until they are approved.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 13
ns e c li
SQL Tuning Tasks: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Tasks: Overview • • • • • •
Identifying high-load SQL Gathering statistics Generating system statistics Rebuilding existing indexes Maintaining execution plans Creating new index strategies
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL tuning tasks should be performed on a regular basis. You may see a way to rewrite Many S i a a WHERE clause, but it may depend on a new index being built. This list of tasks gives you a SQL Tuning Tasks: Overview
background of some important tasks that must be performed, and gives you an idea of what dependencies you may have as you tune SQL: •
Identifying high-load SQL statements is one of the most important tasks you should perform. The ADDM is the ideal tool for this particular task.
•
By default, the Oracle Database gathers optimizer statistics automatically. For this, a job is scheduled to run in the maintenance windows.
•
Operating system statistics provide information about the usage and performance of the main hardware components as well as the performance of the operating system itself.
•
Often, there is a beneficial impact on performance by rebuilding indexes. For example, removing nonselective indexes to speed the data manipulation language (DML), or adding columns to the index to improve selectivity.
•
You can maintain the existing execution plan of SQL statements over time by using stored statistics or SQL plan baselines.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 14
CPU and Wait Time Tuning Dimensions
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
CPU and Wait Time Tuning Dimensions Scalability is a system’s ability to process more workload with a proportional increase in system resource use. CPU time
Possibly needs SQL tuning
e
Scalable application
le
b fera
Scalable application
Needs instance/RAC tuning
ns e c li
s n a r n-t No gain achieved
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
by adding CPUs/nodes
Wait time
Vij
( u h a you tune your system, it is important that you compare the CPU time with the wait time When S i a of your system. By comparing CPU time with wait time, you can determine how much of the CPU and Wait Time Tuning Dimensions
response time is spent on useful work and how much on waiting for resources potentially held by other processes. As a general rule, the systems where CPU time is dominant usually need less tuning than the ones where wait time is dominant. On the other hand, high CPU usage can be caused by badly-written SQL statements. Although the proportion of CPU time to wait time always tends to decrease as load on the system increases, steep increases in wait time are a sign of contention and must be addressed for good scalability. Adding more CPUs to a node, or nodes to a cluster, would provide very limited benefit under contention. Conversely, a system where the proportion of CPU time does not decrease significantly as load increases can scale better, and would most likely benefit from adding CPUs or Real Application Clusters (RAC) instances if needed. Note: AWR reports display CPU time together with wait time in the Top 5 Timed Events section, if the CPU time portion is among the top five events.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 15
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Scalability with Application Design, Implementation, and Configuration
Scalability with Application Design, Implementation, and Configuration Applications have a significant impact on scalability. • Poor schema design can cause expensive SQL that does not scale. • Poor transaction design can cause locking and serialization problems. • Poor connection management can cause unsatisfactoryable er f response times. s n
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
ah Scalability with Application Design, Implementation, and Configuration S i ija Poor application design, implementation, and configuration have a significant impact on
V
scalability. This results in: •
Poor SQL and index design, resulting in a higher number of logical input/output (I/O) for the same number of rows returned
•
Reduced availability because database objects take longer to maintain
However, design is not the only problem. The physical implementation of the application can be the weak link, as in the following examples: •
Systems can move to production environments with poorly written SQL that cause high I/O.
•
Infrequent transaction COMMITs or ROLLBACKs can cause long locks on resources.
•
The production environment can use different execution plans than those generated in testing.
•
Memory-intensive applications that allocate a large amount of memory without much thought for freeing the memory can cause excessive memory fragmentation.
•
Inefficient memory usage places high stress on the operating virtual memory subsystem. This affects performance and availability. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 16
e
ns e c li
Common Mistakes on Customer Systems
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Common Mistakes on Customer Systems 1. 2. 3. 4. 5. 6. 7. 8. 9.
Bad connection management Bad use of cursors and the shared pool Excess of resources consuming SQL statements Use of nonstandard initialization parameters Poor database disk configuration Redo log setup problems ble a r Excessive serialization fe s n Inappropriate full table scans tra n no related to Large number of recursive SQL statements a space management or parsing activity has uideฺ ) m 10. Deployment and migration ฺcoerrors t G
il en a d u gm s St @ 1 hi 2 t y e ija us v u to h on Customer a Common s Mistakes Systems ( 1.hu Bad connection management: The application connects and disconnects for each a S database interaction. This problem is common with stateless middleware in application i
Vija
servers. It has over two orders of magnitude impact on performance, and is not scalable.
2. Bad use of cursors and the shared pool: Not using cursors results in repeated parses. If bind variables are not used, there may be hard parsing of all similar SQL statements. This has an order of magnitude impact on performance, and it is not scalable. Use cursors with bind variables that open the cursor and execute it many times. Be suspicious of applications generating dynamic SQL. 3. Bad SQL: Bad SQL is SQL that uses more resources than appropriate for the application. This can be a decision support system (DSS) query that runs for more than 24 hours or a query from an online application that takes more than a minute. SQL that consumes significant system resources should be investigated for potential improvement. ADDM identifies high-load SQL and the SQL Tuning Advisor can be used to provide recommendations for improvement. 4. Use of nonstandard initialization parameters: These might have been implemented based on poor advice or incorrect assumptions. Most systems give acceptable performance using only the set of basic parameters. In particular, undocumented optimizer features can cause a great deal of problems that may require considerable investigation. Likewise, optimizer parameters set in the initialization parameter file can Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 17
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
override proven optimal execution plans. For these reasons, schemas, schema statistics, and optimizer settings should be managed together as a group to ensure consistency of performance. 5. Getting database I/O wrong: Many sites lay out their databases poorly over the available disks. Other sites specify the number of disks incorrectly because they configure disks by disk space and not by I/O bandwidth. 6. Redo log setup problems: Many sites run with too small redo log files. Small redo logs cause system checkpoints to continuously put a high load on the buffer cache and the I/O system. If there are very few redo logs, the archive cannot keep up, and the database waits for the archive process to catch up. 7. Excessive serialization: Serialization of data blocks in the buffer cache due to shortage of undo segments is particularly common in applications with large numbers of active users and a few undo segments. Use Automatic Segment Space Management (ASSM) and automatic undo management to solve this problem. 8. Long full table scans: Long full table scans for high-volume or interactive online operations could indicate poor transaction design, missing indexes, or poor SQL optimization. Long table scans, by nature, are I/O-intensive and not scalable.
le
b fera
s
9. High amounts of recursive (SYS) SQL: Large amounts of recursive SQL executed by SYS could indicate that space management activities, such as extent allocations, take place. This is not scalable and impacts user response time. Use locally managed tablespaces to reduce recursive SQL due to extent allocation. Recursive SQL executed under another user ID is probably SQL and PL/SQL, so this is not a problem.
n a r t n-
no a has uideฺ ) m cases, 10. Deployment and migration errors: Ino many Gan application uses too many t has c ฺ n l resources because the schema owning the tables not been successfully migrated i e a or from dan older implementation. u m from the development environment Examples of this t g statistics. S @ are missing indexes or incorrect These errors can lead to suboptimal s 1 interactive 2poor thi user performance. When migrating applications of execution plansaand y e s the schema statistics to maintain plan stability using the ij export u known performance, v u o t DBMS_STATS ah package. s ( Although huSQL.these errors are not directly detected by ADDM, ADDM highlights the resulting higha load S i
Vija
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 18
e
ns e c li
Proactive Tuning Methodology
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Proactive Tuning Methodology • • • • • • •
Simple design Data modeling Tables and indexes Using views Writing efficient SQL Cursor sharing Using bind variables
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a usually implies fixing a performance problem. However, tuning should be part of the Tuning S i a life cycle of an application, through the analysis, design, coding, production, and maintenance Proactive Tuning Methodology
stages. The tuning phase is often left until the system is in production. At that time, tuning becomes a reactive exercise, where the most important bottleneck is identified and fixed.
The slide lists some of the issues that affect performance and that should be tuned proactively instead of reactively. These are discussed in more detail in the following slides.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 19
Simplicity in Application Design
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Simplicity in Application Design • • • •
Simple tables Well-written SQL Indexing only as required Retrieving only required information
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Applications are no different from any other designed and engineered product. If the design S i a looks right, it probably is right. This principle should always be kept in mind when building Simplicity in Application Design
applications. Consider some of the following design issues: •
If the table design is so complicated that nobody can fully understand it, the table is probably designed badly.
•
If SQL statements are so long and involved that it would be impossible for any optimizer to effectively optimize it in real time, there is probably a bad statement, underlying transaction, or table design.
•
If there are many indexes on a table and the same columns are repeatedly indexed, there is probably a bad index design.
•
If queries are submitted without suitable qualification (the WHERE clause) for rapid response for online users, there is probably a bad user interface or transaction design.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 20
Data Modeling
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Data Modeling • • • •
Accurately represent business practices Focus on the most frequent and important business transactions Use modeling tools Appropriately normalize data (OLTP versus DW)
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a modeling is important in successful relational application design. This should be done in Data S i a a way that quickly and accurately represents the business practices. Apply your greatest Data Modeling
modeling efforts to those entities affected by the most frequent business transactions. Use of modeling tools can then rapidly generate schema definitions and can be useful when a fast prototype is required. Normalizing data prevents duplication. When data is normalized, you have a clear picture of the keys and relationships. It is then easier to perform the next step of creating tables, constraints, and indexes. A good data model ultimately means that your queries are written more efficiently.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 21
Table Design
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Table Design •
Compromise between flexibility and performance: – Principally normalize – Selectively denormalize
•
Use Oracle performance and management features: – – – – –
•
e
Default values Constraints Materialized views Clusters Partitioning
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Focus on business-critical tables
Vij
( u h a design is largely a compromise between flexibility and performance of core Table S i a transactions. To keep the database flexible and able to accommodate unforeseen workloads, Table Design
the table design should be very similar to the data model, and it should be normalized to at least third normal form. However, certain core transactions can require selective denormalization for performance purposes.
Use the features supplied with Oracle Database to simplify table design for performance, such as storing tables prejoined in clusters, adding derived columns and aggregate values, and using materialized views or partitioned tables. Additionally, create check constraints and columns with default values to prevent bad data from getting into the tables. Design should be focused on business-critical tables so that good performance can be achieved in areas that are the most used. For noncritical tables, shortcuts in design can be adopted to enable a more rapid application development. If, however, a noncore table becomes a performance problem during prototyping and testing, remedial design efforts should be applied immediately.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 22
Index Design
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Design •
Create indexes on the following: – Primary key (can be automatically created) – Unique key (can be automatically created) – Foreign keys (good candidates)
• •
e
Index data that is frequently queried (select list). Use SQL as a guide to index design.
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a design is also a largely iterative process based on the SQL that is generated by Index S i a application designers. However, it is possible to make a sensible start by building indexes that Index Design
enforce foreign key constraints (to reduce response time on joins between primary key tables and foreign key tables) and creating indexes on frequently accessed data, such as a person’s name. Primary keys and unique keys are automatically indexed except for the DISABLE VALIDATE and DISABLE NOVALIDATE RELY constraints. As the application evolves and testing is performed on realistic sizes of data, certain queries need performance improvements, for which building a better index is a good solution. The following indexing design ideas should be considered when building a new index.
Appending Columns to an Index or Using Index-Organized Tables One of the easiest ways to speed up a query is to reduce the number of logical I/Os by eliminating a table scan from the execution plan. This can be done by creating an index over all the columns of the table referenced by the query. These columns are the select list columns, WHERE clause columns, and any required join or sort columns. This technique is particularly useful in speeding up an online application’s response times when timeconsuming I/Os are reduced. This is best applied when testing the application with properly-sized data for the first time. The most aggressive form of this technique is to build an index-organized table (IOT). Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 23
Using Views
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Views • • •
Simplifies application design Is transparent to the developer Can cause suboptimal execution plans
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can speed up and simplify application design. A simple view definition can mask data Views S i a model complexity from the programmers whose priorities are to retrieve, display, collect, and Using Views
store data. Views are often used to provide simple row and column-level access restrictions.
However, though views provide clean programming interfaces, they can cause suboptimal, resource-intensive queries when nested too deeply. The worst type of view use is creating joins on views that reference other views, which in turn reference other views. In many cases, developers can satisfy the query directly from the table without using a view. Because of their inherent properties, views usually make it difficult for the optimizer to generate the optimal execution plan.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 24
SQL Execution Efficiency
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Execution Efficiency • • • •
Good database connectivity Minimizing parsing Share cursors Using bind variables
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a application that is designed for SQL execution efficiency must support the following An S i a characteristics: SQL Execution Efficiency
Good database connection management: Connecting to the database is an expensive operation that is not scalable. Therefore, the number of concurrent connections to the database should be minimized as much as possible. A simple system, where a user connects at application initialization, is ideal. However, in a Web-based or multitiered application, where application servers are used to multiplex database connections to users, this can be difficult. With these types of applications, design efforts should ensure that database connections are pooled and not reestablished for each user request. Good cursor usage and management: Maintaining user connections is equally important for minimizing the parsing activity on the system. Parsing is the process of interpreting a SQL statement and creating an execution plan for it. This process has many phases, including syntax checking, security checking, execution plan generation, and loading shared structures into the shared pool. There are two types of parse operations: •
Hard parsing: A SQL statement is submitted for the first time, and no match is found in the shared pool. Hard parses are the most resource-intensive and are not scalable because they perform all the operations involved in a parse. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 25
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
Soft parsing: A SQL statement is submitted for the first time, and a match is found in the shared pool. The match can be the result of previous execution by another user. The SQL statement is shared, which is good for performance. However, soft parses are not ideal because they still require syntax and security checking, which consume system resources.
Because parsing should be minimized as much as possible, application developers should design their applications to parse SQL statements once and execute them many times. This is done through cursors. Experienced SQL programmers should be familiar with the concept of opening and reexecuting cursors. Application developers must also ensure that SQL statements are shared within the shared pool. To do this, bind variables to represent the parts of the query that change from execution to execution. If this is not done, the SQL statement is likely to be parsed once and never reused by other users. To ensure that SQL is shared, use bind variables and do not use string literals with SQL statements.
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 26
e
ns e c li
Writing SQL to Share Cursors
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Writing SQL to Share Cursors •
Create generic code using the following: – Stored procedures and packages – Database triggers – Any other library routines and procedures
•
e
Write to format standards (improves readability): – – – – –
Case White space Comments Object references Bind variables
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a Applications can share cursors when the code is written in the same way characterwise S i a (which allows the system to recognize that two statements are the same and thus can be
Vij
ns e c li
Writing SQL to Share Cursors
shared), even if you use some special initialization parameters, such as CURSOR_SHARING discussed later in the lesson titled “Using Bind Variables.” You should develop coding conventions for SQL statements in ad hoc queries, SQL scripts, and Oracle Call Interface (OCI) calls.
Use generic shared code: •
Write and store procedures that can be shared across applications.
•
Use database triggers.
•
Write referenced triggers and procedures when using application development tools.
•
Write library routines and procedures in other environments.
Write to format standards: •
Develop format standards for all statements, including those in PL/SQL code.
•
Develop rules for the use of uppercase and lowercase characters.
•
Develop rules for the use of white space (spaces, tabs, returns). Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 27
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Develop rules for the use of comments (preferably keeping them out of the SQL statements themselves).
•
Use the same names to refer to identical database objects. If possible, prefix each object with a schema name.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 28
ns e c li
Performance Checklist
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Performance Checklist
i a j i V
• • • • • •
Set initialization parameters and storage options. Verify resource usage of SQL statements. Validate connections by middleware. Verify cursor sharing. Validate migration of all required objects. Verify validity and availability of optimizer statistics.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a• Set the minimal number of initialization parameters. Ideally, most initialization
Performance Checklist
S
parameters should be left at default. If there is more tuning to perform, this shows up when the system is under load. Set storage options for tables and indexes in appropriate tablespaces. •
Verify that all SQL statements are optimal and understand their resource usage.
•
Validate that middleware and programs that connect to the database are efficient in their connection management and do not log on and log off repeatedly.
•
Validate that the SQL statements use cursors efficiently. Each SQL statement should be parsed once and then executed multiple times. This happens mostly when bind variables are not used properly and the WHERE clause predicates are sent as string literals.
•
Validate that all schema objects are correctly migrated from the development environment to the production database. This includes tables, indexes, sequences, triggers, packages, procedures, functions, Java objects, synonyms, grants, and views. Ensure that any modifications made in testing are made to the production system.
•
As soon as the system is rolled out, establish a baseline set of statistics from the database and operating system. This first set of statistics validates or corrects any assumptions made in the design and rollout process. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 29
Development Environments: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Development Environments: Overview • SQL Developer • SQL*Plus
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah SQL Developer
(
PL/SQL Development Environments
ahu
S Developer i SQL a j i V This course has been developed using Oracle SQL Developer as the tool for running the SQL statements discussed in the examples in the slide and the practices. •
SQL Developer is shipped with Oracle Database 11g Release 2, and is the default tool for this class.
SQL*Plus The SQL*Plus environment may also be used to run all SQL commands covered in this course. Note: See Appendix C titled “Using SQL Developer” for information about using SQL Developer, including simple instructions on installing version 2.1.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 30
What Is Oracle SQL Developer?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
What Is Oracle SQL Developer? •
• • •
Oracle SQL Developer is a free graphical tool that enhances productivity and simplifies database development tasks. You can connect to any target Oracle database schema using standard Oracle database authentication. You will use SQL Developer in this course. Appendix C contains details on using SQL Developer rable
e
f s n tra
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g SQLs Developer S @ i 1 y2 se th a j i uv to u
h
a s ( u
What Is Oracle SQL Developer?
ah SQL Developer is a free graphical tool designed to improve your productivity and Oracle S i ija simplify the development of everyday database tasks. With just a few clicks, you can easily
V
create and maintain stored procedures, test SQL statements, and view optimizer plans.
SQL Developer, the visual tool for database development, simplifies the following tasks: •
Browsing and managing database objects
•
Executing SQL statements and scripts
•
Editing and debugging PL/SQL statements
•
Creating reports
You can connect to any target Oracle database schema using standard Oracle database authentication. When connected, you can perform operations on objects in the database. Appendix C Appendix C of this course provides an introduction on using the SQL Developer interface. It also provides information about creating a database connection, interacting with data using SQL and PL/SQL, and so on.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 31
e
ns e c li
Coding PL/SQL in SQL*Plus
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Coding PL/SQL in SQL*Plus
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL*Plus is a command-line interface that enables you to submit SQL statements and Oracle S i a PL/SQL blocks for execution and receive the results in an application or a command window. Coding PL/SQL in SQL*Plus
SQL*Plus is: •
Shipped with the database
•
Accessed from an icon or the command line
When coding PL/SQL subprograms using SQL*Plus, remember the following: •
You create subprograms by using the CREATE SQL statement.
•
You execute subprograms by using either an anonymous PL/SQL block or the EXECUTE command.
•
If you use the DBMS_OUTPUT package procedures to print text to the screen, you must first execute the SET SERVEROUTPUT ON command in your session.
Note •
To launch SQL*Plus in the Linux environment, open a Terminal window and enter the sqlplus command.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 32
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
For more information about how to use SQL*Plus, see the SQL*Plus User's Guide and Reference.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 33
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz _________automatically identifies bottlenecks within Oracle Database and makes recommendations on the options available for fixing these bottlenecks. a. ASH b. AWR c. ADDM le d. Snapshots rab
e
f s n tra
h
a s ( u
Answer: c
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 34
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Normalizing data results in a good data model, which ultimately means that your queries are written more efficiently. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 35
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Views should be used carefully because, though they provide clean programming interfaces, they can cause suboptimal, resource-intensive queries when nested too deeply. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 36
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Identify the characteristics that must be supported by an application designed for SQL execution efficiency. a. Use concurrent connections to the database. b. Use cursors so that SQL statements are parsed once and executed multiple times. c. Use bind variables.
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b, c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 37
le
b fera
s
n a r t n-
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Describe what attributes of a SQL statement can make it perform poorly • List the Oracle tools that can be used to tune SQL • List the tuning tasks
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 38
ns e c li
Practice 2: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 2: Overview
i a j i V
This practice covers the following topics: • Rewriting queries for better performance • Rewriting applications for better performance
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 39
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to SQL Tuning Chapter 2 - Page 40
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
Introduction noto the Optimizer
a ฺ s a Chapterh3 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Introduction to the Optimizer
i a j i V
Introduction to the Optimizer
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to: • Describe the execution steps of a SQL statement • Discuss the need for an optimizer • Explain the various phases of optimization • Control the behavior of the optimizer
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 3
ns e c li
Structured Query Language
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Structured Query Language DML
ESS DDL
INSERT UPDATE DELETE MERGE SELECT
TCS COMMIT ROLLBACK SAVEPOINT SET TRANSACTION
CREATE DROP ALTER RENAME TRUNCATE GRANT REVOKE AUDIT NOAUDIT COMMENT
DECLARE CONNECT OPEN CLOSE DESCRIBE WHENEVER PREPARE EXECUTE FETCH
e
le
b fera
ns e c li
s
n a r t n-
no SessionCS a ฺ SESSION has uideALTER ) System mCS t G SET ROLE o c ฺ n l i SYSTEM aALTER de u m t g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h All a programs and users access data in an Oracle Database with the language SQL Oracle S i tools and Application programs often allow users to access the database without using SQL a Structured Query Language
directly, but then these applications must use SQL when executing user requests. Oracle Corp strives to comply with industry-accepted standards and participates in SQL standards committees (ANSI and ISO). You can categorize SQL statements into six main sets: •
Data manipulation language (DML) statements manipulate or query data in existing schema objects.
•
Data definition language (DDL) statements define, alter the structure of, and drop schema objects.
•
Transaction control statements (TCS) manage the changes made by DML statements and group DML statements into transactions.
•
System Control statements change the properties of the Oracle Database instance.
•
Session Control statements manage the properties of a particular user’s session.
•
Embedded SQL statements incorporate DDL, DML, and TCS within a procedural language program, such as PL/SQL and Oracle precompilers. This incorporation is done using the statements listed in the slide under the ESS category.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 4
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 5
ns e c li
SQL Statement Representation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Representation
e
Private SQL area
Private SQL area
Private SQL area
Private SQL area
Private SQL area
le
b fera
ns e c li
s
n a r t n-
no a has uiShared deฺ ) Shared SQL area om nt G SQL area c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Database represents each SQL statement it runs with a shared SQL area and a Oracle S i a private SQL area. Oracle Database recognizes when two users execute the same SQL SQL Statement Representation
statement and reuses the shared SQL area for those users. However, each user must have a separate copy of the statement’s private SQL area. A shared SQL area contains all optimization information necessary to execute the statement whereas a private SQL area contains all run-time information related to a particular execution of the statement. Oracle Database saves memory by using one shared SQL area for SQL statements run multiple times, which often happens when many users run the same application. Note: In evaluating whether statements are similar or identical, Oracle Database considers SQL statements issued directly by users and applications, as well as recursive SQL statements issued internally by a DDL statement.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 6
SQL Statement Implementation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Implementation User process
User process
User process
User process
User process
Server process
Server process
Private SQL area
Private SQL area
Client Server Server process
Server process
Server process
Private SQL area
Private SQL area
Private SQL area
Aggregated PGA
SGA
e
le
b fera
ns e c li
Vij
s n a r Shared Shared n-t o SQL area SQLn area a Library cache Java pool s ฺ Buffer cache a e h uidOther Data dictionary )cache Result m cache co ent G ฺ l i Redo log Streams pool ma SHARED_POOL buffer tud g S 1@ this 2 y ja use i v to hu a s ( SQL Statement Implementation u h a Database creates and uses memory structures for various purposes. For example, Oracle S i a memory stores program codes that are run, data that is shared among users, and private data areas for each connected user.
Oracle Database allocates memory from the shared pool when a new SQL statement is parsed, to store in the shared SQL area. The size of this memory depends on the complexity of the statement. If the entire shared pool has already been allocated, Oracle Database can deallocate items from the pool using a modified least recently used (LRU) algorithm until there is enough free space for the new statement’s shared SQL area. If Oracle Database deallocates a shared SQL area, the associated SQL statement must be reparsed and reassigned to another shared SQL area at its next execution.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 7
SQL Statement Processing: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Processing: Overview OPEN PARSE
query?
yes
describe?
no
yes
no
DESCRIBE no
more?
yes
DEFINE no
more?
e
yes
yes reparse?
no
yes
bind? no
le
BIND no
more?
yes
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah EXECUTE
query?
yes
s
n a r t n-
PARALLELIZE
b fera
ns e c li
FETCH
no
yes
execute others?
no
more?
yes
no
CLOSE
( u h a graphic in the slide shows all the steps involved in query execution and these steps can The S i a be found in Oracle® Database Concepts 11g Release 1 (11.1). SQL Statement Processing: Overview
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 8
SQL Statement Processing: Steps
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Processing: Steps 1. 2. 3. 4. 5. 6. 7. 8. 9.
Create a cursor. Parse the statement. Describe query results. Define query output. Bind variables. Parallelize the statement. Execute the statement. Fetch rows of a query. Close the cursor.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a that not all statements require all these steps. For example, nonparallel DDL statements Note S i a are required in only two steps: Create and Parse. SQL Statement Processing: Steps
Parallelizing the statement involves deciding that it can be parallelized as opposed to actually building parallel execution structures.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 9
Step 1: Create a Cursor
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Step 1: Create a Cursor • • • •
A cursor is a handle or name for a private SQL area. It contains information for statement processing. It is created by a program interface call in expectation of a SQL statement. The cursor structure is independent of the SQL statement that it contains.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h Aacursor can be thought of as an association between a cursor data area in a client program S i a and Oracle server’s data structures. Most Oracle tools hide much of cursor handling from the
Vij
Step 1: Create a Cursor
user, but Oracle Call Interface (OCI) programs need the flexibility to be able to process each part of query execution separately. Therefore, precompilers allow explicit cursor declaration. Most of this can also be done using the DBMS_SQL package as well. A handle is similar to the handle on a mug. When you have a hold of the handle, you have a hold of the cursor. It is a unique identifier for a particular cursor that can only be obtained by one process at a time.
Programs must have an open cursor to process a SQL statement. The cursor contains a pointer to the current row. The pointer moves as rows are fetched until there are no more rows left to process. The following slides use the DBMS_SQL package to illustrate cursor management. This may be confusing to people unfamiliar with it; however, it is more friendly than PRO*C or OCI. It is slightly problematic in that it performs FETCH and EXECUTE together, so the execute phase cannot be separately identified in the trace.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 10
e
ns e c li
Step 2: Parse the Statement
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Step 2: Parse the Statement • •
•
Statement passed from the user process to the Oracle instance Parsed representation of SQL created and moved into the shared SQL area if there is no identical SQL in the shared SQL area Can be reused if identical SQL exists
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a parsing, the SQL statement is passed from the user process to the Oracle instance, During S i a and a parsed representation of the SQL statement is loaded into a shared SQL area.
Vij
Step 2: Parse the Statement
Translation and verification involve checking if the statement already exists in the library cache. For distributed statements, check for the existence of database links. Typically, the parse phase is represented as the stage where the query plan is generated. The parse step can be deferred by the client software to reduce network traffic. What this means is that the PARSE is bundled with the EXECUTE, so there are fewer round-trips to the server. Note: When checking if statements are identical, they must be identical in every way including case and spacing.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 11
e
ns e c li
Steps 3 and 4: Describe and Define
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Steps 3 and 4: Describe and Define •
The describe step provides information about the select list items; it is relevant when entering dynamic queries through an OCI application. The define step defines location, size, and data type information required to store fetched values in variables.
•
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Steps 3 and 4: Describe and Define
ahu
S 3: Describe i Step a j i V The describe stage is necessary only if the characteristics of a query’s result are not known, for example, when a query is entered interactively by a user. In this case, the describe stage determines the characteristics (data types, lengths, and names) of a query’s result. Describe tells the application what select list items are required. If, for example, you enter a query such as: SQL> select * from employees;, information about the columns in the employees table is required. Step 4: Define In the define stage, you specify the location, size, and data type of variables defined to receive each fetched value. These variables are called define variables. Oracle Database performs data type conversion, if necessary. These two steps are generally hidden from users in tools such as SQL*Plus. However, with DBMS_SQL or OCI, it is necessary to tell the client what the output data is and which the setup areas are. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 12
e
ns e c li
Steps 5 and 6: Bind and Parallelize
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Steps 5 and 6: Bind and Parallelize •
Bind any bind values: – Enables memory address to store data values – Allows shared SQL even though bind values may change
•
Parallelize the statement: – – – – – – –
e
SELECT INSERT UPDATE MERGE DELETE CREATE ALTER
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Steps 5 and 6: Bind and Parallelize
ahu
S 5: Bind i Step a j i V At this point, Oracle Database knows the meaning of the SQL statement, but still does not have enough information to run the statement. Oracle Database needs values for any variables listed in the statement. The process of obtaining these values is called binding variables. Step 6: Parallelize Oracle Database can parallelize the execution of SQL statements (such as SELECT, INSERT, UPDATE, MERGE, DELETE), and some DDL operations, such as index creation, creating a table with a subquery, and operations on partitions. Parallelization causes multiple server processes to perform the work of the SQL statement, so it can complete faster. Parallelization involves dividing the work of a statement among a number of slave processes. Parsing has already identified if a statement can be parallelized or not and has built the appropriate parallel plan. At execution time, this plan is then implemented if sufficient resource is available.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 13
Steps 7 Through 9
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Steps 7 Through 9 •
Execute: – Drives the SQL statement to produce the desired results
•
Fetch rows: – Into defined output variables – Query results returned in table format – Array fetch mechanism
•
e
le
Close the cursor.
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athis point, Oracle Database has all the necessary information and resources, so the At S i a statement is run. If the statement is a query (without the FOR UPDATE clause) statement, no Steps 7 Through 9
rows need to be locked because no data is changed. If the statement is an UPDATE or a DELETE statement, however, all rows that the statement affects are locked until the next COMMIT, ROLLBACK, or SAVEPOINT for the transaction. This ensures data integrity.
For some statements, you can specify a number of executions to be performed. This is called array processing. Given n number of executions, the bind and define locations are assumed to be the beginning of an array of size n. In the fetch stage, rows are selected and ordered (if requested by the query), and each successive fetch retrieves another row of the result until the last row has been fetched. The final stage of processing a SQL statement is closing the cursor.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 14
SQL Statement Processing PL/SQL: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Processing PL/SQL: Example SQL> variable c1 number SQL> execute :c1 := dbms_sql.open_cursor; SQL> SQL> 2 3 4
variable b1 varchar2 execute dbms_sql.parse (:c1 ,'select null from dual where dummy = :b1' ,dbms_sql.native);
le
b fera
SQL> execute :b1:='Y'; s SQL> exec dbms_sql.bind_variable(:c1,':b1',:b1); ran
-t n o n SQL> variable r number a SQL> execute :r := dbms_sql.execute(:c1); has uideฺ ) om nt G SQL> variable r number c ฺ l i adbms_sql.close_cursor(:c1); de SQL> execute :r := u m t g sS @ 1 hi 2 t y e ija us v u to h a s ( SQL Statement Processing PL/SQL: Example u h a example summarizes the various steps discussed previously. This S i a
Vij
e
ns e c li
Note: In this example, you do not show the fetch operation. It is also possible to combine both the EXECUTE and FETCH operations in EXECUTE_AND_FETCH to perform EXECUTE and FETCH together in one call. This may reduce the number of network round-trips when used against a remote database.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 15
SQL Statement Parsing: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Parsing: Overview
Syntactic and semantic check Privileges check Private SQL area
Parse call
Allocate private SQL Area
e
le
b fera
ns e c li
s n a r n-t Parse operation Parsed representation
Existing shared SQL area?
No (Hard parse)
(Optimization) no a eฺshared SQL area hasAllocate d i ) m t Gu o c Shared ilฺ den Executeastatement SQL area u m St g 1@ this 2 y ja use i v u to sah Yes (Soft parse)
Vij
( u h a is one stage in the processing of a SQL statement. When an application issues a SQL Parsing S i a statement, the application makes a parse call to Oracle Database. During the parse call, SQL Statement Parsing: Overview
Oracle Database performs the following actions: •
Checks the statement for syntactic and semantic validity
•
Determines whether the process issuing the statement has the privileges to run it
•
Allocates a private SQL area for the statement
•
Determines whether or not there is an existing shared SQL area containing the parsed representation of the statement in the library cache. If so, the user process uses this parsed representation and runs the statement immediately. If not, Oracle Database generates the parsed representation of the statement, and the user process allocates a shared SQL area for the statement in the library cache and stores its parsed representation there.
Note the difference between an application making a parse call for a SQL statement and Oracle Database actually parsing the statement. •
A parse call by the application associates a SQL statement with a private SQL area. After a statement has been associated with a private SQL area, it can be run repeatedly without your application making a parse call. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 16
•
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Both parse calls and parsing can be expensive relative to execution, so perform them as rarely as possible.
i a j i V
Note: Although parsing a SQL statement validates that statement, parsing only identifies errors that can be found before statement execution. Thus, some errors cannot be caught by parsing. For example, errors in data conversion or errors in data (such as an attempt to enter duplicate values in a primary key) and deadlocks are all errors or situations that can be encountered and reported only during the execution stage.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 17
ns e c li
Why Do You Need an Optimizer?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Why Do You Need an Optimizer? Query to optimize SELECT * FROM emp WHERE job = 'MANAGER'; Schema information
How to retrieve these rows? Possible access paths
Use the index.
1
Read each row and check.
le
s
n a r t Which one is faster? Statistics o2nn a ฺ s Only 1% of employees are managers a h uide ) om nt G c ฺ l Use the ai tude I have a plan! 3 m index g sS @ 1 hi 2 t y e ija us v u to h a s (You Need an Optimizer? Why Do u h a optimizer should always return the correct result as quickly as possible. The S i a
Vij
b fera
The query optimizer tries to determine which execution plan is most efficient by considering available access paths and by factoring in information based on statistics for the schema objects (tables or indexes) accessed by the SQL statement. The query optimizer performs the following steps: 1. The optimizer generates a set of potential plans for the SQL statement based on available access paths. 2. The optimizer estimates the cost of each plan based on statistics in the data dictionary for the data distribution and storage characteristics of the tables, and indexes accessed by the statement. 3. The optimizer compares the costs of the plans and selects the one with the lowest cost. Note: Because of the complexity of finding the best possible execution plan for a particular query, the optimizer’s goal is to find a “good” plan that is generally called the best cost plan.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 18
e
ns e c li
Why Do You Need an Optimizer?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Why Do You Need an Optimizer? Query to optimize SELECT * FROM emp WHERE job = 'MANAGER'; How to retrieve these rows?
Schema information
Possible access paths
Use the index.
1
Read each row and check.
le
b fera
s n a r Which one is faster? Statistics 2n-t o n a 80% of employees are managers has uideฺ ) om nt G c ฺ l Use Full ai tude Generate a plan 3 m Table Scan g sS @ 1 hi 2 t y e ija us v u to h a s (You Need an Optimizer? (continued) Why Do u h a example in the slide shows you that if statistics change, the optimizer adapts its execution The S i a plan. In this case, statistics show that 80 percent of the employees are managers. In the
Vij
hypothetical case, a full table scan is probably a better solution than using the index.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 19
e
ns e c li
Optimization During Hard Parse Operation
Parsed representation (query blocks) Optimizer Transformer
e
Statistics CBO
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimization During Hard Parse Operation
Estimator Plan Generator
le
b fera
Dictionary
ns e c li
s
n a r t n-
no a Execution Plan as h uideฺ ) om nt G Shared c ฺ l SQL area ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a optimizer creates the execution plan for a SQL statement. The S i a Optimization During Hard Parse Operation
SQL queries submitted to the system first run through the parser, which checks syntax and analyzes semantics. The result of this phase is called a parsed representation of the statement, and is constituted by a set of query blocks. A query block is a self-contained DML against a table. A query block can be a top-level DML or a subquery. This parsed representation is then sent to the optimizer, which handles three main functionalities: Transformation, estimation, and execution plan generation. Before performing any cost calculation, the system may transform your statement into an equivalent statement and calculate the cost of the equivalent statement. Depending on the version of Oracle Database, there are transformations that cannot be done, some that are always done, and some that are done, costed, and discarded. The input to the query transformer is a parsed query, which is represented by a set of interrelated query blocks. The main objective of the query transformer is to determine if it is advantageous to change the structure of the query so that it enables generation of a better query plan. Several query transformation techniques are employed by the query transformer, such as transitivity, view merging, predicate pushing, subquery unnesting, query rewrite, star transformation, and OR expansion. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 20
Transformer: OR Expansion Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Transformer: OR Expansion Example •
Original query:
B*-tree Index
SELECT * FROM emp WHERE job = 'CLERK' OR deptno = 10;
•
e
Equivalent transformed query:
le
b fera
SELECT * FROM emp WHERE job = 'CLERK'
ns e c li
s
n a r t n-
no a has uideฺ ) FROM emp om nt G c ฺ l WHERE deptno = 10 AND ai job de 'CLERK'; u m t g sS @ 1 hi 2 t y e ija us v u to sah
UNION ALL SELECT *
Vij
( u h Ifaa query contains a WHERE clause with multiple conditions combined with OR operators, the S i a Transformer: OR Expansion Example
optimizer transforms it into an equivalent compound query that uses the UNION ALL set operator, if this makes the query execute more efficiently.
For example, if each condition individually makes an index access path available, the optimizer can make the transformation. The optimizer selects an execution plan for the resulting statement that accesses the table multiple times using the different indexes and then puts the results together. This transformation is done if the cost estimation is better than the cost of the original statement. In the example in the slide, it is assumed that there are indexes on both the JOB and DEPTNO columns. Then, the optimizer might transform the original query into the equivalent transformed query shown in the slide. When the cost-based optimizer (CBO) decides whether to make a transformation, the optimizer compares the cost of executing the original query using a full table scan with that of executing the resulting query.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 21
Transformer: Subquery Unnesting Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Transformer: Subquery Unnesting Example •
Original query: SELECT * FROM accounts WHERE custno IN
e
(SELECT custno FROM customers);
•
Equivalent transformed query:
le
b fera
ns e c li
s
n a r t n-
SELECT accounts.*
FROM accounts, customers WHERE accounts.custno = customers.custno;
no a has uideฺ ) om nt G c ฺ l Primary or unique key ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a unnest a query, the optimizer may choose to transform the original query into an equivalent To S i a JOIN statement, and then optimize the JOIN statement. Transformer: Subquery Unnesting Example
The optimizer may do this transformation only if the resulting JOIN statement is guaranteed to return exactly the same rows as the original statement. This transformation allows the optimizer to take advantage of the join optimizer techniques. In the example in the slide, if the CUSTNO column of the customers table is a primary key or has a UNIQUE constraint, the optimizer can transform the complex query into the shown JOIN statement that is guaranteed to return the same data. If the optimizer cannot transform a complex statement into a JOIN statement, it selects execution plans for the parent statement and the subquery as though they were separate statements. The optimizer then executes the subquery and uses the rows returned to execute the parent query. Note: Complex queries whose subqueries contain aggregate functions such as AVG cannot be transformed into JOIN statements.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 22
Transformer: View Merging Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Transformer: View Merging Example •
Original query:
Index
CREATE VIEW emp_10 AS SELECT empno, ename, job, sal, comm, deptno FROM emp
e
WHERE deptno = 10;
le
b fera
SELECT empno FROM emp_10 WHERE empno > 7800;
•
Equivalent transformed query:
ns e c li
s
n a r t n-
Vij
no a SELECT empno has uideฺ ) FROM emp G om >nt7800; c ฺ WHERE deptno = 10 AND empno l i e ma Stud g 1@ this 2 y ja use i v to hu a s ( View Merging Example Transformer: u h a merge the view’s query into a referencing query block in the accessing statement, the To S i a optimizer replaces the name of the view with the names of its base tables in the query block and adds the condition of the view’s query’s WHERE clause to the accessing query block’s WHERE clause.
This optimization applies to select-project-join views, which contain only selections, projections, and joins. That is, views that do not contain set operators, aggregate functions, DISTINCT, GROUP BY, CONNECT BY, and so on. The view in this example is of all employees who work in department 10. The query that follows the view’s definition in the slide accesses the view. The query selects the IDs greater than 7800 of employees who work in department 10. The optimizer may transform the query into the equivalent transformed query shown in the slide that accesses the view’s base table. If there are indexes on the DEPTNO or EMPNO columns, the resulting WHERE clause makes them available.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 23
Transformer: Predicate Pushing Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Transformer: Predicate Pushing Example •
Original query:
Index
CREATE VIEW two_emp_tables AS SELECT empno, ename, job, sal, comm, deptno FROM emp1 UNION SELECT empno, ename, job, sal, comm, deptno FROM emp2;
e
SELECT ename FROM two_emp_tables WHERE deptno = 20;
•
le
b fera
Equivalent transformed query:
ns e c li
s
n a r t n-
SELECT ename
no a has uideฺ UNION ) t G comm, com ejob,sal, SELECT empno, iename, ฺ n l a tdeptno ud = 20 ); mWHERE FROM emp2 g S 1@ this 2 y ja use i v u to sah
FROM ( SELECT empno, ename, job,sal, comm, deptno FROM emp1 WHERE deptno = 20 deptno
Vij
( u h a optimizer can transform a query block that accesses a nonmergeable view by pushing the The S i a query block’s predicates inside the view’s query. Transformer: Predicate Pushing Example
In the example in the slide, the two_emp_tables view is the union of two employee tables. The view is defined with a compound query that uses the UNION set operator. The query that follows the view’s definition in the slide accesses the view. The query selects the IDs and names of all employees in either table who work in department 20. Because the view is defined as a compound query, the optimizer cannot merge the view’s query into the accessing query block. Instead, the optimizer can transform the accessing statement by pushing its predicate, the WHERE clause condition deptno = 20, into the view’s compound query. The equivalent transformed query is shown in the slide. If there is an index in the DEPTNO column of both tables, the resulting WHERE clauses make them available.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 24
Transformer: Transitivity Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Transformer: Transitivity Example •
Original query:
Index
SELECT * FROM emp, dept WHERE emp.deptno = 20 AND emp.deptno = dept.deptno;
•
e
Equivalent transformed query:
le
b fera
SELECT *
ns e c li
s
FROM emp, dept WHERE emp.deptno = 20 AND emp.deptno = dept.deptno
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah AND dept.deptno = 20;
Vij
( u h Ifatwo conditions in the WHERE clause involve a common column, the optimizer sometimes can S i a infer a third condition, using the transitivity principle. The optimizer can then use the inferred Transformer: Transitivity Example
condition to optimize the statement.
The inferred condition can make available an index access path that was not made available by the original conditions. This is demonstrated with the example in the slide. The WHERE clause of the original query contains two conditions, each of which uses the EMP.DEPTNO column. Using transitivity, the optimizer infers the following condition: dept.deptno = 20 If an index exists in the DEPT.DEPTNO column, this condition makes access paths available using that index. Note: The optimizer only infers conditions that relate columns to constant expressions, rather than columns to other columns.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 25
Cost-Based Optimizer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cost-Based Optimizer •
Piece of code: – Estimator – Plan generator
•
Estimator determines cost of optimization suggestions made by the plan generator:
•
– Cost: Optimizer’s best estimate of the number of standardized I/Os made to execute a particular statement ble ra optimization sfe
n a r t n-
Plan generator: – – – –
notechniques Tries out different statement optimization a as ideฺ suggestion Uses the estimator to cost eachhoptimization ) u based on cost m suggestion G Chooses the best optimization o t c ilฺ plandefornbest optimization a Generates an execution m tu
g sS @ 1 hi 2 t y e ija us v u to ah
(s u ah
Cost-Based Optimizer
The combination of the estimator and plan generator code is commonly called the cost-based S i ija optimizer (CBO).
V
The estimator generates three types of measures: selectivity, cardinality, and cost. These measures are related to each other. Cardinality is derived from selectivity and often the cost depends on cardinality. The end goal of the estimator is to estimate the overall cost of a given plan. If statistics are available, the estimator uses these to improve the degree of accuracy when computing the measures. The main function of the plan generator is to try out different possible plans for a given query and pick the one that has the lowest cost. Many different plans are possible because of the various combinations of different access paths, join methods, and join orders that can be used to access and process data in different ways and produce the same result. The number of possible plans for a query block is proportional to the number of join items in the FROM clause. This number rises exponentially with the number of join items. The optimizer uses various pieces of information to determine the best path: WHERE clause, statistics, initialization parameters, supplied hints, and schema information.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 26
e
ns e c li
Estimator: Selectivity
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Estimator: Selectivity Selectivity =
• •
•
•
Number of rows satisfying a condition Total number of rows
Selectivity is the estimated proportion of a row set retrieved by a particular predicate or combination of predicates. It is expressed as a value between 0.0 and 1.0: – High selectivity: Small proportion of rows – Low selectivity: Big proportion of rows le b a r Selectivity computation: fe s n – If no statistics: Use dynamic sampling tra n – If no histograms: Assume even distribution no of rows a Statistic information: as ideฺ h ) – DBA_TABLES and DBA_TAB_STATISTICS m t Gu (NUM_ROWS) o c n ilฺ de(NUM_DISTINCT, – DBA_TAB_COL_STATISTICS DENSITY, a u m t HIGH/LOW_VALUE,…) g S
1@ this 2 y ja use i v u to sah
( u h a Selectivity represents a fraction of rows from a row set. The row set can be a base table, a S i a view, or the result of a join or a GROUP BY operator. The selectivity is tied to a query
Vij
Estimator: Selectivity
predicate, such as last_name = 'Smith', or a combination of predicates, such as last_name = 'Smith' AND job_type = 'Clerk'. A predicate acts as a filter that filters a certain number of rows from a row set. Therefore, the selectivity of a predicate indicates the percentage of rows from a row set that passes the predicate test. Selectivity lies in a value range from 0.0 to 1.0. A selectivity of 0.0 means that no rows are selected from a row set, and a selectivity of 1.0 means that all rows are selected. If no statistics are available, the optimizer either uses dynamic sampling or an internal default value, depending on the value of the OPTIMIZER_DYNAMIC_SAMPLING initialization parameter. When statistics are available, the estimator uses them to estimate selectivity. For example, for an equality predicate (last_name = 'Smith'), selectivity is set to the reciprocal of the number n of distinct values of LAST_NAME because the query selects rows that contain one out of n distinct values. Thus, even distribution is assumed. If a histogram is available in the LAST_NAME column, the estimator uses it instead of the number of distinct values. The histogram captures the distribution of different values in a column, so it yields better selectivity estimates.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 27
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: It is important to have histograms in columns that contain values with large variations in the number of duplicates (data skew).
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 28
ns e c li
Estimator: Cardinality
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Estimator: Cardinality Cardinality = Selectivity * Total number of rows
• • •
Expected number of rows retrieved by a particular operation in the execution plan Vital figure to determine join, filters, and sort costs Simple example:
e
le
b fera
SELECT days FROM courses WHERE dev_name = 'ANGEL';
ns e c li
s n – The number of distinct values in DEV_NAME is 203. a r -t n – The number of rows in COURSES (originalocardinality) is n a ฺ 1018. s a h uide – Selectivity = 1/203 = 4.926*e-03 ) m tG – Cardinality = (1/203)*1018 li ฺco = 5.01 en (rounded off to 6)
ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a cardinality of a particular operation in the execution plan of a query represents the The S i a estimated number of rows retrieved by that particular operation. Most of the time, the row Estimator: Cardinality
source can be a base table, a view, or the result of a join or GROUP BY operator.
When costing a join operation, it is important to know the cardinality of the driving row source. With nested loops join, for example, the driving row source defines how often the system probes the inner row source. Because sort costs are dependent on the size and number of rows to be sorted, cardinality figures are also vital for sort costing. In the example in the slide, based on assumed statistics, the optimizer knows that there are 203 different values in the DEV_NAME column, and that the total number of rows in the COURSES table is 1018. Based on this assumption, the optimizer deduces that the selectivity of the DEV_NAME='ANGEL' predicate is 1/203 (assuming there are no histograms), and also deduces the cardinality of the query to be (1/203)*1018. This number is then rounded off to the nearest integer, 6.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 29
Estimator: Cost
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Estimator: Cost •
•
Cost is the optimizer’s best estimate of the number of standardized I/Os it takes to execute a particular statement. Cost unit is a standardized single block random read: – 1 cost unit = 1 SRds
•
The cost formula combines three different costs units into e standard cost units. abl
r
Multiblock I/O cost
Single block I/O cost
fe s n CPU cost a n-tr
o n#CPUCycles/cpuspeed a sreadtimas h uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah #SRds*sreadtim
+
#MRds*mreadtim +
Cost=
#SRds: Number of single block reads #MRds: Number of multiblock reads #CPUCycles: Number of CPU Cycles
Sreadtim: Single block read time Mreadtim: Multiblock read time Cpuspeed: Millions instructions per second
( u h a cost of a statement represents the optimizer’s best estimate of the number of The S i a standardized inputs/outputs (I/Os) it takes to execute that statement. Basically, the cost is a
Vij
Estimator: Cost
normalized value in terms of a number of single block random reads
The standard cost metric measured by the optimizer is in terms of number of single block random reads, so one cost unit corresponds to one single block random read. The formula shown in the slide combines three different cost units: •
Estimated time to do all the single-block random reads
•
Estimated time to do all the multiblock reads
•
Estimated time for the CPU to process the statement into one standard cost unit
The model includes CPU costing because in most cases CPU utilization is as important as I/O; often it is the only contribution to the cost (in cases of in-memory sort, hash, predicate evaluation, and cached I/O). This model is straightforward for serial execution. For parallel execution, necessary adjustments are made while computing estimates for #SRds, #MRds, and #CPUCycles. Note: #CPUCycles includes CPU cost of query processing (pure CPU cost) and CPU cost of data retrieval (CPU cost of the buffer cache get). Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 30
e
ns e c li
Plan Generator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Plan Generator select e.last_name, d.department_name from employees e, departments d where e.department_id = d.department_id; Join order[1]: DEPARTMENTS[D]#0 EMPLOYEES[E]#1 NL Join: Cost: 41.13 Resp: 41.13 Degree: 1 SM cost: 8.01 HA cost: 6.51 Best:: JoinMethod: Hash Cost: 6.51 Degree: 1 Resp: 6.51 Card: 106.00 Join order[2]: EMPLOYEES[E]#1 DEPARTMENTS[D]#0 NL Join: Cost: 121.24 Resp: 121.24 Degree: 1 SM cost: 8.01 HA cost: 6.51 Join order aborted Final cost for query block SEL$1 (#0) All Rows Plan: Best join order: 1 +----------------------------------------------------------------+ | Id | Operation | Name | Rows | Bytes | Cost | +----------------------------------------------------------------+ | 0 | SELECT STATEMENT | | | | 7 | | 1 | HASH JOIN | | 106 | 6042 | 7 | | 2 | TABLE ACCESS FULL | DEPARTMENTS| 27 | 810 | 3 | | 3 | TABLE ACCESS FULL | EMPLOYEES | 107 | 2889 | 3 | +----------------------------------------------------------------+
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a plan generator explores various plans for a query block by trying out different access The S i a paths, join methods, and join orders. Ultimately, the plan generator delivers the best execution Plan Generator
plan for your statement. The slide shows you an extract of an optimizer trace file generated for the select statement. As you can see from the trace, the plan generator has six possibilities, or six different plans to test: Two join orders, and for each, three different join methods. It is assumed that there are no indexes in this example. To retrieve the rows, you can start to join the DEPARTMENTS table to the EMPLOYEES table. For that particular join order, you can use three possible join mechanisms that the optimizer knows: Nested Loop, Sort Merge, or Hash Join. For each possibility, you have the cost of the corresponding plan. The best plan is the one shown at the end of the trace. The plan generator uses an internal cutoff to reduce the number of plans it tries when finding the one with the lowest cost. The cutoff is based on the cost of the current best plan. If the current best cost is large, the plan generator tries harder (in other words, explores more alternate plans) to find a better plan with lower cost. If the current best cost is small, the plan generator ends the search swiftly because further cost improvement is not significant. The cutoff works well if the plan generator starts with an initial join order that produces a plan with a cost close to optimal. Finding a good initial join order is a difficult problem. Note: Access path, join methods, and plan are discussed in more detail in the lessons titled “Optimizer Operators” and “Interpreting Execution Plans.” Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 31
Controlling the Behavior of the Optimizer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Controlling the Behavior of the Optimizer • • • • • • • •
CURSOR_SHARING: SIMILAR, EXACT, FORCE DB_FILE_MULTIBLOCK_READ_COUNT PGA_AGGREGATE_TARGET STAR_TRANSFORMATION_ENABLED RESULT_CACHE_MODE: MANUAL, FORCE RESULT_CACHE_MAX_SIZE RESULT_CACHE_MAX_RESULT RESULT_CACHE_REMOTE_EXPIRATION
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a parameters control the optimizer behavior: These S i a Controlling the Behavior of the Optimizer •
•
CURSOR_SHARING determines what kind of SQL statements can share the same cursors: -
FORCE: Forces statements that may differ in some literals, but are otherwise identical, to share a cursor, unless the literals affect the meaning of the statement
-
SIMILAR: Causes statements that may differ in some literals, but are otherwise identical, to share a cursor, unless the literals affect either the meaning of the statement or the degree to which the plan is optimized. Forcing cursor sharing among similar (but not identical) statements can have unexpected results in some decision support system (DSS) applications, or applications that use stored outlines.
-
EXACT: Only allows statements with identical text to share the same cursor. This is the default.
DB_FILE_MULTIBLOCK_READ_COUNT is one of the parameters you can use to minimize I/O during table scans or index fast full scan. It specifies the maximum number of blocks read in one I/O operation during a sequential scan. The total number of I/Os needed to perform a full table scan or an index fast full scan depends on factors, such as the size of the segment, the multiblock read count, and whether parallel execution is Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 32
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
Because the parameter is expressed in blocks, it automatically computes a value that is equal to the maximum I/O size that can be performed efficiently divided by the standard block size. Note that if the number of sessions is extremely large, the multiblock read count value is decreased to avoid the buffer cache getting flooded with too many table scan buffers. Even though the default value may be a large value, the optimizer does not favor large plans if you do not set this parameter. It would do so only if you explicitly set this parameter to a large value. Basically, if this parameter is not set explicitly (or is set is 0), the optimizer uses a default value of 8 when costing full table scans and index fast full scans. Online transaction processing (OLTP) and batch environments typically have values in the range of 4 to 16 for this parameter. DSS and data warehouse environments tend to benefit most from maximizing the value of this parameter. The optimizer is more likely to select a full table scan over an index, if the value of this parameter is high. •
le
PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server processes attached to the instance. Setting PGA_AGGREGATE_TARGET to a nonzero value has the effect of automatically setting the WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working areas used by memory-intensive SQL operators (such as sort, group-by, hash-join, bitmap merge, and bitmap create) are automatically sized. A nonzero value for this parameter is the default because, unless you specify otherwise, the system sets it to 20% of the SGA or 10 MB, whichever is greater. Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL work areas are sized using the *_AREA_SIZE parameters. The system attempts to keep the amount of private memory below the target specified by this parameter by adapting the size of the work areas to private memory. When increasing the value of this parameter, you indirectly increase the memory allotted to work areas. Consequently, more memoryintensive 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.
b fera
s
n a r t n-
ahu
S
•
•
•
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
STAR_TRANSFORMATION_ENABLED determines whether a cost-based query transformation is applied to star queries. This optimization is explained in the lesson titled “Case Study: Star Transformation.” The query optimizer manages the result cache mechanism depending on the settings of the RESULT_CACHE_MODE parameter in the initialization parameter file. You can use this parameter to determine whether or not the optimizer automatically sends the results of queries to the result cache. The possible parameter values are MANUAL, and FORCE: -
When set to MANUAL (the default), you must specify, by using the RESULT_CACHE hint, that a particular result is to be stored in the cache.
-
When set to FORCE, all results are stored in the cache. For the FORCE setting, if the statement contains a [NO_]RESULT_CACHE hint, the hint takes precedence over the parameter setting.
The memory size allocated to the result cache depends on the memory size of the SGA as well as the memory management system. You can change the memory allocated to the result cache by setting the RESULT_CACHE_MAX_SIZE parameter. The result cache Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 33
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
•
Use the RESULT_CACHE_MAX_RESULT parameter to specify the maximum amount of cache memory that can be used by any single result. The default value is 5%, but you can specify any percentage value between 1 and 100.
•
Use the RESULT_CACHE_REMOTE_EXPIRATION parameter to specify the time (in number of minutes) for which a result that depends on remote database objects remains valid. The default value is 0, which implies that results using remote objects should not be cached. Setting this parameter to a nonzero value can produce stale answers, for example, if the remote table used by a result is modified at the remote database.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 34
ns e c li
Controlling the Behavior of the Optimizer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Controlling the Behavior of the Optimizer • • • • • • • • •
OPTIMIZER_INDEX_CACHING OPTIMIZER_INDEX_COST_ADJ OPTIMIZER_FEATURES_ENABLED OPTIMIZER_MODE: ALL_ROWS, FIRST_ROWS, FIRST_ROWS_n OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES OPTIMIZER_USE_SQL_PLAN_BASELINES le b a r OPTIMIZER_DYNAMIC_SAMPLING fe s n OPTIMIZER_USE_INVISIBLE_INDEXES -tra on n OPTIMIZER_USE_PENDING_STATISTICS a
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a OPTIMIZER_INDEX_CACHING: This parameter controls the costing of an index probe in
Controlling the Behavior of the Optimizer (continued)
S ijai
•
conjunction with a nested loop or an inlist iterator. The range of values 0 to 100 for OPTIMIZER_INDEX_CACHING indicates percentage of index blocks in the buffer cache, which modifies the optimizer’s assumptions about index caching for nested loops and inlist iterators. A value of 100 infers that 100% of the index blocks are likely to be found in the buffer cache and the optimizer adjusts the cost of an index probe or nested loop accordingly. The default for this parameter is 0, which results in default optimizer behavior. Use caution when using this parameter because execution plans can change in favor of index caching.
V
•
•
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 35
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
For example, if you upgrade your database from release 10.1 to release 11.1, but you want to keep the release 10.1 optimizer behavior, you can do so by setting this parameter to 10.1.0. At a later time, you can try the enhancements introduced in releases up to and including release 11.1 by setting the parameter to 11.1.0.6. However, it is not recommended to explicitly set the OPTIMIZER_FEATURES_ENABLE parameter to an earlier release. To avoid possible SQL performance regression that may result from execution plan changes, consider using SQL plan management instead. •
OPTIMIZER_MODE establishes the default behavior for selecting an optimization approach for either the instance or your session. The possible values are: -
ALL_ROWS: The optimizer uses a cost-based approach for all SQL statements in the session regardless of the presence of statistics and optimizes with a goal of best throughput (minimum resource use to complete the entire statement). This is the default value.
-
FIRST_ROWS_n: The optimizer uses a cost-based approach, regardless of the presence of statistics, and optimizes with a goal of best response time to return the first n number of rows; n can equal 1, 10, 100, or 1000.
-
FIRST_ROWS: The optimizer uses a mix of cost and heuristics to find a best plan for fast delivery of the first few rows. Using heuristics sometimes leads the query optimizer to generate a plan with a cost that is significantly larger than the cost of a plan without applying the heuristic. FIRST_ROWS is available for backward compatibility and plan stability; use FIRST_ROWS_n instead.
le
b fera
s
n a r t n-
no a s ฺ edisables haenables d OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES or automatic i ) u generation oftheSQL m G recognition of repeatable SQL statements, as well as the plan o ฺc ent baselines for such statements. ail m Studenables or disables the use of SQL plan g OPTIMIZER_USE_SQL_PLAN_BASELINES is Base. When enabled, the optimizer looks for a 1@ baselines stored in 2 SQL Management h t y e statement being compiled. If one is found in SQL SQL plan baseline ja for the sSQL i u v Management ahucost.Base,tothe optimizer costs each of the baseline plans and picks one with the(s lowest ahuOPTIMIZER_DYNAMIC_SAMPLING controls the level of dynamic sampling performed by •
•
S ijai
•
the optimizer. If OPTIMIZER_FEATURES_ENABLE is set to:
V
•
•
-
10.0.0 or later, the default value is 2
-
9.2.0, the default value is 1
-
9.0.1 or earlier, the default value is 0
OPTIMIZER_USE_INVISIBLE_INDEXES enables or disables the use of invisible indexes. OPTIMIZER_USE_PENDING_STATISTICS specifies whether or not the optimizer uses pending statistics when compiling SQL statements.
Note: Invisible indexes, pending statistics, and dynamic sampling are discussed later in this course.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 36
e
ns e c li
Optimizer Features and Oracle Database Releases
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Features and Oracle Database Releases OPTIMIZER_FEATURES_ENABLED Features
9.0.0 to 9.2.0
10.1.0 to 10.1.0.5
10.2.0 to 10.2.0.2
11.1.0.6
Index fast full scan Consideration of bitmap access to paths for tables with only Btree indexes Complex view merging Peeking into user-defined bind variables
e
Index joins Dynamic sampling
le
Query rewrite enables
b fera
Skip unusable indexes Automatically compute index statistics as part of creation Cost-based query transformations
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Allow rewrites with multiple MVs and/or base tables Adaptive cursor sharing
ns e c li
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
Vij
( u h a OPTIMIZER_FEATURES_ENABLED acts as an umbrella parameter for enabling a series of S i a optimizer features based on an Oracle release number. The table in the slide describes some Optimizer Features and Oracle Database Releases
of the optimizer features that are enabled depending on the value specified for the OPTIMIZER_FEATURES_ENABLED parameter.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 37
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz The _________step provides information about the select list items and is relevant when entering dynamic queries through an OCI application. a. Parse b. Define c. Describe le d. Parallelize rab
e
f s n tra
h
a s ( u
Answer: c
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 38
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz Which of the following steps is performed by the query optimizer? a. Generating a set of potential plans for the SQL statement based on available access paths b. Estimating and comparing the cost of each plan c. Selecting the plan with the lowest cost le d. All of the above rab
e
f s n tra
h
a s ( u
Answer: d
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 39
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The expected number of rows retrieved by a particular operation in the execution plan is known as its: a. Cost b. Cardinality c. Optimization quotient d. Selectivity
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 40
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Describe the execution steps of a SQL statement • Describe the need for an optimizer • Explain the various phases of optimization • Control the behavior of the optimizer
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 41
ns e c li
Practice 3: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 3: Overview
i a j i V
This practice covers exploring a trace file to understand the optimizer’s decisions.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Introduction to the Optimizer Chapter 3 - Page 42
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
o InterpretingnExecution Plans
a ฺ s a Chapterh4 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Interpreting Execution Plans
i a j i V
Interpreting Execution Plans
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to: • Gather execution plans • Display execution plans • Interpret execution plans
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 3
ns e c li
What Is an Execution Plan?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
What Is an Execution Plan? •
• •
The execution plan of a SQL statement is composed of small building blocks called row sources for serial execution plans. The combination of row sources for a statement is called the execution plan. By using parent-child relationships, the execution plan can be displayed in a tree-like structure (text or graphical). ble
ra
fe s n a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
What Is an Execution Plan?
An ahexecution plan is the output of the optimizer and is presented to the execution engine for S i ija implementation. It instructs the execution engine about the operations it must perform for
V
retrieving the data required by a query most efficiently.
The EXPLAIN PLAN statement gathers execution plans chosen by the Oracle optimizer for the SELECT, UPDATE, INSERT, and DELETE statements. The steps of the execution plan are not performed in the order in which they are numbered. There is a parent-child relationship between steps. The row source tree is the core of the execution plan. It shows the following information: •
An ordering of the tables referenced by the statement
•
An access method for each table mentioned in the statement
•
A join method for tables affected by join operations in the statement
•
Data operations, such as filter, sort, or aggregation
In addition to the row source tree (or data flow tree for parallel operations), the plan table contains information about the following: •
Optimization, such as the cost and cardinality of each operation
•
Partitioning, such as the set of accessed partitions
•
Parallel execution, such as the distribution method of join inputs Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 4
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The EXPLAIN PLAN results help you determine whether the optimizer selects a particular execution plan, such as nested loops join.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 5
ns e c li
Where to Find Execution Plans?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Where to Find Execution Plans? • • • • •
PLAN_TABLE (SQL Developer or SQL*Plus) V$SQL_PLAN (Library Cache) V$SQL_PLAN_MONITOR (11g) DBA_HIST_SQL_PLAN (AWR) STATS$SQL_PLAN (Statspack)
• • •
SQL management base (SQL plan baselines) ble a r SQL tuning set fe s n Trace files generated by DBMS_MONITOR -tra
• •
n
no Event 10053 trace file a ฺ as 10gR2 Process state dump trace file ide ) hsince
m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
( u h a are many ways to retrieve execution plans inside the database. The most well-known There S i a ones are listed in the slide:
Vij
Where to Find Execution Plans?
•
•
•
•
The EXPLAIN PLAN command enables you to view the execution plan that the optimizer might use to execute a SQL statement. This command is very useful because it outlines the plan that the optimizer may use and inserts it in a table called PLAN_TABLE without executing the SQL statement. This command is available from SQL*Plus or SQL Developer. V$SQL_PLAN provides a way to examine the execution plan for cursors that were recently executed. Information in V$SQL_PLAN is very similar to the output of an EXPLAIN PLAN statement. However, while EXPLAIN PLAN shows a theoretical plan that can be used if this statement was executed, V$SQL_PLAN contains the actual plan used. V$SQL_PLAN_MONITOR displays plan-level monitoring statistics for each SQL statement found in V$SQL_MONITOR. Each row in V$SQL_PLAN_MONITOR corresponds to an operation of the execution plan that is monitored. The Automatic Workload Repository (AWR) infrastructure and Statspack store execution plans of top SQL statements. Plans are recorded into DBA_HIST_SQL_PLAN or STATS$SQL_PLAN. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 6
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Plan and row source operations are dumped in trace files generated by DBMS_MONITOR.
•
The SQL management base (SMB) is a part of the data dictionary that resides in the SYSAUX tablespace. It stores statement log, plan histories, and SQL plan baselines, as well as SQL profiles.
•
The event 10053, which is used to dump cost-based optimizer (CBO) computations may include a plan.
•
Starting with Oracle Database 10g, Release 2, when you dump process state (or errorstack from a process), execution plans are included in the trace file that is generated.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 7
ns e c li
Viewing Execution Plans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Viewing Execution Plans •
The EXPLAIN PLAN command followed by: – SELECT from PLAN_TABLE – DBMS_XPLAN.DISPLAY()
• • • • •
SQL*Plus Autotrace: SET AUTOTRACE ON DBMS_XPLAN.DISPLAY_CURSOR() DBMS_XPLAN.DISPLAY_AWR() ble a DBMS_XPLAN.DISPLAY_SQLSET() r fe s n DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE() tra
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Viewing Execution Plans
h Ifayou execute the EXPLAIN PLAN SQL*Plus command, you can then SELECT from the S i ija PLAN_TABLE to view the execution plan. There are several SQL*Plus scripts available to
V
format the plan table output. The easiest way to view an execution plan is to use the DBMS_XPLAN package. The DBMS_XPLAN package supplies five table functions: • •
•
•
•
DISPLAY: To format and display the contents of a plan table DISPLAY_AWR: To format and display the contents of the execution plan of a stored SQL statement in the AWR DISPLAY_CURSOR: To format and display the contents of the execution plan of any loaded cursor DISPLAY_SQL_PLAN_BASELINE: To display one or more execution plans for the SQL statement identified by SQL handle DISPLAY_SQLSET: To format and display the contents of the execution plan of statements stored in a SQL tuning set
An advantage of using the DBMS_XPLAN package table functions is that the output is formatted consistently without regard to the source.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 8
e
ns e c li
The EXPLAIN PLAN Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The EXPLAIN PLAN Command • •
Generates an optimizer execution plan Stores the plan in PLAN_TABLE
•
Does not execute the statement itself
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a EXPLAIN PLAN command is used to generate the execution plan that the optimizer uses The S i a The EXPLAIN PLAN Command
to execute a SQL statement. It does not execute the statement, but simply produces the plan that may be used, and inserts this plan into a table. If you examine the plan, you can see how the Oracle Server executes the statement.
Using EXPLAIN PLAN •
First use the EXPLAIN PLAN command to explain a SQL statement.
•
Then retrieve the plan steps by querying PLAN_TABLE.
PLAN_TABLE is automatically created as a global temporary table to hold the output of an EXPLAIN PLAN statement for all users. PLAN_TABLE is the default sample output table into which the EXPLAIN PLAN statement inserts rows describing execution plans. Note: You can create your own PLAN_TABLE using the $ORACLE_HOME/rdbms/admin/utlxplan.sql script if you want to keep the execution plan information for a long term.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 9
The EXPLAIN PLAN Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The EXPLAIN PLAN Command
EXPLAIN PLAN SET STATEMENT_ID = 'text'
e
le
INTO your plan table
s
n a r t n-
no a FOR statement has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
b fera
( u h a command inserts a row in the plan table for each step of the execution plan. This S i a In the syntax diagram in the slide, the fields in italics have the following meanings: The EXPLAIN PLAN Command (continued)
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 10
ns e c li
The EXPLAIN PLAN Command: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The EXPLAIN PLAN Command: Example
SQL> 2 3 4 5
EXPLAIN PLAN SET STATEMENT_ID = 'demo01' FOR SELECT e.last_name, d.department_name FROM hr.employees e, hr.departments d WHERE e.department_id = d.department_id;
e
le
b fera
Explained.
ns e c li
s
n a r t n-
SQL>
no
adoes ฺnot actually Note: The EXPLAIN PLAN command s a execute the statement. ) h uide om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
The EXPLAIN PLAN Command: Example
V
ahcommand inserts the execution plan of the SQL statement in the plan table and adds the This S i ija optional demo01 name tag for future reference. You can also use the following syntax: EXPLAIN PLAN FOR SELECT e.last_name, d.department_name FROM hr.employees e, hr.departments d WHERE e.department_id =d.department_id;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 11
PLAN_TABLE
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
PLAN_TABLE •
PLAN_TABLE: – Is automatically created to hold the EXPLAIN PLAN output. – You can create your own using utlxplan.sql. – Advantage: SQL is not executed – Disadvantage: May not be the actual execution plan
• •
PLAN_TABLE is hierarchical. e Hierarchy is established with the ID and PARENT_ID rabl e columns. nsf
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
PLAN_TABLE
ah are various available methods to gather execution plans. Now, you are introduced only There S i ija to the EXPLAIN PLAN statement. This SQL statement gathers the execution plan of a SQL
V
statement without executing it, and outputs its result in the PLAN_TABLE table. Whatever the method to gather and display the explain plan, the basic format and goal are the same. However, PLAN_TABLE just shows you a plan that might not be the one chosen by the optimizer. PLAN_TABLE is automatically created as a global temporary table and is visible to all users. PLAN_TABLE is the default sample output table into which the EXPLAIN PLAN statement inserts rows describing execution plans. PLAN_TABLE is organized in a tree-like structure and you can retrieve that structure by using both the ID and PARENT_ID columns with a CONNECT BY clause in a SELECT statement. While a PLAN_TABLE table is automatically set up for each user, you can use the utlxplan.sql SQL script to manually create a local PLAN_TABLE in your schema and use it to store the results of EXPLAIN PLAN. The exact name and location of this script depends on your operating system. On UNIX, it is located in the $ORACLE_HOME/rdbms/admin directory. It is recommended that you drop and rebuild your local PLAN_TABLE table after upgrading the version of the database because the columns might change. This can cause scripts to fail or cause TKPROF to fail, if you are specifying the table.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 12
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 13
ns e c li
Displaying from PLAN_TABLE: Typical
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Displaying from PLAN_TABLE: Typical SQL> EXPLAIN PLAN SET STATEMENT_ID = 'demo01' FOR SELECT * FROM emp 2 WHERE ename = 'KING'; Explained. SQL> SET LINESIZE 130 SQL> SET PAGESIZE 0
e
SQL> select * from table(DBMS_XPLAN.DISPLAY()); Plan hash value: 3956160932
le
b fera
-------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 |
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
|* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - filter("ENAME"='KING')
Vij
( u h athe example in the slide, the EXPLAIN In S i a
Displaying from PLAN_TABLE: Typical
PLAN command inserts the execution plan of the SQL statement in PLAN_TABLE and adds the optional demo01 name tag for future reference. The DISPLAY function of the DBMS_XPLAN package can be used to format and display the last statement stored in PLAN_TABLE. You can also use the following syntax to retrieve the same result: SELECT * FROM TABLE(dbms_xplan.display('plan_table','demo01','typical',null));
The output is the same as shown in the slide. In this example, you can substitute the name of another plan table instead of PLAN_TABLE and demo01 represents the statement ID. TYPICAL displays the most relevant information in the plan: operation ID, name and option, number of rows, bytes, and optimizer cost. The last parameter for the DISPLAY function is the one corresponding to filter_preds. This parameter represents a filter predicate or predicates to restrict the set of rows selected from the table where the plan is stored. When value is null (the default), the plan displayed corresponds to the last executed explain plan. This parameter can reference any column of the table where the plan is stored and can contain any SQL construct—for example, subquery or function calls. Note: Alternatively, you can run the utlxpls.sql (or utlxplp.sql for parallel queries) script (located in the ORACLE_HOME/rdbms/admin/ directory) to display the execution plan Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 14
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
stored in PLAN_TABLE for the last statement explained. This script uses the DISPLAY table function from the DBMS_XPLAN package.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 15
ns e c li
Displaying from PLAN_TABLE: ALL
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Displaying from PLAN_TABLE: ALL SQL> select * from table(DBMS_XPLAN.DISPLAY(null,null,'ALL')); Plan hash value: 3956160932 -------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 | |* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------1 - SEL$1 / EMP@SEL$1 Predicate Information (identified by operation id): ---------------------------------------------------
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah 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]
Vij
( u h a you use the same EXPLAIN Here S i a
Displaying from PLAN_TABLE: ALL
PLAN command example as in the previous slide. The ALL option used with the DISPLAY function allows you to output the maximum user level information. It includes information displayed with the TYPICAL level, with additional information such as PROJECTION, ALIAS, and information about REMOTE SQL, if the operation is distributed. For finer control on the display output, the following keywords can be added to the format parameter to customize its default behavior. Each keyword either represents a logical group of plan table columns (such as PARTITION) or logical additions to the base plan table output (such as PREDICATE). Format keywords must be separated by either a comma or a space: •
ROWS: If relevant, shows the number of rows estimated by the optimizer
•
BYTES: If relevant, shows the number of bytes estimated by the optimizer
•
COST: If relevant, shows optimizer cost information
•
PARTITION: If relevant, shows partition pruning information
•
•
PARALLEL: If relevant, shows PX information (distribution method and table queue information) PREDICATE: If relevant, shows the predicate section Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 16
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
PROJECTION: If relevant, shows the projection section
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 17
ns e c li
The EXPLAIN PLAN Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The EXPLAIN PLAN Command
i a j i V
EXPLAIN PLAN SET STATEMENT_ID = 'text'
e
le
INTO your plan table
b fera
ns e c li
s
n a r t n-
o an ฺ ha uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah FOR statement s
( u h a ALIAS: If relevant, shows the “Query Block Name/Object Alias” section
Displaying from PLAN_TABLE: ALL (continued)
S
• •
•
REMOTE: If relevant, shows the information for the distributed query (for example, remote from serial distribution and remote SQL) NOTE: If relevant, shows the note section of the explain plan
If the target plan table also stores plan statistics columns (for example, it is a table used to capture the content of the fixed view V$SQL_PLAN_STATISTICS_ALL), additional format keywords can be used to specify which class of statistics to display when using the DISPLAY function. These additional format keywords are IOSTATS, MEMSTATS, ALLSTATS and LAST. Note: Format keywords can be prefixed with the “-” sign to exclude the specified information. For example, “-PROJECTION” excludes projection information.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 18
Displaying from PLAN_TABLE: ADVANCED
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Displaying from PLAN_TABLE: ADVANCED select plan_table_output from table(DBMS_XPLAN.DISPLAY(null,null,'ADVANCED -PROJECTION -PREDICATE -ALIAS')); Plan hash value: 3956160932 -------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------Outline Data ------------/*+ BEGIN_OUTLINE_DATA FULL(@"SEL$1" "EMP"@"SEL$1")
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah 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
*/
Vij
( u h a ADVANCED format is available only from Oracle Database 10g, Release 2 and later The S i a versions. Displaying from PLAN_TABLE: ADVANCED
This output format includes all sections from the ALL format plus the outline data that represents a set of hints to reproduce that particular plan. This section may be useful if you want to reproduce a particular execution plan in a different environment. This is the same section, which is displayed in the trace file for event 10053. Note: When the ADVANCED format is used with V$SQL_PLAN, there is one more section called Peeked Binds (identified by position).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 19
Explain Plan Using SQL Developer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Explain Plan Using SQL Developer
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Explain Plan icon generates the execution plan, which you can see in the Explain tab. An The S i a execution plan shows a row source tree with the hierarchy of operations that make up the Explain Plan Using SQL Developer
statement. For each operation, it shows the ordering of the tables referenced by the statement, access method for each table mentioned in the statement, join method for tables affected by join operations in the statement, and data operations such as filter, sort, or aggregation. In addition to the row source tree, the plan table displays information about optimization (such as the cost and cardinality of each operation), partitioning (such as the set of accessed partitions), and parallel execution (such as the distribution method of join inputs).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 20
AUTOTRACE
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
AUTOTRACE • • • • • •
Is a SQL*Plus and SQL Developer facility Was introduced with Oracle 7.3 Needs a PLAN_TABLE Needs the PLUSTRACE role to retrieve statistics from some V$ views By default, produces the execution plan and statistics aftere bl running the query a r fe s n May not be the execution plan used by the optimizer a when r t using bind peeking (recursive EXPLAIN PLAN) on
n a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a running SQL statements under SQL*Plus or SQL Developer, you can automatically get When S i a a report on the execution plan and the statement execution statistics. The report is generated
Vij
AUTOTRACE
after successful SQL DML (that is, SELECT, DELETE, UPDATE, and INSERT) statements. It is useful for monitoring and tuning the performance of these statements.
To use this feature, you must have a PLAN_TABLE available in your schema, and then have the PLUSTRACE role granted to you. The database administrator (DBA) privileges are required to grant the PLUSTRACE role. The PLUSTRACE role is created and granted to the DBA role by running the supplied $ORACLE_HOME/sqlplus/admin/plustrce.sql script. On some versions and platforms, this is run by the database creation scripts. If this is not the case on your platform, connect as SYSDBA and run the plustrce.sql script. The PLUSTRACE role contains the select privilege on three V$ views. These privileges are necessary to generate AUTOTRACE statistics. AUTOTRACE is an excellent diagnostic tool for SQL statement tuning. Because it is purely declarative, it is easier to use than EXPLAIN PLAN. Note: The system does not support EXPLAIN PLAN for statements performing implicit type conversion of date bind variables. With bind variables in general, the EXPLAIN PLAN output might not represent the real execution plan. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 21
e
ns e c li
The AUTOTRACE Syntax
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The AUTOTRACE Syntax
OFF ON
SET AUTOTRACE
TRACE[ONLY]
e
le
EXPLAIN rab e f s STATISTICS ran
ns e c li
t
onn a ฺ s a SHOW AUTOTRACE ) h de i u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
The AUTOTRACE Syntax
ahcan enable AUTOTRACE in various ways using the syntax shown in the slide. The You S i ija command options are as follows:
V
•
OFF: Disables autotracing SQL statements
•
ON: Enables autotracing SQL statements
•
TRACE or TRACE[ONLY]: Enables autotracing SQL statements and suppresses statement output
•
EXPLAIN: Displays execution plans, but does not display statistics
•
STATISTICS: Displays statistics, but does not display execution plans
Note: If both the EXPLAIN and STATISTICS command options are omitted, execution plans and statistics are displayed by default.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 22
AUTOTRACE: Examples
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
AUTOTRACE: Examples •
To start tracing statements using AUTOTRACE: SQL> set autotrace on
•
To display the execution plan only without execution:
e
SQL> set autotrace traceonly explain
•
To display rows and statistics: SQL> set autotrace on statistics
•
le
b fera
ns e c li
s
n a r t n-
no a s (suppress eฺ To get the plan and the statistics rows): haonly d i ) u m co ent G ฺ SQL> set autotrace itraceonly l ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a can control the report by setting the AUTOTRACE system variable. The following are some You S i a AUTOTRACE: Examples examples: •
•
•
•
•
SET AUTOTRACE ON: The AUTOTRACE report includes both the optimizer execution plan and the SQL statement execution statistics. SET AUTOTRACE TRACEONLY EXPLAIN: The AUTOTRACE report shows only the optimizer execution path without executing the statement. SET AUTOTRACE ON STATISTICS: The AUTOTRACE report shows the SQL statement execution statistics and rows. SET AUTOTRACE TRACEONLY: This is similar to SET AUTOTRACE ON, but it suppresses the printing of the user’s query output, if any. If STATISTICS is enabled, the query data is still fetched, but not printed. SET AUTOTRACE OFF: No AUTOTRACE report is generated. This is the default.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 23
AUTOTRACE: Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
AUTOTRACE: Statistics SQL> show autotrace autotrace OFF SQL> set autotrace traceonly statistics SQL> SELECT * FROM oe.products; 288 rows selected. Statistics -------------------------------------------------------1334 recursive calls 0 db block gets 686 consistent gets 394 physical reads 0 redo size 103919 bytes sent via SQL*Net to client 629 bytes received via SQL*Net from client 21 SQL*Net roundtrips to/from client 22 sorts (memory) 0 sorts (disk) 288 rows processed
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a statistics are recorded by the server when your statement executes and indicate the The S i a system resources required to execute your statement. The results include the following AUTOTRACE: Statistics
statistics: •
recursive calls is the number of recursive calls generated at both the user and system level. Oracle Database maintains tables used for internal processing. When Oracle Database needs to make a change to these tables, it internally generates an internal SQL statement, which in turn generates a recursive call.
•
db block gets is the number of times a CURRENT block was requested.
•
consistent gets is the number of times a consistent read was requested for a block.
•
• •
•
physical reads is the total number of data blocks read from disk. This number equals the value of “physical reads direct” plus all reads into buffer cache. redo size is the total amount of redo generated in bytes. bytes sent via SQL*Net to client is the total number of bytes sent to the client from the foreground processes. bytes received via SQL*Net from client is the total number of bytes received from the client over Oracle Net. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 24
•
SQL*Net roundtrips to/from client is the total number of Oracle Net messages sent to and received from the client.
Note: The statistics printed by AUTOTRACE are retrieved from V$SESSTAT.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
sorts (memory) is the number of sort operations that were performed completely in memory and did not require any disk writes.
•
sorts (disk) is the number of sort operations that required at least one disk write.
•
rows processed is the number of rows processed during the operation.
The client referred to in the statistics is SQL*Plus. Oracle Net refers to the generic process communication between SQL*Plus and the server, regardless of whether Oracle Net is installed. You cannot change the default format of the statistics report. Note: db block gets indicates reads of the current block from the database. consistent gets are reads of blocks that must satisfy a particular system change number (SCN). physical reads indicates reads of blocks from disk. db block gets and consistent gets are the two statistics that are usually monitored. These should be low compared to the number of rows retrieved. Sorts should be performed in memory rather than on disk.
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 25
e
ns e c li
AUTOTRACE Using SQL Developer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
AUTOTRACE Using SQL Developer
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Autotrace pane displays trace-related information when you execute the SQL statement The S i a by clicking the Autotrace icon. This information can help you to identify SQL statements that AUTOTRACE Using SQL Developer
will benefit from tuning.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 26
Using the V$SQL_PLAN View
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using the V$SQL_PLAN View • •
V$SQL_PLAN provides a way of examining the execution plan for cursors that are still in the library cache. V$SQL_PLAN is very similar to PLAN_TABLE: – PLAN_TABLE shows a theoretical plan that can be used if this statement were to be executed. – V$SQL_PLAN contains the actual plan used.
• •
It contains the execution plan of every cursor in the library ble a r fe cache (including child). s n a Link to V$SQL: n-tr
o has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( V$SQL_PLAN View Usinguthe h a view displays the execution plan for cursors that are still in the library cache. The This S i in this view is very similar to the information in PLAN_TABLE. However, Vija information V$SQL_PLAN contains the actual plan used. The execution plan obtained by the EXPLAIN – ADDRESS, HASH_VALUE, and CHILD_NUMBER an
PLAN statement can be different from the execution plan used to execute the cursor. This is because the cursor might have been compiled with different values of session parameters or bind variables.. V$SQL_PLAN shows the plan for a cursor rather than for all cursors associated with a SQL statement. The difference is that a SQL statement can have more than one cursor associated with it, with each cursor further identified by a CHILD_NUMBER. For example, the same statement executed by different users has different cursors associated with it if the object that is referenced is in a different schema. Similarly, different hints can cause different cursors. The V$SQL_PLAN table can be used to see the different plans for different child cursors of the same statement. Note: Another useful view is V$SQL_PLAN_STATISTICS, which provides the execution statistics of each operation in the execution plan for each cached cursor. Also, the V$SQL_PLAN_STATISTICS_ALL view concatenates information from V$SQL_PLAN with execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 27
e
ns e c li
The V$SQL_PLAN Columns
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The V$SQL_PLAN Columns HASH_VALUE
Hash value of the parent statement in the library cache
ADDRESS
Address of the handle to the parent for this cursor
CHILD_NUMBER
Child cursor number using this execution plan
POSITION
Order of processing for all operations that have the same PARENT_ID
e
PARENT_ID
le
ID of the next execution step that operates on the output of the current step Number assigned to each step in the execution plan
b fera
ns e c li
s
n a r t n-
Vija
no a ฺ hofastheuSQL deplan for the cursor i PLAN_HASH_VALUE Numerical representation ) m G o ilฺc dent a m listing tu of the columns. Note: This is only a partial g S 1@ this 2 y ja use i v to hu a s ( The V$SQL_PLAN Columns u h a view contains many of the PLAN_TABLE columns, plus several others. The columns that i SThe ID
are also present in PLAN_TABLE have the same values: • ADDRESS • HASH_VALUE
The ADDRESS and HASH_VALUE columns can be used to join with V$SQLAREA to add the cursor-specific information. The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be used to join with V$SQL to add the child cursor–specific information. The PLAN_HASH VALUE column is a numerical representation of the SQL plan for the cursor. By comparing one PLAN_HASH_VALUE with another, you can easily identify whether the two plans are the same or not (rather than comparing the two plans line-by-line). Note: Since Oracle Database 10g, SQL_HASH_VALUE in V$SESSION has been complemented with SQL_ID, which you retrieve in many other V$ views. SQL_HASH_VALUE is a 32-bit value and is not unique enough for large repositories of AWR data. SQL_ID is a 64-bit hash value, which is more unique, the bottom 32 bits of which are SQL_HASH_VALUE. It is normally represented as a character string to make it more manageable. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 28
The V$SQL_PLAN_STATISTICS View
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The V$SQL_PLAN_STATISTICS View •
V$SQL_PLAN_STATISTICS provides actual execution statistics: – STATISTICS_LEVEL set to ALL – The GATHER_PLAN_STATISTICS hint
•
V$SQL_PLAN_STATISTICS_ALL enables side-by-side comparisons of the optimizer estimates with the actual execution statistics. ble
ra
fe s n a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
The V$SQL_PLAN_STATISTICS View
ahV$SQL_PLAN_STATISTICS view provides the actual execution statistics for every The S i ija operation in the plan, such as the number of output rows, and elapsed time. All statistics,
V
except the number of output rows, are cumulative. For example, the statistics for a join operation also include the statistics for its two inputs. The statistics in V$SQL_PLAN_STATISTICS are available for cursors that have been compiled with the STATISTICS_LEVEL initialization parameter set to ALL or using the GATHER_PLAN_STATISTICS hint.
The V$SQL_PLAN_STATISTICS_ALL view contains memory-usage statistics for row sources that use SQL memory (sort or hash join). This view concatenates information in V$SQL_PLAN with execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 29
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Links Between Important Dynamic Performance Views
Links Between Important Dynamic Performance Views
V$SQLAREA
V$SQL
V$SQL_WORKAREA
V$SQLSTATS
e
Estimated statistics for each row source
le
b fera
V$SQL_PLAN
ns e c li
s
n a r t n-
Execution statistics for each row source
no a V$SQL_PLAN_STATISTICS has uideฺ ) om tG c ฺ n l V$SQL_PLAN_STATISTICS_ALL i e ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a V$SQLAREA displays statistics on shared SQL areas and contains one row per SQL string. It S i a provides statistics on SQL statements that are in memory, parsed, and ready for execution: Links Between Important Dynamic Performance Views
• •
SQL_ID is the SQL identifier of the parent cursor in the library cache. VERSION_COUNT is the number of child cursors that are present in the cache under this parent.
V$SQL lists statistics on shared SQL areas and contains one row for each child of the original SQL text entered: •
ADDRESS represents the address of the handle to the parent for this cursor.
•
HASH_VALUE is the value of the parent statement in the library cache.
•
SQL_ID is the SQL identifier of the parent cursor in the library cache.
•
•
PLAN_HASH_VALUE is a numeric representation of the SQL plan for this cursor. By comparing one PLAN_HASH_VALUE with another, you can easily identify if the two plans are the same or not (rather than comparing the two plans line-by-line). CHILD_NUMBER is the number of this child cursor.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 30
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Statistics displayed in V$SQL are normally updated at the end of query execution. However, for long-running queries, they are updated every five seconds. This makes it easy to see the impact of long-running SQL statements while they are still in progress. V$SQL_PLAN contains the execution plan information for each child cursor loaded in the library cache. The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be used to join with V$SQL to add the child cursor–specific information. V$SQL_PLAN_STATISTICS provides execution statistics at the row source level for each child cursor. The ADDRESS and HASH_VALUE columns can be used to join with V$SQLAREA to locate the parent cursor. The ADDRESS, HASH_VALUE, and CHILD_NUMBER columns can be used to join with V$SQL to locate the child cursor using this area. V$SQL_PLAN_STATISTICS_ALL contains memory usage statistics for row sources that use SQL memory (sort or hash join). This view concatenates information in V$SQL_PLAN with execution statistics from V$SQL_PLAN_STATISTICS and V$SQL_WORKAREA.
le
b fera
s
n a r t n-
Vija
no a • What are the top 10 work areas that require the most s cacheearea? ฺ a h d i • For work areas allocated in the AUTO mode, )what percentage u of work areas run using m G o maximum memory? lฺc dent i a V$SQLSTATS displays basic performance for SQL cursors, with each row m statistics tuof SQL g S representing the data for a unique combination text and optimizer plan (that is, unique @ this 1 2 combination of SQL_IDyand PLAN_HASH_VALUE). The column definitions for columns in ja touthose se in the V$SQL and V$SQLAREA views. However, the i V$SQLSTATS arevidentical u differstofrom V$SQL and V$SQLAREA in that it is faster, more scalable, and hview V$SQLSTATS a s ( data retention (the statistics may still appear in this view, even after the cursor has augreater h a been aged out of the shared pool). Note that V$SQLSTATS contains a subset of columns i Shas You can use this view to find answers to the following questions:
that appear in V$SQL and V$SQLAREA.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 31
e
ns e c li
V$SQL_WORKAREA displays information about work areas used by SQL cursors. Each SQL statement stored in the shared pool has one or more child cursors that are listed in the V$SQL view. V$SQL_WORKAREA lists all work areas needed by these child cursors. V$SQL_WORKAREA can be joined with V$SQLAREA on (ADDRESS, HASH_VALUE) and with V$SQL on (ADDRESS, HASH_VALUE, CHILD_NUMBER).
Querying V$SQL_PLAN
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Querying V$SQL_PLAN SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('47ju6102uvq5q')); SQL_ID 47ju6102uvq5q, child number 0 ------------------------------------SELECT e.last_name, d.department_name FROM hr.employees e, hr.departments d WHERE e.department_id =d.department_id Plan hash value: 2933537672 -------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU| -------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100| | 1 | MERGE JOIN | | 106 | 2862 | 6 (17| | 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0| | 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0| |* 4 | SORT JOIN | | 107 | 1177 | 4 (25| | 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0| -------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah 4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID") filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
24 rows selected.
Vij
( u h a can query V$SQL_PLAN using the DBMS_XPLAN.DISPLAY_CURSOR() function to You S i a display the current or last executed statement (as shown in the example). You can pass the Querying V$SQL_PLAN
value of SQL_ID for the statement as a parameter to obtain the execution plan for a given statement. SQL_ID is the SQL_ID of the SQL statement in the cursor cache. You can retrieve the appropriate value by querying the SQL_ID column in V$SQL or V$SQLAREA. Alternatively, you could select the PREV_SQL_ID column for a specific session out of V$SESSION. This parameter defaults to null in which case the plan of the last cursor executed by the session is displayed. To obtain SQL_ID, execute the following query: SELECT e.last_name, d.department_name FROM hr.employees e, hr.departments d WHERE e.department_id =d.department_id; SELECT SQL_ID, SQL_TEXT FROM V$SQL WHERE SQL_TEXT LIKE '%SELECT e.last_name,%' ; 13saxr0mmz1s3
select SQL_id, sql_text from v$SQL …
47ju6102uvq5q
SELECT e.last_name, d.department_name …
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 32
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
The FORMAT parameter controls the level of detail for the plan. In addition to the standard values (BASIC, TYPICAL, SERIAL, ALL, and ADVANCED), there are additional supported values to display run-time statistics for the cursor: •
•
IOSTATS: Assuming that the basic plan statistics are collected when SQL statements are executed (either by using the GATHER_PLAN_STATISTICS hint or by setting the statistics_level parameter to ALL), this format shows I/O statistics for ALL (or only for LAST) executions of the cursor. MEMSTATS: Assuming that the Program Global Area (PGA) memory management is enabled (that is, the pga_aggregate_target parameter is set to a nonzero value), this format allows to display memory management statistics (for example, execution mode of the operator, how much memory was used, number of bytes spilled to disk, and so on). These statistics only apply to memory-intensive operations, such as hash joins, sort or some bitmap operators.
le
• •
ALLSTATS: A shortcut for 'IOSTATS MEMSTATS'
n a r t n-
s
b fera
LAST: By default, plan statistics are shown for all executions of the cursor. The LAST keyword can be specified to see only the statistics for the last execution.
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 33
e
ns e c li
Automatic Workload Repository (AWR)
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic Workload Repository (AWR) • •
Collects, processes, and maintains performance statistics for problem-detection and self-tuning purposes Statistics include: – – – –
•
Object statistics Time-model statistics Some system and session statistics Active Session History (ASH) statistics
e
le
b fera
ns e c li
s Automatically generates snapshots of the performance n a r data n-t
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a AWR is part of the intelligent infrastructure introduced with Oracle Database 10g. This The S i a infrastructure is used by many components, such as Automatic Database Diagnostic Monitor Automatic Workload Repository (AWR)
(ADDM) for analysis. The AWR automatically collects, processes, and maintains systemperformance statistics for problem-detection and self-tuning purposes and stores the statistics persistently in the database. The statistics collected and processed by the AWR include: •
Object statistics that determine both access and usage statistics of database segments
•
Time-model statistics based on time usage for activities, displayed in the V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views
•
Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views
•
SQL statements that produce the highest load on the system, based on criteria, such as elapsed time, CPU time, buffer gets, and so on
•
ASH statistics, representing the history of recent sessions
The database automatically generates snapshots of the performance data once every hour and collects the statistics in the workload repository. The data in the snapshot interval is then analyzed by ADDM. The ADDM compares the differences between snapshots to determine Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 34
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: By using PL/SQL packages, such as DBMS_WORKLOAD_REPOSITORY or Oracle Enterprise Manager, you can manage the frequency and retention period of SQL that is stored in the AWR.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 35
ns e c li
Managing AWR with PL/SQL
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Managing AWR with PL/SQL •
Creating snapshots:
SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ('ALL');
•
Dropping snapshots:
SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE – (low_snap_id => 22, high_snap_id => 32, dbid => 3310949047);
•
Managing snapshot settings:
e
le
b fera
ns e c li
s
n a r t n-
SQL> exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS – (retention => 43200, interval => 30, dbid => 3310949047);
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Although the primary interface for managing the AWR is Enterprise Manager, monitoring S i a functions can be managed with procedures in the DBMS_WORKLOAD_REPOSITORY package. Managing AWR with PL/SQL
Snapshots are automatically generated for an Oracle Database; however, you can use DBMS_WORKLOAD_REPOSITORY procedures to manually create, drop, and modify the snapshots and baselines that are used by the ADDM. Snapshots and baselines are sets of historical data for specific time periods that are used for performance comparisons. To invoke these procedures, a user must be granted the DBA role. Creating Snapshots You can manually create snapshots with the CREATE_SNAPSHOT procedure if you want to capture statistics at times different than those of the automatically generated snapshots. Here is an example: Exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ('ALL'); In this example, a snapshot for the instance is created immediately with the flush level specified to the default flush level of TYPICAL. You can view this snapshot in the DBA_HIST_SNAPSHOT view. Dropping Snapshots Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 36
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
You can drop a range of snapshots using the DROP_SNAPSHOT_RANGE procedure. To view a list of the snapshot IDs along with database IDs, check the DBA_HIST_SNAPSHOT view. For example, you can drop the following range of snapshots: Exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE - (low_snap_id => 22, high_snap_id => 32, dbid => 3310949047); In the example, the range of snapshot IDs to drop is specified from 22 to 32. The optional database identifier is 3310949047. If you do not specify a value for dbid, the local database identifier is used as the default value. ASH data that belongs to the time period specified by the snapshot range is also purged when the DROP_SNAPSHOT_RANGE procedure is called. Modifying Snapshot Settings You can adjust the interval and retention of snapshot generation for a specified database ID. However, note that this can affect the precision of the Oracle diagnostic tools.
le
b fera
s
n a r t n-
no a In this example, the retention period is specified as 43,200 and the interval s minutes ฺ (30 days), a e h d between each snapshot is specified as 30 minutes. If NULL is specified, the existing value is ) Gui m preserved. The optional database identifier iso3310949047. If you do not specify a value for t value. cas the default ฺ n l i e dbid, the local database identifier is used You can check the current a tud m settings for your database instance g withstheSDBA_HIST_WR_CONTROL view. @ 1 hi 2 t y e ija us v u to h a s ( u h i Sa
Vija
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 37
e
ns e c li
The INTERVAL setting specifies how often (in minutes) snapshots are automatically generated. The RETENTION setting specifies how long (in minutes) snapshots are stored in the workload repository. To adjust the settings, use the MODIFY_SNAPSHOT_SETTINGS procedure, as in the following example: Exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( -retention => 43200, interval => 30, dbid => 3310949047);
Important AWR Views
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Important AWR Views • • •
V$ACTIVE_SESSION_HISTORY V$ metric views DBA_HIST views: – – – – –
DBA_HIST_ACTIVE_SESS_HISTORY DBA_HIST_BASELINE DBA_HIST_DATABASE_INSTANCE DBA_HIST_SNAPSHOT ble DBA_HIST_SQL_PLAN a r e DBA_HIST_WR_CONTROL nsf
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Important AWR Views
ahcan view the AWR data on Oracle Enterprise Manager screens or in AWR reports. You S i ija However, you can also view the statistics directly from the following views:
V
V$ACTIVE_SESSION_HISTORY: This view displays active database session activity, sampled once every second. V$ metric views provide metric data to track the performance of the system. The metric views are organized into various groups, such as event, event class, system, session, service, file, and tablespace metrics. These groups are identified in the V$METRICGROUP view.
The DBA_HIST views contain historical data stored in the database. This group of views includes: •
• •
DBA_HIST_ACTIVE_SESS_HISTORY displays the history of the contents of the sampled in-memory active session history for recent system activity. DBA_HIST_BASELINE displays information about the baselines captured in the system. DBA_HIST_DATABASE_INSTANCE displays information about the database environment.
•
DBA_HIST_SNAPSHOT displays information about snapshots in the system.
•
DBA_HIST_SQL_PLAN displays SQL execution plans. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 38
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
DBA_HIST_WR_CONTROL displays the settings for controlling AWR.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 39
ns e c li
Querying the AWR
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Querying the AWR •
Retrieve all execution plans stored for a particular SQL_ID.
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE (DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w'));
PLAN_TABLE_OUTPUT -----------------------------------------------------------------------------------SQL_ID 454rug2yva18w -------------------select /* example */ * from hr.employees natural join hr.departments Plan hash value: 4179021502 ---------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100)| | | 1 | HASH JOIN | | 11 | 968 | 6 (17)| 00:00:01 | | 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 2 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------
le
b fera
s
n a r t n-
•
no a Display all execution plans of allhstatements as ideฺ containing ) “JF.” m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
SELECT tf.* FROM DBA_HIST_SQLTEXT ht, table (DBMS_XPLAN.DISPLAY_AWR(ht.sql_id,null, null, WHERE ht.sql_text like '%JF%';
'ALL' )) tf
( u h a can use the DBMS_XPLAN.DISPLAY_AWR() function to display all stored plans in the You S i a
Vij
Querying the AWR
AWR. In the example in the slide, you pass in a SQL_ID as an argument. SQL_ID is the SQL_ID of the SQL statement in the cursor cache. The DISPLAY_AWR() function also takes the PLAN_HASH_VALUE, DB_ID, and FORMAT parameters. The steps to complete this example are as follows: 1. Execute the SQL statement: SQL> select /* example */ * from hr.employees natural join hr.departments; 2. Query V$SQL_TEXT to obtain the SQL_ID: SQL> select sql_id, sql_text from v$SQL where sql_text like '%example%'; SQL_ID SQL_TEXT ------------- ------------------------------------------F8tc4anpz5cdb select sql_id, sql_text from v$SQL … 454rug2yva18w select /* example */ * from … Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 40
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
3. Using the SQL_ID, verify that this statement has been captured in the DBA_HIST_SQLTEXT dictionary view. If the query does not return rows, it indicates that the statement has not yet been loaded in the AWR. SQL> SELECT SQL_ID, SQL_TEXT FROM dba_hist_sqltext WHERE SQL_ID =' 454rug2yva18w';
i a j i V
no rows selected You can take a manual AWR snapshot rather than wait for the next snapshot (which occurs every hour). Then check to see if it has been captured in DBA_HIST_SQLTEXT: SQL> exec dbms_workload_repository.create_snapshot; PL/SQL procedure successfully completed.
le
--------------
-------------------------------
454rug2yva18w
select /* example */ * from …
b fera
s
n a r t n-
no a 4. Use the DBMS_XPLAN.DISPLAY_AWR () function s to retrieveฺthe execution plan: a e h SQL>SELECT PLAN_TABLE_OUTPUT FROM TABLEuid ) om nt G (DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w’)); c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( u h a
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 41
e
ns e c li
SQL> SELECT SQL_ID, SQL_TEXT FROM dba_hist_sqltext WHERE SQL_ID =' 454rug2yva18w'; SQL_ID SQL_TEXT
Generating SQL Reports from AWR Data
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Generating SQL Reports from AWR Data SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt Specify the Report Type … Would you like an HTML report, or a plain text report? Specify the number of days of snapshots to choose from Specify the Begin and End Snapshot Ids … Specify the SQL Id … Enter value for sql_id: dvza55c7zu0yv Specify the Report Name …
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Oracle Database 10g, Release 2, it is possible to generate SQL reports from AWR data, Since S i a basically, the equivalent to sqrepsql.sql with Statspack. In 10.1.0.4.0, the equivalent to Generating SQL Reports from AWR Data
sprepsql.sql is not available in AWR. However, in 10gR2, the equivalent of sprepsql.sql is available. In 10gR2, the AWR SQL report can be generated by calling the $ORACLE_HOME/rdbms/admin/awrsqrpt.sql file.
You can display the plan information in AWR by using the display_awr table function in the dbms_xplan PL/SQL package. For example, this displays the plan information for a SQL_ID in AWR: select * from table(dbms_xplan.display_awr('dvza55c7zu0yv')); You can retrieve the appropriate value for the SQL statement of interest by querying SQL_ID in the DBA_HIST_SQLTEXT column.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 42
SQL Monitoring: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Monitoring: Overview STATISTICS_LEVEL=TYPICAL|ALL
+ CONTROL_MANAGEMENT_PACK_ACCESS=DIAGNOSTIC+TUNING
SQL monitoring Every second
V$SQL_MONITOR V$SQL_PLAN_MONITOR
e
le
b fera
ns e c li
s n a r -t DBMS_SQLTUNE.REPORT_SQL_MONITOR n o n a s eฺ V$SQL ha d i ) V$SQL_PLAN m t Gu o V$ACTIVE_SESSION_HISTORY c ilฺ den V$SESSION_LONGOPS a m SV$SESSION tu g 1@ this 2 y ja use i v u to sah
Vij
( u h a SQL monitoring feature is enabled by default when the STATISTICS_LEVEL initialization The S i a SQL Monitoring: Overview
parameter is either set to ALL or TYPICAL (the default value).
Additionally, the CONTROL_MANAGEMENT_PACK_ACCESS parameter must be set to DIAGNOSTIC+TUNING (the default value) because SQL monitoring is a feature of the Oracle Database Tuning Pack. By default, SQL monitoring is automatically started when a SQL statement runs parallel, or when it has consumed at least five seconds of the CPU or I/O time in a single execution. As mentioned, SQL monitoring is active by default. However, two statement-level hints are available to force or prevent a SQL statement from being monitored. To force SQL monitoring, use the MONITOR hint. To prevent the hinted SQL statement from being monitored, use the NO_MONITOR hint. You can monitor the statistics for SQL statement execution using the V$SQL_MONITOR and V$SQL_PLAN_MONITOR views. After monitoring is initiated, an entry is added to the dynamic performance V$SQL_MONITOR view. This entry tracks key performance metrics collected for the execution, including the elapsed time, CPU time, number of reads and writes, I/O wait time, and various other wait Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 43
times. These statistics are refreshed in near real time as the statement executes, generally once every second.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
After the execution ends, monitoring information is not deleted immediately, but is kept in the V$SQL_MONITOR view for at least one minute. The entry is eventually deleted so its space can be reclaimed as new statements are monitored.
i a j i V
The V$SQL_MONITOR and V$SQL_PLAN_MONITOR views can be used in conjunction with the following views to get additional information about the execution that is monitored: V$SQL, V$SQL_PLAN, V$ACTIVE_SESSION_HISTORY, V$SESSION_LONGOPS, and V$SESSION Instead, you can use the SQL monitoring report to view SQL monitoring data. The SQL monitoring report is also available in a GUI version through Enterprise Manager and SQL Developer
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 44
ns e c li
SQL Monitoring Report: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Monitoring Report: Example SQL> SQL> SQL> SQL>
set long 10000000 set longchunksize 10000000 set linesize 200 select dbms_sqltune.report_sql_monitor from dual;
SQL Monitoring Report
In a different session SQL Text -------------------------select count(*) from sales
SQL> select count(*) from sales;
Global Information Status : EXECUTING Instance ID : 1 Session ID : 125 SQL ID : fazrk33ng71km SQL Execution ID : 16777216 Plan Hash Value : 1047182207 Execution Started : 02/19/2008 21:01:18 First Refresh Time : 02/19/2008 21:01:22 Last Refresh Time : 02/19/2008 21:01:42 -----------------------------------------------------------| Elapsed | Cpu | IO | Other | Buffer | Reads | | Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | | -----------------------------------------------------------| 22 | 3.36 | 0.01 | 19 | 259K | 199K | ------------------------------------------------------------
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athis example, it is assumed that you SELECT from SALES from a different session than the In S i a one used to print the SQL monitoring report. SQL Monitoring Report: Example
The DBMS_SQLTUNE.REPORT_SQL_MONITOR function accepts several input parameters to specify the execution, the level of detail in the report, and the report type (TEXT, HTML, or XML). By default, a text report is generated for the last execution that was monitored if no parameters are specified as shown in the example in the slide. After the SELECT statement is started, and while it executes, you print the SQL monitoring report from a second session. From the report, you can see that the SELECT statement executes currently. The Global Information section gives you some important information: •
To uniquely identify two executions of the same SQL statement, a composite key called an execution key is generated. This execution key consists of three attributes, each corresponding to a column in V$SQL_MONITOR: -
SQL identifier to identify the SQL statement (SQL_ID)
-
An internally generated identifier to ensure that this primary key is truly unique (SQL_EXEC_ID) Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 45
A start execution time stamp (SQL_EXEC_START)
-
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The report also shows you some important statistics calculated so far.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 46
ns e c li
SQL Monitoring Report: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Monitoring Report: Example
SQL Plan Monitoring Details ==================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | | | | | (Estim) | | Active(s) | Active | ==================================================================================== | 0 | SELECT STATEMENT | | | 78139 | | | | 1 | SORT AGGREGATE | | 1 | | | | | -> 2 | TABLE ACCESS FULL | SALES | 53984K | 78139 | 23 | +1 | | | | | | | | | ====================================================================================
le
b fera
s
n a r t n-
================================================================================== Starts | Rows | Activity | Activity Detail | Progress | | (Actual) | (percent) | (sample #) | | 1 | | | | | 1 | | | | | 1 | 42081K | 100.00 | Cpu (4) | 74% | ==================================================================================
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a report then displays the execution path currently used by your statement. SQL monitoring The S i a gives you the display of the current operation that executes in the plan. This enables you to
Vij
SQL Monitoring Report: Example (continued)
detect parts of the plan that are the most time consuming, so that you can focus your analysis on those parts. The running operation is marked by an arrow in the Id column of the report. The Time Active(s) column shows how long the operation has been active (the delta in seconds between the first and the last active time). The Start Active column shows, in seconds, when the operation in the execution plan started relative to the SQL statement execution start time. In this report, the table access full operation at Id 2 was the first to start (+1s Start Active) and ran for the first 23 seconds so far. The Starts column shows the number of times the operation in the execution plan was executed. The Rows (Actual) column indicates the number of rows produced, and the Rows (Estim) column shows the estimated cardinality from the optimizer. The Activity (percent) and Activity Detail (sample #) columns are derived by joining the V$SQL_PLAN_MONITOR and V$ACTIVE_SESSION_HISTORY views. Activity (percent) shows the percentage of database time consumed by each operation of the execution plan. Activity Detail (sample#) shows the nature of that activity (such as CPU or wait event). Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 47
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
The last column, Progress, shows progress monitoring information for the operation from the V$SESSION_LONGOPS view. In this report, it shows that, so far, the TABLE ACCESS FULL operation is 74% complete. This column only appears in the report after a certain amount of time, and only for the instrumented row sources. Note: Not shown by this particular report, the Memory and Temp columns indicate the amount of memory and temporary space consumed by corresponding operation of the execution plan.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 48
ns e c li
Interpreting an Execution Plan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Interpreting an Execution Plan id= 1 id= 2 id= 3 id= 4 id= 5 id= 6 id= 7 id= 8 id= 9 id=10
(pid= ) (pid=1) (pid=2) (pid=2) (pid=4) (pid=4) (pid=1) (pid=7) (pid=7) (pid=9)
(pos=1) (pos=1) (pos=2) (pos=1) (pos=2) (pos=2) (pos=1) (pos=2) (pos=1)
root/parent parent/child child/leaf parent/child child/leaf child/leaf parent/child child/leaf parent/child child/leaf
Executed first Parent/Child
Transform it into a tree.
e
Root/Parent From top/down
Executed next
bl1e Level a r fe
s
n a r t n-
Parent/Child
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
ns e c li
Level 2
From left/right
Child/Leaf
Parent/Child
Child/Leaf
Child/Leaf
Child/Leaf
Parent/Child
Level 3
Child/Leaf
Level 4
Vij
( u h a plan output is a representation of a tree of row sources. Explain S i a Interpreting an Execution Plan
Each step (line in the execution plan or node in the tree) represents a row source. The explain plan utility indents nodes to indicate that they are the children of the parent above it. The order of the nodes under the parent indicates the order of execution of the nodes within that level. If two steps are indented at the same level, the first one is executed first. In the tree format, the leaf at the left on each level of the tree is where the execution starts. The steps of the execution plan are not performed in the order in which they are numbered. there is a parent–child relationship between steps. In PLAN_TABLE and V$SQL_PLAN, the important elements to retrieve the tree structure are the ID, PARENT_ID, and POSITION columns. In a trace file, these columns correspond to the id, pid, and pos fields, respectively. One way to read an execution plan is by converting it into a graph that has a tree structure. You can start from the top, with id=1, which is the root node in the tree. Next, you must find the operations that feed this root node. That is accomplished by operations, which have parent_id or pid with value 1. Note: The course focuses on serial plans and does not discusses parallel execution plans. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 49
To draw plan as a tree, do the following: 1. Take the ID with the lowest number and place it at the top. 2. Look for rows which have a PID (parent) equal to this value.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
3. Place these in the tree below the Parent according to their POS values from the lowest to the highest, ordered from left to right. 4. After all the IDs for a parent have been found, move down to the next ID and repeat the process, finding new rows with the same PID. The first thing to determine in an explain plan is which node is executed first. The method in the slide explains this, but sometimes with complicated plans it is difficult to do this and also difficult to follow the steps through to the end. Large plans are exactly the same as smaller ones, but with more entries. The same basic rules apply. You can always collapse the plan to hide a branch of the tree which does not consume much of the resources. Standard explain plan interpretation:
e
1. Start at the top.
le
2. Move down the row sources until you get to one which produces data, but does not consume any. This is the start row source.
b fera
ns e c li
Vij
s n a r 4. After the children are executed, the parent is executed next. n-t o up the tree, and look at nback 5. Now that this parent and its children are completed, work a the siblings of the parent row source and its parents. eฺas before. has Execute d i ) u 6. Move back up the plan until all row sources mare exhausted. G o t c ilฺ den Standard tree interpretation: a m Stu g 1. Start at the top. @left tuntil isyou reach the left node. This is executed first. 1the h 2. Move down the tree to 2 y e source. These row sources are executed next. ja of this srow i u 3. Look at the siblings v u toexecuted, the parent is executed next. hchildren a 4. After the are s ( u 5. Now that this parent and its children are completed, work back up the tree, and look at h a the siblings S of the parent row source and its parents. Execute as before. i a 3. Look at the siblings of this row source. These row sources are executed next.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 50
Execution Plan Interpretation: Example 1
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Execution Plan Interpretation: Example 1 SELECT /*+ RULE */ ename,job,sal,dname FROM emp,dept WHERE dept.deptno=emp.deptno and not exists(SELECT * FROM salgrade WHERE emp.sal between losal and hisal); -------------------------------------------------| Id | Operation | Name | -------------------------------------------------| 0 | SELECT STATEMENT | | |* 1 | FILTER | | | 2 | NESTED LOOPS | | | 3 | TABLE ACCESS FULL | EMP | | 4 | TABLE ACCESS BY INDEX ROWID| DEPT | |* 5 | INDEX UNIQUE SCAN | PK_DEPT | |* 6 | TABLE ACCESS FULL | SALGRADE | --------------------------------------------------
FILTER
NESTED LOOPS
1 - filter( NOT EXISTS (SELECT 0 FROM "SALGRADE" "SALGRADE" WHERE "HISAL">=:B1 AND "LOSAL"=:B1 AND "LOSAL" alter session set statistics_level=ALL; Session altered. SQL> select /*+ RULE to make sure it reproduces 100% */ ename,job,sal,dname from emp,dept where dept.deptno = emp.deptno and not exists (select * from salgrade where emp.sal between losal and hisal); no rows selected
e
SQL> select * from table(dbms_xplan.display_cursor(null,null,'TYPICAL IOSTATS LAST')); SQL_ID 274019myw3vuf, child number 0 ------------------------------------… Plan hash value: 1175760222 -------------------------------------------------------------------------------| Id | Operation | Name | Starts | A-Rows | Buffers | -------------------------------------------------------------------------------|* 1 | FILTER | | 1 | 0 | 61 | | 2 | NESTED LOOPS | | 1 | 14 | 25 | | 3 | TABLE ACCESS FULL | EMP | 1 | 14 | 7 | | 4 | TABLE ACCESS BY INDEX ROWID| DEPT | 14 | 14 | 18 | |* 5 | INDEX UNIQUE SCAN | PK_DEPT | 14 | 14 | 4 | |* 6 | TABLE ACCESS FULL | SALGRADE | 12 | 12 | 36 | -------------------------------------------------------------------------------…
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide is a plan dump from V$SQL_PLAN with STATISTICS_LEVEL set to The S i a Execution Plan Interpretation: Example 1 (continued)
ALL. This report shows you some important additional information compared to the output of the EXPLAIN PLAN command: •
A-Rows corresponds to the number of rows produced by the corresponding row source.
•
Buffers corresponds to the number of consistent reads done by the row source.
•
Starts indicates how many times the corresponding operation was processed.
For each row from the EMP table, the system gets its ENAME, SAL, JOB, and DEPTNO. Then the system accesses the DEPT table by its unique index (PK_DEPT) to get DNAME using DEPTNO from the previous result set. If you observe the statistics closely, the TABLE ACCESS FULL operation on the EMP table (ID=3) is started once. However, operations from ID 5 and 4 are started 14 times; once for each EMP rows. At this step (ID=2), the system gets all ENAME, SAL, JOB, and DNAME. The system now must filter out employees who have salaries outside the range of salaries in the salary grade table. To do that, for each row from ID=2, the system accesses the SALGRADE table using a FULL TABLE SCAN operation to check if the employee’s salary is outside the salary range. This operation only needs to be done 12 times in this case because Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 53
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
at run time the system does the check for each distinct salary, and there are 12 distinct salaries in the EMP table.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 54
ns e c li
Execution Plan Interpretation: Example 2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Execution Plan Interpretation: Example 2 SQL> 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
0 1 2 3 2 5 1 7
select , , from
where
/*+ USE_NL(d) use_nl(m) */ m.last_name as dept_manager d.department_name l.street_address hr.employees m join hr.departments d on (d.manager_id = m.employee_id) natural join hr.locations l l.city = 'Seattle';
SELECT STATEMENT NESTED LOOPS NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX UNIQUE SCAN
e
1 LOCATIONS LOC_CITY_IX DEPARTMENTS DEPT_LOCATION_IX EMPLOYEES EMP_EMP_ID_PK
s
2
n a r t n-
no a has uid3eฺ ) om nt G c ฺ l ai tude 4 m g S 1@ this 2 y ja use i v u to sah
5
le
b fera
ns e c li
7
8
6
Vij
( u h a query retrieves names, department names, and addresses for employees whose This S i a departments are located in Seattle and who have managers. Execution Plan Interpretation: Example 2
For formatting reasons, the explain plan has the ID in the first column, and PID in the second column. The position is reflected by the indentation. The execution plan shows two nested loops join operations. You follow the steps from the previous example: 1. Start at the top. ID=0 2. Move down the row sources until you get to the one, which produces data, but does not consume any. In this case, ID 0, 1, 2, and 3 consume data. ID=4 is the first row source that does not consume any. This is the start row source. ID=4 is executed first. The index range scan produces ROWIDs, which are used to lookup in the LOCATIONS table in ID=3. 3. Look at the siblings of this row source. These row sources are executed next. The sibling at the same level as ID=3 is ID=5. Node ID=5 has a child ID=6, which is executed before it. This is another index range scan producing ROWIDs, which are used to lookup in the DEPARTMENTS table in ID=5. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 55
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
4. After the children operation, the parent operation is next. The NESTED LOOPS join at ID=2 is executed next bringing together the underlying data. 5. Now that this parent and its children are completed, walk back up the tree, and look at the siblings of the parent row source and its parents. Execute as before. The sibling of ID=2 at the same level in the plan is ID=7. This has a child ID=8, which is executed first. The index unique scan produces ROWIDs, which are used to lookup in the EMPLOYEES table in ID=7. 6. Move back up the plan until all row sources are exhausted. Finally this is brought together with the NESTED LOOPS at ID=1, which passes the results back to ID=0. 7. The execution order is: 4 – 3 – 6 – 5 – 2 – 8 – 7 – 1 – 0 Here is the complete description of this plan: The inner nested loops is executed first using LOCATIONS as the driving table, using an index access on the CITY column. This is because you search for departments in Seattle only.
e
ns e The result is joined with the DEPARTMENTS table, using the index on the LOCATION_ID join c li e column; the result of this first join operation is the driving row source for the second nested l loops join. rab e f s table. The n The second join probes the index on the EMPLOYEE_ID column of the EMPLOYEES a r -t ID of all managers of system can do that because it knows (from the first join) the employee n o nit is based on the primary key. departments in Seattle. Note that this is a unique scan because a Finally, the EMPLOYEES table is accessed to retrievehthe aslast name. eฺ d i ) m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v to hu a s ( u h a S i a
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 56
Execution Plan Interpretation: Example 3
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Execution Plan Interpretation: Example 3 select /*+ ORDERED USE_HASH(b) SWAP_JOIN_INPUTS(c) */ max(a.i) from t1 a, t2 b, t3 c where a.i = b.i and a.i = c.i;
0 1 2 3 4 5 6
1 2 2 4 4
SELECT STATEMENT SORT AGGREGATE HASH JOIN TABLE ACCESS FULL T3 HASH JOIN TABLE ACCESS FULL T1 TABLE ACCESS FULL T2
1
e
2 3
le
4s
n a r t n-
no a has uideฺ ) om nt G c ฺ l i de Join order is: T1 -a T2 - T3 u m t g sS @ 1 hi 2 t y e ija us v u to sah
b fera
ns e c li
5
6
Vij
( u h a the execution plan in the slide. Try to find the order in which the plan is executed and See S i a deduce what is the join order (order in which the system joins tables). Again, ID is in the first Execution Plan Interpretation: Example 3
column and PID in the second column. The position is reflected by the indentation. It is important to recognize what the join order of an execution plan is, to be able to find your plan in a 10053 event trace file. Here is the interpretation of this plan: •
The system first hashes the T3 table (Operation ID=3) into memory.
•
Then it hashes the T1 table (Operation ID=5) into memory.
•
Then the scan of the T2 table begins (Operation ID=6).
•
The system picks a row from T2 and probes T1 (T1.i=T2.i).
•
If the row survives, the system probes T3 (T1.i=T3.i).
•
If the row survives, the system sends it to next operation.
•
The system outputs the maximum value from the previous result set.
In conclusion, the execution order is : 3 – 5 – 6 – 4 – 2 – 1 The join order is: T1 – T2 – T3 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 57
You can also use Enterprise Manager to understand execution plans, especially because it displays the Order column.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: A special hint was used to make sure T3 would be first in the plan.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 58
ns e c li
Reading More Complex Execution Plans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Reading More Complex Execution Plans SELECT owner , segment_name , segment_type FROM dba_extents WHERE file_id = 1 AND 123213 BETWEEN block_id AND block_id + blocks -1;
e
le
b fera
ns e c li
s
n a r t n-
Collapse using indentation and focus on operations consuming most resources.
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a plan at the left comes from the query (in the slide) on the data dictionary. It is so long that The S i a it is very difficult to apply the previous method to interpret it and locate the first operation. Reading More Complex Execution Plans
You can always collapse a plan to make it readable. This is illustrated at the right where you can see the same plan collapsed. As shown, this is easy to do when using the Enterprise Manager or SQL Developer graphical interface. You can clearly see that this plan is a UNION ALL of two branches. Your knowledge about the data dictionary enables you to understand that the two branches correspond to dictionary-managed tablespaces and locally-managed ones. Your knowledge about your database enables you to know that there are no dictionarymanaged 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 59
Reviewing the Execution Plan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Reviewing the Execution Plan • •
Drive from the table that has most selective filter. Look for the following: – Driving table has the best filter – Fewest number of rows are returned to the next step – The join method is appropriate for the number of rows returned – Views are correctly used ble a r fe – Unintentional Cartesian products s n a – Tables accessed efficiently n-tr
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a you tune a SQL statement in an online transaction processing (OLTP) environment, the When S i a goal is to drive from the table that has the most selective filter. This means that there are
Vij
Reviewing the Execution Plan
fewer rows passed to the next step. If the next step is a join, this means fewer rows are joined. Check to see whether the access paths are optimal. When you examine the optimizer execution plan, look for the following: •
The plan is such that the driving table has the best filter.
•
The join order in each step means that the fewest number of rows are returned to the next step (that is, the join order should reflect going to the best not-yet-used filters).
•
The join method is appropriate for the number of rows being returned. For example, nested loop joins through indexes may not be optimal when many rows are returned.
•
Views are used efficiently. Look at the SELECT list to see whether access to the view is necessary.
•
There are any unintentional Cartesian products (even with small tables).
•
Each table is being accessed efficiently: Consider the predicates in the SQL statement and the number of rows in the table. Look for suspicious activity, such as a full table scans on tables with large number of rows, which have predicates in the WHERE clause.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 60
e
ns e c li
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
If any of these conditions are not optimal, consider restructuring the SQL statement or the indexes available on the tables.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 61
ns e c li
Looking Beyond Execution Plans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Looking Beyond Execution Plans • •
An execution plan alone cannot tell you whether a plan is good or not. May need additional testing and tuning: – – – – –
SQL Tuning Advisor SQL Access Advisor SQL Performance Analyzer SQL Monitoring Tracing
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a execution plan alone cannot differentiate between well-tuned statements and those that The S i a perform poorly. For example, an EXPLAIN PLAN output that shows that a statement uses an Looking Beyond Execution Plans
index does not necessarily mean that the statement runs efficiently. Sometimes indexes can be extremely inefficient.
It is best to use EXPLAIN PLAN to determine an access plan, and then later prove that it is the optimal plan through testing. When evaluating a plan, you should examine the statement’s actual resource consumption. The rest of this course is intended to show you various methods to achieve this.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 62
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
A user needs to be granted some specialized privileges to generate AUTOTRACE statistics. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 63
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
An EXPLAIN PLAN command executes the statement and inserts the plan used by the optimizer into a table. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 64
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Which of the following is not true about a PLAN_TABLE? a. The PLAN_TABLE is automatically created to hold the EXPLAIN PLAN output. b. You cannot create your own PLAN_TABLE. c. The actual SQL command is not executed. d. The plan in the PLAN_TABLE may not be the actual execution plan.
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 65
le
b fera
s
n a r t n-
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
After monitoring is initiated, an entry is added to the _______view. This entry tracks key performance metrics collected for the execution. a. V$SQL_MONITOR b. V$PLAN_MONITOR c. ALL_SQL_MONITOR d. ALL_SQL_PLAN_MONITOR
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 66
le
b fera
s
n a r t n-
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Gather execution plans • Display execution plans • Interpret execution plans
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 67
ns e c li
Practice 4: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 4: Overview
i a j i V
This practice covers the following topics: • Using different techniques to extract execution plans • Using SQL monitoring
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Interpreting Execution Plans Chapter 4 - Page 68
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
s
b fera
n a r t n-
o ApplicationnTracing
a ฺ s a Chapterh5 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Application Tracing
i a j i V
Application Tracing
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to do the following: • Configure the SQL Trace facility to collect session statistics • Use the trcsess utility to consolidate SQL trace files • Format trace files using the tkprof utility • Interpret the output of the tkprof command
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 3
le
b fera
s
n a r t n-
e
ns e c li
End-to-End Application Tracing Challenge
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
End-to-End Application Tracing Challenge Client
Client
Clients
Client Client OE
Client OE
Client JF/Session 6
Client C4 CRM
ERP
CRM
CRM
ERP
CRM
Dedicated server
Dedicated server
Dedicated server
Shared server
Shared server
Shared server
Trace file
Trace file
Trace file
Trace file
Trace file
Trace file
e
le
b fera
ns e c li
Vij
s n a r • I want to retrieve traces from CRM service.n-t o • I want to retrieve traces from clientsC4. an ฺ ha u6.ide • I want to retrieve traces from session ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s End-to-End Application Tracing Challenge ( u Oracle ah Database implements tracing by generating a trace file for each server process when S i a you enable the tracing mechanism.
Tracing a specific client is usually not a problem in the dedicated server model as a single dedicated process serves a session during its lifetime. All the trace information for the session can be seen from the trace file belonging to the dedicated server serving it. However, in a shared server configuration, a client is serviced by different processes from time-to-time. The trace pertaining to the user session is scattered across different trace files belonging to different processes. This makes it difficult for you to get a complete picture of the life cycle of a session. Moreover, what if you want to consolidate trace information for a particular service for performance or debugging purposes? This is also difficult because you have multiple clients using the same service and each generating trace files belonging to the server process serving it.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 4
End-to-End Application Tracing
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
End-to-End Application Tracing •
Simplifies the process of diagnosing performance problems in multitier environments by allowing application workloads to be seen by: – – – – –
•
Service Module Action Session Client
e
le
End-to-end application tracing tools:
b fera
ns e c li
s
n a r t n-
– Enterprise Manager no a – DBMS_APPICATION_INFO, DBMS_SERVICE, as ideฺ h ) DBMS_MONITOR, DBMS_SESSION m t Gu o c – SQL Trace and trcsess ilฺ utility en a d u gm St – tkprof
1@ this 2 y ja use i v u to sah
Vij
( u h a End-to-end application tracing simplifies the diagnosis of performance problems in multitier S i a environments. In multitier environments, a request from an end client is routed to different End-to-End Application Tracing
database sessions by the middle tier, making it difficult to track a specific client. A client identifier is used to uniquely trace a specific end client through all tiers to the database server. You can used end-to-end application tracing to identify the source of an excessive workload, such as a high-load SQL statement. Also, you can identify what a user’s session does at the database level to resolve that user's performance problems. End-to-end application tracing also simplifies management of application workloads by tracking specific modules and actions in a service. Workload problems can be identified by: •
Client identifier: Specifies an end user based on the logon ID, such as HR
•
Service: Specifies a group of applications with common attributes, service-level thresholds, and priorities; or a single application
•
Module: Specifies a functional block within an application
•
Action: Specifies an action, such as an INSERT or an UPDATE operation, in a module
•
Session: Specifies a session based on a given database session identifier (SID)
The primary interface for end-to-end application tracing is Enterprise Manager. Other tools listed in the slide are discussed later in this lesson. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 5
Location for Diagnostic Traces
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Location for Diagnostic Traces DIAGNOSTIC_DEST Diagnostic Data
Previous Location
ADR Location
Foreground process traces
USER_DUMP_DEST
$ADR_HOME/trace
Background process traces
BACKGROUND_DUMP_DEST
$ADR_HOME/trace
Alert log data
BACKGROUND_DUMP_DEST
$ADR_HOME/alert $ADR_HOME/trace
Core dumps
CORE_DUMP_DEST
$ADR_HOME/cdump
Incident dumps
USER_DUMP_DEST BACKGROUND_DUMP_DEST
$ADR_HOME/incident/incdir_n
e
le
b fera
ns e c li
s
n a r t n-
Vij
no a eฺ has uidV$DIAG_INFO ) G – critical error trace om n11gt trace Database $ADR_HOME/trace 'C4', waits => TRUE, binds => FALSE);
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athe first code box, all sessions that log in under the AP service are traced. A trace file is In S i a created for each session that uses the service, regardless of the module and action. You can Service Tracing: Example
also enable tracing for specific tasks within a service. This is illustrated in the second example, where all sessions of the AP service that execute the QUERY_DELINQUENT action within the PAYMENTS module are traced.
Tracing by service, module, and action enable you to focus your tuning efforts on specific SQL, rather than sifting through trace files with SQL from different programs. Only the SQL statements that are identified with this MODULE and ACTION are recorded in the trace file. With this feature, relevant wait events for a specific action can be identified. You can also start tracing for a particular client identifier as shown by the third example. In this example, C4 is the client identifier for which SQL tracing is to be enabled. The TRUE argument specifies that wait information is present in the trace file. The FALSE argument specifies that bind information is not present in the trace file. Although not shown in the slide, you can use the CLIENT_ID_TRACE_DISABLE procedure to disable tracing globally for the database for a given client identifier. To disable tracing, for the previous example, execute the following command: EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'C4'); Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 12
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: CLIENT_IDENTIFIER can be set using the DBMS_SESSION.SET_IDENTIFIER procedure.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 13
ns e c li
Session Level Tracing: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Session Level Tracing: Example •
For all sessions in the database:
EXEC dbms_monitor.DATABASE_TRACE_ENABLE(TRUE,TRUE); EXEC dbms_monitor.DATABASE_TRACE_DISABLE();
•
For a particular session:
EXEC dbms_monitor.SESSION_TRACE_ENABLE(session_id=>le b 27, serial_num=>60, waits=>TRUE, binds=>FALSE); fera
s n a r -t EXEC dbms_monitor.SESSION_TRACE_DISABLE(session_id n o n =>27, serial_num=>60); a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s (Level Tracing: Example Session u h a can use tracing to debug performance problems. Trace-enabling procedures have been You S i a implemented as part of the DBMS_MONITOR package. These procedures enable tracing
Vij
globally for a database.
You can use the DATABASE_TRACE_ENABLE procedure to enable session level SQL tracing instance-wide. The procedure has the following parameters: •
WAITS: Specifies whether wait information is to be traced
•
BINDS: Specifies whether bind information is to be traced
•
INSTANCE_NAME: Specifies the instance for which tracing is to be enabled. Omitting INSTANCE_NAME means that the session-level tracing is enabled for the whole database.
Use the DATABASE_TRACE_DISABLE procedure to disable SQL tracing for the whole database or a specific instance. Similarly, you can use the SESSION_TRACE_ENABLE procedure to enable tracing for a given database session identifier on the local instance. The SID and SERIAL# information can be found from V$SESSION.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 14
e
ns e c li
Use the SESSION_TRACE_DISABLE procedure to disable the trace for a given database session identifier and serial number.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: SQL Trace involves some overhead, so you usually do not want to enable SQL Trace at the instance level.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 15
ns e c li
Trace Your Own Session
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Trace Your Own Session •
Enabling trace:
EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => FALSE);
•
e
Disabling trace:
le
b fera
EXEC DBMS_SESSION.SESSION_TRACE_DISABLE();
•
ns e c li
s
Easily identifying your trace files:
n a r t n-
no eฺ d i u
alter session set a s a tracefile_identifier='mytraceid'; h
) G m o ilฺc dent a m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a Although the DBMS_MONITOR package can be invoked only by a user with the DBA role, any S i a Trace Your Own Session
user can enable SQL tracing for his or her own session by using the DBMS_SESSION package. The SESSION_TRACE_ENABLE procedure can be invoked by any user to enable session level SQL tracing for his or her own session. An example is shown in the slide. You can then use the DBMS_SESSION.SESSION_TRACE_DISABLE procedure to stop dumping to your trace file.
The TRACEFILE_IDENTIFIER initialization parameter specifies a custom identifier that becomes part of the Oracle trace file name. You can use such a custom identifier to identify a trace file simply from its name and without opening it or view its contents. Each time this parameter is dynamically modified at the session level, the next trace dump written to a trace file will have the new parameter value embedded in its name. This parameter can only be used to change the name of the foreground process trace file; the background processes continue to have their trace files named in the regular format. For foreground processes, the TRACEID column of the V$PROCESS view contains the current value of this parameter. When this parameter value is set, the trace file name has the following format: sid_ora_pid_traceid.trc.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 16
The trcsess Utility
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The trcsess Utility Clients
Client
Client
Client
CRM
ERP
CRM
Dedicated server
Dedicated server
Dedicated server
Shared server
Trace file
Trace file
Trace file
Trace file
CRM
ERP
CRM
Shared server
Trace file
Shared server
Trace file
e
le
b fera
ns e c li
s
n a r TRCSESS t trcsess onn a Traceฺ file s Trace file a e client tkprof h for done for CRM service i ) u om nt G c ฺ l Report ai file de u m t g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
The trcsess Utility
V
ahtrcsess utility consolidates trace output from selected trace files on the basis of several The S i ija criteria: session ID, client identifier, service name, action name, and module name. After trcsess merges the trace information into a single output file, the output file can be processed by tkprof.
When using the DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE procedure, tracing information is present in multiple trace files and you must use the trcsess tool to collect it into a single file. The trcsess utility is useful for consolidating the tracing of a particular session or service for performance or debugging purposes. Tracing a specific session is usually not a problem in the dedicated server model because a single dedicated process serves a session during its lifetime. All the trace information for the session can be seen from the trace file belonging to the dedicated server that serves it. However, tracing a service might become a complex task even in the dedicated server model. Moreover, in a shared-server configuration, a user session is serviced by different processes from time-to-time. The trace pertaining to the user session is scattered across different trace files belonging to different processes. This makes it difficult to get a complete picture of the life cycle of a session. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 17
Invoking the trcsess Utility
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Invoking the trcsess Utility trcsess
[output=output_file_name] [session=session_id] [clientid=client_identifier] [service=service_name] [action=action_name] [module=module_name] [] Trace file
Trace file
Trace file
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) m tG Consolidated ofile c ฺ l trace i en a d u gm s St @ 1 hi 2 t y e ija us v u to sah TRCSESS
Vij
( u h a syntax for the trcsess utility is shown in the slide, where: The S i a Invoking the trcsess Utility •
output specifies the file where the output is generated. If this option is not specified, standard output is used for the output.
•
session consolidates the trace information for the session specified. The session identifier is a combination of session index and session serial number, such as 21.2371. You can locate these values in the V$SESSION view.
•
clientid consolidates the trace information for the given client identifier.
•
service consolidates the trace information for the given service name.
•
action consolidates the trace information for the given action name.
•
module consolidates the trace information for the given module name.
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 18
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 19
ns e c li
The trcsess Utility: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The trcsess Utility: Example exec dbms_session.set_identifier('HR session'); Second session
First session
exec dbms_session.set_identifier('HR session'); exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE( client_id=>'HR session', waits => FALSE, binds => FALSE);
e
Third session
le
b fera
select * from employees; …
ns e c li
s
n a r t n-
select * from departments;
…
no a exec DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE( s ฺa e client_id => 'HR session'); h d ) Gui m o nt ilฺc clientid='HR trcsess output=mytrace.trc session' e a d u m t $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide illustrates a possible use of the trcsess utility. The example The S i a The trcsess Utility: Example
assumes that you have three different sessions: Two sessions that are traced (left and right), and one session (center) that enables or disables tracing and concatenates trace information from the previous two sessions. The first and second session set their client identifier to the ‘HR session’ value. This is done using the DBMS_SESSION package. Then, the third session enables tracing for these two sessions using the DBMS_MONITOR package. At that point, two new trace files are generated in ADR; one for each session that is identified with the ‘HR session’ client identifier. Each traced session now executes its SQL statements. Every statement generates trace information in its own trace file in ADR. Then, the third session stops trace generation using the DBMS_MONITOR package, and consolidates trace information for the ‘HR session’ client identifier in the mytrace.trc file. The example assumes that all trace files are generated in the $ORACLE_BASE/diag/rdbms/orcl/orcl/trace directory, which is the default in most cases.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 20
SQL Trace File Contents
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Trace File Contents • • • • • • • • • •
Parse, execute, and fetch counts CPU and elapsed times Physical reads and logical reads Number of rows processed Misses on the library cache Username under which each parse occurred ble a r Each commit and rollback fe s n Wait event and bind data for each SQL statement tra n no plan of each Row operations showing the actual execution a SQL statement has uideฺ ) Number of consistent reads, omphysical t G reads, physical c ฺ n l i e d operation on a row writes, and time elapsed ma fortueach
g sS @ 1 hi 2 t y e ija us v u to ah
(s u ah
SQL Trace File Contents
As seen already, a SQL trace file provides performance information on individual SQL S i ija statements. It generates the following statistics for each statement:
V
•
Parse, execute, and fetch counts
•
CPU and elapsed times
•
Physical reads and logical reads
•
Number of rows processed
•
Misses on the library cache
•
Username under which each parse occurred
•
Each commit and rollback
•
Wait event data for each SQL statement, and a summary for each trace file
If the cursor for the SQL statement is closed, SQL Trace also provides row source information that includes: •
Row operations showing the actual execution plan of each SQL statement
•
Number of rows, number of consistent reads, number of physical reads, number of physical writes, and time elapsed for each operation. This is possible only when the STATISTICS_LEVEL initialization parameter is set to ALL. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 21
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 22
ns e c li
SQL Trace File Contents: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Trace File Contents: Example *** [ Unix process pid: 15911 ] *** 2010-07-29 13:43:11.327 *** 2010-07-29 13:43:11.327 *** 2010-07-29 13:43:11.327 *** 2010-07-29 13:43:11.327 … ==================== PARSING IN CURSOR #2 len=23 dep=0 uid=85 oct=3 lid=85 tim=1280410994003145 hv=40 69246757 ad='4cd57ac0' sqlid='f34thrbt8rjt5' select * from employees END OF STMT PARSE #2:c=3000,e=2264,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=1445457117, tim=1280410994003139 EXEC #2:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1445457117, tim=1280410994003312 FETCH #2:c=0,e=215,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,plh=1445457117, tim=1280410994003628 FETCH #2:c=0,e=89,p=0,cr=5,cu=0,mis=0,r=15,dep=0,og=1,plh=1445457117, tim=1280410994004232 … FETCH #2:c=0,e=60,p=0,cr=1,cu=0,mis=0,r=1,dep=0,og=1,plh=1445457117, tim=1280410994107857 STAT #2 id=1 cnt=107 pid=0 pos=1 obj=73933 op='TABLE ACCESS FULL EMPLOYEES (cr=15 pr=0 pw=0 time=0 us cost=3 size=7383 card=107)' XCTEND rlbk=0, rd_only=1, tim=1280410994108875 =====================
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a are multiple types of trace files that can be generated by the Oracle Database. The one There S i a that is referred to in this lesson is generally called a SQL trace file. The slide shows you a SQL Trace File Contents: Example
sample output from the mytrace.trc SQL trace file generated by the previous example.
In this type of trace file, you can find (for each statement that was traced) the statement itself, with some corresponding cursor details. You can see statistic details for each phase of the statement’s execution: PARSE, EXEC, and FETCH. As you can see, you can have multiple FETCH for one EXEC depending on the number of rows returned by your query. Last part of the trace is the execution plan with some cumulated statistics for each row source. Depending on the way you enabled tracing, you can also obtain information about wait events and bind variables in the generated trace files. Generally, you do not try to interpret the trace file itself. This is because you do not get an overall idea of what your sessions did. For example, one session could have executed the same statement multiple times at different moments. The corresponding traces are then scattered across the entire trace file, which makes them hard to find. Instead, you use another tool, such as tkprof to interpret the contents of the raw trace information.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 23
Formatting SQL Trace Files: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Formatting SQL Trace Files: Overview Use the tkprof utility to format your SQL trace files: • •
Sort raw trace file to exhibit top SQL statements Filter dictionary statements
Trace file
Trace file
Trace file
Trace Trace file Trace file Trace file Trace file file
Trace file
e
le
b fera
ns e c li
s
trcsess
n a r t n-
no a as ideฺ h ) u mReport o file t G c ilฺ den a m Stu g 1@ this 2 y ja use i v u to Consolidated trace file
tkprof
Concatenated trace file
h
a s ( u
Formatting SQL Trace Files: Overview
V
ahtkprof utility parses SQL trace files to produce more readable output. Remember that The S i ija all the information in tkprof is available from the raw trace file. There is a huge number of
sort options that you can invoke with tkprof at the command prompt. A useful starting point is the fchela sort option, which orders the output by elapsed time fetching. The resultant file contains the most time-consuming SQL statement at the start of the file. Another useful parameter is SYS=NO. This can be used to prevent SQL statements run as the SYS user from being displayed. This can make the output file much shorter and easier to manage. After a number of SQL trace files have been generated, you can perform any of the following: •
Run tkprof on each individual trace file, producing a number of formatted output files, one for each session.
•
Concatenate the trace files, and then run tkprof on the result to produce a formatted output file for the entire instance.
•
Run the trcsess command-line utility to consolidate tracing information from several trace files, then run tkprof on the result.
tkprof does not report COMMITs and ROLLBACKs that are recorded in the trace file.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 24
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 25
ns e c li
Invoking the tkprof Utility
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Invoking the tkprof Utility
tkprof inputfile outputfile [waits=yes|no] [sort=option] [print=n] [aggregate=yes|no] [insert=sqlscriptfile] [sys=yes|no] ble a r [table=schema.table] fe s n tra [explain=user/password] n no [record=statementfile] a has ideฺ )[width=n]
m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
( u h a you enter the tkprof command without any arguments, it generates a usage message When S i a
Vij
Invoking the tkprof Utility
together with a description of all tkprof options. The various arguments are shown in the slide: •
inputfile: Specifies the SQL trace input file
•
outputfile: Specifies the file to which tkprof writes its formatted output
•
waits: Specifies whether to record the summary for any wait events found in the trace file. Values are YES or NO. The default is YES.
•
sorts: Sorts traced SQL statements in the descending order of specified sort option before listing them into the output file. If more than one option is specified, the output is sorted in the descending order by the sum of the values specified in the sort options. If you omit this parameter, tkprof lists statements into the output file in the order of first use.
•
print: Lists only the first integer sorted SQL statements from the output file. If you omit this parameter, tkprof lists all traced SQL statements. This parameter does not affect the optional SQL script. The SQL script always generates insert data for all traced SQL statements. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 26
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
aggregate: If set to NO, tkprof does not aggregate multiple users of the same SQL text.
•
insert: Creates a SQL script to store the trace file statistics in the database. tkprof creates this script with the name you specify for sqlscriptfile. This script creates a table and inserts a row of statistics for each traced SQL statement into the table.
•
sys: Enables and disables the listing of SQL statements issued by the SYS user, or recursive SQL statements, into the output file. The default value of YES causes tkprof to list these statements. The value of NO causes tkprof to omit them. This parameter does not affect the optional SQL script. The SQL script always inserts statistics for all traced SQL statements, including recursive SQL statements.
•
table: Specifies the schema and name of the table into which tkprof temporarily places execution plans before writing them to the output file. If the specified table already exists, tkprof deletes all rows in the table, uses it for the EXPLAIN PLAN statement (which writes more rows into the table), and then deletes those rows. If this table does not exist, tkprof creates it, uses it, and then drops it. The specified user must be able to issue INSERT, SELECT, and DELETE statements against the table. If the table does not already exist, the user must also be able to issue the CREATE TABLE and DROP TABLE statements. This option allows multiple individuals to run tkprof concurrently with the same user in the EXPLAIN value. These individuals can specify different TABLE values and avoid destructively interfering with each other’s processing on the temporary plan table. If you use the EXPLAIN parameter without the TABLE parameter, tkprof uses the PROF$PLAN_TABLE table in the schema of the user specified by the EXPLAIN parameter. If you use the TABLE parameter without the EXPLAIN parameter, tkprof ignores the TABLE parameter. If no plan table exists, tkprof creates the PROF$PLAN_TABLE table and then drops it at the end.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi plan for each SQL statement in the trace file and • explain: Determines the execution 2 t y e s to the output file. tkprof determines execution plans by ija plans writes thesevexecution u u o t PLAN statement after connecting to the system with the user and issuing EXPLAIN ahthespecified s ( password in this parameter. The specified user must have CREATE SESSION u h a system privileges. tkprof takes longer to process a large trace file if the EXPLAIN
S
option is used.
•
record: Creates a SQL script with the specified file name statementfile with all the nonrecursive SQL statements in the trace file. This can be used to replay the user events from the trace file.
•
width: An integer that controls the output line width of some tkprof output, such as the explain plan. This parameter is useful for post-processing of tkprof output.
The input and output files are the only required arguments.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 27
e
ns e c li
tkprof Sorting Options
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
tkprof Sorting Options Sort Option
Description
prscnt
Number of times parse was called
prscpu
CPU time parsing
prsela
Elapsed time parsing
prsdsk
Number of disk reads during parse
prsqry
Number of buffers for consistent read during parse
prscu
Number of buffers for current read during parse
prsmis
Number of misses in the library cache during parse
execnt
Number of executes that were called
execpu
CPU time spent executing
exeela
Elapsed time executing
e
s
n a r t n-
no a eฺ exedsk hasexecute Number of disk reads )during d i uread during execute m G o exeqry Number of buffers for consistent t c ilฺ fordcurrent en read during execute a execu Number of buffers u gm s St @ 1 hi 2 t y e ija us v u to h a s ( tkprof Sorting Options u h a table lists all the sort options you can use with the sort argument of tkprof. The S i a
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 28
le
b fera
ns e c li
tkprof Sorting Options
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
tkprof Sorting Options
i a j i V
Sort Option
Description
exerow
Number of rows processed during execute
exemis
Number of library cache misses during execute
fchcnt
Number of times fetch was called
fchcpu
CPU time spent fetching
fchela
Elapsed time fetching
fchdsk
Number of disk reads during fetch
fchqry
Number of buffers for consistent read during fetch
fchcu
Number of buffers for current read during fetch
fchrow
Number of rows fetched
userid
User ID of user that parsed the cursor
ahu
e
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 29
s
n a r t n-
le
b fera
ns e c li
Output of the tkprof Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Output of the tkprof Command • •
Text of the SQL statement Trace statistics (for statement and recursive calls) separated into three SQL processing steps: PARSE
Translates the SQL statement into an execution plan
EXECUTE
Executes the statement (This step modifies the data for the INSERT, UPDATE, and DELETE statements.)
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah FETCH
Retrieves the rows returned by a query (Fetches are performed only for the SELECT statements.)
Vij
( u h The a tkprof output file lists the statistics for a SQL statement by the SQL processing step. S i The step for each row that contains statistics is identified by the value of the call column. a Output of the tkprof Command
PARSE
This step translates the SQL statement into an execution plan and includes checks for proper security authorization and checks for the existence of tables, columns, and other referenced objects.
EXECUTE
This step is the actual execution of the statement by the Oracle server. For the INSERT, UPDATE, and DELETE statements, this step modifies the data (including sorts when needed). For the SELECT statements, this step identifies the selected rows.
FETCH
This step retrieves rows returned by a query and sorts them when needed. Fetches are performed only for the SELECT statements.
Note: The PARSE value includes both hard and soft parses. A hard parse refers to the development of the execution plan (including optimization); it is subsequently stored in the library cache. A soft parse means that a SQL statement is sent for parsing to the database, but the database finds it in the library cache and only needs to verify things, such as access rights. Hard parses can be expensive, particularly due to the optimization. A soft parse is mostly expensive in terms of library cache activity 25
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 30
Output of the tkprof Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Output of the tkprof Command There are seven categories of trace statistics: Count
Number of times the procedure was executed
CPU
Number of seconds to process
Elapsed
Total number of seconds to execute
Disk
Number of physical blocks read
e
le
b fera
ns e c li
s n a r Number of logical buffers read for consistent -t read n o n mode Current Number of logical buffers read in a current as ideฺ h ) Rows Number of rows processed theufetch or execute m byt G o c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah Query
Vij
( u h a output is explained on the following page. The S i a
Output of the tkprof Command (continued) Sample output is as follows: call count ------- ------
cpu elapsed disk query current rows -------- ---------- ---------- ---------- ---------- ---
Parse 1 Execute 1 Fetch 2 ------- ------
0.03 0.06 0 0 0 0.06 0.30 1 3 0 0.00 0.46 0 0 0 -------- ---------- ---------- ---------- ----------
total
4
0.09
0.83
1
3
0
0 0 1 --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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 31
•
•
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
•
Disk: Total number of data blocks physically read from the data files on disk for all parse, execute, or fetch calls Query: Total number of buffers retrieved in consistent mode for all parse, execute, or fetch calls (Buffers are usually retrieved in consistent mode for queries.) Current: Total number of buffers retrieved in current mode (Buffers typically are retrieved in current mode for data manipulation language statements. However, segment header blocks are always retrieved in current mode.) Rows: Total number of rows processed by the SQL statement (This total does not include rows processed by subqueries of the SQL statement. For SELECT statements, the number of rows returned appears for the fetch step. For the UPDATE, DELETE, and INSERT statements, the number of rows processed appears for the execute step.)
Note •
DISK is equivalent to physical reads from v$sysstat or AUTOTRACE.
•
QUERY is equivalent to consistent gets from v$sysstat or AUTOTRACE.
•
CURRENT is equivalent to db block gets from v$sysstat or AUTOTRACE.
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 32
le
b fera
s
n a r t n-
e
ns e c li
Output of the tkprof Command
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Output of the tkprof Command The tkprof output also includes the following: • • • • • •
Recursive SQL statements Library cache misses Parsing user ID Execution plan Optimizer mode or hint Row source operation
...
e
le
b fera
ns e c li
s
n a r t n-
Vij
no a has uideฺ Rows Row Source Operation ) ------- --------------------------------------------------m tG oEMPLOYEES 5 TABLE ACCESS BY INDEX ROWID (cr=4 pr=1 pw=0 time=0 us … c ฺ n pr=1 l i e 5 INDEX RANGE SCAN EMP_NAME_IX (cr=2 pw=0 time=80 us cost=1 … a d u m … t g sS @ 1 hi 2 t y e ija us v u to h a s ( the tkprof Command (continued) Output of u h a S i Recursive Calls a Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 85
To execute a SQL statement issued by a user, the Oracle server must occasionally issue additional statements. Such statements are called recursive SQL statements. For example, if you insert a row in a table that does not have enough space to hold that row, the Oracle server makes recursive calls to allocate the space dynamically. Recursive calls are also generated when data dictionary information is not available in the data dictionary cache and must be retrieved from disk. If recursive calls occur while the SQL Trace facility is enabled, tkprof marks them clearly as recursive SQL statements in the output file. You can suppress the listing of recursive calls in the output file by setting the SYS=NO command-line parameter. Note that the statistics for recursive SQL statements are always included in the listing for the SQL statement that caused the recursive call.
Library Cache Misses tkprof also lists the number of library cache misses resulting from parse and execute steps for each SQL statement. These statistics appear on separate lines following the tabular statistics. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 33
Row Source Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
These provide the number of rows processed for each operation executed on the rows and additional row source information, such as physical reads and writes; cr = consistent reads, w = physical writes, r = physical reads, time = time (in microseconds). Parsing User ID This is the ID of the last user to parse the statement. Row Source Operation The row source operation shows the data sources for execution of the SQL statement. This is included only if the cursor has been closed during tracing. If the row source operation does not appear in the trace file, you may then want to view the output of the EXPLAIN PLAN. Execution Plan If you specify the EXPLAIN parameter on the tkprof command line, tkprof uses the EXPLAIN PLAN command to generate the execution plan of each SQL statement traced. tkprof also displays the number of rows processed by each step of the execution plan.
le
b fera
s
n a r t n-
Note: Be aware that the execution plan is generated at the time that the tkprof command is run and not at the time the trace file was produced. This could make a difference if, for example, an index has been created or dropped since tracing the statements.
no a Optimizer Mode or Hint has uideฺ ) m thetexecution G This indicates the optimizer hint that is used o during of the statement. If there is c ฺ n l i no hint, it shows the optimizer mode that is used. e ma Stud g 1@ this 2 y ja use i v to hu a s ( u h i Sa
Vija
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 34
e
ns e c li
tkprof Output with No Index: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
tkprof Output with No Index: Example ... select max(cust_credit_limit) from customers where cust_city ='Paris' call count ------- -----Parse 1 Execute 1 Fetch 2 ------- -----total 4
cpu elapsed disk query current ------- --------- -------- -------- --------0.00 0.00 0 0 0 0.00 0.00 0 0 0 0.02 0.10 72 1459 0 ------- --------- -------- -------- --------0.02 0.10 72 1459 0
Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 88 Rows ------1 77 cost=405 ...
rows --------0 0 1 --------1
le
b fera
s
n a r t n-
Row Source Operation --------------------------------------------------SORT AGGREGATE (cr=1459 pr=72 pw=0 time=0 us) TABLE ACCESS FULL CUSTOMERS (cr=1459 pr=72 pw=0 time=4104 us size=1260 card=90)
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide shows that the aggregation of results across several executions The S i a tkprof Output with No Index: Example
(rows) is being fetched from the CUSTOMERS table. It requires 0.12 second of CPU fetch time. The statement is executed through a full table scan of the CUSTOMERS table, as you can see in the row source operation of the output. The statement must be optimized. Note: If CPU or elapsed values are 0, timed_statistics is not set.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 35
e
ns e c li
tkprof Output with Index: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
tkprof Output with Index: Example ...
select max(cust_credit_limit) from customers where cust_city ='Paris' call count ------- -----Parse 1 Execute 1 Fetch 2 ------- -----total 4
cpu elapsed disk query current -------- ---------- --------- --------- ---------0.00 0.00 0 0 0 0.00 0.00 0 0 0 0.00 0.00 1 77 0 -------- ---------- --------- --------- ---------0.00 0.00 1 77 0
Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 88 Rows ------1 77
rows ---------0 0 1 ---------1
le
b fera
s
n a r t n-
Row Source Operation --------------------------------------------------SORT AGGREGATE (cr=77 pr=1 pw=0 time=0 us) TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=77 pr=1 pw=0 time=760 us cost=85 size=1260 card=90) 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)
no a has uideฺ 77 ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( tkprof Output with Index: Example u h a results shown in the slide indicate that CPU time was reduced to 0.01 second when an The S i a
Vij
index was created on the CUST_CITY column. These results may have been achieved because the statement uses the index to retrieve the data. Additionally, because this example reexecutes the same statement, most of the data blocks are already in memory. You can achieve significant improvements in performance by indexing sensibly. Identify areas for potential improvement using the SQL Trace facility. Note: Indexes should not be built unless required. Indexes do slow down the processing of the INSERT, UPDATE, and DELETE commands because references to rows must be added, changed, or removed. Unused indexes should be removed. However, instead of processing all the application SQL through EXPLAIN PLAN, you can use index monitoring to identify and remove any indexes that are not used.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 36
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Which command would you use to create a trace file of your SQL*Plus session in a dedicated server environment? a. alter session set tracefile_identifier='mytraceid'; b. EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => FALSE); ble a r fe c. trcsess output=mytrace.trc clientid='HR s n tra session' n no $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.t a rc has uideฺ ) d. tkprof *mytrace*.trc SYS=NO tG commytrace.txt
ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 37
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The _____ utility formats the trace file into a readable format. a. trcsess b. tkprof c. d.
SQL Developer SQL*Plus Autotrace
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b, c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 38
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
In an environment with an applications server that uses a connection pool, you will use ________ to identify which trace files need to be combined to get an overall trace of the application. a. trcsess b. tkprof c. d.
SQL Developer DBMS_APPLICATION_INFO
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: d
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 39
le
b fera
s
n a r t n-
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Configure the SQL Trace facility to collect session statistics • Use the trcsess utility to consolidate SQL trace files • Format trace files using the tkprof utility • Interpret the output of the tkprof command
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 40
le
b fera
s
n a r t n-
e
ns e c li
Practice 5: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 5: Overview
i a j i V
This practice covers the following topics: • Creating a service • Tracing your application using services • Interpreting trace information using trcsess and tkprof
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 41
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Tracing Chapter 5 - Page 42
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
s
b fera
n a r t n-
Optimizer Operators no
a ฺ s a Chapterh6 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Operators
i a j i V
Optimizer Operators
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this lesson, you should be able to: • Describe the SQL operators for tables and indexes • List the possible access paths
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h This a lesson helps you understand the execution plans that use operators related to table and S i index access methods. a Objectives
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 3
Row Source Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Row Source Operations •
Unary operations – Access Path
•
Binary operations – Joins
• N-ary operations Ams row source is a set of rows returned by a step in the execution plan .
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Aarow source is a set of rows returned by a step in the execution plan. The row source can be S i a a table, view, or result of a join or grouping operation. Row Source Operations
You can classify row sources as follows: •
Unary operations: Operations that act on only one input, such as an access path
•
Binary operations: Operations that act on two inputs, such as joins
•
N-ary operations: Operations that act on several inputs, such as a relational operator
Access paths are ways in which data is retrieved from the database. In general, index access paths should be used for statements that retrieve a small subset of table rows, while full scans are more efficient when accessing a large portion of the table. Online transaction processing (OLTP) applications, which consist of short-running SQL statements with high selectivity, are often characterized by the use of index access paths. Decision support systems (DSS), on the other hand, tend to use partitioned tables and perform full scans of the relevant partitions.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 4
Main Structures and Access Paths
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Main Structures and Access Paths Structures
Access Paths 1. Full Table Scan
Tables
2. Rowid Scan 3. Sample Table Scan
e
4. Index Scan (Unique)
le
b fera
5. Index Scan (Range) 6. Index Scan (Full)
ns e c li
s
n a r t n-
7. Index Scan (Fast Full)
Indexes
no a ฺ 9. Index Join) e(Index hasScan d i ) u 10. Indexes mUsingt GBitmap o c ฺ n l e Bitmap Indexes ai 11. dCombining u m t g sS @ 1 hi 2 t y e ija us v u to sah 8. Index Scan (Skip)
Vij
( u h a row can be located and retrieved with one of the methods mentioned in the slide. Any S i a Main Structures and Access Paths
In general, index access paths should be used for statements that retrieve a small subset of table rows, while full scans are more efficient when accessing a large portion of the table. To decide on the alternative, the optimizer gives each alternative (execution plan) a cost. The one with the lower cost is elected. There are special types of table access paths including clusters, index-organized tables, and partitions, which have not been mentioned in the slide. Clusters are an optional method of storing table data. A cluster is a group of tables that share the same data blocks because they share common columns and are often used together. For example, the EMP and DEPT table share the DEPTNO column. When you cluster the EMP and DEPT tables, Oracle physically stores all rows for each department from both the EMP and DEPT tables in the same data blocks. Hash clusters are single-table clusters in which rows with the same hash-key values are stored together. A mathematical hash function is used to select the location of a row within the cluster. All rows with the same key value are stored together on disk. The special types of access paths are discussed later in this course.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 5
Full Table Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Full Table Scan •
Performs multiblock reads (here DB_FILE_MULTIBLOCK_READ_COUNT = 4)
• • •
Reads all formatted blocks below the high-water mark HWM May filter rows B B B B ... B B B B B Is faster than index range scans for large amount of data
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h Aafull table scan sequentially reads all rows from a table and filters out those that do not meet S i a the selection criteria. During a full table scan, all formatted blocks in the table that are under
Vij
Full Table Scan
the high-water mark are scanned even if all the rows have been deleted from the table. Each block is read only once. The high-water mark indicates the amount of used space, or space that was formatted to receive data. Each row is examined to determine whether it satisfies the statement’s WHERE clause using the applicable filter conditions specified in the query. You can see the filter conditions in the “Predicate Information” section of the explain plan. The filter to be applied returns only rows where EMP.ENAME='King'. Because a full table scan reads all the formatted blocks in a table, it reads blocks that are physically adjacent to each other. This means that performance benefits can be reaped by utilizing input/output (I/O) calls that read multiple blocks at the same time. The size of the read call can range from a single block to any number of blocks up to the DB_FILE_MULTIBLOCK_READ_COUNT init parameter. Note: In Oracle 6, a full table scan (FTS) could flood the buffer cache because there was no difference in the way blocks were handled between FTS and other reads. Since Oracle V7, blocks read by FTS are allowed to occupy only a small percentage of the buffer cache. Currently, FTS are read into the PGA with direct reads bypassing the buffer cache in most cases. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 6
e
ns e c li
Full Table Scans: Use Cases
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Full Table Scans: Use Cases • • • • •
No suitable index Low selectivity filters (or no filters) Small table High degree of parallelism Full table scan hint: FULL ()
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a optimizer uses a full table scan in any of the following cases: The S i a Full Table Scans: Use Cases •
Lack of index: If the query is unable to use any existing indexes, it uses a full table scan (unless a ROWID filter or a cluster access path is available). For example, if there is a function used on the indexed column in the query, the optimizer cannot use the index and instead uses a full table scan. If you need to use the index for case-independent searches, either do not permit mixed-case data in the search columns or create a function-based index, such as UPPER(last_name) on the search column.
•
Large amount of data (low selectivity): If the optimizer thinks that the query accesses enough blocks in the table, it may use a full table scan even though indexes might be available.
•
Small table: If a table contains less than DB_FILE_MULTIBLOCK_READ_COUNT blocks under the high-water mark, a full table scan might be cheaper than an index range scan, regardless of the fraction of tables being accessed or indexes present.
•
High degree of parallelism: A high degree of parallelism for a table skews the optimizer towards full table scans over range scans. Examine the DEGREE column in ALL_TABLES for the table to determine the degree of parallelism.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 7
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
Full table scan hints: Use the FULL(table alias) hint to instruct the optimizer to use a full table scan.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 8
ns e c li
ROWID Scan
select * from scott.emp where rowid='AAAQ+LAAEAAAAAfAAJ'; -----------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost | -----------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 37 | 1| | 1 | TABLE ACCESS BY USER ROWID| EMP | 1 | 37 | 1| ------------------------------------------------------------------
B
B
.
e
le
B
B
b fera
ns e c li
sB
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Block 6959–Row 2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
ROWID Scan
Row migration
Vij
( u h a rowid of a row specifies the data file and data block containing the row and the location of The S i a the row in that block. Locating a row by specifying its rowid is the fastest way to retrieve a ROWID Scan
single row because the exact location of the row in the database is specified.
To access a table by rowid, the system first obtains the rowids of the selected rows, either from the statement’s WHERE clause or through an index scan of one or more of the table’s indexes. The system then locates each selected row in the table based on its rowid. Mostly, the optimizer uses rowids after retrieving them from an index (See the “Index Scans” slides.). The table access might be required for columns in the statement that are not present in the index. A table access by rowid does not need to follow every index scan. If the index contains all the columns needed for the statement, table access by rowid might not occur. Rowids are the system’s internal representation of where data is stored. Accessing data based on position is not recommended because rows can move around due to row migration and chaining, and also after export and import. Note: Due to row migration, a rowid can sometimes point to an address different from the actual row location, resulting in more than one block being accessed to locate a row. For example, an update to a row may cause the row to be placed in another block with a pointer in the original block. The rowid, however, still has only the address of the original block. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 9
Sample Table Scans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Sample Table Scans
SELECT * FROM emp SAMPLE BLOCK (10) SEED (1); --------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| --------------------------------------------------------------------| 0 | SELECT STATEMENT | | 4 | 99 | 2 (0)| | 1 | TABLE ACCESS SAMPLE| EMP | 4 | 99 | 2 (0)| ---------------------------------------------------------------------
e
le
b fera
B
B
B
B
ns e c li
s n a r n-t B
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Aasample table scan retrieves a random sample of data from a simple table or a complex S i a SELECT statement, such as a statement involving joins and views. This access path is used Sample Table Scans
when a statement’s FROM clause includes the SAMPLE clause or the SAMPLE BLOCK clause. To perform a sample table scan when sampling by rows with the SAMPLE clause, the system reads a specified percentage of rows in the table. To perform a sample table scan when sampling by blocks with the SAMPLE BLOCK clause, the system reads a specified percentage of table blocks. •
•
SAMPLE option: To perform a sample table scan when sampling by rows, the system reads a specified percentage of rows in the table and examines each of these rows to determine whether it satisfies the statement’s WHERE clause. SAMPLE BLOCK option: To perform a sample table scan when sampling by blocks, the system reads a specified percentage of the table’s blocks and examines each row in the sampled blocks to determine whether it satisfies the statement’s WHERE clause.
The sample percent is a number specifying the percentage of the total row or block count to be included in the sample. The sample value must be in the [0.000001 , 99.999999] range. This percentage indicates the probability of each row, or each cluster of rows in the case of block sampling, being selected as part of the sample. It does not mean that the database retrieves exactly sample_percent of the rows of table. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 10
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
SEED seed_value: Specify this clause to instruct the database to attempt to return the same sample from one execution to the next. seed_value must be an integer between 0 and 4294967295. If you omit this clause, the resulting sample changes from one execution to the next.
In row sampling, more blocks need to be accessed given a particular sample size, but the results are usually more accurate. Block samples are less costly, but may be inaccurate; more so with smaller samples. Note: Block sampling is possible only during full table scans or index fast full scans. If a more efficient execution path exists, Oracle Database does not perform block sampling. If you want to guarantee block sampling for a particular table or index, use the FULL or INDEX_FFS hint.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 11
ns e c li
Indexes: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Indexes: Overview Indexes • Storage techniques: – B*-tree indexes: The default and the most common — — —
Normal Function based: Precomputed value of a function or expression Index-organized table (IOT)
– Bitmap indexes – Cluster indexes: Defined specifically for cluster
•
•
Index attributes:
le
b fera
s
n a r t n-
no a has uideฺ tG n l i e Domain indexes:gSpecific ma Sto tudan application or cartridge 1@ this 2 y ja use i v u to sah – Key compression – Reverse key ) m o – Ascending, descending ฺc
( u h a index is an optional database object that is logically and physically independent of the An S i a table data. Being independent structures, they require storage space. Just as the index of a
Vij
Indexes: Overview
book helps you locate information fast, an Oracle Database index provides a faster access path to table data. The Oracle Database may use an index to access data that is required by a SQL statement, or it may use indexes to enforce integrity constraints. The system automatically maintains indexes when the related data changes. You can create and drop indexes at any time. If you drop an index, all applications continue to work. However, access to previously indexed data might be slower. Indexes can be unique or nonunique. A composite index, also called a concatenated index, is an index that you create on multiple columns (up to 32) in a table. Columns in a composite index can appear in any order and need not be adjacent in the table. For standard indexes, the database uses B*-tree indexes that are balanced to equalize access times. B*-tree indexes can be normal, reverse key, descending, or function based. •
B*-tree indexes: They are by far the most common indexes. Similar in construct to a binary tree, B*-tree indexes provide fast access, by key, to an individual row or range of rows, normally requiring few reads to find the correct row. However, the “B” in “B*-tree” does not stand for “binary,” but rather for “balanced.” Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 12
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Descending indexes: Descending indexes allow for data to be sorted from “big to small” (descending) instead of from “small to big” (ascending) in the index structure.
•
Reverse key indexes: These are B*-tree indexes whereby the bytes in the key are reversed. Reverse key indexes can be used to obtain a more even distribution of index entries throughout an index that is populated with increasing values. For example, if you use a sequence to generate a primary key, the sequence generates values such as 987500, 987501, 987502, and so on. With a reverse key index, the database logically indexes 005789, 105789, 205789, and so on, instead of 987500, 987501, and 987502. Because these reverse keys are now likely to be placed in different locations, this can reduce contention for particular blocks that may otherwise be targets for contention. However, only equality predicates can benefit from these indexes.
•
Index key compression: The basic concept behind a compressed key index is that every entry is broken into two—a prefix and a suffix component. The prefix is built on the leading columns of the concatenated index and has many repeating values. The suffix is built on the trailing columns in the index key and is the unique component of the index entry within the prefix. This is not compression in the same manner that ZIP files are compressed; rather, this is an optional compression that removes redundancies from concatenated (multicolumn) indexes.
le
•
b fera
s
n a r t n-
Function-based indexes: These are B*-tree or bitmap indexes that store the computed result of a function on a row’s column or columns, and not the column data itself. You can consider them as indexes on a virtual (derived or hidden) column. In other words, it is a column that is not physically stored in the table. You can gather statistics on this virtual column.
no a has uideฺ ) omstored • Index-organized tables: These are tables t inGa B*-tree structure. While rows of c ฺ n l i e data in a heap organized table are stored in an unorganized fashion (data goes a tud m wherever there is available g space), data S in an IOT is stored and sorted by a primary key. @ IOTs behave like regular tablesh asisfar as your application is concerned. 1 t yIn2a normal e a • Bitmap indexes: B*-tree, there is a one-to-one relationship between an j s i u is, an index entry points to a row. With bitmap indexes, a v to that u index entry and a row, h aindex entry uses a bitmap to point to many rows simultaneously. They are s single ( ahuappropriate for repetitive data (data with few distinct values relative to the total number
S
of rows in the table) that is mostly read-only. Bitmap indexes should never be considered in an OLTP database for concurrency-related issues.
•
Bitmap join indexes: A bitmap join index is a bitmap index for the join of two or more tables. A bitmap join index can be used to avoid actual joins of tables, or to greatly reduce the volume of data that must be joined, by performing restrictions in advance. Queries using bitmap join indexes can be sped up using bit-wise operations.
•
Application domain indexes: These are indexes you build with packages and store, either in the database or even outside the database. You tell the optimizer how selective your index is and how costly it is to execute, and the optimizer decides whether or not to use your index based on that information.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 13
e
ns e c li
Normal B*-tree Indexes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Normal B*-tree Indexes Index entry Root
e
le
Branch
b fera
ns e c li
s
n a r t n-
Index entry header
Vij
Key o column length n a Keyฺcolumn value Leaf s a e h uidrowid ) om nt G c ฺ l aiTabletudata de retrieved by using rowid m g sS @ 1 hi 2 t y e ija us v u to h a s ( Normal B*-tree Indexes u h a B*-tree index has a root block as a starting point. Depending on the number of entries, Each S i a there are multiple branch blocks that can have multiple leaf blocks. The leaf blocks contain all values of the index plus ROWIDs that point to the rows in the associated data segment.
Previous and next block pointers connect the leaf blocks so that they can be traversed from left to right (and vice versa). Indexes are always balanced, and they grow from the top down. In certain situations, the balancing algorithm can cause the B*-tree height to increase unnecessarily. It is possible to reorganize indexes. This is done by the ALTER INDEX … REBUILD | COALESCE command. The internal structure of a B*-tree index allows rapid access to the indexed values. The system can directly access rows after it has retrieved the address (the ROWID) from the index leaf blocks. Note: The maximum size of a single index entry is approximately one-half of the data block size.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 14
Index Scans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Scans Types of index scans: • Unique • Min/Max • Range (Descending) • Skip • Full and fast full • Index join
B-Tree index IX_EMP
e
le
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l B B B aiB tude B m g sS @ 1 hi 2 t y e ija us v u to sah
B : block
b fera
ns e c li
Table EMP
B
Vij
( u h a index scan can be one of the following types: An S i a Index Scans
A row is retrieved by traversing the index, using the indexed column values specified by the statement’s WHERE clause. An index scan retrieves data from an index based on the value of one or more columns in the index. To perform an index scan, the system searches the index for the indexed column values accessed by the statement. If the statement accesses only columns of the index, the system reads the indexed column values directly from the index, rather than from the table. The index contains not only the indexed value, but also the rowids of rows in the table that have the value. Therefore, if the statement accesses other columns in addition to the indexed columns, the system can find the rows in the table by using either a table access by rowid or a cluster scan. Note: The graphic shows a case where four rows are retrieved from the table using their rowids obtained by the index scan.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 15
Index Unique Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Unique Scan
index UNIQUE Scan PK_EMP
create unique index PK_EMP on EMP(empno)
e
select * from emp where empno = 9999;
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a index unique scan returns, at most, a single ROWID. The system performs a unique scan if An S i a Index Unique Scan
a statement contains a UNIQUE or a PRIMARY KEY constraint that guarantees that only a single row is accessed. This access path is used when all the columns of a unique (B*-tree) index are specified with equality conditions. Key values and ROWIDs are obtained from the index, and table rows are obtained using ROWIDs.
You can look for access conditions in the “Predicate Information” section of the execution plan (The execution plan is dealt with in detail in the lesson titled “Interpreting Execution Plans.”). Here the system accesses only matching rows for which EMPNO=9999. Note: Filter conditions filter rows after the fetch operation and output the filtered rows.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 16
Index Range Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Range Scan Index Range SCAN I_DEPTNO
create index I_DEPTNO on EMP(deptno);
e
select /*+ INDEX(EMP I_DEPTNO) */ * from emp where deptno = 10 and sal > 1000;
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a index range scan is a common operation for accessing selective data. It can be bounded An S i a (on both sides) or unbounded (on one or both sides). Data is returned in the ascending order Index Range Scan
of index columns. Multiple rows with identical values are sorted in the ascending order by ROWID.
The optimizer uses a range scan when it finds one or more leading columns of an index specified in conditions (the WHERE clause), such as col1 = :b1, col1 < :b1, col1 > :b1, and any combination of the preceding conditions. Wildcard searches (col1 like '%ASD') should not be in a leading position, as this does not result in a range scan. Range scans can use unique or nonunique indexes. Range scans can avoid sorting when index columns constitute the ORDER BY/GROUP BY clause and the indexed columns are NOT NULL as otherwise they are not considered. An index range scan descending is identical to an index range scan, except that the data is returned in the descending order. The optimizer uses index range scan descending when an order by descending clause can be satisfied by an index.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 17
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 18
ns e c li
Index Range Scan: Descending
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Range Scan: Descending Index Range SCAN IDX
e
select * from emp where deptno>20 order by deptno desc;
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h aaddition to index range scans in ascending order, which are described in the previous slide, In S i a the system is also able to scan indexes in the reverse order as illustrated by the graphic in the Index Range Scan: Descending slide.
The example retrieves rows from the EMP table by descending order on the DEPTNO column. You can see the DESCENDING operation row source for ID 2 in the execution plan that materialized this type of index scans. Note: By default an index range scan is done in the ascending order.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 19
Descending Index Range Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Descending Index Range Scan Index Range SCAN IX_D
drop index I_Deptno; create index IX_D on EMP(deptno desc); select * from emp where deptno 1000 and deptno is not null order by deptno;
index Full Scan I_DEPTNO
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Aafull scan is available if a predicate references one of the columns in the index. The predicate S i a does not need to be an index driver (leading column). A full scan is also available when there Index Full Scan
is no predicate, if both the conditions are met: •
All the columns in the table referenced in the query are included in the index.
•
At least one of the index columns is not null.
A full scan can be used to eliminate a sort operation because the data is ordered by the index key. Note: An index full scan reads index using single-block input/output (I/O) (unlike a fast full index scan).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 22
Index Fast Full Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Fast Full Scan LEGEND:
db_file_multiblock_read_count = 4 multiblock read
SH
R
L
discard
L
SH=segment header R=root block B=branch block L=leaf block
multiblock read
L
B
L
L
discard
select /*+ INDEX_FFS(EMP I_DEPTNO) where deptno is not null;
...
B
L
e
discard
*/ deptno from emp
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a fast full scans are an alternative to full table scans when the index contains all the Index S i a columns that are needed for the query and at least one column in the index key has a NOT Index Fast Full Scan
NULL constraint. A fast full scan accesses the data in the index itself without accessing the table. It cannot be used to eliminate a sort operation because the data is not ordered by the index key. It can be used for the min/avg/sum aggregate functions. In this case, the optimizer must know that all table rows are represented in the index; at least one NOT NULL column. This operation reads the entire index using multiblock reads (unlike a full index scan). Fast full index scans cannot be performed against bitmap indexes. A fast full scan is faster than a normal full index scan because it can use multiblock I/O just as a table scan.
You can specify fast full index scans with the OPTIMIZER_FEATURES_ENABLE initialization parameter or the INDEX_FFS hint as shown in the slide example. Note: Index fast full scans are used against an index when it is rebuilt offline.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 23
Index Skip Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Skip Scan SELECT * FROM employees WHERE age BETWEEN 20 AND 29 Min M10
B1 Min F16 F20 F26 F30
F10 F11 F12 F13 F14 F15
R
F16 F17 F18 F19
F20 F21 F22 F23 F24 F25
F26 F27 F28 F29
Index on (GENDER, AGE) B2
M10 M16 M20 M26 M30
F30 F31 F32 F33 F34 F35
M10 M11 M12 M13 M14 M15
M16 M17 M18 M19
M20 M21 M22 M23 M24 M25
M26 M27 M28 M29
no a has uideฺ ) om nt G c ฺ l i e L7 L8 L1 L2 L3 L4 maL5 tud L6 g sS @ 1 hi 2 t y e ija us v u to sah
L9
le
b fera
s
n a r t n-
e
M30 M31 M32 M33 M34 M35
ns e c li
L10
Vij
( u h a skip scans improve index scans by skipping blocks that could never contain keys Index S i a matching the filter column values. Scanning index blocks is often faster than scanning table Index Skip Scan
data blocks. Skip scanning can happen when the initial (leading) column of the composite index is not specified in a query. Suppose that there is a concatenated index on the GENDER and AGE columns in the EMPLOYEES table. This example illustrates how skip scanning is processed to answer the query in the slide. The system starts from the root of the index [R] and proceeds to the left branch block [B1]. From there, the system identifies a first entry to be F16, goes to the left leaf [L1], and starts to scan it because it could contain A25 (that is, where the “gender” is before “F” in the alphabet). The server identifies that this is not possible because the first entry is F10. It is thus not possible to find an entry such as A25 in this leaf, so it can be skipped. Backtracking to the first branch block [B1], the server identifies that the next subtree (F16) does not need to be scanned because the next entry in [B1] is F20. Because the server is certain that it is not possible to find a 25 between F16 and F20, the second leaf block [L2] can be skipped. Returning to [B1], the server finds that the next two entries have a common prefix of F2. This identifies possible subtrees to scan. The system knows that these subtrees are ordered by age. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 24
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].
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 25
ns e c li
Index Skip Scan: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Skip Scan: Example
Index on (DEPTNO, SAL) create index IX_SS on EMP(DEPTNO,SAL);
e
select /*+ index_ss(EMP IX_SS) */ * from emp where SAL < 1500;
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide finds employees who have salary less than 1500 using an index skip The S i a scan. Index Skip Scan: Example
It is assumed that there is a concatenated index on the DEPTNO and SAL columns. As you can see, the query does not have a predicate on the DEPTNO leading column. This leading column only has some discrete values, that is, 10, 20 and 30. Skip scanning lets a composite index be split logically into smaller subindexes. The number of logical subindexes is determined by the number of distinct values in the initial column. The system pretends that the index is really three little index structures hidden inside one big one. In the example, it is three index structures: •
where deptno = 10
•
where deptno = 20
•
where deptno = 30
The output is ordered by DEPTNO. Note: Skip scanning is advantageous if there are few distinct values in the leading column of the composite index and many distinct values in the nonleading key of the index. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 26
Index Join Scan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Join Scan alter table emp modify (SAL not null, ENAME not null); create index I_ENAME on EMP(ename); create index I_SAL on EMP(sal);
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a index join is a hash join of several indexes that together contain all the table columns that An S i a are referenced in the query. If an index join is used, no table access is needed because all the Index Join Scan
relevant column values can be retrieved from the indexes. An index join cannot be used to eliminate a sort operation.
The index join is not a real join operation (note that the example is a single table query), but is built using index accesses followed by a join operation on rowid. The example in the slide assumes that you have two separate indexes on the ENAME and SAL columns of the EMP table. Note: You can specify an index join with the INDEX_JOIN hint as shown in the example.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 27
B*-tree Indexes and Nulls
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
B*-tree Indexes and Nulls create table nulltest ( col1 number, col2 number not null); create index nullind1 on nulltest (col1); create index notnullind2 on nulltest (col2);
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Itais a common mistake to forget about nulls when dealing with B*-tree indexes. Single-column S i a B*-tree Indexes and Nulls
B*-tree indexes do not store null values and so indexes on nullable columns cannot be used to drive queries unless there is something that eliminates the null values from the query.
In the slide example, you create a table containing a nullable column called COL1, and COL2, which cannot have null values. One index is built on top of each column. The first query, retrieves all COL1 values. Because COL1 is nullable, the index cannot be used without a predicate. Hinting the index on COL1 (nullind1) to force index utilization makes no difference because COL1 is nullable. Because you only search for COL1 values, there is no need to read the table itself. However, with the second query, the effect of the predicate against COL1 is to eliminate nulls from the data returned from the column. This allows the index to be used. The third query can directly use the index because the corresponding column is declared NOT NULL at table-creation time. Note: The index could also be used by forcing the column to return only NOT NULL values using the COL1 IS NOT NULL predicate.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 28
Using Indexes: Considering Nullable Columns
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Indexes: Considering Nullable Columns Column
Null?
SSN FNAME LNAME
Y Y N
PERSON
CREATE UNIQUE INDEX person_ssn_ix ON person(ssn); SELECT COUNT(*) FROM person; SELECT STATEMENT | SORT AGGREGATE | TABLE ACCESS FULL| PERSON DROP INDEX person_ssn_ix;
ble a r ALTER TABLE person ADD CONSTRAINT pk_ssn fe s Column Null? n PRIMARY KEY (ssn); tra N SSN n SELECT /*+ INDEX(person)n*/ o COUNT(*) FROM FNAME Y a person; LNAME N as ideฺ h ) u| SELECT STATEMENT com ent G | SORTilฺAGGREGATE a FAST PERSON mINDEX tud FULL SCAN| PK_SSN g S 1@ this 2 y ja use i v to hu a s ( UsinguIndexes: Considering Nullable Columns h a queries look as if they should use an index to compute a simple count of rows in the Some S i a table. This is typically more efficient that scanning the table. But the index to be used must not
Vij
be built on a column that can contain null values. Single-column B*-tree indexes never store null values, so the rows are not represented in the index, and thus, do not contribute to the COUNT being computed, for example.
In the example in the slide, there is a unique index on the SSN column of the PERSON table. The SSN column is defined as allowing null values, and creating a unique index on it does nothing to change that. This index is not used when executing the count query in the slide. Any rows with null for SSN are not represented in the index, so the count across the index is not necessarily accurate. This is one reason why it is better to create a primary key rather than a unique index. A primary key column cannot contain null values. In the slide, after the unique index is dropped in the place of designating a primary key, the index is used to compute the row count. Note: The PRIMARY KEY constraints combine a NOT NULL constraint and a unique constraint in a single declaration.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 29
e
ns e c li
Index-Organized Tables
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index-Organized Tables Indexed access on table
Accessing index-organized table
e
le
ROWID
b fera
ns e c li
s
n a r t n-
no a Non-key columns s ฺ a e h d ) Gui Key column m o ilฺc dent a Row header m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a index-organized table (IOT) is a table physically stored in a concatenated index structure. An S i a The key values (for the table and the B*-tree index) are stored in the same segment. An IOT Index-Organized Tables contains: •
Primary key values
•
Other (non-key) column values for the row
The B*-tree structure, which is based on the primary key of the table, is organized in the same way as an index. The leaf blocks in this structure contain the rows instead of the ROWIDs. This means that the rows in the IOT are always maintained in the order of the primary key. You can create additional indexes on IOTs. The primary key can be a composite key. Because large rows of an IOT can destroy the dense and efficient storage of the B*-tree structure, you can store part of the row in another segment, which is called an overflow area. Index-organized tables provide fast key-based access to table data for queries involving exact match and range searches. Changes to the table data result only in updating the index structure. Also, storage requirements are reduced because key columns are not duplicated in the table and index. The remaining non-key columns are stored in the index structure. IOTs are particularly useful when you use applications that must retrieve data based on a primary key and have only a few, relatively short non-key columns. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 30
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: The descriptions mentioned here are correct if no overflow segments exist. Overflow segments should be used with long rows.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 31
ns e c li
Index-Organized Table Scans
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index-Organized Table Scans create table iotemp ( empno number(4) primary key, ename varchar2(10) not null, job varchar2(9), mgr number(4), hiredate date, sal number(7,2) not null, comm number(7,2), deptno number(2)) organization index; select * from iotemp where empno=9999;
e
le
b fera
ns e c li
s
select * from iotemp where sal>1000;
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Index-organized tables are just like indexes. They use the same access paths that you saw for S i a normal indexes. Index-Organized Table Scans
The major difference from a heap-organized table is that there is no need to access both an index and a table to retrieve indexed data. Note: SYS_IOT_TOP_75664 is the system-generated name of the segment used to store the IOT structure. You can retrieve the link between the table name and the segment from USER_INDEXES with these columns: INDEX_NAME, INDEX_TYPE, TABLE_NAME.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 32
Bitmap Indexes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Indexes Table File 3 Block 10
Index
Block 11
e
le
Block 12
b fera
ns e c li
s
n a r t n-
o 010010100> n010000000 a 100100000> s 000000000 ฺ a e h d ) Gui001100000 000001001> m o 100000000 001000010> c ent ฺ l i ma Stud g 1@ this 2 y ja use i v u to sah 'FR'; ---------------------------------------------------------------------------| Id
| Operation
| Name
| Rows
| Bytes | Cost (%CPU)|
---------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
3 |
|
1 |
|
|
1 |
3 |
|
2 |
BITMAP CONVERSION COUNT |
|
1 |
3 |
|
3 |
BITMAP INDEX RANGE SCAN| IX_B2 |
|
|
SORT AGGREGATE
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 35
2
(0)| |
2
(0)| |
----------------------------------------------------------------------------
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Predicate: 3 - access("COUNTRY">'FR') filter("COUNTRY">'FR')
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 36
ns e c li
Combining Bitmap Indexes: Examples
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Combining Bitmap Indexes: Examples SELECT * FROM PERF_TEAM WHERE country in('FR','DE');
FR 0 0 1 1 1 1 0 0 0 0 0 0
0 1 1 1 1 1 0 0 0 0 0
OR
DE 0 1 0 0 0 0 0 0 0 0 0 0
e
le
F 0 0 1 1 1 1 0 0 0 0 0 0
b fera
ns e c li
s
n a r t n-
o as ideฺ M 1 1 1 0 1 1 0 1 0 1 1 1)h m t Gu o c n ilTฺ WHEREdecountry='FR' a SELECT * FROM EMEA_PERF_TEAM and gender='M'; u m St g 1@ this 2 y ja use i v to hu a s ( Bitmap Indexes: Examples Combining u h a indexes are the most effective for queries that contain multiple conditions in the WHERE Bitmap S i Rows that satisfy some, but not all, conditions are filtered out before the table itself is Vija clause. accessed. This improves response time, often dramatically. As the bitmaps from bitmap AND
0 0 1a0n1 1 0 0 0 0 0
indexes can be combined quickly, it is usually best to use single-column bitmap indexes. Due to fast bit-and, bit-minus, and bit-or operations, bitmap indexes are efficient when: •
Using IN (value_list)
•
Predicates are combined with AND or OR
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 37
Combining Bitmap Index Access Paths
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Combining Bitmap Index Access Paths SELECT * FROM PERF_TEAM WHERE country in ('FR','DE'); --------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | | 0 | SELECT STATEMENT | | 1 | 45 | | 1 | INLIST ITERATOR | | | | | 2 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 | | 3 | BITMAP CONVERSION TO ROWIDS| | | | | 4 | BITMAP INDEX SINGLE VALUE | IX_B2 | | | Predicate: 4 - access("COUNTRY"='DE' OR "COUNTRY"='FR')
e
le
b fera
SELECT * FROM PERF_TEAM WHERE country='FR' and gender='M'; --------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | | 0 | SELECT STATEMENT | | 1 | 45 | | 1 | TABLE ACCESS BY INDEX ROWID | PERF_TEAM | 1 | 45 | | 2 | BITMAP CONVERSION TO ROWIDS| | | | | 3 | BITMAP AND | | | | | 4 | BITMAP INDEX SINGLE VALUE| IX_B1 | | | | 5 | BITMAP INDEX SINGLE VALUE| IX_B2 | | | Predicate: 4 - access("GENDER"='M') 5 - access("COUNTRY"='FR')
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a indexes can be used efficiently when a query combines several possible values for a Bitmap S i a column or when two separately-indexed columns are used. Combining Bitmap Index Access Paths
In some cases, a WHERE clause might reference several separately indexed columns as in the examples shown in the slide. If both the COUNTRY and GENDER columns have bitmap indexes, a bit-and operation on the two bitmaps quickly locates the rows that you look for. The more complex the compound WHERE clauses become, the more benefit you get from bitmap indexing.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 38
Bitmap Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Operations •
BITMAP CONVERSION: – TO ROWIDS – FROM ROWIDS – COUNT
•
e
BITMAP INDEX: – SINGLE VALUE – RANGE SCAN – FULL SCAN
• • • •
BITMAP BITMAP BITMAP BITMAP
le
b fera
ns e c li
s
n a r t n-
MERGE no a AND/OR as ideฺ h ) MINUS m t Gu o c KEY ITERATION ailฺ den
m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a slide summarizes all the possible bitmap operations. The following operations have not The S i a been explained so far: Bitmap Operations
•
• •
•
BITMAP CONVERSION FROM ROWID: B*-tree index converted by the optimizer into BITMAP (cost is lower than other methods) to make these efficient bitmaps comparison operations available. After the bitmap comparison has been done, the resultant bitmap is converted back into ROWIDs (BITMAP CONVERSION TO ROWIDS) to perform the data lookup. BITMAP MERGE merges several bitmaps resulting from a range scan into one bitmap. BITMAP MINUS is a dual operator that takes the second bitmap operation and negates it by changing ones to zeros, and zeros to ones. The bitmap minus operation can then be performed as a BITMAP AND operation using this negated bitmap. This would typically be the case with the following combination of predicates: C1=2 and C26. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 39
Bitmap Join Index
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Join Index
1.2.3 Sales
CREATE BITMAP INDEX cust_sales_bji ON sales(c.cust_city) FROM sales s, customers c WHERE c.cust_id = s.cust_id; Customers
e
le
b fera
ns e c li
s
n a r t n-
Vij
no a as ideฺ h ) o c ฺ n l i e a d tu g S 1@ this 2 y ja use i v to hu a s ( Index Bitmap Join u h aaddition to a bitmap index on a single table, you can create a bitmap join index. A bitmap In S i a join index is a bitmap index for the join of two or more tables. A bitmap join index is a space10.8000.3
efficient way of reducing the volume of data that must be joined by performing the join in advance. Note: Bitmap join indexes are much more efficient in storage than materialized join views. For a row source example, see the lesson titled “Case Study: Star Transformation.” Here, you create a new bitmap join index named cust_sales_bji on the SALES table. The key of this index is the CUST_CITY column of the CUSTOMERS table. This example assumes that there is an enforced primary key constraint on CUSTOMERS to ensure that what is stored in the bitmap reflects the reality of the data in the tables. The CUST_ID column is the primary key of CUSTOMERS, but is also a foreign key inside SALES, although not required. The FROM and WHERE clause in the CREATE statement allow the system to make the link between the two tables. They represent the join condition between the two tables. The middle part of the graphic shows you a theoretical implementation of this bitmap join index. Each entry or key in the index represents a possible city found in the CUSTOMERS table. A bitmap is then associated to one particular key. Each bit in a bitmap corresponds to one row in the SALES table. In the first key in the slide (Rognes), you see that the first row in the SALES table corresponds to a product sold to a Rognes customer, while the second bit is not a product Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 40
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 41
ns e c li
Composite Indexes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Composite Indexes MAKE
MODEL
CARS Index columns create index cars_make_model_idx on cars(make, model); select * from cars where make = 'CITROËN' and model = '2CV';
ble a r fe ----------------------------------------------------------------s n | Id | Operation | Name | a r t ----------------------------------------------------------------on | 0 | SELECT STATEMENT | | n a | 1 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS | s ฺ a e |* 2 | INDEX RANGE SCAN |h CARS_MAKE_MODEL_IDX | d i ) u ----------------------------------------------------------------om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( Indexes Composite u h Aacomposite index is also referred to as a concatenated index because it concatenates S i a column values together to form the index key value. In the illustration in the slide, the MAKE
Vij
and MODEL columns are concatenated together to form the index. It is not required that the columns in the index are adjacent. And, you can include up to 32 columns in the index, unless it is a bitmap composite index, in which case the limit is 30. Composite indexes can provide additional advantages over single-column indexes: •
Improved selectivity: Sometimes two or more columns or expressions, each with poor selectivity, can be combined to form a composite index with higher selectivity.
•
Reduced I/O: If all columns selected by a query are in a composite index, the system can return these values from the index without accessing the table.
A composite index is mainly useful when you often have a WHERE clause that references all, or the leading portion of the columns in the index. If some keys are used in WHERE clauses more frequently, and you decided to create a composite index, be sure to create the index so that the more frequently selected keys constitute a leading portion for allowing the statements that use only these keys to use the index. Note: It is also possible for the optimizer to use a concatenated index even though your query does not reference a leading part of that index. This is possible since index skip scans and fast full scans were implemented. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 42
e
ns e c li
Invisible Index: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Invisible Index: Overview Use index.
Do not use index.
Optimizer view point INVISIBLE
VISIBLE
e
Index
Index
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE
le
b fera
ns e c li
s
Data view point
n a r t n-
no a has uideฺ ) G Update index. om t index. c Update ฺ n l i Update table. e Update table. a tud m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a invisible index is an index that is ignored by the optimizer unless you explicitly set the An S i a OPTIMIZER_USE_INVISIBLE_INDEXES initialization parameter to TRUE at the session or Invisible Index: Overview
system level. The default value for this parameter is FALSE.
Making an index invisible is an alternative to making it unusable or dropping it. Using invisible indexes, you can perform the following actions: •
Test the removal of an index before dropping it.
•
Use temporary index structures for certain operations or modules of an application without affecting the overall application.
Unlike unusable indexes, an invisible index is maintained during DML statements.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 43
Invisible Indexes: Examples
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Invisible Indexes: Examples •
Index is altered as not visible to the optimizer:
ALTER INDEX ind1 INVISIBLE;
•
Optimizer does not consider this index:
e
SELECT /*+ index(TAB1 IND1) */ COL1 FROM TAB1 WHERE …;
•
Optimizer considers this index:
le
b fera
ns e c li
s
n a r t n-
Vij
no a • Create an index as invisible initially: has uideฺ ) om nt G c ฺ l CREATE INDEX IND1 ON TAB1(COL1) ai tudeINVISIBLE; m g sS @ 1 hi 2 t y e ija us v u to h a s (Indexes: Examples Invisible u h a an index is invisible, the optimizer selects plans that do not use the index. If there is no When S i a discernible drop in performance, you can drop the index. You can also create an index initially ALTER INDEX ind1 VISIBLE;
as invisible, perform testing, and then determine whether to make the index visible.
You can query the VISIBILITY column of the *_INDEXES data dictionary views to determine whether the index is VISIBLE or INVISIBLE. Note: For all the statements given in the slide, it is assumed that OPTIMIZER_USE_INVISIBLE_INDEXES is set to FALSE.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 44
Guidelines for Managing Indexes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Guidelines for Managing Indexes
i a j i V
• • • • • • • •
Create indexes after inserting table data. Index the correct tables and columns. Order index columns for performance. Limit the number of indexes for each table. Drop indexes that are no longer required. Specify the tablespace for each index. ble a r Consider parallelizing index creation. fe s n Consider creating indexes with NOLOGGING.-tra
n
noor rebuilding Consider costs and benefits of coalescing a indexes. has uideฺ ) m G Consider cost before disabling constraints. ฺco or tdropping
• •
il en a d u gm s St @ 1 hi 2 t y e ija us v u to sah
( u h a• Create indexes after inserting table data: Data is often inserted or loaded into a table
Guidelines for Managing Indexes
S
using either the SQL*Loader or an import utility. It is more efficient to create an index for a table after inserting or loading the data. •
•
•
Index the correct tables and columns: Use the following guidelines for determining when to create an index: -
Create an index if you frequently want to retrieve less than 15% of the rows in a large table.
-
To improve performance on joins of multiple tables, index the columns used for joins.
-
Small tables do not require indexes.
Columns suitable for indexing: Some columns are strong candidates for indexing: -
Values are relatively unique in the column.
-
There is a wide range of values (good for regular indexes).
-
There is a small range of values (good for bitmap indexes).
-
The column contains many nulls, but queries often select all rows having a value.
Columns not suitable for indexing: Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 45
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
-
There are many nulls in the column and you do not search on the not null values.
-
The LONG and LONG RAW columns cannot be indexed.
-
Virtual columns: You can create unique or nonunique indexes on virtual columns.
•
Order index columns for performance: The order of columns in the CREATE INDEX statement can affect query performance. In general, specify the most frequently used columns first.
•
Limit the number of indexes for each table: A table can have any number of indexes. However, the more indexes there are, the more overhead is incurred as the table is modified. Thus, there is a trade-off between the speed of retrieving data from a table and the speed of updating the table.
•
Drop indexes that are no longer required.
•
Specify the tablespace for each index: If you use the same tablespace for a table and its index, it can be more convenient to perform database maintenance, such as tablespace backup.
•
le
Consider parallelizing index creation: You can parallelize index creation, just as you can parallelize table creation. This speeds up index creation. However, an index created with an INITIAL value of 5M and a parallel degree of 12 consumes at least 60 MB of storage during index creation.
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g of coalescing • Consider costs and benefits or rebuilding indexes: Improper sizing or S @ s i 1 increased growth can produce index fragmentation. To eliminate or reduce h 2 t y e fragmentation,ijyou can rebuild or coalesce the index. But before you perform either task, a us v weigh theu costs andto benefits of each option, and select the one that works best for your ah situation. s ( a• huConsider cost before disabling or dropping constraints: Because unique and •
S
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.
primary keys have associated indexes, you should factor in the cost of dropping and creating indexes when considering whether to disable or drop a UNIQUE or PRIMARY KEY constraint. If the associated index for a UNIQUE key or PRIMARY KEY constraint is extremely large, you can save time by leaving the constraint enabled rather than dropping and re-creating the large index. You also have the option of explicitly specifying that you want to keep or drop the index when dropping or disabling a UNIQUE or PRIMARY KEY constraint.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 46
e
ns e c li
Investigating Index Usage
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Investigating Index Usage An index may not be used for one of many reasons: • There are functions being applied to the predicate. • There is a data type mismatch. • Statistics are old. • The column can contain null. • Using the index would actually be slower than not using it.le
b
era f s n
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Investigating Index Usage
ahmay often run a SQL statement expecting a particular index to be used, and it is not. This can be You S i ija because the optimizer is unaware of some information, or because it should not use the index.
V
Functions If you apply a function to the indexed column in the WHERE clause, the index cannot be used; the index is based on column values without the effect of the function. For example, the following statement does not use an index on the salary column: SELECT * FROM employees WHERE 1.10*salary > 10000 If you want an index to be used in this case, you can create a function-based index. Function-based indexes were covered under “Index Range Scan: Function-Based” earlier in this lesson.
Data Type Mismatch If there is a data type mismatch between the indexed column and the compared value, the index is not used. This is due to the implicit data type conversion. For example, if the SSN column is of the VARCHAR2 type, the following does not use the index on SSN: SELECT * FROM person WHERE SSN = 123456789
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 47
e
ns e c li
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Null Columns
i a j i V
If a column can contain nulls, it may prevent the use of an index on that column. This is covered later in this lesson. Slower Index Sometimes the use of an index is not efficient. This is covered later in this lesson.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 48
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
A full table scan sequentially reads all rows from a table and filters out those that do not meet the selection criteria. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 49
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Assuming that the column email has an index, the following query will result in an index range scan:
Select employee_name from employees where email like '%A';
e
a. True b. False
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 50
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
To get optimum result from indexes: a. Create indexes before inserting table data b. Do not order index columns c. Limit the number of indexes for each table d. Do not specify the tablespace for each index
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 51
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned to: • Describe the SQL operators for tables and indexes • List the possible access paths
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 52
ns e c li
Practice 6: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 6: Overview
i a j i V
This practice covers using different access paths for better optimization. • Case 1 through case 13
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 53
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Operators Chapter 6 - Page 54
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
Optimizer: Join no Operators
a ฺ s a Chapterh7 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer: Join Operators
i a j i V
Optimizer: Join Operators
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this lesson, you should be able to: • Describe the SQL operators for joins • List the possible access paths
e
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h This a lesson helps you understand the execution plans related to join operations. S i a Objectives
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 3
ns e c li
Join Methods
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Join Methods A join: • Defines the relationship between two row sources • Is a method of combining data from two data sources • Is controlled by join predicates, which define how the objects are related • Join methods: – Nested loops – Sort-merge join – Hash join
e
le
SELECT e.ename, d.dname FROM dept d JOIN emp e USING (deptno) WHERE e.job = 'ANALYST' OR e.empno = 9999;
b fera
ns e c li
s
n a r t n-
Vij
predicate o Join n Nonjoin predicate a ฺ s ha uide SELECT e.ename,d.dname ) FROM emp e, dept d om nt G c ฺ l WHERE e.deptno = d.deptno AND predicate ai OR e.empno de = 9999); Join u (e.job = 'ANALYST' m t Nonjoin predicate g sS @ 1 hi 2 t y e ija us v u to h a s ( Join Methods u h Aarow source is a set of data that can be accessed in a query. It can be a table, an index, a S i 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. 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 4
smaller table fits in the available memory. The cost is then limited to a single read pass over the data for the two tables.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: The slide shows you the same query using both the American National Standards Institute (ANSI) and non-ANSI join syntax. The ANSI syntax is the first example.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 5
ns e c li
Nested Loops Join
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Nested Loops Join NL
• • •
Driving row source is scanned. Each row returned drives a lookup in inner row source. Joining rows are then returned.
TAF
TAR
Driving
IS
For each
Inner
select ename, e.deptno, d.deptno, d.dname from emp e, dept d where e.deptno = d.deptno and ename like 'A%'; --------------------------------------------------------------------| Id | Operation | Name | Rows |Cost | --------------------------------------------------------------------| 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")
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athe general form of the nested loops join, one of the two tables is defined as the outer table, In S i a or the driving table. The other table is called the inner table, or the right-hand side. Nested Loops Join
For each row in the outer (driving) table that matches the single table predicates, all rows in the inner table that satisfy the join predicate (matching rows) are retrieved. If an index is available, it can be used to access the inner table by rowid. 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.
Optimizer: Join Operators Chapter 7 - Page 6
Nested Loops Join: Prefetching
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Nested Loops Join: Prefetching NL
TAF
TAR
Driving
IRS
e
Inner
select ename, e.deptno, d.deptno, d.dname from emp e, dept d where e.deptno = d.deptno and ename like 'A%'; --------------------------------------------------------------------| 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")
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a 9iR2 introduced a mechanism called nested loops prefetching. The idea is to improve Oracle S i a I/O utilization, therefore response time, of index access with table lookup by batching rowid Nested Loops Join: Prefetching lookups into parallel block reads.
This change to the plan output is not considered a different execution plan. It does not affect the join order, join method, access method, or parallelization scheme. 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.
Optimizer: Join Operators Chapter 7 - Page 7
Nested Loops Join: 11g Implementation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Nested Loops Join: 11g Implementation NL select ename, e.deptno, d.deptno, d.dname from emp e, dept d where e.deptno = d.deptno and ename like 'A%';
Driving
NL
TAF
TAR
IRS
Inner
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Database 11g introduces a new way of performing joins with NESTED Oracle S i a Nested Loops Join: 11g Implementation
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 8
Sort Merge Join
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Sort Merge Join • •
Merged
First and second row sources are sorted by the same sort key. Sorted Sorted rows from both tables are merged. select /*+ USE_MERGE(d e) NO_INDEX(d) */ ename, e.deptno, d.deptno, dname from emp e, dept d where e.deptno = d.deptno and ename > 'A'
MJ
SJ
SJ
TAF
IRS
Sorted
Independent
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h aa sort merge join, there is no concept of a driving table. A sort merge join is executed as In S i a follows: Sort Merge Join
1. Get the first data set, using any access and filter predicates, and sort it on the join columns. 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: Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 9
•
The join condition between two tables is not an equijoin.
•
Sorts already required by previous operations.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: Sort merge joins are useful when the join condition between two tables is an inequality condition (but not a nonequality), such as =.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 10
ns e c li
Hash Join
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hash Join HJ
•
The smallest row source is used to build a hash table. The second row source is hashed and checked against the hash table.
•
Driving
TAF
TAR
Build hash table in memory
IS
select /*+ USE_HASH(e d) */ ename, e.deptno, d.deptno, dname from emp e, dept d where e.deptno = d.deptno and ename like 'A%’
e
Probe
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a perform a hash join between two row sources, the system reads the first data set and To S i a builds an array of hash buckets in memory. A hash bucket is little more than a location that Hash Join
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. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 11
Cartesian Join
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cartesian Join
e
select ename, e.deptno, d.deptno, dname from emp e, dept d where ename like 'A%';
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h AaCartesian join is used when one or more of the tables does not have any join conditions to S i a any other tables in the statement. The optimizer joins every row from one data source with Cartesian Join
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 12
Join Types
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Join Types •
A join operation combines the output from two row sources and returns one resulting row source. Join operation types include the following :
•
– – – –
Join (Equijoin/Natural – Nonequijoin) Outer join (Full, Left, and Right) Semi join: EXISTS subquery Anti join: NOT IN subquery
– Star join (Optimization)
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a operation types include the following: Join S i a Join Types •
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 13
Equijoins and Nonequijoins
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Equijoins and Nonequijoins SELECT e.ename, e.sal, s.grade FROM emp e ,salgrade s WHERE e.sal = s.hisal;
Nonequijoin
Equijoin
SELECT e.ename, e.sal, s.grade FROM emp e ,salgrade s WHERE e.sal between s.hisal and s.hisal;
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a join condition determines whether a join is an equijoin or a nonequijoin. An equijoin is a The S i a join with a join condition containing an equality operator. When a join condition relates two Equijoins and Nonequijoins
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 14
Outer Joins
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Outer Joins An outer join returns a row even if no match is found. SELECT d.deptno,d.dname,e.empno,e.ename FROM emp e, dept d WHERE e.deptno(+)=d.deptno;
DEPT
EMP
10
20
20
10
30
20
40
30
1 SELECT /*+ USE_HASH(e d) */ d.deptno,d.dname,e.empno,e.ename FROM emp e, dept d WHERE e.deptno(+)=d.deptno;
e
10
le
b fera
ns e c li
s
n a r t n-
SELECT /*+ USE_NL(e d) */ d.deptno,d.dname,e.empno,e.ename FROM emp e, dept d WHERE e.deptno(+)=d.deptno;
no a as ideฺ h ) 2 m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
3
Vij
( u h a simple join is the most commonly used within the system. Other joins open up extra The S i a functionality, but have much more specialized uses. The outer join operator is placed on the Outer Joins
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 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.
Optimizer: Join Operators Chapter 7 - Page 15
table whose rows are being preserved, probing the hash table to see whether there was a row to join to.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: You can also use the ANSI syntax for full, left, and right outer joins (not shown in the slide).
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 16
ns e c li
Semijoins
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Semijoins Semijoins look only for the first match.
DEPT
EMP
10
20
20
10
30
20
40
30
e
10
le
b fera
SELECT deptno, dname FROM dept WHERE EXISTS (SELECT 1 FROM emp WHERE emp.deptno=dept.deptno);
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Semijoins return a result when you hit the first joining record. A semijoin is an internal way of S i a transforming an EXISTS subquery into a join. However, you cannot see this occur anywhere. Semijoins
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 17
Antijoins
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Antijoins Reverse of what would have been returned by a join SELECT deptno, dname FROM dept WHERE deptno not in (SELECT deptno FROM emp);
DEPT
EMP
10
20
20
10
30
20
40
30 10
e
le
b fera
SELECT deptno, dname FROM dept WHERE deptno IS NOT NULL AND deptno NOT IN (SELECT /*+ HASH_AJ */ deptno FROM emp WHERE deptno IS NOT NULL);
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah EMP
DEPT
Vij
( u h a Antijoins return rows that fail to match (NOT IN) the subquery at the right side. For example, S i a an antijoin can select a list of departments which do not have any employee. Antijoins
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, it is useful to know that these join types exist and could help explain unexpected performance changes between releases.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 18
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz The _______ join is used when one or more of the tables do not have any join conditions to any other tables in the statement. a. Hash b. Cartesian c. Non-equi le d. Outer rab
e
f s n tra
h
a s ( u
Answer: b
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 19
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The _______ join returns a row even if no match is found. a. Hash b. Cartesian c. Semi d. Outer
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: d
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 20
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The _______ join looks only for the first match. a. Hash b. Cartesian c. Semi d. Outer
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 21
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
In a hash join, the _______row source is used to build a hash table. a. Biggest b. Smallest c. Sorted d. Unsorted
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 22
le
b fera
s
n a r t n-
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned to: • Describe the SQL operators for joins • List the possible access paths
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 23
ns e c li
Practice 7: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 7: Overview
i a j i V
This practice covers the following topics: • Using different access paths for better optimization • Using the result cache
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer: Join Operators Chapter 7 - Page 24
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
Other Optimizer no Operators
a ฺ s a Chapterh8 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Other Optimizer Operators
i a j i V
Other Optimizer Operators
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this lesson, you should be able to: • Describe SQL operators for: – – – – –
•
Clusters In-List Sorts Filters Set Operations
e
le
Result Cache operators
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
b fera
ns e c li
( u h This a lesson helps you understand the execution plans that use common operators of other S i access methods. a Objectives
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 3
Clusters
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Clusters ORD_NO PROD ----------101 A4102 102 A2091 102 G7830 102 N9587 101 A5675 101 W0824
QTY -----20 11 20 26 19 10
ORD_NO -----101 102
... -
ORD_DT CUST_CD ----------05-JAN-97 R01 07-JAN-97 N45
Cluster Key (ORD_NO) 101 ORD_DT CUST_CD 05-JAN-97 R01 PROD QTY A4102 20 A5675 19 W0824 10 102 ORD_DT CUST_CD 07-JAN-97 N45 PROD QTY A2091 11 G7830 20 N9587 26
e
le
b fera
ns e c li
s
n a r t n-
no a eฺ hasClustered d i ) ORDERS and Unclustered ORDERS and m t Gu o c ORDER_ITEMS tables ilฺ en ORDER_ITEMS tables a d u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a are an optional method for storing table data. A cluster is a group of tables that share Clusters S i a the same data blocks because they share common columns and are often used together. For Clusters
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 4
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: Hash clusters are a better choice than using an indexed table or index cluster when a table is queried frequently with equality queries.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 5
ns e c li
When Are Clusters Useful?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
When Are Clusters Useful? •
Index cluster: – Tables always joined on the same keys – The size of the table is not known – In any type of searches
•
e
Hash cluster: – Tables always joined on the same keys ble – Storage for all cluster keys allocated initially a r e – In either equality (=) or nonequality () searchesnsf
ns e c li
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
When Are Clusters Useful?
h Index clusters allow row data from one or more tables that share a cluster key value to
a• S i ija
V
•
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 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 userprovided 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.
Other Optimizer Operators Chapter 8 - Page 6
When Are Clusters Useful?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
When Are Clusters Useful?
i a j i V
•
Single-table hash cluster: – Fastest way to access a large table with an equality search
•
Sorted hash cluster: – Only used for equality search – Avoid sorts on batch reporting – Avoid overhead probe on the branch blocks of an IOT
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a• This means that in a hash cluster the clustering factor is also very good and a row may
When Are Clusters Useful? (continued)
S
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 7
Cluster Access Path: Examples
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cluster Access Path: Examples
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide shows you two different cluster access paths. The S i a Cluster Access Path: Examples
In the top one, a hash scan is used to locate rows in a hash cluster, based on a hash value. In a hash cluster, all rows with the same hash value are stored in the same data block. To perform a hash scan, the system first obtains the hash value by applying a hash function to a cluster key value specified by the statement. The system then scans the data blocks 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 8
Sorting Operators
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Sorting Operators •
SORT operator: – – – –
•
AGGREGATE: Single row from group function UNIQUE: To eliminate duplicates JOIN: Precedes a merge join GROUP BY, ORDER BY: For these operators
HASH operator: – GROUP BY: For this operator – UNIQUE: Equivalent to SORT UNIQUE
•
e
le
b fera
ns e c li
s n a r -t BY. If you want ordered results, always use ORDER n o n a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a operations result when users specify an operation that requires a sort. Commonly Sort S i a encountered operations include the following: Sorting Operators
•
•
•
•
•
•
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 9
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
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.
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.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 10
ns e c li
Buffer Sort Operator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Buffer Sort Operator
SELECT ename, emp.deptno, dept.deptno, dname FROM emp, dept WHERE ename like 'A%';
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a BUFFER SORT operator uses a temporary table or a sort area in memory to store The S i a intermediate data. However, the data is not necessarily sorted. Buffer Sort Operator
The BUFFER SORT operator is needed if there is an operation that needs all the input data before it can start. (See “Cartesian Join.”) 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 11
Inlist Iterator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Inlist Iterator Every value executed separately deptno=1
deptno=2
e
SELECT * FROM emp WHERE empno IN (7876, 7900, 7902);
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Itais used when a query contains an IN clause with values or multiple equality predicates on S i a Inlist Iterator
the same column linked with ORs.
The INLIST ITERATOR operator iterates over the enumerated value list, and every value is executed separately. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 12
View Operator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
View Operator create view V as select /*+ NO_MERGE */ DEPTNO, sal from emp ; select * from V;
e
select v.*,d.dname from (select DEPTNO, sum(sal) SUM_SAL from emp group by deptno) v, dept d where v.deptno=d.deptno;
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a query produces a variable set of data in the form of a table. A view simply gives a name Each S i a to this set of data. View Operator
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 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 13
Count Stop Key Operator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Count Stop Key Operator SELECT count(*) FROM (SELECT /*+ NO_MERGE */ * FROM emp WHERE empno ='1' and rownum < 10);
e
le
b fera
ns e c li
s
n a r t n-
(
Count Stop Key Operator
hu a COUNT S ai
Vij
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 14
Min/Max and First Row Operators
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Min/Max and First Row Operators SELECT MIN(quantity_on_hand) FROM INVENTORIES WHERE quantity_on_hand < 500;
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a ROW retrieves only the first row selected by a query. It stops accessing the data after FIRST S i a the first value is returned. This is an optimization introduced in Oracle 8i and it works with the Min/Max and First Row Operators
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 column.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 15
Other N-Array Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Other N-Array Operations
i a j i V
• • • • •
FILTER CONCATENATION UNION ALL/UNION INTERSECT MINUS
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 16
ns e c li
FILTER Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
FILTER Operations • • •
Accepts a set of rows Eliminates some of them Returns the rest
SELECT deptno, sum(sal) SUM_SAL FROM emp GROUP BY deptno HAVING sum(sal) > 9000;
1
ble a r fe EXISTS SELECT deptno, dname FROM dept d WHERE s NOT n (select 1 from emp e where e.deptno=d.deptno); tra n no a has uideฺ ) om nt G c ฺ l 2 ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
FILTER Operations
h operation is any operation that discards rows returned by another step, but is not AaFILTER S i ija involved in retrieving the rows itself. All sorts of operations can be filters, including subqueries
V
and single table predicates.
In the example 1, FILTER applies to the groups that are created by the GROUP BY operation. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 17
e
ns e c li
Concatenation Operation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Concatenation Operation
SELECT * FROM emp WHERE deptno=1 or sal=2; -------------------------------------------------------------------| 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 | | -------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------3 - access("SAL"=2) 4 - filter(LNNVL("SAL"=2)) 5 - access("DEPTNO"=1)
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a CONCATENATION concatenates the rows returned by two or more row sets. This works like S i a Concatenation Operation
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): 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 18
UNION [ALL], INTERSECT, MINUS
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
UNION [ALL], INTERSECT, MINUS
UNION UNION ALL
SORT UNIQUE UNION-ALL INDEX FULL SCAN INDEX FAST FULL SCAN
INTERSECT
INTERSECTION SORT UNIQUE NOSORT INDEX FULL SCAN SORT UNIQUE INDEX FAST FULL SCAN
1 2
3 3
4
1 5
3 3
2
4 5
e
1
3 3
2
4
le
5
b fera
ns e c li
s
n a r t n-
Vij
o1 n a 3 4 MINUS s ฺ ha uid2 e 3 5 ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( INTERSECT, MINUS UNION [ALL], u h a handles duplicate rows with an ALL or DISTINCT modifier in different places in the SQL S i a MINUS SORT UNIQUE NOSORT INDEX FULL SCAN SORT UNIQUE INDEX FAST FULL SCAN
language. ALL preserves duplicates and DISTINCT removes them. Here is a quick description of the possible SQL set operations: •
•
•
•
INTERSECTION: Operation accepting two sets of rows and returning the intersection of 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 matchand-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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 19
Result Cache Operator
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Result Cache Operator
SELECT /*+ RESULT_CACHE */ deptno, AVG(sal) FROM emp GROUP BY deptno;
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL query result cache enables explicit caching of query result sets and query fragments The S i a in database memory. A dedicated memory buffer stored in the shared pool can be used for Result Cache Operator
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 20
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Hash clusters are a better choice than using an indexed table or index cluster when a table is queried frequently with equality queries. a. True b. False
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 21
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The ________ operator uses a temporary table to store intermediate data. a. b. c. d.
Buffer Sort Operator Inlist Min/Max N-Array
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 22
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The following query uses the ________ operator: SELECT * FROM emp WHERE empno IN (7876, 7900, 7902);
a. b. c. d.
Buffer Sort Operator Inlist Min/Max N-Array
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 23
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
A FILTER operation retrieves rows returned by another statement. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 24
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned to: • Describe SQL operators for: – – – – –
•
ahu
Clusters In-List Sorts Filters Set Operations
e
le
Result Cache operators
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 25
s
b fera
ns e c li
Practice 8: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 8: Overview
i a j i V
This practice covers the following topics: • Using different access paths for better optimization – Case 14 to case 16
•
Using the result cache
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Other Optimizer Operators Chapter 8 - Page 26
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
Case Study: noStar a Transformation eฺ has
d
ahu
) Gui m o Chapter c en9t ฺ l i ma Stud g 1@ this 2 y ja use i v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Case Study: Star Transformation
i a j i V
Case Study: Star Transformation
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to: • Define a star schema • Show a star query plan without transformation • Define the star transformation requirements • Show a star query plan after transformation
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 3
ns e c li
The Star Schema Model
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The Star Schema Model Dimension/Lookup table
PRODUCTS
TIMES
Fact table Keys
PROD_ID PROD_NAME PROD_DESC
PROD_ID TIME_ID CHANNEL_ID
SALES CUSTOMERS
AMOUNT_SOLD QUANTITY_SOLD
TIME_ID DAY_NAME CALENDAR_YEAR
e
le
b fera
ns e c li
s n a r -t nCHANNELS
no a CUST_ID s ฺ CHANNEL_ID a e h d Measures ) Gui CHANNEL_DESC CUST_GENDER m CUST_CITY CHANNEL_CLASS o c ent ฺ l i a >>tDimension ud mFact g S 1@ this 2 y ja use i v u to sah
Vij
( u h The a star schema is the simplest data warehouse schema. It is called a star schema because S i the entity-relationship diagram of this schema resembles a star, with points radiating from a a The Star Schema Model
central table. The center of the star consists of one or more fact tables and the points of the star are the dimension tables. A star schema is characterized by one or more very large fact tables that contain the primary information in the data warehouse and a number of much 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 4
The Snowflake Schema Model
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The Snowflake Schema Model
PRODUCTS
TIMES
e
le
SALES
s
n a r t n-
CUSTOMERS
b fera
ns e c li
no a has uideฺCHANNELS ) om nt G COUNTRIES c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a snowflake schema is a more complex data warehouse model than a star schema, and is The S i a a type of star schema. It is called a snowflake schema because the diagram of the schema The Snowflake Schema Model
resembles a snowflake. Snowflake schemas normalize dimensions to eliminate redundancy. That is, the dimension data has been grouped into multiple tables instead of one large table. For example, a product dimension table in a star schema might be normalized into a 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 5
Star Query: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Query: Example SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s,times t,customers c,channels ch 0 1 1 0
WHERE s.time_id = t.time_id AND
e
0 1 1 0
s.cust_id = c.cust_id AND
le
b fera
0 1 1 0
s.channel_id = ch.channel_id AND
ns e c li
s
n a r t n-
c.cust_state_province = 'CA' AND ch.channel_desc IN ('Internet','Catalog') AND t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
Vij
no a has uideฺ ) m tG GROUP BY ch.channel_class, c.cust_city, o c ฺ l t.calendar_quarter_desc; i en a d u gm s St @ 1 hi 2 t y e ija us v u to h a s ( Example Star Query: u h a Consider the star query in the slide. For the star transformation to operate, it is supposed that S i a the sales table of the Sales History schema has bitmap indexes on the time_id, channel_id, and cust_id columns.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 6
Execution Plan Without Star Transformation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Execution Plan Without Star Transformation Hash Join
CHANNELS
Hash Join
TIMES
Hash Join
------------------------------------------| Id | Operation | Name | ------------------------------------------| 0 | SELECT STATEMENT | | | 1 | HASH GROUP BY | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | CHANNELS | |* 4 | HASH JOIN | | |* 5 | TABLE ACCESS FULL | TIMES | |* 6 | HASH JOIN | | |* 7 | TABLE ACCESS FULL| CUSTOMERS | | 8 | TABLE ACCESS FULL| SALES | -------------------------------------------
le
b fera
s
Predicate Information (by operation id): -------------------------------------------2 - access("S"."CHANNEL_ID"="CH"."CHANNEL_ID") 3 - filter("CH"."CHANNEL_DESC"='Catalog' OR "CH"."CHANNEL_DESC"='Internet') 4 - access("S"."TIME_ID"="T"."TIME_ID") 5 - filter("T"."CALENDAR_QUARTER_DESC"='1999-Q1' OR "T"."CALENDAR_QUARTER_DESC"='1999-Q2') 6 - access("S"."CUST_ID"="C"."CUST_ID") 7 - filter("C"."CUST_STATE_PROVINCE"='CA')
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah CUSTOMERS
SALES
( u h a you see the benefits of a star transformation, you should review how a join on a star Before S i a schema is processed without their benefits.
Vij
Execution Plan Without Star Transformation
The fundamental issue with the plan in the slide is that the query always starts joining the SALES table to a dimension table. This results in a very large number of rows that can only be trimmed down by the other parent joins in the execution plan.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 7
e
ns e c li
Star Transformation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation • •
Create bitmap indexes on fact tables foreign keys. Set STAR_TRANSFORMATION_ENABLED to TRUE.
• • •
Requires at least two dimensions and one fact table Gather statistics on all corresponding objects. Carried out in two phases: – First, identify interesting fact rows using bitmap indexes ble based on dimensional filters. a r fe s – Join them to the dimension tables. n a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Star Transformation
ahget the best possible performance for star queries, it is important to follow some basic To S i ija guidelines:
V
•
A bitmap index should be built on each of the foreign key columns of the fact table or tables.
•
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 8
e
ns e c li
•
The second phase joins this result set to the dimension tables. This operation is called a semijoin.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: At least three tables are used in the query (two dimensions and one fact).
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 9
ns e c li
Star Transformation: Considerations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation: Considerations • • • •
Queries containing bind variables are not transformed. Queries referring to remote fact tables are not transformed. Queries containing antijoined tables are not transformed. Queries referring to unmerged nonpartitioned views are not transformed.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a transformation is not supported for tables with any of the following characteristics: Star S i a
Vij
Star Transformation: Considerations •
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 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 10
e
ns e c li
Star Transformation: Rewrite Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation: Rewrite Example Phase 1 SELECT s.amount_sold FROM sales s 0 1 1 0
WHERE time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN('1999-Q1','1999-Q2')) AND
e
0 1 1 0
le
b fera
cust_id IN (SELECT cust_id FROM customers WHERE cust_state_province = 'CA')
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah 0 1 1 0
AND channel_id IN(SELECT channel_id FROM channels WHERE channel_desc IN ('Internet','Catalog'));
Vij
( u h a system processes the query seen earlier in two phases. In the first phase, the system The S i a uses the filters against the dimensional tables to retrieve the dimensional primary keys, which Star Transformation: Rewrite Example
match those filters. Then the system uses those primary keys to probe the bitmap indexes on the foreign key columns of the fact table to identify and retrieve only the necessary rows from the fact table. That is, the system retrieves the result set from the sales table by using 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 11
Retrieving Fact Rows from One Dimension
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Retrieving Fact Rows from One Dimension Phase 1
BITMAP MERGE
One bitmap is Produced.
e
BITMAP KEY ITERATION
le
b fera
ns e c li
s
n a r t n-
no a as idFact Dimension eฺ Table h ) Table m t Gu Bitmap o Access Access c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a slide shows retrieval of fact table rows using only one dimension table. Based on the The S i a corresponding dimension filter predicates, like in t.calendar_quarter_desc IN Retrieving Fact Rows from One Dimension
('1999-Q1','1999-Q2') from the example in the previous slide, the system scans the dimension table, and for each corresponding row, it probes the corresponding fact bitmap index and fetches the corresponding bitmap. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 12
Retrieving Fact Rows from All Dimensions
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Retrieving Fact Rows from All Dimensions Intermediate Result Set (IRS)
Multiple bitmaps are ANDed together.
Phase 1
BITMAP Conversion To Rowids
e
BITMAP AND
le
b fera
ns e c li
s
n a r t n-
no a has… uideฺ … ) MERGE 1 MERGE om nt G MERGE n c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the first phase, the steps mentioned in the previous slide are repeated for each During S i a dimension table. So each BITMAP MERGE in the plan generates a bitmap for a single Retrieving Fact Rows from All Dimensions
dimension table. To identify all rows from the fact table that are of interest, the system must intersect all generated bitmaps. This is to eliminate fact rows that join with one dimension, but not with all of them. This is achieved by performing a very efficient BITMAP AND operation on 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 13
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Joining the Intermediate Result Set with Dimensions
Joining the Intermediate Result Set with Dimensions
Phase 2
Hash Join
Dimension n Table Access
e
Hash Join
le
b fera
ns e c li
s n a r Hash Join -t n o n a has uideฺ ) m tG 1 Fact Table oDimension c ฺ n l Table Access i e a tudAccess From IRS m g sS @ 1 hi 2 t y e ja s uvi to u Dimension i Table Access
h
a s ( u
Joining the Intermediate Result Set with Dimensions
V
ah the result set is determined, the system enters phase 2 of the star transformation After S i ija algorithm. In this phase, it is needed to join the sales data, corresponding to the result set,
with the dimension tables data used to group the rows and pertaining to the query’s select list. Note that the graphic in the slide shows that a hash join is performed between the fact table and its dimensions. Although a hash join is statistically the most-used technique to join rows in a star query, this might not be always true, as this is evaluated by the CBO.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 14
Star Transformation Plan: Example 1
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation Plan: Example 1 SORT GROUP BY HASH JOIN HASH JOIN TABLE ACCESS BY INDEX ROWID SALES BITMAP CONVERSION TO ROWIDS BITMAP AND BITMAP MERGE BITMAP KEY ITERATION BUFFER SORT TABLE ACCESS FULL CHANNELS BITMAP INDEX RANGE SCAN SALES_CHANNELS_BX BITMAP MERGE BITMAP KEY ITERATION BUFFER SORT TABLE ACCESS FULL TIMES BITMAP INDEX RANGE SCAN SALES_TIMES_BX
e
le
b fera
s
n a r t n-
no a as ideฺ h ) … m t Gu o c TABLE ACCESS FULL ilฺCHANNELS en a d TABLE ACCESS FULL TIMES u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a is a possible plan to answer the query shown in the “Execution Plan Without Star This S i a Transformation” section. Note that for formatting purposes, only the channels and times Star Transformation Plan: Example 1
dimensions are shown. It is easy to generalize the case for n dimensions.
Note: It is supposed that sales is not partitioned.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 15
ns e c li
Star Transformation: Further Optimization
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation: Further Optimization • • •
•
In a star transformation execution plan, dimension tables are accessed twice; once for each phase. This might be a performance issue in the case of big dimension tables and low selectivity. If the cost is lower, the system might decide to create a temporary table and use it instead of accessing the same dimension table twice. ble a r e Temporary table’s creation in the plan: nsf
tra n no a LOAD AS SELECT SYS_TEMP_0FD9D6720_BEBDC s eฺ TABLE ACCESS FULL CUSTOMERSha d i ) … m t Gu o c filter("C"."CUST_STATE_PROVINCE"='CA') ilฺ den a m Stu g 1@ this 2 y ja use i v to hu a s ( Star Transformation: Further Optimization u h a you look at the previous execution plan, you see that each dimension table is accessed When S i a twice—once during the first phase, where the system determines the necessary fact table
Vij
rows, and once when joining the fact rows to each dimension table during the second phase. This might be a performance issue if the dimension tables are big, and there is no fast access path to them for solving the problem. In such cases, the system might decide to create 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 16
e
ns e c li
Using Bitmap Join Indexes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Bitmap Join Indexes • • •
Volume of data to be joined is reduced Can be used to eliminate bitwise operations More efficient in storage than MJVs CREATE BITMAP INDEX sales_q_bjx ON sales(times.calendar_quarter_desc) ble a FROM sales, times r e WHERE sales.time_id = times.time_id LOCAL; nsf
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Using Bitmap Join Indexes
ahvolume of data that must be joined can be reduced if the join indexes used have already The S i ija been precalculated.
V
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.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 17
e
ns e c li
Star Transformation Plan: Example 2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation Plan: Example 2
SORT GROUP BY HASH JOIN HASH JOIN TABLE ACCESS BY INDEX ROWID SALES BITMAP CONVERSION TO ROWIDS BITMAP AND BITMAP MERGE BITMAP KEY ITERATION BUFFER SORT TABLE ACCESS FULL CHANNELS 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
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a processing of the same star query using the bitmap join index is similar to the previous The S i a example. The only difference is that the system uses the join index instead of a single-table Star Transformation Plan: Example 2
bitmap index to access the times data in the first phase of the star query.
The difference between this plan as compared to the previous one is that the inner part of the 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')
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 18
Star Transformation Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Star Transformation Hints
i a j i V
• •
•
•
The STAR_TRANSFORMATION hint: Use best plan containing a star transformation, if there is one. The FACT() hint: The hinted table should be considered as the fact table in the context of a star transformation. The NO_FACT () hint: The hinted table should not be considered as the fact table in the context b ofle a r a star transformation. fe s n tra queries The FACT and NO_FACT hints are useful for star n containing more than one fact table. a no
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a• The STAR_TRANSFORMATION hint makes the optimizer use the best plan in which the
Star Transformation Hints
S
transformation has been used. Without the hint, the optimizer could make a cost-based decision to use the best plan generated without the transformation, instead of the best plan for the transformed query. Even if the hint is given, there is no guarantee that the transformation takes place. The optimizer only generates the subqueries 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. •
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 19
e
ns e c li
Bitmap Join Indexes: Join Model 1
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Join Indexes: Join Model 1 c1
pk
fk
e
d
f
CREATE BITMAP INDEX bji ON f(d.c1) FROM f, d WHERE d.pk = f.fk;
le
b fera
ns e c li
s
n a r t n-
no a SELECT sum(f.facts) as ideฺ h ) FROM d, f m t Gu o c WHERE d.pk = f.fk AND ilฺ d.c1 en= 1; a d u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athe following three slides, F represents the fact table, D, the dimension table, PK a primary In S i a Bitmap Join Indexes: Join Model 1 key, and FK a foreign key.
A bitmap join index can be used in the SELECT statement in the slide to avoid the join operation. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 20
Bitmap Join Indexes: Join Model 2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Join Indexes: Join Model 2 c1 c2
pk
fk
e
d
f
le
CREATE BITMAP INDEX bjx ON f(d.c1,d.c2) rab e f s FROM f, d n a r WHERE d.pk = f.fk; n-t
no a SELECT sum(f.facts) as ideฺ h ) FROM d, f m t Gu o c WHERE d.pk = f.fk AND ilฺ d.c1 en= 1 AND d.c2 a d u gm s St @ 1 hi 2 t y e ija us v u to sah
ns e c li
= 1;
Vij
( u h a model in the slide is an extension of model 1, requiring a concatenated bitmap join index The S i a to represent it. Bitmap Join Indexes: Join Model 2
Note that BJX, in this case, can also be used to answer the following select statement: select sum(f.facts) from d,f where d.pk=f.fk and d.c1=1 This is due to the fact that D.C1 is the leading part of the BJX.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 21
Bitmap Join Indexes: Join Model 3
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Join Indexes: Join Model 3 c1
pk
fk1
fk2
pk
c1
e
d1
f
d2
le
CREATE BITMAP INDEX bjx ON f(d1.c1,d2.c1) rab e f s FROM f, d1, d2 n a r WHERE d1.pk = f.fk1 AND d2.pk = f.fk2; n-t
no a SELECT sum(f.sales) as ideฺ h ) FROM d1, f, d2 m t Gu o c WHERE d1.pk = f.fk1ilฺAND d2.pk en == f.fk2 d u d1.c1gm =a 1 AND d2.c1 2; t S 1@ this 2 y ja use i v u to sah
ns e c li
AND
( u h a model also requires the concatenated bitmap join index shown in the slide. In this case, This S i a two dimension tables are used. Bitmap Join Indexes: Join Model 3
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 22
Bitmap Join Indexes: Join Model 4
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bitmap Join Indexes: Join Model 4 c1
pk
c2
pk
fk
e
d1
d2
f
le
CREATE BITMAP INDEX bjx ON f(d1.c1) rab e f s FROM f, d1, d2 n a r WHERE d1.pk = d2.c2 AND d2.pk = f.fk; n-t
no a SELECT sum(f.sales) as ideฺ h ) FROM d1, d2, f m t Gu o c WHERE d1.pk = d2.c2ilฺAND d2.pk en = f.fk a d u d1.c1 = 1; gm s St @ 1 hi 2 t y e ija us v u to sah
ns e c li
AND
Vij
( u h a slide shows a snowflake model that involves joins between two or more dimension tables. The S i a It can be expressed by a bitmap join index. The bitmap join index can be either single or Bitmap Join Indexes: Join Model 4
concatenated depending on the number of columns in the dimension tables to be indexed. A bitmap join index on D1.C1 with a join between D1 and D2 and a join between D2 and F can be created as shown in the slide with BJX.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 23
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
If the star_transformation_enabled parameter is set to true, the optimizer will: a. Always use a star transformation b. Always use a temporary table c. Always consider a star transformation d. Never use a temporary table ble a e. Always use a hash join r fe
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 24
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz Which two of the following properties of the schema structure are required by the optimizer to consider using the star transformation? a. At least one fact table b. At least one bitmap join index c. At least two dimension tables ble d. At least one bind variable a r fe s n e. At least one histogram on a join column ra
t
h
a s ( u
Answer: a, c
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 25
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz Assuming that the START_TRANSFORMATION_ENABLED parameter is set to TRUE, the star transformation is chosen by the optimizer when: a. All the conditions are met b. The cost is lower than a tradition access path c. The bitmap join indexes eliminate additional joins le d. Temporary tables can be used to reduce table accesses rab
e
f s n tra
h
a s ( u
Answer: b
onn a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 26
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Define a star schema • Show a star query plan without transformation • Define the star transformation requirements • Show a star query plan after transformation
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 27
ns e c li
Practice 9: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 9: Overview
i a j i V
This practice covers using the star transformation technique to optimize your query.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Case Study: Star Transformation Chapter 9 - Page 28
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
s
b fera
n a r t n-
Optimizer Statistics no
a ฺ s a Chapterh10 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Statistics
i a j i V
Optimizer Statistics
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to do the following: • Gather optimizer statistics • Gather system statistics • Set statistic preferences • Use dynamic sampling • Manipulate optimizer statistics
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 3
le
b fera
s
n a r t n-
e
ns e c li
Optimizer Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Statistics • •
Describe the database and the objects in the database Information used by the query optimizer to estimate: – – – –
•
Selectivity of predicates Cost of each execution plan Access method, join order, and join method CPU and input/output (I/O) costs
e
Refreshing optimizer statistics whenever they are staleaisble er f as important as gathering them: s n
ns e c li
a
tr – Automatically gathered by the system n o – Manually gathered by the user with DBMS_STATS an
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Optimizer statistics describe details about the database and the objects in the database. a S i These statistics are used by the query optimizer to select the best execution plan for each a Optimizer Statistics 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 by Oracle Database, or you can maintain the optimizer statistics manually using the DBMS_STATS package.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 4
Types of Optimizer Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Types of Optimizer Statistics •
Table statistics:
•
– Number of rows – Number of blocks – Average row length
•
Index Statistics: – – – –
•
B*-tree level Distinct keys Number of leaf blocks Clustering factor
System statistics
Column statistics – Basic: Number of distinct values, number of nulls, average length, min, max – Histograms (data distribution when the column data is skewed) – Extended statistics
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah – I/O performance and utilization – CPU performance and utilization
( u h a of the optimizer statistics are listed in the slide. Most S i a
Vij
Types of Optimizer Statistics
Starting with Oracle Database 10g, index statistics are automatically gathered when the index is created or rebuilt. Note: The statistics mentioned in this slide are optimizer statistics, which are created for query optimization and are stored in the data dictionary. These statistics should not be confused with performance statistics visible through V$ views.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 5
e
ns e c li
Table Statistics (DBA_TAB_STATISTICS)
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Table Statistics (DBA_TAB_STATISTICS) •
Table statistics are used to determine: – Table access cost – Join cardinality – Join order
•
e
Some of the table statistics gathered are: – – – –
Row count (NUM_ROWS) Block count (BLOCKS) Exact Average row length (AVG_ROW_LEN) Statistics status (STALE_STATS)
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a NUM_ROWS S i a This is the basis for cardinality computations. Row count is especially important if the table is Table Statistics (DBA_TAB_STATISTICS)
the driving table of a nested loops join, as it defines how many times the inner table is probed. BLOCKS 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 6
Index Statistics (DBA_IND_STATISTICS)
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Statistics (DBA_IND_STATISTICS) •
Used to decide: – Full table scan versus index scan
•
Statistics gathered are: – B*-tree level (BLEVEL) Exact – Leaf block count (LEAF_BLOCKS) – Clustering factor (CLUSTERING_FACTOR) – Distinct keys (DISTINCT_KEYS)
e
le
b fera
ns e c li
s
n value in – Average number of leaf blocks in which each tdistinct a r the index appears (AVG_LEAF_BLOCKS_PER_KEY ) on-
n a – Average number of data blocks in asthe table eฺpointed to by a d i distinct value in the index m) h u G o t c (AVG_DATA_BLOCKS_PER_KEY ) ilฺ den a m tu (NUM_ROWS) – Number of rows in the S index g 1@ this 2 y ja use i v u to sah
Vij
( u h ageneral, to select an index access, the optimizer requires a predicate on the prefix of the In S i a index columns. However, in case there is no predicate and all the columns referenced in the Index Statistics (DBA_IND_STATISTICS)
query are present in an index, the optimizer considers using a full index scan versus a full table scan. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 7
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
STALE_STATS
i a j i V
This tells you if the statistics are valid in the corresponding index. DISTINCT_KEYS 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, rounded to the nearest integer. For indexes that enforce UNIQUE and PRIMARY KEY constraints, this value is always 1 (one). AVG_DATA_BLOCKS_PER_KEY This is the average number of data blocks in the table that are pointed to by a distinct value in the index rounded to the nearest integer. This statistic is the average number of data blocks that contain rows that contain a given value for the indexed columns. NUM_ROWS It is the number of rows in the index.
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 8
e
ns e c li
Index Clustering Factor
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Index Clustering Factor Must read all blocks to retrieve all As Block 1
Block 2
Block 3
A B C
A B C
A B C
Number of rows (9)
C B A
High clustering factor: Favor alternative paths
e
le
b fera
DBA_IND_STATISTICS.CLUSTERING_FACTOR
ns e c li
s
A B C
n a r t n-
Low clustering factor: Favor the index range scan path
no a as ideฺ h ) A A A B m C u B B C C G o t c Block 1 ilฺ Block 2 en Block 3 a d u mread Sone t block to retrieve all As Only needgto @ s 1 hi 2 t y e ija us v u to sah Number of blocks (3)
Vij
( u h a system performs input/output (I/O) by blocks. Therefore, the optimizer’s decision to use The S i a full table scans is influenced by the percentage of blocks accessed, not rows. When an index Index Clustering Factor
range scan is used, each index entry selected points to a block in the table. If each entry points to a different block, the rows accessed and blocks accessed are the same. Consequently, the desired number of rows could be clustered together in a few blocks, or they 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
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
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 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 following situation: There is a table with 9 rows, there is a nonunique index on col1 for table, the c1 column currently stores the values A, B, and C, and the table only has three data blocks. •
Case 1: If the same rows in the table are arranged so that the index values are scattered across the table blocks (rather than collocated), the index clustering factor is high.
•
Case 2: The index clustering factor is low for the rows as they are collocated in the same block for the same value.
Note: For bitmap indexes, the clustering factor is not applicable and is not used.
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 10
le
b fera
e
ns e c li
Column Statistics (DBA_TAB_COL_STATISTICS)
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Column Statistics (DBA_TAB_COL_STATISTICS) • • • • • • •
Count of distinct values of the column (NUM_DISTINCT) Low value (LOW_VALUE) Exact High value (HIGH_VALUE) Exact Number of nulls (NUM_NULLS) Selectivity estimate for nonpopular values (DENSITY) Number of histogram buckets (NUM_BUCKETS) le b a r Type of histogram (HISTOGRAM) fe
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a NUM_DISTINCT is used in selectivity calculations, for example, 1/Number of Distinct Values S i a
Vij
Column Statistics (DBA_TAB_COL_STATISTICS)
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. 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 11
e
ns e c li
Histograms
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Histograms • •
The optimizer assumes uniform distributions; this may lead to suboptimal access plans in the case of data skew. Histograms: – Store additional column distribution information – Give better selectivity estimates in the case of nonuniform distributions
• •
With unlimited resources you could store each differentable er f value and the number of rows for that value. s n a r t This becomes unmanageable for a large number n- of distinct o n values and a different approach is used: a
s
ฺ
a i≤d#buckets) e – Frequency histogram (#distinct hvalues ) u m t G < #distinct values) – Height-balanced histogram ฺco (#buckets n
il e S @ s i 1 y2 se th a j i v to u u h a s ( Histograms hu Aahistogram captures the distribution of different values in a column, so it yields better S i selectivity estimates. Having histograms on columns that contain skewed data or values with a j i V large variations in the number of duplicates help the query optimizer generate good selectivity •
a tud They are stored in DBA_TAB_HISTOGRAMS. gm
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, 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 12
e
ns e c li
Frequency Histograms
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Frequency Histograms 10 buckets, 10 distinct values Cumulative cardinality 40000 ENDPOINT
# rows for column value
e
30000
NUMBER 20000
le
10000 0
b fera
ns e c li
s
n a r t n-
o n32 a ENDPOINT VALUE:h Column as value eฺ d i ) u m32, 39,t G o c Distinct values: 1, 3, 5, 7, 10,il16, 27, 49 ฺ en a d u Number of rows: 40001 gm s St @ 1 hi 2 t y e ija us v u to sah 1
3
5
7
10
16 27
39 49
Vij
( u h a the example in the slide, assume that you have a column that is populated with 40,001 For S i a numbers. You only have ten distinct values: 1, 3, 5, 7, 10, 16, 27, 32, 39, and 49. Value 10 is Frequency Histograms
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, 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 13
Viewing Frequency Histograms
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Viewing Frequency Histograms BEGIN DBMS_STATS.gather_table_STATS (OWNNAME=>'OE', TABNAME=>'INVENTORIES', METHOD_OPT => 'FOR COLUMNS SIZE 20 warehouse_id'); END; SELECT column_name, num_distinct, num_buckets, histogram FROM USER_TAB_COL_STATISTICS WHERE table_name = 'INVENTORIES' AND column_name = 'WAREHOUSE_ID';
e
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM ------------ ------------ ----------- --------WAREHOUSE_ID 9 9 FREQUENCY
le
b fera
ns e c li
s
SELECT endpoint_number, endpoint_value FROM USER_HISTOGRAMS WHERE table_name = 'INVENTORIES' and column_name = 'WAREHOUSE_ID' ORDER BY endpoint_number;
n a r t n-
Vij
no a ENDPOINT_NUMBER ENDPOINT_VALUE as ideฺ --------------- -------------h ) 36 1 m t Gu o 213 2 c ฺ 261 3 il en a d u … gm s St @ 1 hi 2 t y e ija us v u to h a s (Frequency Histograms Viewing u h a example in the slide shows you how to view a frequency histogram. Because the number The S i a of distinct values in the WAREHOUSE_ID column of the INVENTORIES table is 9, and the number of requested buckets is 20, the system automatically creates a frequency histogram with 9 buckets. You can view this information in the USER_TAB_COL_STATISTICS view. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 14
Height-Balanced Histograms
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Height-Balanced Histograms 5 buckets, 10 distinct values (8000 rows per bucket)
Popular value
1
7
10
10
32
e
49
ENDPOINT VALUE
Same number of rows per bucket
le
b fera
ns e c li
s
n a r t n-
no a eฺ ENDPOINT NUMBER: Bucket hasnumber d i ) u m32, 39, G o t c Distinct values: 1, 3, 5, 7, 10,il16, 27, 49 ฺ en a d u Number of rows: 40001 gm s St @ 1 hi 2 t y e ija us v u to sah 0
1
2
3
4
5
Vij
( u h aa height-balanced histogram, the ordered column values are divided into bands so that In S i a each band contains approximately the same number of rows. The histogram tells you values Height-Balanced Histograms
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 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 15
Viewing Height-Balanced Histograms
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Viewing Height-Balanced Histograms BEGIN DBMS_STATS.gather_table_STATS(OWNNAME =>'OE', TABNAME=>'INVENTORIES', METHOD_OPT => 'FOR COLUMNS SIZE 10 quantity_on_hand'); END; SELECT column_name, num_distinct, num_buckets, histogram FROM USER_TAB_COL_STATISTICS WHERE table_name = 'INVENTORIES' AND column_name = 'QUANTITY_ON_HAND';
e
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM ------------------------------ ------------ ----------- --------------QUANTITY_ON_HAND 237 10 HEIGHT BALANCED
le
b fera
SELECT endpoint_number, endpoint_value FROM USER_HISTOGRAMS WHERE table_name = 'INVENTORIES' and column_name = 'QUANTITY_ON_HAND' ORDER BY endpoint_number;
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
ENDPOINT_NUMBER ENDPOINT_VALUE --------------- -------------0 0 1 27 2 42 3 57 …
Vij
( u h a example in the slide shows you how to view a height-balanced histogram. Because the The S i a number of distinct values in the QUANTITY_ON_HAND column of the INVENTORIES table is Viewing Height-Balanced Histograms
237, and the number of requested buckets is 10, the system automatically creates a heightbalanced histogram with 10 buckets. You can view this information in the USER_TAB_COL_STATISTICS view. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 16
Histogram Considerations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Histogram Considerations • •
Histograms are useful when you have a high degree of skew in the column distribution. Histograms are not useful for: – Columns which do not appear in the WHERE or JOIN clauses – Columns with uniform distributions – Equality predicates with unique columns
• •
e
e
The maximum number of buckets is the least (254,# rabl fe s distinct values). n tra improve Do not use histograms unless they substantially n o performance. an
ns e c li
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Histograms are useful only when they reflect the current data distribution of a given column. S i a The data in the column can change as long as the distribution remains constant. If the data Histogram Considerations
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 17
Multicolumn Statistics: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Multicolumn Statistics: Overview VEHICLE MAKE
MODEL
1
S(MAKE Λ MODEL)=S(MAKE)xS(MODEL)
select dbms_stats.create_extended_stats('jfv','vehicle','(make,model)') from dual;
Vij
le3 b a r method_opt=>'for all columns size 1 for columns (make,model) size fe 3'); s n SYS_STUF3GLKIOP5F4B0BTTCFTMX0W tra n VEHICLE no a MAKE MODELs ha uideฺ4 ) om nt G c ฺ l i aΛ MODEL)=S(MAKE,MODEL) de u m S(MAKE t g sS @ 1 hi 2 t y e ija us v u to h a s ( Statistics: Overview Multicolumn u h a Oracle Database 10g, the query optimizer takes into account the correlation between With S i a columns when computing the selectivity of multiple predicates in the following limited cases: exec dbms_stats.gather_table_stats('jfv','vehicle',-
DBA_STAT_EXTENSIONS
•
If all the columns of a conjunctive predicate match all the columns of a concatenated index key, and the predicates are equalities used in equijoins, then the optimizer uses the number of distinct keys (NDK) in the index for estimating selectivity, as 1/NDK.
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 18
e
ns e c li
2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
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 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. Note •
The CREATE_EXTENDED_STATS function returns a virtual hidden column name, such as SYS_STUW_5RHLX443AN1ZCLPE_GLE4.
•
Based on the example in the slide, the name can be determined by using the following SQL: select dbms_stats.show_extended_stats_name('jfv','vehicle','(make,model) ') from dual
•
s
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 19
le
b fera
After you create the statistics extensions, you can retrieve them by using the ALL|DBA|USER_STAT_EXTENSIONS views.
e
ns e c li
Expression Statistics: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Expression Statistics: Overview CREATE INDEX upperidx ON VEHICLE(upper(MODEL))
VEHICLE
VEHICLE Still possible
MODEL
MODEL
Recommended
S(upper( MODEL))=0.01
DBA_STAT_EXTENSIONS
le
b fera
VEHICLE select dbms_stats.create_extended_stats( 'jfv','vehicle','(upper(model))') from dual;
MODEL
s
n a r t n-
no a has uideฺ ) exec dbms_stats.gather_table_stats('jfv','vehicle',om n(upper(model)) tG ccolumns ฺ l method_opt=>'for all columns size 1ifor size 3'); e a d u gm s St @ 1 hi 2 t y e ija us v u to h a s ( Statistics: Overview Expression u h a Predicates involving expressions on columns are a significant issue for the query optimizer. S i a When computing selectivity on predicates of the form function(Column) = constant, the
Vij
SYS_STU3FOQ$BDH0S_14NGXFJ3TQ50
optimizer assumes a static selectivity value of 1 percent. This approach almost never has the correct selectivity and it may cause the optimizer to produce suboptimal plans.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 20
e
ns e c li
Gathering System Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Gathering System Statistics • • • •
•
System statistics enable the CBO to use CPU and I/O characteristics. System statistics must be gathered on a regular basis; this does not invalidate cached plans. Gathering system statistics equals analyzing system activity for a specified period of time: le Procedures: rab
fe – DBMS_STATS.GATHER_SYSTEM_STATS s n tra – DBMS_STATS.SET_SYSTEM_STATS n o – DBMS_STATS.GET_SYSTEM_STATSa n
has uideฺ ) om nt G c – NOWORKLOAD|INTERVAL ฺ l ai tude – START|STOP gm S @ s i 1 y2 se th a j i v to u u h sa GATHERING_MODE:
( u h a statistics allow the optimizer to consider a system’s I/O and CPU performance, and System S i a utilization. For each candidate plan, the optimizer computes estimates for I/O and CPU costs.
Vij
Gathering System Statistics
It is important to know the system characteristics to select the most efficient plan with optimal proportion between I/O and CPU cost. System CPU and I/O characteristics depend on many factors and do not stay constant all the time. Using system statistics management routines, 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 21
e
ns e c li
When you use the GATHER_SYSTEM_STATS procedure, you should specify the GATHERING_MODE parameter:
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
•
•
NOWORKLOAD: This is the default. This mode captures characteristics of the I/O system. 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 tablespaces. INTERVAL: Captures system activity during a specified interval. This works in combination with the interval parameter that specifies the amount of time for the capture. You should provide an interval value in minutes, after which system statistics are created or updated in the dictionary or a staging table. You can use GATHER_SYSTEM_STATS (gathering_mode=>'STOP') to stop gathering earlier than scheduled. START | STOP: Captures system activity during specified start and stop times, and refreshes the dictionary or a staging table with statistics for the elapsed period.
le b a r Note: Since Oracle Database 10g, Release 2, the system automatically gathers feessential s parts of system statistics at startup. n tra n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( u h a S i a
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 22
e
ns e c li
Gathering System Statistics: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Gathering System Statistics: Example
First day
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( interval => 120, stattab => 'mystats', statid => 'OLTP');
First night
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( interval => 120, stattab => 'mystats', statid => 'OLAP');
ble a r EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS( Next days sfe n stattab => 'mystats', statid => a 'OLTP'); tr n no EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS( a Next nights stattab => 'mystats', eฺ => 'OLAP'); has statid d i ) m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v to hu a s ( System Statistics: Example Gathering u h a example in the slide shows database applications processing OLTP transactions during The S i a the day and running reports at night.
Vij
First, system statistics must be collected during the day. In this example, gathering ends after 120 minutes and is stored in the mystats table. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 23
e
ns e c li
Gathering System Statistics: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Gathering System Statistics: Example •
Start manual system statistics collection in the data dictionary: SQL> EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( 2 gathering_mode => 'START');
• •
Generate the workload. End the collection of system statistics:
le b a r SQL> EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS( -e f s 2 gathering_mode => 'STOP'); n tra n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( System Statistics: Example (continued) Gathering u h a example in the previous slide shows how to collect system statistics with jobs by using The S i a the internal parameter of the DBMS_STATS.GATHER_SYSTEM_STATS procedure. To collect
Vij
system statistics manually, another parameter of this procedure can be used as shown in the slide. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 24
e
ns e c li
Mechanisms for Gathering Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Mechanisms for Gathering Statistics •
Automatic statistics gathering – gather_stats_prog automated task
•
Manual statistics gathering – DBMS_STATS package
• •
Dynamic sampling When statistics are missing:
Selectivity: Equality
1%
Inequality
5%
Other predicates
5%
Table row length
le
b fe20ra
s
n a r t # of distinct values onn Table cardinality a ฺ s a e h table Remote dcardinality i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u # of index leaf blocks
e
ns e c li
25
100 100 2000
h
a s ( u
Mechanisms for Gathering Statistics
V
ah Database provides several mechanisms to gather statistics. These are discussed in Oracle S i ija more detail in the subsequent slides. It is recommended that you use automatic statistics gathering for objects.
Note: When the system encounters a table with missing statistics, it dynamically gathers the necessary statistics needed by the optimizer. However, for certain types of tables, it does not 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 25
Statistic Preferences: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Statistic Preferences: Overview Optimizer statistics gathering task
Statement level Table level
DBA_TAB_STAT_PREFS
Schema level Database level Global level
e
CASCADE DEGREE ESTIMATE_PERCENT METHOD_OPT GRANULARITY NO_INVALIDATE INCREMENTAL PUBLISH
le
b fera
STALE_PERCENT
set_global_prefs set_database_prefs
ns e c li
s
n a r t n-
Vij
no a has uideฺ ) om nt G c ฺ l ai tude exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13'); m g sS @ 1 hi 2 t y e ija us v u to h a s (Preferences: Overview Statistic u h a automated statistics-gathering feature was introduced in Oracle Database 10g, Release 1 The S i a to reduce the burden of maintaining optimizer statistics. However, there were cases where set_schema_prefs set_table_prefs gather_*_stats
you had to disable it and run your own scripts instead. One reason was the lack of object-level control. Whenever you found a small subset of objects for which the default gather statistics options did not work well, you had to lock the statistics and analyze them separately by using 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, Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 26
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). In the graphic in the slide, the last three highlighted options are new in Oracle Database 11g,
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Release 1:
i a j i V
•
•
•
CASCADE gathers statistics on the indexes as well. Index statistics gathering is not parallelized. ESTIMATE_PERCENT is the estimated percentage of rows used to compute statistics (Null means all rows): The valid range is [0.000001,100]. Use the constant DBMS_STATS.AUTO_SAMPLE_SIZE to have the system determine the appropriate sample size for good statistics. This is the recommended default. NO_INVALIDATE controls the invalidation of dependent cursors of the tables for which statistics are being gathered. It does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE. Use DBMS_STATS.AUTO_INVALIDATE to have the system decide when to invalidate dependent cursors. This is the default.
e
ns e c li
ble a r fe or to store PUBLISH is used to decide whether to publish the statistics to the dictionary s n them in a pending area before. tra n STALE_PERCENT is used to determine the threshold level nato which an object is a considered to have stale statistics. The value is a percentage rows modified since the s10 percent ฺofdefault a e last statistics gathering. The example changes the to 13 percent for h d ) Gui m SH.SALES only. o nt c ฺ l i DEGREE determines the degree of a parallelism deused to compute statistics. The default for u m t degree is null, which meansguse the table S default value specified by the DEGREE clause @ s i 1 in the CREATE TABLE or ALTER TABLE statement. Use the constant h 2 t y e DBMS_STATS.DEFAULT_DEGREE to specify the default value based on the initialization ija us v u o parameters. The AUTO_DEGREE value determines the degree of parallelism t h a s automatically. This is either 1 (serial execution) or DEFAULT_DEGREE (the system ( u h default value based on the number of CPUs and initialization parameters), depending on a •
•
•
S
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. INCREMENTAL is used to gather global statistics on partitioned tables in an incremental way.
It is important to note that you can change default values for the above parameters using the DBMS_STATS.SET_GLOBAL_PREFS procedure. Note: You can describe all the effective statistics preference settings for all relevant tables by using the DBA_TAB_STAT_PREFS view.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 27
When to Gather Statistics Manually
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
When to Gather Statistics Manually •
Rely mostly on automatic statistics collection: – Change the frequency of automatic statistics collection to meet your needs. – Remember that STATISTICS_LEVEL should be set to TYPICAL or ALL for automatic statistics collection to work properly.
•
Gather statistics manually for:
e
le
b fera
– Objects that are volatile s n a – Objects modified in batch operations: Gather-statistics as r t n part of the batch operation. no a s objects – External tables, system statistics,afixed eฺ h d i ) u object creation. – New objects: Gather statistics m rightGafter
ns e c li
co ent ฺ l i ma Stud g 1@ this 2 y ja use i v u to
h
a s ( u
When to Gather Statistics Manually
V
ahautomatic statistics gathering mechanism gather statistics on schema objects in the The S i ija database for which statistics are absent or stale. It is important to determine when and how
often to gather new statistics. The default gathering interval is nightly, but you can change this interval to suit your business needs. You can do so by changing the characteristics of your maintenance windows. Some cases may require manual statistics gathering. For example, the 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 28
Manual Statistics Gathering
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Manual Statistics Gathering You can use Enterprise Manager and the DBMS_STATS package to: • Generate and manage statistics for use by the optimizer: – – – –
•
• •
Gather/Modify View/Name Export/Import Delete/Lock
e
le
b fera
ns e c li
s
Gather statistics on: – Indexes, tables, columns, partitions – Object, schema, or database s
n a r t n-
o an ฺ hain parallel de i ) Gather statistics either serially or u om(currently t G not possible in EM) c ฺ n l Gather/Set system statistics i e ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a Enterprise Manager and the DBMS_STATS package enable you to manually generate Both S i a Manual Statistics Gathering
and manage statistics for the optimizer. You can use the DBMS_STATS package to gather, modify, view, export, import, lock, and delete statistics. You can also use this package to identify or name gathered statistics. You can gather statistics on indexes, tables, columns, and partitions at various granularity: object, schema, and database level.
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 29
Manual Statistics Collection: Factors
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Manual Statistics Collection: Factors • • • • • •
Monitor objects for DMLs. Determine the correct sample sizes. Determine the degree of parallelism. Determine if histograms should be used. Determine the cascading effects on indexes. Procedures to use in DBMS_STATS: – – – – – –
e
le
b fera
ns e c li
GATHER_INDEX_STATS s n GATHER_TABLE_STATS a r -t n GATHER_SCHEMA_STATS o n a GATHER_DICTIONARY_STATS as eฺ h d i ) GATHER_DATABASE_STATS m t Gu o c GATHER_SYSTEM_STATS ailฺ den
m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a you manually gather optimizer statistics, you must pay special attention to the following When S i a factors: Manual Statistics Collection: Factors
•
Monitoring objects for mass data manipulation language (DML) operations and gathering statistics if necessary
•
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 30
Managing Statistics Collection: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Managing Statistics Collection: Example dbms_stats.gather_table_stats ('sh' -- schema ,'customers' -- table , null -- partition , 20 -- sample size(%) , false -- block sample? ,'for all columns' -- column spec , 4 -- degree of parallelism
,'default'
-- granularity
le
b fera
s
-- cascade to indexesran
, true );
e
ns e c li
Vij
-t n o dbms_stats.set_param('CASCADE', a n 'DBMS_STATS.AUTO_CASCADE'); has uideฺ ) dbms_stats.set_param('ESTIMATE_PERCENT','5'); om nt G c ฺ l dbms_stats.set_param('DEGREE','NULL'); ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( Statistics Collection: Example Managing u h a first example uses the DBMS_STATS package to gather statistics on the CUSTOMERS table The S i a of the SH schema. It uses some of the options discussed in the previous slides.
Setting Parameter Defaults 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 31
Optimizer Dynamic Sampling: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Dynamic Sampling: Overview •
Dynamic sampling can be done for tables and indexes: – Without statistics – Whose statistics cannot be trusted
•
Used to determine more accurate statistics when estimating: – Table cardinality – Predicate selectivity
e
•
le
b fera
ns e c li
s n a r -t – The OPTIMIZER_DYNAMIC_SAMPLING parameter n o n a – The OPTIMIZER_FEATURES_ENABLE parameter has uideฺ – The DYNAMIC_SAMPLING hint ) om nt G hint c – The DYNAMIC_SAMPLING_EST_CDN ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Feature controlled by:
Vij
( u h a Dynamic sampling improves server performance by determining more accurate selectivity and S i a cardinality estimates that allow the optimizer to produce better performing plans. For example, Optimizer Dynamic Sampling: Overview
although it is recommended that you collect statistics on all of your tables for use by the CBO, you may not gather statistics for your temporary tables and working tables used for intermediate data manipulation. In these cases, the CBO provides a value through a simple 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 32
Optimizer Dynamic Sampling at Work
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Dynamic Sampling at Work • •
Sampling is done at compile time. If a query benefits from dynamic sampling: – A recursive SQL statement is executed to sample data – The number of blocks sampled depends on the OPTIMIZER_DYNAMIC_SAMPLING initialization parameter
• •
During dynamic sampling, predicates are applied to the sample to determine selectivity. ble a r e Use dynamic sampling when: nsf
ra
-t time – Sampling time is a small fraction of the execution n o n – Query is executed many times a s eฺ hafound d – You believe a better plan can) be i u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Optimizer Dynamic Sampling at Work
ahprimary performance attribute is compile time. The system determines at compile time The S i ija whether a query would benefit from dynamic sampling. If so, a recursive SQL statement is
V
issued to scan a small random sample of the table’s blocks, and to apply the relevant single table predicates to estimate predicate selectivities.
Depending on the value of the OPTIMIZER_DYNAMIC_SAMPLING initialization parameter, a 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 33
e
ns e c li
OPTIMIZER_DYNAMIC_SAMPLING
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
OPTIMIZER_DYNAMIC_SAMPLING • • • •
Dynamic session or system parameter Can be set to a value from "0" to "10" "0" turns off dynamic sampling "1" samples all unanalyzed tables, if an unanalyzed table: – Is joined to another table or appears in a subquery or nonmergeable view ble – Has no indexes a r e – Has more than 32 blocks nsf
• • •
tra
"2" samples all unanalyzed tables onn a application The higher the value the more aggressive of s ฺ a e h d ) Gui sampling m o Dynamic sampling isarepeatable ilฺc denift no update activity
m Stu g 1@ this 2 y ja use i v u to sah
( u h a control dynamic sampling with the OPTIMIZER_DYNAMIC_SAMPLING parameter, which can You S i a be set to a value from "0" to "10." A value of "0" means dynamic sampling is not done.
Vij
OPTIMIZER_DYNAMIC_SAMPLING
A value of "1" means dynamic sampling is performed on all unanalyzed tables if the following criteria are met: •
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 34
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: Dynamic sampling is repeatable if no rows have been inserted, deleted, or updated in the table being sampled since the previous sample operation.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 35
ns e c li
Locking Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Locking Statistics • •
Prevents automatic gathering Is mainly used for volatile tables: – Lock without statistics implies dynamic sampling. BEGIN DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS'); DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS'); END;
e
le
– Lock with statistics for representative values.
s
n a r t n-
BEGIN DBMS_STATS.GATHER_TABLE_STATS('OE','ORDERS'); DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS'); END;
•
b fera
ns e c li
no a as ideฺ h ) u locking. The FORCE argument overrides m statistics G o t c n ilฺ FROMdedba_tab_statistics; a SELECT stattype_locked u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a with Oracle Database 10g, you can lock statistics on a specified table with the Starting S i a LOCK_TABLE_STATS procedure of the DBMS_STATS package. You can lock statistics on a Locking Statistics
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 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 36
Restoring Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Restoring Statistics •
Past Statistics may be restored with DBMS_STATS.RESTORE_*_STATS procedures
BEGIN DBMS_STATS.RESTORE_TABLE_STATS( OWNNAME=>'OE', TABNAME=>'INVENTORIES', AS_OF_TIMESTAMP=>'15-JUL-10 09.28.01.597526000 AM -05:00'); END;
•
Statistics are automatically stored – With the timestamp in DBA_TAB_STATS_HISTORY
e
le
b fera
ns e c li
s – When collected with DBMS_STATS procedures ran
-t n o n a – When STATISTICS_LEVEL is set to TYPICAL s ฺ or ALL a e h d ) Gui automatically m o ฺc ebynt – After 31 days or timeildefined a m Stud DBMS_STATS.ALTER_STATS_HISTORY_RETENTION g 1@ this 2 y ja use i v to ahu
•
Statistics are purged
(s u ah
Restoring Statistics
V
Old versions of statistics are saved automatically whenever statistics in dictionary are modified S i ija 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 suboptimal execution plans and the administrator wants to revert to the previous set of statistics. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 37
Export and Import Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Export and Import Statistics Use DBMS_STATS procedures: • CREATE_STAT_TABLE creates the statistics table. • EXPORT_*_STATS moves the statistics to the statistics table. • Use Data Pump to move the statistics table. • IMPORT_*_STATS moves the statistics to data dictionary.
le
expdp impdp
b fera
s
n a r t n-
no a as ideฺ h ) u EXPORT_*_STATS m IMPORT_*_STATS G o t c ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah
( u h a can export and import statistics from the data dictionary to user-owned tables, enabling You S i a you to create multiple versions of statistics for the same schema. You can also copy statistics
Vij
Export and Import Statistics
from one database to another database. You may want to do this to copy the statistics from a production database to a scaled-down test database. Before exporting statistics, you first need to create a table for holding the statistics. The 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 38
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
When there are no statistics for an object being used in a SQL statement, the optimizer uses: a. Rule-based optimization b. Dynamic sampling c. Fixed values d. Statistics gathered during parse phase ble a e. Random values r fe
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b, c
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 39
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The optimizer depends on accurate statistics to produce the best execution plans. The automatic statistics gathering (AGS) task does not gather statistics on everything. Which objects require you to gather statistics manually? a. External tables b. Data dictionary ble c. Fixed objects a r fe s d. Volatile tables n tra n e. System statistics o
n a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a, c, e
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 40
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz There is a very volatile table in the database. The size of the table changes by more than 50% daily. What steps are part of the procedure to force dynamic sampling? a. Delete statistics. b. Lock statistics. c. Gather statistics when the table is at its largest. ble d. Set DYNAMIC_SAMPLING=9. a r fe s n e. Set DYNAMIC_SAMPLING=0. tra n f. Allow the DYNAMIC_SAMPLING parameter no to default.
a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Answer: a, b, f
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 41
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Collect optimizer statistics • Collect system statistics • Set statistic preferences • Use dynamic sampling • Manipulate optimizer statistics
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 42
ns e c li
Practice 10: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 10: Overview
i a j i V
This practice covers the following topics: • Using system statistics • Using automatic statistics gathering
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 43
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Optimizer Statistics Chapter 10 - Page 44
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
s
b fera
n a r t n-
o Using BindnVariables
a ฺ s a Chapterh11 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Bind Variables
i a j i V
Using Bind Variables
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to: • List the benefits of using bind variables • Use bind peeking • Use adaptive cursor sharing
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 3
ns e c li
Cursor Sharing and Different Literal Values
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cursor Sharing and Different Literal Values SELECT * FROM jobs WHERE min_salary > 12000; SELECT * FROM jobs WHERE min_salary > 18000; SELECT * FROM jobs WHERE min_salary > 7500;
e
le
Cursor sharing
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ Library cache l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Ifayour SQL statements use literal values for the WHERE clause conditions, there will be many S i a versions of almost identical SQL stored in the library cache. For each different SQL statement, Cursor Sharing and Different Literal Values
the optimizer must perform all the steps for processing a new SQL statement. This may also cause the library cache to fill up quickly because of all the different statements stored in it.
When coded this way, you are not taking advantage of cursor sharing. If the cursor is shared 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 4
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: In the case of the example in the slide, V$SQL.PLAN_HASH_VALUE is identical for the first and third query.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 5
ns e c li
Cursor Sharing and Bind Variables
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cursor Sharing and Bind Variables 12000
SELECT * FROM jobs WHERE min_salary > :min_sal;
18000
SELECT * FROM jobs WHERE min_salary > :min_sal;
17500
SELECT * FROM jobs WHERE min_salary > :min_sal;
e
le
Cursor sharing
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l Library cache ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h ainstead of issuing different statements for each literal, you use a bind variable, then that If, S i a extra parse activity is eliminated (in theory). This is because the optimizer recognizes that the Cursor Sharing and Bind Variables
statement is already parsed and decides to reuse the same execution plan even though you specified different bind values the next time you execute the same statement.
In the example in the slide, the bind variable is called min_sal. It is to be compared with the 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 6
Bind Variables in SQL*Plus
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bind Variables in SQL*Plus SQL> variable job_id varchar2(10) SQL> exec :job_id := 'SA_REP'; PL/SQL procedure successfully completed. SQL> select count(*) from employees where job_id = :job_id;
e
COUNT(*) ---------30
le
SQL> exec :job_id := 'AD_VP';
b fera
ns e c li
s
n a r t n-
Vij
no a SQL> select count(*) from employees where s job_id ฺ = :job_id; a e h d ) Gui m COUNT(*) o ilฺc dent ---------a m Stu 2 g 1@ this 2 y ja use i v to hu a s ( Bind Variables in SQL*Plus u h a variables can be used in SQL*Plus sessions. In SQL*Plus, use the VARIABLE command Bind S i a to define a bind variable. Then, you can assign values to the variable by executing an PL/SQL procedure successfully completed.
assignment statement with the EXEC[UTE] command. Any references to that variable from then on use the value you assigned.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 7
Bind Variables in Enterprise Manager
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bind Variables in Enterprise Manager
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the SQL Worksheet page of Enterprise Manager (see the SQL Worksheet link in the On S i a Related Links region of the Database Home page), you can specify that a SQL statement Bind Variables in Enterprise Manager
should use bind variables. You can do this by selecting the "Use bind variables for execution" check box. When you select that, several fields are generated, where you can enter bind variable values. Refer to these values in the SQL statement using variable names that begin 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 8
Bind Variables in SQL Developer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bind Variables in SQL Developer
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the SQL Worksheet pane of SQL, you can specify that a SQL statement that uses bind On S i a variables. When you execute the statement , the Enter Binds dialog appears where you can Bind Variables in SQL Developer
enter bind variable values. Refer to these values in the SQL statement using variable names that begin with a colon. Select each bind variable in turn to enter a value for that variable.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 9
Bind Variable Peeking
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bind Variable Peeking SELECT * FROM jobs WHERE min_salary > :min_sal
Plan A
12000
First time you execute
e
le
b fera
s n a r -t min_sal=12000 n o n a Next time you execute has uideฺ ) om nt G c ฺ l SELECT * FROM jobsaWHERE min_salary > :min_sal i de u m t g sS @ 1 hi 2 t y e ija us v u to sah
ns e c li
18000
Vij
( u h a literals are used in a query, those literal values can be used by the optimizer to decide When S i a on the best plan. However, when bind variables are used, the optimizer still needs to select Bind Variable Peeking
the best plan based on the values of the conditions in the query, but cannot see those values readily in the SQL text. That means, as a SQL statement is parsed, the system needs to be able to see the value of the bind variables, to ensure that a good plan that would suit those 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 10
Bind Variable Peeking
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Bind Variable Peeking SELECT * FROM jobs WHERE min_salary > :min_sal
1
min_sal=12000
2
e
min_sal=18000
le
3
min_sal=7500
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ Plan A l e aialways dappropriate One planm not for all bind values u t g S 1@ this 2 y ja use i v u to sah
Vij
( u h a some conditions, bind variable peeking can cause the optimizer to select the Under S i a suboptimal plan. This occurs because the first value of the bind variable is used to determine Bind Variable Peeking (continued)
the plan for all subsequent executions of the query. Therefore, even though subsequent executions provide different bind values, the same plan is used. It is possible that a different plan would be better for executions that have different bind variable values. An example is 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 11
Cursor Sharing Enhancements
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Cursor Sharing Enhancements • • •
Oracle8i introduced the possibility of sharing SQL statements that differ only in literal values. Oracle9i extends this feature by limiting it to similar statements only, instead of forcing it. Similar: Regardless of the literal value, same execution plan SQL> SELECT * FROM employees 2 WHERE employee_id = 153;
•
e
le
b fera
ns e c li
s
n a r t n-
Not similar: Possible different execution plans o for different n literal values sa ฺ
ha uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah SQL> SELECT * FROM employees 2 WHERE department_id = 50;
Vij
( u h a Oracle8i introduced the possibility of sharing SQL statements that differ only in literal values. S i a Rather than developing an execution plan each time the same statement—with a different Cursor Sharing Enhancements
literal value—is executed, the optimizer generates a common execution plan used for all subsequent executions of the statement.
Because only one execution plan is used instead of potential different ones, this feature 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.
Using Bind Variables Chapter 11 - Page 12
SQL> SELECT * FROM employees WHERE department_id = 70;
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using only one execution plan for sharing the same cursor would not be safe if you have histogram statistics (and there is skew in the data) on the DEPARTMENT_ID column. In this case, depending on which statement was executed first, the execution plan could contain a full table (or fast full index) scan, or it could use a simple index range scan.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 13
ns e c li
The CURSOR_SHARING Parameter
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The CURSOR_SHARING Parameter •
The CURSOR_SHARING parameter values: – FORCE – EXACT (default) – SIMILAR
•
CURSOR_SHARING can be changed using: – ALTER SYSTEM – ALTER SESSION – Initialization parameter files
•
The CURSOR_SHARING_EXACT hint
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a value of the CURSOR_SHARING initialization parameter determines how the optimizer The S i a The CURSOR_SHARING Parameter
processes statements with bind variables: •
EXACT: Literal replacement disabled completely
•
FORCE: Causes sharing for all literals
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 14
Forcing Cursor Sharing: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Forcing Cursor Sharing: Example SQL> alter session set cursor_sharing = FORCE; SELECT * FROM jobs WHERE min_salary > 12000; SELECT * FROM jobs WHERE min_salary > 18000; SELECT * FROM jobs WHERE min_salary > 7500;
e
le
b fera
SELECT * FROM jobs WHERE min_salary > :"SYS_B_0"
ns e c li
s
n a r t n-
no a has uideฺSystem-generated ) bind variable om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Because you forced cursor sharing with the ALTER SESSION command, all your queries that S i a differ only with literal values are automatically rewritten to use the same system-generated Forcing Cursor Sharing: Example
bind variable called SYS_B_0 in the example in the slide. As a result, you end up with only one child cursor instead of three.
Note: Adaptive cursor sharing may also apply, and might generate a second child cursor in this case.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 15
Adaptive Cursor Sharing: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Adaptive Cursor Sharing: Overview Adaptive cursor sharing: • Allows for intelligent cursor sharing for statements that use bind variables • Is used to compromise between cursor sharing and optimization • Has the following benefits:
le
– Automatically detects when different executions would rab fe benefit from different execution plans s n traa minimum – Limits the number of generated child cursors to n o – Provides an automated mechanism that a ncannot be turned off
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a variables were designed to allow the Oracle Database to share a single cursor for Bind S i a multiple SQL statements to reduce the amount of shared memory used to parse SQL
Vij
Adaptive Cursor Sharing: Overview
statements. However, cursor sharing and SQL optimization are conflicting goals. Writing a SQL statement with literals provides more information for the optimizer and naturally leads to better execution plans, while increasing memory and CPU overhead caused by excessive 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 16
e
ns e c li
Adaptive Cursor Sharing: Architecture
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Adaptive Cursor Sharing: Architecture Bind-sensitive cursor
System observes statement for a while.
11
SELECT * FROM emp WHERE sal = :1 and dept = :2
Bind-aware cursor Initial selectivity cube
Initial plan GB
S o f t
HJ
0.0025
HJ
.
No need for new plan
Same selectivity cube
P a r s e
GB HJ 0.003
0.15
.
Merged selectivity cubes
No need for new plan
:1=C & :2=D S(:1)=0.18 ∧ S(:2)=0.003
P a r s e
0.004
GB
GB
HJ
HJ
HJ
HJ
Cubes merged
H a r d
0.009
P a r s e
0.28
ns e c li
s
n a r t n-
Second selectivity cube
no. a . 4 has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah H a r d
le
b fera
0.18
:1=A & :2=B S(:1)=0.15 ∧ S(:2)=0.0025
e
2
HJ
Need new plan GB
GB
HJ
HJ
HJ
HJ
3
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
Vij
( u h a you use adaptive cursor sharing, the following steps take place in the scenario When S i a illustrated in the slide: Adaptive Cursor Sharing: Architecture
1. The cursor starts its life with a hard parse, as usual. If bind peeking takes place, and a histogram is used to compute selectivity of the predicate containing the bind variable, then the cursor is marked as a bind-sensitive cursor. In addition, some information is 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.
Using Bind Variables Chapter 11 - Page 17
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
matching, and because the selectivity is within an existing cube, the statement uses the existing child cursor’s execution plan to run.
i a j i V
3. On the next soft parse of this query, suppose that the selectivity of the predicate with the 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 executes, the system stores the bind values and execution statistics in the cursor. 4. On the next soft parse of this query, suppose the selectivity of the predicate with the new set of bind values is now (0.28,0.004). Because that selectivity is not within one of the existing cubes, the system does a hard parse. Suppose that this time, the hard parse generates the same execution plan as the first one. Because the plan is the same as the first child cursor, both child cursors are merged. That is, both cubes are merged into a new bigger cube, and one of the child cursors is deleted. The next time there is a soft parse, if the selectivity falls within the new cube, the child cursor matches.
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 18
e
ns e c li
Adaptive Cursor Sharing: Views
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Adaptive Cursor Sharing: Views The following views provide information about adaptive cursor sharing usage: V$SQL
Two new columns show whether a cursor is bind sensitive or bind aware.
V$SQL_CS_HISTOGRAM
Shows the distribution of the execution count across the execution history histogram
V$SQL_CS_SELECTIVITY
e
le
b fera
ns e c li
s
n a r t n-
Shows the selectivity cubes stored for every predicate containing a bind variable and whose selectivity is used in the cursor sharing checks
Vij
no a has uideฺ ) statistics of a cursor V$SQL_CS_STATISTICS mShowst execution G o c ilฺ dusing endifferent bind sets a u gm s St @ 1 hi 2 t y e ija us v u to h a s (Cursor Sharing: Views Adaptive u h a views determine whether a query is bind aware or not, and is handled automatically, These S i a without any user input. However, information about what goes on is exposed through V$ views so that you can diagnose problems, if any. New columns have been added to V$SQL: •
•
•
•
IS_BIND_SENSITIVE: Indicates if a cursor is bind sensitive; value YES | NO. A query for 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 threebucket 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 19
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
•
i a j i V
V$SQL_CS_STATISTICS: Adaptive cursor sharing monitors execution of a query and collects information about it for a while, and uses this information to decide whether to switch to using bind-aware cursor sharing for the query. This view summarizes the information that it collects to make this decision. For a sample of executions, it keeps 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.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 20
ns e c li
Adaptive Cursor Sharing: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Adaptive Cursor Sharing: Example SQL> variable job varchar2(6) SQL> exec :job := 'AD_ASST' SQL> select count(*), max(salary) from emp where job_id=:job; Selectivity
Plan A
Plan B
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude 'SA_REP' 'AD_ASST' m g S 1@ this 2 y ja use i v u to sah
Vij
( u h a Consider the data in the slide. There are histogram statistics on the JOB_ID column, showing S i a Adaptive Cursor Sharing: Example
that there are many thousands times more occurrences of SA_REP than AD_ASST. In this case, if literals were used instead of a bind variable, the query optimizer would see that the AD_ASST value occurs in less than 1% of the rows, whereas the SA_REP value occurs in approximately a third of the rows. If the table has over a million rows in it, the execution plans 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 21
Interacting with Adaptive Cursor Sharing
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Interacting with Adaptive Cursor Sharing •
CURSOR_SHARING: – If CURSOR_SHARING EXACT, statements containing literals may be rewritten using bind variables. – If statements are rewritten, adaptive cursor sharing may apply to them.
•
SQL Plan Management (SPM):
– If OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is set to ble a r TRUE, only the first generated plan is used. fe s n – As a workaround, set this parameter to FALSE, traand run your n application until all plans are loaded in the nocursor cache. a – Manually load the cursor cache into plan ฺ as theidcorresponding e h ) baseline. u m
co ent G ฺ l i ma Stud g 1@ this 2 y ja use i v u to
h
a s ( u
Interacting with Adaptive Cursor Sharing
h Adaptive cursor sharing is independent of the CURSOR_SHARING parameter. The setting
a• S i ija
V
•
of this parameter determines whether literals are replaced by the system-generated bind variables. If they are, adaptive cursor sharing behaves just as it would if the user supplied binds to begin with. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 22
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz Which three statements are true about applications that are coded with literals in the SQL statements rather than bind variables? a. More shared pool space is required for cursors. b. Less shared pool space is required for cursors. c. Histograms are used if available. ble d. Histograms are not used. a r fe s n e. No parsing is required for literal values. tra n f. Every different literal value requires parsing. no
a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Answer: a, c, f
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 23
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz The CURSOR_SHARING parameter should be set to ________ for systems with large tables and long-running queries such as a data warehouse. a. Similar b. Force c. Exact ble d. Literal a r fe s n e. True tra n f. False no
h
a s ( u
Answer: c
a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 24
e
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Adaptive Cursor Sharing can be turned off by setting the CURSOR_SHARING parameter to FALSE. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 25
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • List the benefits of using bind variables • Use bind peeking • Use adaptive cursor sharing
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 26
ns e c li
Practice 11: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 11: Overview
i a j i V
This practice covers the following topics: • Using adaptive cursor sharing and bind peeking • Using the CURSOR_SHARING initialization parameter
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 27
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Bind Variables Chapter 11 - Page 28
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
s
b fera
n a r t n-
SQL Tuningno Advisor
a ฺ s a Chapterh12 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Advisor
i a j i V
SQL Tuning Advisor
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to do the following: • Describe statement profiling • Use SQL Tuning Advisor
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 3
ns e c li
Tuning SQL Statements Automatically
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Tuning SQL Statements Automatically • •
Tuning SQL statements automatically eases the entire SQL tuning process and replaces manual SQL tuning. Optimizer modes: – Normal mode – Tuning mode or Automatic Tuning Optimizer (ATO)
• •
SQL Tuning Advisor is used to access tuning mode. e You should use tuning mode only for high-load SQL rabl e statements. nsf
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Tuning SQL Statements Automatically
Tuning ah SQL statements automatically is the capability of the query optimizer to automate the S i ija entire SQL tuning process. This automatic process replaces manual SQL tuning, which is a
V
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 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 4
e
ns e c li
Application Tuning Challenges
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Application Tuning Challenges
How can I tune my high-load SQL?
I can do it for you!
e
SQL workload
le
b fera
ns e c li
s
n a r t n-
no a as ideฺ h ) High-load m t Gu o c SQL ilฺ den a m Stu g 1@ this 2 y ja use i v u to sah ADDM
SQL Tuning Advisor
Vij
( u h a process of identifying high-load SQL statements and tuning them is very challenging even The S i a for an expert. SQL tuning is not only one of the most critical aspects of managing the Application Tuning Challenges
performance of a database server, but also one of the most difficult tasks to accomplish. Starting with Oracle Database 10g, the task of identifying high-load SQL statements has been automated by Automatic Database Diagnostic Monitor (ADDM). Even though the number of 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 5
SQL Tuning Advisor: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Advisor: Overview
Statistics Check optimization mode
Detect stale or missing statistics.
Plan Tuning optimization mode
Plan tuning (SQL Profile).
Access Analysis optimization mode
Add missing index. Run Access Advisor.
e
le
b fera
ns e c li
s
n a r t n-
o nRestructure SQL. a s ฺ a e ) h Guid m co ent ฺ l i Automatic Tuning Comprehensive a tud m Optimizer SQL tuning g sS @ 1 hi 2 t y e ija us v u to sah SQL Analysis optimization mode
SQL Tuning Advisor
Vij
( u h a Tuning Advisor is primarily the driver of the tuning process. It calls Automatic Tuning SQL S i a Optimizer (ATO) to perform the following four specific types of analysis: SQL Tuning Advisor: Overview
•
Statistics Analysis: ATO checks each query object for missing or stale statistics and makes a recommendation to gather relevant statistics. It also collects auxiliary information to supply missing statistics or correct stale statistics in case 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 6
Stale or Missing Object Statistics
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Stale or Missing Object Statistics • • •
Object statistics are key inputs to the optimizer. ATO verifies object statistics for each query object. ATO uses dynamic sampling and generates: – Auxiliary object statistics to compensate for missing or stale object statistics – Recommendations to gather object statistics where appropriate: ble
ra
fe s n a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
EXEC DBMS_STATS.GATHER_TABLE_STATS( ownname=>'SH', tabname=>'CUSTOMERS', estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
h
a s ( u
Stale or Missing Object Statistics
ahquery optimizer relies on object statistics to generate execution plans. If these statistics The S i ija are stale or missing, the optimizer does not have the necessary information it needs and can
V
generate suboptimal execution plans.
ATO checks each query object for missing or stale statistics and produces two types of outputs: •
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 7
e
ns e c li
SQL Statement Profiling
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Statement Profiling • •
Statement statistics are key inputs to the optimizer. ATO verifies statement statistics such as: – Predicate selectivity – Optimizer settings (FIRST_ROWS versus ALL_ROWS)
•
•
e
Automatic Tuning Optimizer uses: – Dynamic sampling ble – Partial execution of the statement a r fe – Past execution history statistics of the statementans
ns e c li
tr
ATO builds a profile if statistics were generated: on-
n a has- uideฺ exec :profile_name := ) dbms_sqltune.accept_sql_profile( om nt G c ฺ l i e task_name =>'my_sql_tuning_task'); ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a main verification step during SQL Profiling is the verification of the query optimizer’s own The S i a estimates of cost, selectivity, and cardinality for the statement that is tuned. SQL Statement Profiling
During SQL Profiling, ATO performs verification steps to validate its own estimates. The validation consists of taking a sample of data and applying appropriate predicates to the sample. The new estimate is compared to the regular estimate, and if the difference is large 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 8
Plan Tuning Flow and SQL Profile Creation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Plan Tuning Flow and SQL Profile Creation
Submit
Optimizer
Create
(Tuning mode)
SQL Tuning Advisor
SQL Profile
e
le
b fera
Use
ns e c li
s
No application code change Optimizer
n a r t n-
no a has uideฺ ) om nt G Database c ฺ l users ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Output
(Normal mode)
Well-tuned plan
Vij
( u h AaSQL Profile is a collection of auxiliary information that is built during automatic tuning of a S i a SQL statement. Thus, a SQL Profile is to a SQL statement what statistics are to a table or Plan Tuning Flow and SQL Profile Creation
index. After it is created, a SQL Profile is used in conjunction with the existing statistics by the query optimizer, in normal mode, to produce a well-tuned plan for the corresponding SQL statement. A SQL Profile is stored persistently in the data dictionary. However, the SQL profile 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 9
SQL Tuning Loop
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Loop
Workload Generate profiles
High load
SQL Tuning Advisor
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ADDM ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a auxiliary information contained in a SQL Profile is stored in such a way that it stays The S i a relevant after database changes, such as addition or removal of indexes, growth in the size of SQL Tuning Loop
tables, and periodic collection of database statistics. Therefore, when a profile is created, the corresponding plan is not frozen (as when outlines are used). However, a SQL Profile may not adapt to massive changes in the database or changes that 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 10
Access Path Analysis
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Access Path Analysis SQL Tuning Advisor
Significant performance gain
e
SQL Access Advisor
Workload
le
b fera
ns e c li
Vij
s n a r Comprehensive -t n o index n analysis a Indexes has uideฺ ) om nt G c ฺ l Indexes ai tudone JFV.TEST("C"); CREATE INDEX JFV.IDX$_00002 m g sS @ 1 hi 2 t y e ija us v u to h a s ( Analysis Access Path u h a also provides advice on indexes. Effective indexing is a well-known tuning technique that ATO S i a can significantly improve the performance of SQL statements by reducing the need for full table scans. Any index recommendations generated by ATO are specific to the SQL statement being tuned. Therefore, it provides a quick solution to the performance problem associated with a single SQL statement.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 11
SQL Structure Analysis
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Structure Analysis
Poorly written SQL statement
How can I rewrite it?
e
Restructured SQL statement SQL constructs Type mismatch and indexes
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ Design mistakes ) m tG SQL Tuning o c ฺ l Advisor i en a d u gm s St @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a goal of the SQL Structure Analysis is to help you identify poorly written SQL statements The S i a as well as to advise you on how to restructure them. SQL Structure Analysis
There are certain syntax variations that are known to have a negative impact on performance. In this mode, ATO evaluates statements against a set of rules, identifying less efficient coding techniques, and providing recommendations for an alternative statement where possible. The 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)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 12
SQL Tuning Advisor: Usage Model
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Advisor: Usage Model Automatic selection AWR
ADDM
High-load SQL
Sources AWR
Manual Selection
SQL Tuning Advisor
e
le
b fera
ns e c li
s
n a r t n-
no a Cursor cache eฺ has uidFilter ) om nt G c ฺ l ai tude Custom m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Tuning Advisor takes one or more SQL statements as input. The input can come from SQL S i a different sources: SQL Tuning Advisor: Usage Model
•
High-load SQL statements identified by ADDM
•
SQL statements that are currently in cursor cache
•
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.
SQL Tuning Advisor Chapter 12 - Page 13
Database Control and SQL Tuning Advisor
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Database Control and SQL Tuning Advisor
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a easiest way to access the SQL Tuning Advisor from Enterprise Manager is on the Advisor The S i a Central page. On the Home page, click the Advisor Central link located in the Related Links Database Control and SQL Tuning Advisor section to open the Advisor Central page.
On the Advisor Central page, click the SQL Advisors link. On the SQL Advisors page, click the SQL Tuning Advisor link. This takes you to the Schedule SQL Tuning Advisor page. On this page, you find links to various other pages. You click the Top Activity link to open the Top Activity page.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 14
Running SQL Tuning Advisor: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Running SQL Tuning Advisor: Example
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can use Database Control to identify the high-load or top SQL statements. There are You S i a several locations in Database Control from where SQL Tuning Advisor can be launched with Running SQL Tuning Advisor: Example
the identified SQL statement or statements, or an STS: •
Tuning ADDM-identified SQL statements: The ADDM Finding Details page shows high-load SQL statements identified by ADDM. Each of these high-load SQL statements 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 15
Schedule SQL Tuning Advisor
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Schedule SQL Tuning Advisor
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL Tuning Advisor is launched, Enterprise Manager automatically creates a tuning When S i a task, provided the user has the appropriate ADVISOR privilege to do so. Enterprise Manager Schedule SQL Tuning Advisor
shows the tuning task with automatic defaults on the Schedule SQL Tuning Advisor page. On this page, the user can change the automatic defaults pertaining to a tuning task. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 16
Implementing Recommendations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Implementing Recommendations
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the recommendations page, you can view the various recommendations. For each On S i a recommendation, as shown, a SQL Profile has been created; you can implement it if you Implementing Recommendations
want, after you view the new plan. Click the eyeglass icon to view the Compare Explain Plan page.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 17
Compare Explain Plan
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Compare Explain Plan
e
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Compare explain Plan page give you the opportunity to view the projected benefits of The S i a implementing the recommendation, in this case a SQL profile. You can see the benefits Compare Explain Plan
graphically and in a table. Notice the Cost values for the SQL statement in the original and new explain plans. If the difference is not enough or the explain is not acceptable, the recommendation can ignored or deleted.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 18
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz SQL Tuning Advisor will recommend: a. SQL Profiles b. Additional Indexes c. Deleting Indexes d. Rewriting SQL Statements e. All of the above
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Tuning Advisor in comprehensive mode recommends all except deleting indexes. SQL SQL S i a Tuning Advisor focuses on one SQL statement at a time. An entire workload must be Answer: a, b, d
considered to determine if deleting an index will help performance.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 19
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
The SQL Profile will force the best execution plan even when the data in the table changes. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 20
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned the following: • Statement profiling • SQL Tuning Advisor
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 21
ns e c li
Practice 12: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 12: Overview
i a j i V
This practice covers using ADDM and SQL Tuning Advisor to tune your SQL statements
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Tuning Advisor Chapter 12 - Page 22
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
o Using SQL nAccess Advisor
a ฺ s a Chapterh13 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using SQL Access Advisor
i a j i V
Using SQL Access Advisor
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to use SQL Access Advisor.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 3
ns e c li
SQL Access Advisor: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Overview What partitions, indexes, and MVs do I need to optimize my entire workload?
SQL Access Advisor
Solution
e
le
b fera
ns e c li
s
No expertise required
n a r t n-
no a has uProvides deฺ i ) G om nt implementation c ฺ script l i e a d u gm s St @ 1 hi 2 t y e ija us v u to sah Workload
Component of CBO
Vij
( u h Defining appropriate access structures to optimize SQL queries has always been a concern a S i for the developer. As a result, there have been many papers and scripts written as well as a SQL Access Advisor: Overview
high-end tools developed to address the matter. In addition, with the development of partitioning and materialized view technology, deciding on access structures has become even more complex.
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.
Using SQL Access Advisor Chapter 13 - Page 4
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Provides simple, user-friendly GUI wizards
•
Generates scripts for implementation of recommendations
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 5
ns e c li
SQL Access Advisor: Usage Model
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Usage Model SQL Access Advisor SQL cache Workload
Hypothetical
e
STS
le
Filter Options
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l e Indexes Materialized ai tudMaterialized m views views log g sS @ i 1 y2 se th a j i v to u u h sa
Partitioned objects
Vij
( u h a Access Advisor takes as input a workload that can be derived from multiple sources: SQL S i a SQL Access Advisor: Usage Model •
SQL cache, to take the current content of V$SQL
•
Hypothetical, to generate a likely workload from your dimensional model. This option is interesting when your system is being initially designed.
•
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 6
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
•
Combines similar indexes into a single index
•
Generates recommendations that support multiple workload queries
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 7
ns e c li
Possible Recommendations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Possible Recommendations Recommendation
Comprehensive
Limited
Add new (partitioned) index on table or materialized view.
YES
YES
Drop an unused index.
YES
NO
Modify an existing index by changing the index type.
YES
NO
Modify an existing index by adding columns at the end.
YES
YES
Add a new (partitioned) materialized view.
YES
YES
Drop an unused materialized view (log).
YES
Add a new materialized view log. Modify an existing materialized view log to add new columns or clauses.
s
n a r t nYES YES
NO ble a r fe YES
YES
no a Partition an existing unpartitioned table or index. YES has uideฺ YES ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s (Recommendations Possible u h a Access Advisor carefully considers the overall impact of recommendations and makes i SSQL
Vija
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 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 8
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 9
ns e c li
SQL Access Advisor Session: Initial Options
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor Session: Initial Options
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a next few slides describe a typical SQL Access Advisor session. You can access the SQL The S i a Access Advisor by clicking the Advisor Central link on the Database Home page or through SQL Access Advisor Session: Initial Options
individual alerts or performance pages that may include a link to facilitate solving a performance problem. The SQL Access Advisor consists of several steps during which you supply the SQL statements to tune and the types of access methods you want to use. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 10
SQL Access Advisor Session: Initial Options
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor Session: Initial Options
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Ifayou select the "Inherit Options from a Task or Template" option on the Initial Options page, S i a you can select an existing task, or an existing template to inherit SQL Access Advisor’s SQL Access Advisor Session: Initial Options (continued)
options. By default, the SQLACCESS_EMTASK template is used.
You can view the various options defined by a task or a template by selecting the corresponding object and clicking View Options.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 11
SQL Access Advisor: Workload Source
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Workload Source
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can select your workload source from three different sources: You S i a SQL Access Advisor: Workload Source •
Current and Recent SQL Activity: This source corresponds to SQL statements that are still cached in your System Global Area (SGA).
•
Use an existing SQL Tuning Set: You also have the possibility of creating and using a 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 12
SQL Access Advisor: Recommendation Options
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Recommendation Options
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the Recommendations Options page, you can select whether to limit the SQL Access On S i a Advisor to recommendations based on a single access method. You can select the type of SQL Access Advisor: Recommendation Options
structures to be recommended by the advisor. If none of the three possible ones are chosen, the advisor evaluates existing structures instead of trying to recommend new ones. You can use the Advisor Mode section to run the advisor in one of the two modes. These 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 13
SQL Access Advisor: Schedule and Review
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Schedule and Review
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a can then schedule and submit your new analysis by specifying various parameters to the You S i a scheduler. The possible options are shown in the screenshots in the slide. SQL Access Advisor: Schedule and Review
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 14
SQL Access Advisor: Results
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Results
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the Advisor Central page, you can retrieve the task details for your analysis. By From S i a selecting the task name in the Results section of the Advisor Central page, you can access SQL Access Advisor: Results
the Results for Task Summary page, on which you can see an overview of the Access Advisor findings. The page shows you charts and statistics that provide overall workload performance and potential for improving query execution time for the recommendations. You can use the page to show statement counts and recommendation action counts.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 15
SQL Access Advisor: Results and Implementation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Access Advisor: Results and Implementation
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a see other aspects of the results for the Access Advisor task, click one of the three other To S i a tabs on the page, Recommendations, SQL Statements, or Details. SQL Access Advisor: Results and Implementation
On the Recommendations page, you can drill down to each of the recommendations. For each of them, you see important information in the Select Recommendations for Implementation table. You can then select one or more recommendations and schedule their 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 16
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
You can also schedule the implementation of the recommendations by clicking the Schedule Implementation button.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 17
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
Identify two available workload analysis methods. a. Comprehensive b. Complete c. Partial d. Limited
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: a, d
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 18
ns e c li
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz
i a j i V
SQL Access Advisor identifies but cannot help resolve performance problems relating to the execution of SQL statements. a. True b. False
e
le
s
b fera
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
Answer: b
ahu
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 19
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned to use SQL Access Advisor.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 20
ns e c li
Practice 13: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 13: Overview
i a j i V
This practice covers the following topics using SQL Access Advisor to change your schema
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 21
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Access Advisor Chapter 13 - Page 22
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
o Tuning AutomatingnSQL
a ฺ s a Chapterh14 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automating SQL Tuning
i a j i V
Automating SQL Tuning
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to use Automatic SQL Tuning.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 3
ns e c li
SQL Tuning Loop
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Tuning Loop 1 Workload
e
Automatic
High load
b4le a r fe
SQL Tuning Advisor
ns e c li
s
n a r t n-
no a 2 ADDM has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Generate SQL profiles.
3
Run SQL Tuning Advisor.
Vij
( u h Oracle a Database 10g introduced SQL Tuning Advisor to help application developers improve S i the performance of SQL statements. The advisor targets the problem of poorly written SQL, in a SQL Tuning Loop
which SQL statements have not been designed in the most efficient fashion. It also targets the (more common) problem in which a SQL statement performs poorly because the optimizer generated a poor execution plan due to lack of accurate and relevant data statistics. In all 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 4
Automatic SQL Tuning
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning AWR
2
Top SQL
Auto matic
Workload
e
3
le
1
b fera
ns e c li
s
SQL Tuning
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Reports
4
Vij
( u h a Database 11g further automates the SQL Tuning process by identifying problematic Oracle S i a SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL Automatic SQL Tuning
profile recommendations to tune the statement without requiring user intervention. Automatic SQL Tuning uses the AUTOTASK framework through a task called "Automatic SQL Tuning" that runs every night by default. A brief description of the automated SQL tuning process in 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 5
Automatic Tuning Process
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic Tuning Process Not considered for auto implementation New SQL profile
Restructure SQL.
Existing profile?
Indexes
Considered for auto implementation
N
3X benefit?
Y
le
N Y
b fera
s n a Ignore new profile r n-t
3X benefit?
Stale stats
e
ns e c li
Accept profile
N
.
Vij
no a eฺ hasReplace d i profile. ) m t Gu o c ilฺ den a GATHER_STATS_JOB m Stu g 1@ this 2 y ja use i v to hu a s ( Tuning Process Automatic u h a the tuning process, all the recommendation types are considered and reported, but During S i a only SQL profiles can be implemented automatically (when the ACCEPT_SQL_PROFILES task Y
parameter is set to TRUE). Otherwise, only the recommendation to create a SQL profile is reported in the automatic SQL tuning reports.
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.
Automating SQL Tuning Chapter 14 - Page 6
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
A. Test the new SQL profile by executing the statement with and without it.
i a j i V
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 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 time, with neither statistic becoming worse. In this way, the statement runs faster than it would without the profile, even with contention in CPU or I/O. 3. If stale or missing statistics are found, make this information available to GATHER_STATS_JOB. Automatic implementation of tuning recommendations is limited to SQL profiles because they have fewer risks. It is easy for you to reverse the implementation. Note: All SQL profiles are created in the standard EXACT mode. They are matched and tracked according to the current value of the CURSOR_SHARING parameter. You are responsible for setting CURSOR_SHARING appropriately for your workload.
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 7
e
ns e c li
Automatic SQL Tuning Controls
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning Controls •
Autotask configuration: – On/off switch – Maintenance windows running tuning task – CPU resource consumption of tuning task
•
e
Task parameters: – – – – –
SQL profile implementation automatic/manual switch ble Global time limit for tuning task a r fe s Per-SQL time limit for tuning task n ra Test-execute mode disabled to save timeon-t a n ฺ implemented Maximum number of SQL profiles s automatically ha uide per execution as well as overall ) m G – Task execution expiration lฺco periodnt
ns e c li
ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a is a PL/SQL control example for the Automatic SQL Tuning task: Here S i dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', a Automatic SQL Tuning Controls
'LOCAL_TIME_LIMIT', 1400); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE'); 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 testexecute 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 8
Automatic SQL Tuning Task
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning Task
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a already stated, Automatic SQL Tuning is implemented as an automated maintenance task As S i a that is called Automatic SQL Tuning. You can see some high-level information about the last Automatic SQL Tuning Task
runs of the Automatic SQL Tuning task on the Automated Maintenance Tasks page. To open this page, on your Database Control Home page, click the Server tab. On the Server tabbed page that opens, click the Automated Maintenance Tasks link in the Tasks section. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 9
Configuring Automatic SQL Tuning
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Configuring Automatic SQL Tuning
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can configure various Automatic SQL Tuning parameters by using the Automatic SQL You S i a Tuning Settings page. Configuring Automatic SQL Tuning
To navigate to that page, click the Configure button on the Automated Maintenance Tasks page. You see the Automated Maintenance Tasks Configuration page, on which you see the various maintenance windows that are delivered with Oracle Database 11g. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 10
Automatic SQL Tuning: Result Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning: Result Summary
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h aaddition, the Automatic SQL Tuning Result Summary page contains various summary In S i a graphs so that you can control the Automatic SQL Tuning task. An example is given in the Automatic SQL Tuning: Result Summary
slide. The first chart in the Overall Task Statistics section shows you the breakdown by finding types for the designated period of time. You can control the period of time for which you want the report to be generated by selecting a value from the Time Period list. In the example, 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 11
Automatic SQL Tuning: Result Details
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning: Result Details
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the Automatic SQL Tuning Result Details page, you can also see important information for On S i a each automatically tuned SQL statement, including its SQL text and SQL ID, the type of Automatic SQL Tuning: Result Details
recommendation that was done by SQL Tuning Advisor, the verified benefit percentage, whether a particular recommendation was automatically implemented, and the date of the recommendation.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 12
Automatic SQL Tuning Result Details: Drilldown
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning Result Details: Drilldown
e
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the “Recommendations for SQL ID” page, you can see the corresponding On S i a recommendations and implement them manually. Automatic SQL Tuning Result Details: Drilldown
By clicking the SQL Test link, you access the SQL Details page, where you see the tuning history as well as the plan control associated with your SQL statement. In the slide, you see that the statement was tuned by Automatic SQL Tuning and that the associated profile was automatically implemented.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 13
ns e c li
Automatic SQL Tuning Considerations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Automatic SQL Tuning Considerations •
SQL not considered for Automatic SQL Tuning: – – – – –
•
Ad hoc or rarely repeated SQL Parallel queries Long-running queries after profiling Recursive SQL statements DML and DDL
e
e
These statements can still be manually tuned by usingrabl e SQL Tuning Advisor. nsf
ns e c li
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Automatic SQL Tuning Considerations
V
ah SQL Tuning does not seek to solve every SQL performance issue occurring on a Automatic S i ija 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.
•
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.
Automating SQL Tuning Chapter 14 - Page 14
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz In the maintenance window, an Automatic SQL Tuning task will run by default. Which two actions will this task perform by default? a. Prioritizes and tunes the SQL statements with the top resource consumption b. Works on each statement for a maximum of 30 minutes ble c. Stops when all SQL statements are tuned, or when the a r fe window closes s n ra profiles d. Automatically implements any recommended n-tSQL
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a default settings for Automatic SQL Tuning task is to tune the top SQL statements after The S i a prioritizing them based on the AWR Top SQL identification (SQLs that were top in four
Vij
Answer: a, c
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). 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 15
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned to use Automatic SQL Tuning
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 16
ns e c li
Practice 14: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 14: Overview
i a j i V
This practice covers using Automatic SQL Tuning to tune your statements
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 17
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Automating SQL Tuning Chapter 14 - Page 18
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
SQL Plan Management no
a ฺ s a Chapterh15 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Plan Management
i a j i V
SQL Plan Management
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to: • Manage SQL performance through changes • Set up SQL Plan Management • Set up various SQL Plan Management scenarios
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 3
ns e c li
Maintaining SQL Performance
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Maintaining SQL Performance Maintaining performance may require using SQL plan baselines
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h Any a number of factors that influence the optimizer can change over time. The challenge is to S i maintain the SQL performance levels in spite of the changes. a Maintaining SQL Performance
Optimizer statistics change for many reasons. Managing the changes to SQL performance despite the changes to statistics is the task of the DBA.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 4
SQL Plan Management: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Plan Management: Overview • •
SQL Plan Management is automatically controlled SQL plan evolution. Optimizer automatically manages SQL plan baselines. – Only known and verified plans are used.
•
e
Plan changes are automatically verified. – Only comparable or better plans are subsequently used.
•
le
The plan baseline can be seeded for critical SQL with rSQL ab e f tuning set (STS) from SQL Performance Analyzer. ns
ns e c li
a
tr n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
SQL Plan Management: Overview
V
ah performance risk occurs when the SQL execution plan changes for a SQL Potential S i ija 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 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 5
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 6
ns e c li
SQL Plan Baseline: Architecture
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Plan Baseline: Architecture SYSAUX
SQL management base Statement log
Plan history Repeatable SQL statement
SQL profile
e
Plan baseline
…
GB
GB
HJ
HJ
HJ
le
b fera
GB HJ HJ
ns e c li
s
n a r t n-
Automatic o n SQL tuning a ฺ s task ha uide ) om nt G c ฺ l ai tude Plan verification before m g S integration to baseline @ this 1 2 y se a j i uv to u HJ
h
a s ( u
SQL Plan Baseline: Architecture
V
ahSQL Plan Management (SPM) feature introduces necessary infrastructure and services in The S i ija support of plan maintenance and performance verification of new plans. For SQL statements that are executed more than once, the optimizer maintains a history of plans for individual SQL statements. The optimizer recognizes a repeatable SQL statement by maintaining a statement log. A SQL statement is recognized as repeatable when it is parsed 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 7
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
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, periodic purging of unused plans). You can configure the SMB to change the plan retention policy and set space size limits. Note: With Oracle Database 11g, if the database instance is up but the SYSAUX tablespace is OFFLINE, the optimizer is unable to access SQL management objects. This can affect performance on some of the SQL workload.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 8
ns e c li
Loading SQL Plan Baselines
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Loading SQL Plan Baselines OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
dbms_spm Plan history
Plan history GB
1
HJ HJ GB HJ HJ
e
GB
2
HJ HJ
HJ
3
A
HJ
le
b fera B
GB
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l DBA ai tude m g sS @ 1 hi 2 t y e ija us v u to sah Plan history
Cursor cache
GB
4
HJ
Staging table
HJ
Vij
( u h a are two ways to load SQL plan baselines. There S i a Loading SQL Plan Baselines •
On the fly capture: Uses automatic plan capture by setting the OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES initialization parameter to TRUE. This parameter is set to FALSE by default. Setting it to TRUE turns on automatic recognition of 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 9
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 10
ns e c li
Evolving SQL Plan Baselines
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Evolving SQL Plan Baselines
Plan history Automatic SQL Tuning
e
GB HJ
le
HJ
DBA
b f>?era
GB HJ
s
n a r t nHJ
ns e c li
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah SQL Tuning Advisor
Vij
( u h a the optimizer finds a new plan for a SQL statement, the plan is added to the plan history When S i a as a nonaccepted plan. The plan will not be accepted into the SQL plan baseline until it is Evolving SQL Plan Baselines
verified for performance relative to the SQL plan baseline performance. Verification means a nonaccepted plan does not cause a performance regression (either manually or automatically). The verification of a nonaccepted plan consists of comparing its performance 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.
SQL Plan Management Chapter 15 - Page 11
Important Baseline SQL Plan Attributes
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Important Baseline SQL Plan Attributes Plan history
Enabled but not accepted
GB
GB
HJ
HJ
HJ
HJ
Enabled and accepted
e
select signature, sql_handle, sql_text, plan_name, origin, enabled, accepted, fixed, autopurge from dba_sql_plan_baselines;
le
b fera
SIGNATURE SQL_HANDLE SQL_TEXT PLAN_NAME ORIGIN ENA ACC FIX AUT --------- ------------ -------- ---------------- ------------ --- --- --- --8.062E+18 SYS_SQL_6fe2 select.. SQL_PLAN_6zsn… AUTO-CAPTURE YES NO NO YES 8.062E+18 SYS_SQL_e23f select.. SQL_PLAN_f4gy… AUTO-CAPTURE YES YES NO YES
ns e c li
s
n a r t n-
Vij
no a as ideฺ exec :cnt := dbms_spm.alter_sql_plan_baseline(h ) sql_handle => 'SYS_SQL_6fe28d438dfc352f', m t Gu o c plan_name lฺ 'SQL_PLAN_6zsnd8f6zsd9g54bc8843',i=> en attribute_value => 'NO'); a d attribute_name => 'ENABLED', u gm s St @ 1 hi 2 t y e ija us v u to h a s ( Baseline SQL Plan Attributes Important u h a a plan enters the plan history, it is associated with a number of important attributes: When S i a …
•
•
•
•
SIGNATURE, SQL_HANDLE, SQL_TEXT, and PLAN_NAME are important identifiers for search operations. ORIGIN allows you to determine whether the plan was automatically captured (AUTOCAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTOSQLTUNE). 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 12
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
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 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 DBMS_SPM.DROP_SQL_PLAN_BASELINE function. The example shown in the slide changes the ENABLED attribute of SQL_PLAN_6zsnd8f6zsd9g54bc8843 to NO. Note: The DBA_SQL_PLAN_BASELINES view contains additional attributes that enable you to determine when each plan was last used and whether a plan should be automatically purged.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 13
ns e c li
SQL Plan Selection
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Plan Selection GB HJ
optimizer_use_sql_ plan_baselines=true?
HJ
Yes
Plan part of history?
No Plan history
Yes
No GB GB HJ HJ
HJ
Plan part of baseline?
Yes
HJ
Plan baseline GB HJ
…
HJ
HJ HJ
s n a r -t baseline plan Select n o with n lowest best cost. a has uideฺ ) om nt G < c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u HJ
Yes
HJ
le
b fera
No
GB
e
GB
GB
GB
HJ
HJ
HJ
HJ
No
ns e c li
GB HJ HJ
h
a s ( u
SQL Plan Selection
V
h Ifayou are using automatic plan capture, the first time that a SQL statement is recognized as S i ija repeatable, its best-cost plan is added to the corresponding SQL plan baseline. That plan is then used to execute the statement.
The optimizer uses a comparative plan selection policy when a plan baseline exists for a SQL statement and the OPTIMIZER_USE_SQL_PLAN_BASELINES initialization parameter is set to 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 14
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
In addition, you can use the new dbms_xplain.display_sql_plan_baseline function to display one or more execution plans for the specified sql_handle of a plan baseline. If plan_name is also specified, the corresponding execution plan is displayed.
i a j i V
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. Stored outlines can be migrated to SQL plan baselines by using the MIGRATE_STORED_OUTLINE procedure from the DBMS_SPM package. When the migration is complete, you should disable or drop the original stored outline using the DROP_MIGRATED_STORED_OUTLINE procedure of the DBMS_SPM package.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 15
ns e c li
Possible SQL Plan Manageability Scenarios
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Possible SQL Plan Manageability Scenarios Database Upgrade
New Application Deployment
Oracle Database 11g
Production database
Plan history
Plan history
GB
GB
GB
GB
HJ
HJ
HJ
HJ
HJ
HJ
No plan regressions
HJ
HJ
No plan regressions
e
DBA
DBA
s
n a r t n-
Plan history
le
b fera
ns e c li
no a has uideฺ ) om nt G c ฺ l ai tudeDevelopment database Oracle Database 10g m g sS @ 1 hi 2 t y e ija us v u to h a s (SQL Plan Manageability Scenarios Possible u h a• Database upgrade: Bulk SQL plan loading is especially useful when the system is S i being upgraded from an earlier version to Oracle Database 11g. For this, you can a Well- GB tuned HJ plan HJ
Vij
GB
GB
HJ
HJ
HJ
Well-tuned plan
HJ
Baseline plans staging table
capture plans for a SQL workload into a SQL tuning set (STS) before the upgrade, and then load these plans from the STS into the SQL plan baseline immediately after the upgrade. This strategy can minimize plan regressions resulting from the use of the new 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 16
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Performance Analyzer and SQL Plan Baseline Scenario
SQL Performance Analyzer and SQL Plan Baseline Scenario Before change
O_F_E=10
Oracle Database 11g Plan history GB
GB
HJ
HJ
HJ
Regressing statements
HJ
No plan regressions
le
After O_F_E=11 change
b fera
s
n a r t n-
optimizer_features_enable
no a has uideฺ ) om nt G Well-tuned c ฺ l plans ai10g tude Oracle Database m g S 1@ this 2 y ja use i v u to sah GB
GB
GB
HJ
HJ
HJ
HJ
HJ
HJ
( u h Aavariation of the first method described in the previous slide is through the use of SQL S i a Performance Analyzer. You can capture pre–Oracle Database 11g plans in an STS and
Vij
SQL Performance Analyzer and SQL Plan Baseline Scenario
import them into Oracle Database 11g. Then set the optimizer_features_enable (O_F_E) initialization parameter to 10.1.0 to make the optimizer behave as if this were a 10g Oracle Database. Next run SQL Performance Analyzer for the STS. When that is complete, 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 17
e
ns e c li
Loading a SQL Plan Baseline Automatically
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Loading a SQL Plan Baseline Automatically Oracle Database 11g
No plan regressions
Plan history Plan baseline GB
Oracle Database 11g New plan waiting verification
GB HJ
HJ
HJ
HJ
Plan history Plan baseline GB
GB
HJ
HJ
GB HJ HJ
HJ
HJ
optimizer_features_enable=10.2.0.2 optimizer_capture_sql_plan_baselines=true
No plan regressions
e
optimizer_features_enable=11.1.0.1 optimizer_capture_sql_plan_baselines=true
Oracle Database 11g
le
b fera
Better plans
ns e c li
s
Plan history
n a r t n-
Plan baseline
Vij
no a has uideฺ ) m tG o c ฺ l Oracle Database 10g i en a d u gm s St @ 1 hi 2 t y e ija us v u to h a s (a SQL Plan Baseline Automatically: Scenario Loading u h a upgrade scenario involves using the automatic SQL plan capture mechanism. In this Another S i a case, set the initialization parameter optimizer_features_enable (O_F_E) to the pre– GB HJ
HJ
GB HJ
HJ
Welltuned plans
GB
GB
GB
HJ
HJ
HJ
HJ
HJ
HJ
optimizer_features_enable=11.1.0.1 optimizer_capture_sql_plan_baselines=true
Oracle Database 11g version value for an initial period of time such as a quarter, and execute your workload after upgrade by using the automatic SQL plan capture. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 18
Purging SQL Management Base Policy
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Purging SQL Management Base Policy SQL> exec dbms_spm.configure('SPACE_BUDGET_PERCENT',20); SQL> exec dbms_spm.configure('PLAN_RETENTION_WEEKS',105);
DBA_SQL_MANAGEMENT_CONFIG time 105
Alert log
e
SQL Management Base
SYSAUX
le
b fera
ns e c li
s
n a r t n-
53
Vij
no a space 1% 10% 20% 50% as h uideฺ ) om nt G c ฺ l ai tude SQL> exec :cnt := dbms_spm.drop_sql_plan_baseline('SYS_SQL_37e0168b04e73efe'); m g sS @ 1 hi 2 t y e ija us v u to h a s (SQL Management Base Policy Purging u h a space occupied by the SQL management base (SMB) is checked weekly against a The S i a defined limit. A limit based on the percentage size of the SYSAUX tablespace is defined. By
default, the space budget limit for the SMB is set to 10 percent of SYSAUX size. However, you can configure SMB and change the space budget to a value between 1 percent and 50 percent by using the DBMS_SPM.CONFIGURE procedure. 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.
SQL Plan Management Chapter 15 - Page 19
Enterprise Manager and SQL Plan Baselines
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Enterprise Manager and SQL Plan Baselines
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a the SQL Plan Management page to manage SQL profiles, SQL patches, and SQL plan Use S i a baselines from one location rather than from separate locations in Enterprise Manager. You Enterprise Manager and SQL Plan Baselines
can also enable, disable, drop, pack, unpack, load, and evolve selected baselines. From this page, you can also configure the various SQL plan baseline settings.
To navigate to this page, click the Server tab, and then click the SQL Plan Control entry in the Query Optimizer section.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 20
Quiz
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Quiz When the OPTIMIZER_USE_SQL_PLAN_BASELINES parameter is set to TRUE, the optimizer: a. Does not develop an execution plan; it uses an accepted plan in the baselines b. Compares the plan it develops with accepted plans in the baselines ble c. Compares the plan it develops with enabled plans in the a r fe baselines s n tra d. Does not develop an execution plan; it uses enabled plans n o n in the baselines a ฺ s a e. Develops plans and adds them as verified ide ) hto theubaselines
om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Answer: b
ahoptimizer always develops an execution plan. Then it compares the plan with accepted The S i ija plans in the SQL baseline. If an accepted baseline exists, the baseline is used. If the plan
V
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 21
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary
i a j i V
In this lesson, you should have learned how to: • Manage SQL performance through changes • Set up SQL Plan Management • Set up various SQL Plan Management scenarios
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 22
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice 15: Overview Using SQL Plan Management
i a j i V
Practice 15: Overview Using SQL Plan Management This practice covers the use of SQL Plan Management.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 23
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
SQL Plan Management Chapter 15 - Page 24
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
Using Optimizer no Hints
a ฺ s a Chapterh16 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Optimizer Hints
i a j i V
Using Optimizer Hints
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives
i a j i V
After completing this lesson, you should be able to : • Use hints when appropriate • Specify hints for: – – – – – –
ahu
Optimizer mode Query transformation Access path Join orders Join methods Views
e
le
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 3
s
b fera
ns e c li
Optimizer Hints: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Hints: Overview Optimizer hints: • Influence optimizer decisions • Example: SELECT /*+ INDEX(e empfirstname_idx) skewed col */ * FROM employees e WHERE first_name='David'
le b a r • HINTS SHOULD ONLY BE USED AS A LAST RESORT. fe s n • When you use a hint, it is good practice to also traadd a n comment about that hint. no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s Optimizer Hints: Overview ( u h Hints a enable you to influence decisions made by the optimizer. Hints provide a mechanism to S i direct the optimizer to select a certain query execution plan based on the specific criteria. a
Vij
For example, you might know that a certain index is more selective for certain queries. Based on this information, you might be able to select a more efficient execution plan than the plan that the optimizer recommends. In such a case, use hints to force the optimizer to use the 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 4
e
ns e c li
Types of Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Types of Hints
Single-table hints
Specified on one table or view
Multitable hints
Specify more than one table or view
Query block hints
Operate on a single query block
Statement hints
Apply to the entire SQL statement
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Single-table: Single-table hints are specified on one table or view. INDEX and USE_NL are S i a examples of single-table hints. Types of 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. 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).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 5
Specifying Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Specifying Hints Hints apply to the optimization of only one statement block: • A self-contained DML statement against a table • A top-level DML or a subquery MERGE SELECT INSERT UPDATE
e
/*+
*/
hint comment text
DELETE MERGE
le
b fera
ns e c li
s
n a r t n-
no a as ideฺ hhint --+ ) u m comment G o t c UPDATE ilฺ dentext a m Stu DELETE g 1@ this 2 y ja use i v u to sah SELECT INSERT
Vij
( u h a apply to the optimization of only the block of the statement in which they appear. A Hints S i a statement block is: Specifying Hints
•
A simple MERGE, SELECT, INSERT, UPDATE, or DELETE statement
•
A parent statement or a subquery of a complex statement
•
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.
Optimizer Hint Syntax Enclose hints within the comments of a SQL statement. You can use either style of comment. The hint delimiter (+) must come immediately after the comment delimiter. If you separate them by a space, the optimizer does not recognize that the comment contains hints.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 6
Rules for Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Rules for Hints
i a j i V
• • • • •
Place hints immediately after the first SQL keyword of a statement block. Each statement block can have only one hint comment, but it can contain multiple hints. Hints apply to only the statement block in which they appear. If a statement uses aliases, hints must reference the rable fe aliases rather than the table names. s n trawithout The optimizer ignores hints specified incorrectly n o raising errors. an
has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a• You must place the hint comment immediately after the first keyword (MERGE, SELECT,
Rules for Hints
S
INSERT, DELETE, or UPDATE) of a SQL statement block. •
A statement block can have only one comment containing hints, but it can contain many hints inside that comment separated by spaces.
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 7
e
ns e c li
Hint Recommendations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hint Recommendations
i a j i V
• •
Use hints carefully because they imply a high-maintenance load. Be aware of the performance impact of hard-coded hints when they become less valid.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a• Use hints as a last remedy when tuning SQL statements.
Hint Recommendations
S
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 8
Optimizer Hint Syntax: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimizer Hint Syntax: Example
UPDATE /*+ INDEX(p PRODUCTS_PROD_CAT_IX)*/ products p SET p.prod_min_price = (SELECT (pr.prod_list_price*.95) FROM products pr WHERE p.prod_id = pr.prod_id) WHERE p.prod_category = 'Men' AND p.prod_status = 'available, on stock' /
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a slide shows an example with a hint that advises the cost-based optimizer (CBO) to use The S i a the index. The execution plan is as follows: Optimizer Hint Syntax: Example
Execution Plan ---------------------------------------------------------0
UPDATE STATEMENT Optimizer=ALL_ROWS (Cost=3 …)
1
0
2
1
3
2
UPDATE OF 'PRODUCTS' TABLE ACCESS (BY INDEX ROWID) OF 'PRODUCTS' (TABLE) (Cost…) INDEX (RANGE SCAN) OF 'PRODUCTS_PROD_CAT_IX' (INDEX) (cost…)
4 5
1 4
TABLE ACCESS (BY INDEX ROWID) OF 'PRODUCTS' (TABLE) (Cost…) 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 9
Hint Categories
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hint Categories There are hints for: • Optimization approaches and goals • Access paths • Query transformations • Join orders • Join operation • Parallel execution • Additional hints
e
le
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
b fera
ns e c li
Vij
( u h a of these hints are discussed in the following slides. Many of these hints accept the table Most S i a and index names as arguments. Hint Categories
Note: Hints for parallel execution is not covered in this course.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 10
Optimization Goals and Approaches
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Optimization Goals and Approaches
ALL_ROWS
Selects a cost-based approach with a goal of best throughput
FIRST_ROWS(n)
Instructs the Oracle server to optimize an individual SQL statement for fast response
e
le
b fera
ns e c li
s
n a r t n-
Note: The ALTER SESSION... SET OPTIMIZER_MODE no a s fromewithin statement does not affect SQL that is PL/SQL. harun d ฺ
) Gui m o ilฺc dent a m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a ALL_ROWS: The ALL_ROWS hint explicitly selects the cost-based approach to optimize a S i a statement block with a goal of best throughput. That is, minimum total resource consumption. Optimization Goals and Approaches
FIRST_ROWS(n): The FIRST_ROWS(n) hint (where n is any positive integer) instructs the Oracle server to optimize an individual SQL statement for fast response. It instructs the server 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.
Using Optimizer Hints Chapter 16 - Page 11
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Note: The FIRST_ROWS hints are probably the most useful hints.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 12
ns e c li
Hints for Access Paths
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Access Paths
FULL
Performs a full table scan
CLUSTER
Accesses table using a cluster scan
HASH
Accesses table using a hash scan
ROWID
Accesses a table by ROWID
INDEX
Selects an index scan for the specified rab e table nsf
e
le
ns e c li
Vij
tra n INDEX_ASC Scans an index in ascending no order a ฺ INDEX_COMBINE Explicitly chooses eaccess path haasbitmap d i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s Hints u for(Access Paths h a Specifying one of these hints causes the optimizer to choose the specified access path only if S i a the access path is available based on the existence of an index and on the syntactic constructs of the SQL statement. If a hint specifies an unavailable access path, the optimizer ignores it. You must specify the table to be accessed exactly as it appears in the statement. If the statement uses an alias for the table, use the alias rather than the table name in the hint. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 13
ROWID: The ROWID hint explicitly chooses a table scan by ROWID for the specified table.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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 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. If this hint specifies a list of available indexes, the optimizer considers the cost of a scan on each index in the list and then performs the index scan with the lowest cost. The optimizer can also choose to scan multiple indexes from this list and merge the results, if such an access path has the lowest cost. The optimizer does not consider a full table scan or a scan on an index not listed in the hint. If this hint specifies no indexes, the optimizer considers the cost of a scan on each available index on the table and then performs the index scan with the lowest cost. The optimizer can also choose to scan multiple indexes and merge the results, if such an access path has the lowest cost. The optimizer does not consider a full table scan.
le b a r INDEX_ASC: The INDEX_ASC hint explicitly chooses an index scan for the specified fe intable. If s the statement uses an index range scan, the Oracle server scans the index entries n ra for a range tbehavior ascending order of their indexed values. Because the server’s default n scan is to scan index entries in the ascending order of their indexed no values, this hint does not a specify anything more than the INDEX hint. However, you to use the INDEX_ASC s might ewant ฺbehavior a h d hint to specify ascending range scans explicitly, should the default change. ) Gui m INDEX_COMBINE: The INDEX_COMBINE ฺhint tchooses a bitmap access path for the coexplicitly n l i e table. If no indexes are given as arguments d INDEX_COMBINE hint, the optimizer uses a ma thatSforhas tuthe g Boolean combination of bitmap indexes the best cost estimate for the table. If certain @ s i 1 indexes are given as arguments, the optimizer tries to use some Boolean combination of h 2 t y e those particular bitmap s ija indexes. u v u o t For example: ah s ( SELECT u /*+INDEX_COMBINE(customers cust_gender_bix cust_yob_bix)*/ * h a FROM customers WHERE cust_year_of_birth < 70 AND cust_gender = 'M'; ai S
Vij
e
ns e c li
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 14
Hints for Access Paths
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Access Paths
INDEX_JOIN
Instructs the optimizer to use an index join as an access path
INDEX_DESC
Scans an index in descending order
INDEX_FFS
Performs a fast-full index scan
INDEX_SS
Performs an index skip scan
NO_INDEX
Does not allow using a set of indexes
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a INDEX_JOIN: The INDEX_JOIN hint explicitly instructs the optimizer to use an index join as S i a an access path. For the hint to have a positive effect, a sufficiently small number of indexes Hints for Access Paths (continued)
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 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:
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 15
SELECT /*+ INDEX_DESC(a ord_order_date_ix) */ a.order_date, a.promotion_id, a.order_id FROM oe.orders a WHERE a.order_date < '01-jan-1985';
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
INDEX_FFS: The INDEX_FFS hint causes a fast-full index scan to be performed rather than a full table scan. For example: SELECT /*+ INDEX_FFS ( o order_pk ) */ COUNT(*) FROM order_items l, orders o WHERE l.order_id > 50 AND l.order_id = o.order_id; INDEX_SS: The INDEX_SS hint instructs the optimizer to perform an index skip scan for the specified indexes of the specified table. If the statement uses an index range scan, the system scans the index entries in the ascending order of their indexed values. In a partitioned index, the results are in the ascending order within each partition. There are also INDEX_SS_ASC and INDEX_SS_DESC hints.
e
ns NO_INDEX: The NO_INDEX hint explicitly disallows a set of indexes for the specified table.lice ble on • If this hint specifies a single available index, the optimizer does not consider a scan a r this index. Other indexes that are not specified are still considered. fe s n a consider a scan on • If this hint specifies a list of available indexes, the optimizer doestrnot n any of the specified indexes. Other indexes that are not specified in the list are still o n considered. a ฺ s a • If this hint specifies no indexes, the optimizer does h notuconsider de a scan on any index on i ) the table. This behavior is the same as o am NO_INDEX Ghint that specifies a list of all t c ฺ n l available indexes for the table. ai tude m The NO_INDEX hint applies to function-based, g s S B*-tree, bitmap, or domain indexes. If a @ NO_INDEX hint and an index 1 hint (INDEX, hi INDEX_ASC, INDEX_DESC, INDEX_COMBINE, or 2 t y e INDEX_FFS) both specify the same indexes, then both the NO_INDEX hint and the index hint ja us i v are ignored for to indexes and the optimizer considers the specified indexes. huthe specified a s For example: ( u h a SELECT /*+NO_INDEX(employees emp_empid)*/ employee_id S i FROM employees WHERE employee_id > 200; a
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 16
The INDEX_COMBINE Hint: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The INDEX_COMBINE Hint: Example
SELECT /*+INDEX_COMBINE(CUSTOMERS)*/ cust_last_name FROM SH.CUSTOMERS WHERE ( CUST_GENDER= 'F' AND CUST_MARITAL_STATUS = 'single') OR CUST_YEAR_OF_BIRTH BETWEEN '1917' AND '1920';
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a INDEX_COMBINE hint is designed for bitmap index operations. Remember the following: The S i a The INDEX_COMBINE Hint: Example •
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.
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 17
The INDEX_COMBINE Hint: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The INDEX_COMBINE Hint: Example
Execution Plan --------------------------------------------------| 0 | SELECT STATEMENT | | 1 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 2 | BITMAP CONVERSION TO ROWIDS | | 3 | BITMAP OR | | 4 | BITMAP MERGE | | 5 | BITMAP INDEX RANGE SCAN | CUST_YOB_BIX | 6 | BITMAP AND | | 7 | BITMAP INDEX SINGLE VALUE| CUST_MARITAL_BIX | 8 | BITMAP INDEX SINGLE VALUE| CUST_GENDER_BIX
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athe example in the slide, the following bitmap row sources are used: In S i a The INDEX_COMBINE Hint: Example (continued) •
BITMAP CONVERSION TO ROWIDS: Converts bitmaps into ROWIDs to access a table
•
COUNT: Returns the number of entries if the actual values are not needed
•
BITMAP OR: Computes the bitwise OR of two bitmaps
•
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)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 18
Hints for Query Transformation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Query Transformation
USE_CONCAT
Skips all query transformation Rewrites OR into UNION ALL and disables INLIST processing
NO_EXPAND
Prevents OR expansions
REWRITE
Rewrites query in terms of materialized views
NO_QUERY_TRANSFORMATION
Turns off query rewrite
e
le
b fera
ns e c li
Vij
s n a r UNNEST Merges subquerynbodies -t into o n block surroundingaquery asunnesting eฺ NO_UNNEST Turnshoff d i ) m t Gu o c ilฺ den a m Stu g 1@ this 2 y ja use i v to hu a s Hints u for(Query Transformation h a NO_QUERY_TRANSFORMATION: The NO_QUERY_TRANSFORMATION hint instructs the S i a optimizer to skip all query transformations, including but not limited to OR-expansion, view NO_REWRITE
merging, subquery unnesting, star transformation, and materialized view rewrite.
USE_CONCAT: The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a 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 ORexpansion 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 19
Hints for Query Transformation
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Query Transformation
MERGE
Merges complex views or subqueries with the surrounding query
NO_MERGE
Prevents merging of mergeable views
STAR_TRANSFORMATION
Makes the optimizer use the best plan in which the transformation can be used
Vij
le b a r FACT Indicates that the hinted table should fe s n be considered as a fact table tra n NO_FACT Indicates that the hinted no table should a not be considered s aseaฺ fact table a h ) Guid m co ent ฺ l i ma Stud g 1@ this 2 y ja use i v to hu a s Hints u for(Query Transformation (continued) h a The MERGE hint lets you merge a view for each query. If a view’s query contains a MERGE: S i a
GROUP BY clause or a DISTINCT operator in the SELECT list, then the optimizer can merge the view’s query into the accessing statement only if complex view merging is enabled. This is the case by default, but you can disable this mechanism using the NO_MERGE hint. Complex merging can also be used to merge an IN subquery into the accessing statement if the 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.
Using Optimizer Hints Chapter 16 - Page 20
e
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
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 transformation that the hinted table should not be considered as a fact table.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 21
ns e c li
Hints for Join Orders
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Join Orders
ORDERED
Causes the Oracle server to join tables in the order in which they appear in the FROM clause
LEADING
Uses the specified tables as the first table in the join order
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a following hints are used to suggest join orders: The S i a Hints for 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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 22
Hints for Join Operations
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints for Join Operations USE_NL
Joins the specified table using a nested loop join
NO_USE_NL
Does not use nested loops to perform the join
USE_NL_WITH_INDEX Similar to USE_NL, but must be able to use an index for the join USE_MERGE Joins the specified table using a sort-merge se n e join lic e l NO_USE_MERGE Does not perform sort-merge operationsrfor abthe e f s join n a r USE_HASH Joins the specified table using n-ta hash join
Vij
o n a Does not use hashsjoin a ideฺ h ) DRIVING_SITE Instructs the uto execute the query at moptimizer G o t c a different site than that selected by the ilฺ den a database m Stu g 1@ this 2 y ja use i v to hu a s Hints u for(Join Operations h a hint described here suggests a join operation for a table. In the hint, you must specify a Each S i a table exactly the same way as it appears in the statement. If the statement uses an alias for NO_USE_HASH
the table, you must use the alias rather than the table name in the hint. However, the table name in the hint should not include the schema name if the schema name is present in the statement. Use of the USE_NL and USE_MERGE hints is recommended with the ORDERED hint. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 23
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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 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. In the following statement in which a nested loop is forced through a hint, orders is accessed through a full table scan and the l.order_id = h.order_id filter condition is applied to every row. For every row that meets the filter condition, order_items is accessed through the index order_id. SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity FROM oe.orders h ,oe.order_items l WHERE l.order_id = h.order_id;
e
Vij
ns Adding an INDEX hint to the query could avoid the full table scan on orders, resulting in anice l e execution plan similar to one that is used on larger systems, even though it might not be l particularly efficient here. rab e f s table with USE_MERGE: The USE_MERGE hint causes the Oracle server to join eachaspecified n r -t another row source by using a sort-merge join, as in the following example: n o n* FROM employees, SELECT /*+USE_MERGE(employees departments)*/ a departments WHERE employees.department_id has uid= eฺ departments.department_id; ) G to exclude the sort-merge om thentoptimizer c NO_USE_MERGE: The NO_USE_MERGE hint causes ฺ l i e a rowtusource d using the specified table as the inner join to join each specified table to another m g S table. @ this 1hint 2 USE_HASH: The USE_HASH causes the Oracle server to join each specified table with y e a j s i u another row source using a hash join, as in the following example: v to u h a /*+USE_HASH(l l2) */ l.order_date, l.order_id, SELECT s ( SUM(l2.unit_price*quantity) huFROM l2.product_id, a oe.orders l, oe.order_items l2 ai S WHERE l.order_id = l2.order_id GROUP BY l2.product_id, l.order_date, l.order_id; Here is another example: 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 24
Additional Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Additional Hints
APPEND
Enables direct-path INSERT
NOAPPEND
Enables regular INSERT
CURSOR_SHARING_EXACT
Prevents replacing literals with bind variables
CACHE
Overrides the default caching specification of the table
ble a r PUSH_PRED fe Pushes join predicate into view s n a trsubqueries PUSH_SUBQ Evaluates nonmerged first n o n DYNAMIC_SAMPLING Controls dynamic to a sampling s ฺ a e improve idperformance ) h server u m co ent G ฺ l i ma Stud g 1@ this 2 y ja use i v to hu a s ( Hints Additional u h a APPEND: The APPEND hint lets you enable direct-path INSERT if your database runs in serial S i a mode. Your database is in serial mode if you are not using Enterprise Edition. Conventional
Vij
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 25
e
ns e c li
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.
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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. PUSH_SUBQ: The PUSH_SUBQ hint instructs the optimizer to evaluate nonmerged subqueries at the earliest possible step in the execution plan. Generally, subqueries that are not merged are executed as the last step in the execution plan. If the subquery is relatively inexpensive and reduces the number of rows significantly, evaluating the subquery earlier can improve performance. This hint has no effect if the subquery is applied to a remote table or one that is joined using a merge join.
le
b fera
s
Consider the following example: SELECT /*+ dynamic_sampling(1) */ * FROM ...
n a r t n-
no a eฺ are true: This example enables dynamic sampling if all the following has conditions d i ) m t Gu • There is more than one table in the query. o c n no indexes. ilฺ and ehas • At least one table has not been analyzed a d u t expensive table scan is required for the table gma relatively S • The optimizer determines that @ s 1 hi that has not beenyanalyzed. 2 t e ija us v u to h a s ( u h a S i a
Vij
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 26
e
ns e c li
DYNAMIC_SAMPLING: The DYNAMIC_SAMPLING hint lets you control dynamic sampling to improve server performance by determining more accurate selectivity and cardinality estimates. You can set the value of DYNAMIC_SAMPLING to a value from 0 to 10. The higher the level, the more effort the compiler puts into dynamic sampling and the more broadly it is applied. Sampling defaults to the cursor level unless you specify a table.
Additional Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Additional Hints
MONITOR
Forces real-time query monitoring
NO_MONITOR
Disables real-time query monitoring
RESULT_CACHE
Caches the result of the query or query fragment
NO_RESULT_CACHE
Disables result caching for the ble a r query or query fragment fe
ns
Sets initialization parameter tra for n query duration no
OPT_PARAM
a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Additional Hints (continued)
ah The MONITOR hint forces real-time SQL monitoring for the query, even if the MONITOR: S i ija statement is not long running. This hint is valid only when the
V
CONTROL_MANAGEMENT_PACK_ACCESS parameter is set to DIAGNOSTIC+TUNING.
NO_MONITOR: The NO_MONITOR hint disables real-time SQL monitoring for the query. 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 27
e
ns e c li
Hints and Views
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints and Views • •
Do not use hints in views. Use view-optimization techniques: – Statement transformation – Results accessed like a table
•
Hints can be used on mergeable views and nonmergeable views.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a should not use hints in or on views because views can be defined in one context and You S i a used in another; such hints can result in unexpected plans. In particular, hints in views are
Vij
Hints and Views
handled differently from hints on views depending on whether or not the view is mergeable into the top-level query.
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.
Using Optimizer Hints Chapter 16 - Page 28
e
ns e c li
•
The CONNECT BY clause
•
The ROWNUM pseudocolumn
•
Group functions (AVG, COUNT, MAX, MIN, SUM) in the select list
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Hints and Mergeable Views Optimization-approach and goal hints can occur in a top-level query or in views: •
If there is such a hint in the top-level query, that hint is used regardless of any such hints in the views.
•
If there is no top-level optimizer-mode hint, mode hints in referenced views are used as long as all mode hints in the views are consistent.
•
If two or more mode hints in the referenced views conflict, all mode hints in the views are discarded and the session mode is used, whether default or user specified.
Access-method and join hints can also appear in a view definition: •
le
b fera
s
n a r t n-
If the view is a subquery (that is, if it appears in the FROM clause of a SELECT statement), all access-method and join hints in the view are preserved when the view is merged with the top-level query.
no a ฺ in the view are • For views that are not subqueries, access-method hints asand join e h d i ) preserved only if the top-level query references no other u tables or views (that is, if the m only G o t FROM clause of the SELECT statement contains the view). c ilฺ den a m Stu Hints and Nonmergeable Views g @ this hints in the view are ignored. The top-level query 1optimizer-mode 2 With nonmergeable views, y ja mode. se decides the optimization i u v to are optimized separately from the top-level query, accesshu Because nonmergeable views a s (and join hints in the view are always preserved. For the same reason, access-method method u h a on the view in the top-level query are ignored. i Shints
Vija
However, join hints on the view in the top-level query are preserved because (in this case) a nonmergeable view is similar to a table.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 29
e
ns e c li
Access-method and join hints on referenced views are ignored unless the view contains a single table (or references another view with a single table). For such single-table views, an access-method hint or a join hint on the view applies to the table in the view.
Global Table Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Global Table Hints • •
Extended hint syntax enables specifying for tables that appear in views References a table name in the hint with a recursive dot notation
CREATE SELECT FROM WHERE
view city_view AS * customers c cust_city like 'S%';
e
le
b fera
ns e c li
s
n a r t n-
no SELECT /*+ index(v.c cust_credit_limit_idx) */ a v.cust_last_name, v.cust_credit_limit as ideฺ h ) FROM city_view v m t Gu o c WHERE cust_credit_limit ilฺ > 5000; en ma Stud g 1@ this 2 y ja use i v u to sah
Vij
( u h a that specify a table generally refer to tables in the DELETE, SELECT, or UPDATE query Hints S i a block in which the hint occurs, rather than to tables inside any views that are referenced by Global Table Hints
the statement. When you want to specify hints for tables that appear inside views, it is recommended that you use global hints instead of embedding the hint in the view.
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).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 30
Specifying a Query Block in a Hint
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Specifying a Query Block in a Hint explain plan for select /*+ FULL(@strange dept) */ ename from emp e, (select /*+ QB_NAME(strange) */ * from dept where deptno=10) d where e.deptno = d.deptno and d.loc = 'C'; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'ALL')); Plan hash value: 615168685 --------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost(%CPU)| --------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 41 | 7 (15)| |* 1 | HASH JOIN | | 1 | 41 | 7 (15)| |* 2 | TABLE ACCESS FULL| DEPT | 1 | 21 | 3 (0)| |* 3 | TABLE ACCESS FULL| EMP | 3 | 60 | 3 (0)| --------------------------------------------------------------Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------1 - SEL$DB579D14 2 - SEL$DB579D14 / DEPT@STRANGE 3 - SEL$DB579D14 / E@SEL$1
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can specify an optional query block name in many hints to specify the query block to You S i a which the hint applies. This syntax lets you specify in the outer query a hint that applies to an Specifying a Query Block in a Hint inline view.
The syntax of the query block argument is of the @queryblock form, where queryblock is 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 systemgenerated names for each query block in the original query.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 31
Specifying a Full Set of Hints
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Specifying a Full Set of Hints
SELECT /*+ LEADING(e2 e1) USE_NL(e1) INDEX(e1 emp_emp_id_pk) USE_MERGE(j) FULL(j) */ e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal FROM hr.employees e1, hr.employees e2, hr.job_history j WHERE e1.employee_id = e2.manager_id ble a r fe AND e1.employee_id = j.employee_id s n AND e1.hire_date = j.start_date tra n no j.job_id GROUP BY e1.first_name, e1.last_name, a ORDER BY total_sal; has deฺ
) Gui m o ilฺc dent a m Stu g 1@ this 2 y ja use i v u to sah
( u h a using hints, you might sometimes need to specify a full set of hints to ensure the When S i a optimal execution plan. For example, if you have a very complex query consisting of many
Vij
Specifying a Full Set of Hints
table joins, and if you specify only the INDEX hint for a given table, then the optimizer needs to determine the remaining access paths to be used as well as the corresponding join methods. Therefore, even though you gave the INDEX hint, the optimizer might not 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 32
e
ns e c li
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary In this lesson, you should have learned how to: • Use hints when appropriate • Specify hints for: – – – – – –
Optimizer mode Query transformation Access path Join orders Join methods Views
e
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athis lesson, you should have learned about additional optimizer settings and hints. In S i a Summary
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. To specify a hint, use the hint syntax in the SQL statement.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 33
ns e c li
Practice Appendix B: Overview
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Practice Appendix B: Overview
i a j i V
This practice covers using various hints to influence execution plans.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Optimizer Hints Chapter 16 - Page 34
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
e
le
b fera
s
n a r t n-
o Using SQL nDeveloper
a ฺ s a Chapterh17 de i ) u om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
h
a S i ija
V
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 1
ns e c li
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using SQL Developer
i a j i V
Using SQL Developer
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 2
ns e c li
Objectives
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Objectives After completing this appendix, you should be able to do the following: • List the key features of Oracle SQL Developer • Identify menu items of Oracle SQL Developer • Create a database connection • Manage database objects ble • Use SQL Worksheet a r fe s n • Save and run SQL scripts tra n • Create and save reports no
a ฺ s a h uide ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ja s uvi to u
h
a s ( u
Objectives
h appendix, you are introduced to the graphical tool called SQL Developer. You learn In athis S i ija how to use SQL Developer for your database development tasks. You learn how to use SQL
V
Worksheet to execute SQL statements and SQL scripts.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 3
e
ns e c li
What Is Oracle SQL Developer?
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
What Is Oracle SQL Developer? • •
Oracle SQL Developer is a graphical tool that enhances productivity and simplifies database development tasks. You can connect to any target Oracle database schema by using standard Oracle database authentication.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l i aSQL de u Developer m t g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL Developer is a free graphical tool designed to improve your productivity and Oracle S i a simplify the development of everyday database tasks. With just a few clicks, you can easily What Is Oracle SQL Developer?
create and debug stored procedures, test SQL statements, and view optimizer plans.
SQL Developer, the visual tool for database development, simplifies the following tasks: •
Browsing and managing database objects
•
Executing SQL statements and scripts
•
Editing and debugging PL/SQL statements
•
Creating reports
You can connect to any target Oracle database schema 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.
Using SQL Developer Chapter 17 - Page 4
Specifications of SQL Developer
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Specifications of SQL Developer • • • • • •
Shipped along with Oracle Database 11g Release 2 Developed in Java Supports Windows, Linux, and Mac OS X platforms Default connectivity by using the Java Database Connectivity (JDBC) thin driver Connects to Oracle Database version 9.2.0.1 and later ble a Freely downloadable from the following link: r fe
s
n – http://www.oracle.com/technology/products/database/sql_de a r t veloper/index.html on-
n a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a SQL Developer 1.5 is shipped along with Oracle Database 11g Release 2. SQL Oracle S i a Developer is developed in Java leveraging the Oracle JDeveloper integrated development
Vij
Specifications of SQL Developer
environment (IDE). Therefore, it is a cross-platform tool. The tool runs on Windows, Linux, and Mac operating system (OS) X platforms. Default connectivity to the database is through the JDBC thin driver, and therefore, no Oracle 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 5
e
ns e c li
SQL Developer 2.1 Interface
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
SQL Developer 2.1 Interface
Reports
You must define a connection to start using SQL Developer for running SQL queries on a database schema.
e
Files
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a SQL Developer 2.1 interface contains three main navigation tabs, from left to right: The S i a SQL Developer 2.1 Interface •
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 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.
General Navigation and Use SQL Developer uses the left side for navigation to find and select objects, and the right side to display information about selected objects. You can customize many aspects of the appearance and behavior of SQL Developer by setting preferences. Note: You need to define at least one connection to be able to connect to a database schema and issue SQL queries or run procedures/functions.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 6
Menus
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
The following menus contain standard entries, plus entries for features specific to SQL Developer: •
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
•
Run: Contains the Run File and Execution Profile options that are relevant when a function or procedure is selected, and also debugging options
•
Edit: Contains options for use when you edit functions and procedures
•
Versioning: Provides integrated support for the following versioning and source control systems: Concurrent Versions System (CVS) and Subversion
•
Migration: Contains options related to migrating third-party databases to an Oracle database
•
Tools: Invokes SQL Developer tools such as SQL*Plus, Preferences, and SQL Worksheet
le b a r Note: The Run menu also contains options that are relevant when a function or feprocedure is s selected for debugging. n tra n no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a s ( u h i Sa
Vija
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 7
e
ns e c li
Creating a Database Connection
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Creating a Database Connection • •
You must have at least one database connection to use SQL Developer. You can create and test connections for multiple: – Databases – Schemas
•
e
SQL Developer automatically imports any connections e defined in the tnsnames.ora file on your system. abl
ns e c li
Vij
r e f s • You can export connections to an Extensible Markup n a r t Language (XML) file. onn acreated • Each additional database connection is listed in s ฺ a e the Connections Navigator hierarchy. ) h Guid m co ent ฺ l i ma Stud g 1@ this 2 y ja use i v to hu a s (a Database Connection Creating u h Aaconnection is a SQL Developer object that specifies the necessary information for S i a connecting to a specific database as a specific user of that database. To use SQL Developer,
you must have at least one database connection, which may be existing, created, or imported. You can create and test connections for multiple databases and for multiple schemas. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 8
Creating a Database Connection
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Creating a Database Connection
2
1
e
3
le
b fera
ns e c li
s
n a r t n-
Vija
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to h a Creating asDatabase Connection (continued) ( u To h create a database connection, perform the following steps: a S i
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 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.
Using SQL Developer Chapter 17 - Page 9
d) Click Connect
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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 for the password.
i a j i V
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. Note: From the same New/Select Database Connection window, You can also connect to schemas for selected third-party (non-Oracle) databases, such as MySQL, Microsoft SQL Server, Sybase Adaptive Server, Microsoft Access, and IBM DB2, and view metadata and data. However, these connections are read-only connections that enable you to browse objects and data in that data source.
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 10
ns e c li
Browsing Database Objects
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Browsing Database Objects Use the Connections Navigator to: • Browse through many objects in a database schema • Review the definitions of objects at a glance
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a you create a database connection, you can use the Connections Navigator to browse After S i a through many objects in a database schema including Tables, Views, Indexes, Packages, Browsing Database Objects
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 11
Displaying the Table Structure
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Displaying the Table Structure Use the DESCRIBE command to display the structure of a table:
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h aSQL Developer, you can also display the structure of a table using the DESCRIBE In S i a command. The result of the command is a display of column names and data types as well as Displaying the Table Structure
an indication if a column must contain data.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 12
Browsing Files
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Browsing Files Use the File Navigator to explore the file system and open system files.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can use the File Navigator to browse and open system files. You S i a Browsing Database Objects •
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 13
Creating a Schema Object
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Creating a Schema Object •
SQL Developer supports the creation of any schema object by: – Executing a SQL statement in SQL Worksheet – Using the context menu
• •
Edit the objects by using an edit dialog box or one of the many context-sensitive menus. ble View the data definition language (DDL) for adjustments a r fe such as creating a new object or editing an existing s n a schema object. n-tr
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a Developer supports the creation of any schema object by executing a SQL statement in SQL S i a SQL Worksheet. Alternatively, you can create objects using the context menus. When
Vij
Creating a Schema Object
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 14
e
ns e c li
Creating a New Table: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Creating a New Table: Example
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h athe Create Table dialog box, if you do not select the Advanced check box, you can create a In S i a table quickly by specifying columns and some frequently used features. Creating a New Table: Example
If you select the Advanced check box, the Create Table dialog box changes to one with multiple options, in which you can specify an extended set of features while you create the table. 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 15
Using the SQL Worksheet
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using the SQL Worksheet • •
Use the SQL Worksheet to enter and execute SQL, PL/SQL, and SQL *Plus statements. Specify any actions that can be processed by the database connection associated with the worksheet.
e
le
b fera
ns e c li
s
n a r t n-
Vij
no Click the Open SQL a s ฺ Worksheet icon. a e h d ) Gui m Select SQL Worksheet o from the Tools menu, lฺc dent i a or m Stu g 1@ this 2 y ja use i v to hu a s ( SQL Worksheet Usinguthe h a you connect to a database, a SQL Worksheet window for that connection automatically When S i a opens. You can use the SQL Worksheet to enter and execute SQL, PL/SQL, and SQL*Plus
statements. The SQL Worksheet supports SQL*Plus statements to a certain extent. SQL*Plus statements that are not supported by the SQL Worksheet are ignored and not passed to the database. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 16
Using the SQL Worksheet
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using the SQL Worksheet 2
1
4
3
6
5
10
8
7
e
9
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a may want to use the shortcut keys or icons to perform certain tasks such as executing a You S i a SQL statement, running a script, and viewing the history of SQL statements that you have Using the SQL Worksheet (continued)
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 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 17
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
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
10. SQL History: Displays a dialog box with information about SQL statements that you have executed
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 18
ns e c li
Using the SQL Worksheet
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using the SQL Worksheet • •
Use the SQL Worksheet to enter and execute SQL, PL/SQL, and SQL*Plus statements. Specify any actions that can be processed by the database connection associated with the worksheet.
e
Enter SQL statements.
le
b fera
ns e c li
s
n a r t n-
no a eฺ hasResults d i ) m t Gu are o c ilฺ den shown here. a m Stu g 1@ this 2 y ja use i v u to sah
Vij
( u h a you connect to a database, a SQL Worksheet window for that connection automatically When S i a opens. You can use the SQL Worksheet to enter and execute SQL, PL/SQL, and SQL*Plus Using the SQL Worksheet (continued)
statements. All SQL and PL/SQL commands are supported as they are passed directly from the SQL Worksheet to the Oracle database. SQL*Plus commands used in the SQL Developer have to be interpreted by the SQL Worksheet before being passed to the database. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 19
Executing SQL Statements
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Executing SQL Statements Use the Enter SQL Statement box to enter single or multiple SQL statements. Ctrl+Enter
F5
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a example in the slide shows the difference in output for the same query when the Run The S i a Statement command (Ctrl+Enter key) is used versus the output when Run Script (F5 key) is Executing SQL Statements used.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 20
Saving SQL Scripts
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Saving SQL Scripts 1
Click the Save icon to save your SQL statement to a file.
e
3
The contents of the saved file are visible and editable in your SQL Worksheet window.
2
le
b fera
Identify a location, enter a file name, and click Save.
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can save your SQL statements from the SQL Worksheet into a text file. To save the You S i a contents of the Enter SQL Statement box, follow these steps: Saving SQL Scripts
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 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 21
Executing Saved Script Files: Method 1
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Executing Saved Script Files: Method 1 1. 2.
1
Use the Files tab to locate the script file that you want to open. Double-click the script to display the code in the SQL Worksheet.
3
To run the code, click either: • Run Script (F5), or • Run Statement (Ctrl +Enter)
2 Select a connection from the drop-down list.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u h ScripttoFiles: Method 1 a ExecutingsSaved ( u To h open a script file and display the code in the SQL Worksheet area, perform the following: a S i
Vija
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. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 22
e
ns e c li
Executing Saved Script Files: Method 2
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Executing Saved Script Files: Method 2 Use the @ command followed by the location and name of the file you want to execute, and click the Run Script icon.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
The output from the script is displayed on the Script Output tabbed page.
Vij
( u h a run a saved SQL script, perform the following: To S i a Executing Saved Script Files: Method 2
1. Use the @ command, followed by the location, and name of the file you want to run, in the Enter SQL Statement window. 2. Click the Run Script icon.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 23
Formatting the SQL Code
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Formatting the SQL Code Before formatting
After formatting
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a may want to beautify the indentation, spacing, capitalization, and line separation of the You S i a SQL code. SQL Developer has a feature for formatting SQL code. Formatting the 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 and the statement not properly indented. After formatting, the SQL code is beautified with the keywords capitalized and the statement properly indented.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 24
Using Snippets
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Snippets Snippets are code fragments that may be just syntax or examples. From the drop-down list, you can select the functions category that you want.
le
b fera
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
( u h a may want to use certain code fragments when you use the SQL Worksheet or create or You S i a edit a PL/SQL function or procedure. SQL Developer has the feature called Snippets.
Vij
Using 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.
The Snippets window is displayed at the right side. You can use the drop-down list to select a group.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 25
e
ns e c li
Using Snippets: Example
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Using Snippets: Example
Inserting a snippet
e
le
b fera
ns e c li
s
Editing the snippet
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a insert a Snippet into your code in a SQL Worksheet or in a PL/SQL function or procedure, To S i a drag the snippet from the Snippets window into the desired place in your code. Then you can Using Snippets: Example
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 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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 26
Debugging Procedures and Functions
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Debugging Procedures and Functions •
•
•
Use SQL Developer to debug PL/SQL functions and procedures. Use the “Compile for Debug” option to perform a PL/SQL compilation so that the procedure can be debugged. Use the Debug menu options to set breakpoints, and to perform the step into and step over tasks. m)
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ co ent G ฺ l i ma Stud g 1@ this 2 y ja use i v u to
h
a s ( u
Debugging Procedures and Functions
V
h Developer, you can debug PL/SQL procedures and functions. Using the Debug menu aSQL In S i ija options, you can perform the following debugging tasks: •
Find Execution Point goes to the next execution point.
•
Resume continues execution.
•
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 27
Database Reporting
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Database Reporting SQL Developer provides a number of predefined reports about the database and its objects.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Developer provides many reports about the database and its objects. These reports can SQL S i a be grouped into the following categories: Database Reporting
•
About Your Database reports
•
Database Administration reports
•
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.
Using SQL Developer Chapter 17 - Page 28
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
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.
i a j i V
e
le
s
b fera
n a r t n-
ahu
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
(
S
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 29
ns e c li
Creating a User-Defined Report
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Creating a User-Defined Report Create and save user-defined reports for repeated use.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tureports Organize de in folders. m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a User-defined reports are reports created by SQL Developer users. To create a user-defined S i a report, perform the following steps: Creating a User-Defined Report
1. Right-click the User Defined Reports node under Reports, and select Add Report. 2. In the Create Report dialog box, specify the report name and the SQL query to retrieve 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 30
External Tools
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
External Tools
Shortcuts to frequently used tools
e
le
b fera
ns e c li
s
1
n a r t n-
no a has uideฺ2 ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a enhance productivity of the SQL developers, SQL Developer allows you to add shortcut To S i a icons to some of the frequently used tools such as Notepad, Microsoft Word, and Search Engines and External Tools Dreamweaver, available to you.
You can add external tools to the existing list or even delete shortcuts to tools that you do not use frequently. To do so, perform the following: 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 31
Setting Preferences
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Setting Preferences • •
Customize the SQL Developer interface and environment. In the Tools menu, select Preferences.
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a can customize many aspects of the SQL Developer interface and environment by You S i a modifying SQL Developer preferences according to your preferences and needs. To modify Setting Preferences
SQL Developer preferences, select Tools, then Preferences. The preferences are grouped into the following categories: •
Environment
•
Accelerators (keyboard shortcuts)
•
Code Editors
•
Database
•
Debugger
•
Documentation
•
Extensions
•
File Types
•
Migration
•
PL/SQL Compilers
•
PL/SQL Debugger, and so on Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 32
Resetting the SQL Developer Layout
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Resetting the SQL Developer Layout
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a working with SQL Developer, if the Connections Navigator disappears or if you cannot While S i a dock the Log window in its original place, perform the following steps to fix the problem: Resetting the SQL Developer Layout
1. Exit from SQL Developer. 2. Open a terminal window and use the locate command to find the location of windowinglayout.xml. 3. Go to the directory which has windowinglayout.xml and delete it. 4. Restart SQL Developer.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 33
Summary
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2010, Oracle and/or its affiliatesฺ
Summary In this appendix, you should have learned how to use SQL Developer to do the following: • Browse, create, and edit database objects • Execute SQL statements and scripts in SQL Worksheet • Create and save custom reports
e
le
b fera
ns e c li
s
n a r t n-
no a has uideฺ ) om nt G c ฺ l ai tude m g sS @ 1 hi 2 t y e ija us v u to sah
Vij
( u h a Developer is a free graphical tool to simplify database development tasks. Using SQL SQL S i a Developer, you can browse, create, and edit database objects. You can use SQL Worksheet Summary
to run SQL statements and scripts. SQL Developer enables you to create and save your own special set of reports for repeated use.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using SQL Developer Chapter 17 - Page 34
View more...
Comments
