Sideris-Oracle Database 11g R2 Tuning-1

Oracle Database 11g R2: SQL Tuning 1
Oracle Database 11g R2: SQL Tuning by Sideris Courseware Corporation Sideris 2011 (577 pages) Citation ISBN:9781936930029 A mandatory reference for any database administrator or SQL database application developer, this book covers the internals of SQL statement execution, how to monitor the performance of such execution, and how to influence the behavior to achieve performance gains.
Recommend? Table of Contents Oracle Database 11g R2SQL Tuning Introduction Workshop Setup Guide Section 1 - Tuning & the Oracle Database Advisory Framework
Workshop Section - Tuning & the Oracle Database Advisory Framework Section 2 - Viewing & Monitoring the Execution Plan
Workshop Section - Viewing & Monitoring the Execution Plan Section 3 - Understanding the Optimizer
Workshop Section - Understanding the Optimizer Section 4 - Execution Plan Methods & Operations
Workshop Section - Execution Plan Methods & Operations Section 5 - Managing Optimizer Statistics
Workshop Section - Managing Optimizer Statistics Section 6 - Enhanced Optimizer Statistics
1|Page
Workshop Section - Enhanced Optimizer Statistics Section 7 - Histograms & Extended Statistics
Workshop Section - Histograms & MultiColumn Statistics Section 8 - Application Tracing
Workshop Section - Application Tracing Section 9 - ADDM & the SQL Tuning Advisor
Workshop Section - ADDM & the SQL Tuning Advisor Section 10 - The SQL Access Advisor
Workshop Section - The SQL Access Advisor Section 11 - Plan Management
Workshop Section - Plan Management Section 12 Section 13 - Managing Cursor Sharing - Optimizer Hints
Workshop Section - Optimizer Hints List of Sidebars
Introduction
Objectives

About This Textbook About The Sample Databases
About This Textbook

Objectives This learning guide will equip database administrators and application developers to build efficient SQL statements and to tune database applications. When this
2|Page
effort is complemented by database server and PL/SQL application tuning, then a highly efficient application execution environment is created. One will learn about the internals of SQL statement execution, how to monitor the performance of such execution, and how one can influence the behavior of the database to achieve performance gains. This textbook is a mandatory reference for any database administrator or SQL database application developer. The following specific topics are among those considered:
Consider the unique and differing tuning issues found in online database applications, enterprise resource and data warehouse environments and the important metrics of SQL statement performance. Learn about the internal mechanisms use for SQL statement execution within a database instance and how these can affect performance for good or bad, including the Optimizer facilities known as the Transformation Engine, Estimator and Plan Generator. Use a variety of techniques to examine the details of SQL statement execution, spotting trouble areas and bottlenecks which require tuning. Learn about the Auto-Task framework and how to manage the automatic collection of Optimizer statistics and automatic SQL tuning using both the programmatic and Enterprise Manager interfaces. Learn how statistic deficiencies can dramatically degrade performance, and how these problems are resolved through customized Optimizer statistics collection procedures using the DBMS_STATS() package, system statistics, histograms, expression statistics and MultiColumn statistics. Influence the behavior of the Optimizer by setting database parameters and other SQL tuning techniques. Utilize the database advisory framework and the SQL Tuning and SQL Access advisors. Use plan management to achieve plan stability which is adaptive and even dynamic. Understand the self-tuning infrastructure and the automatic SQL tuning capabilities found within the database. Employ SQL hints embedded into the statement text to resolve unique tuning challenges. Learn to identify poorly performing SQL statements using real-time SQL monitoring and application tracing techniques such as DBMS_MONITOR(), trcsess and tkprof.
Target Audience
3|Page
The primary target audiences for this course are:

Senior application designers and database developers PL/SQL developer Database administrators Web server administrators System administrators Implementation specialists Data center support engineers
Course Prerequisites Specific prerequisites for this course are the following Sideris titles, or equivalent experience:

Oracle Database 11g: SQL Fundamentals Complete Library Oracle Database 11g: Architecture & Internals
Suggested Next Courses You may wish to consider the following courses which are also related to the subject of Oracle database performance tuning:

Oracle Database 11g: Resource Manager & Scheduler Oracle Database 11g: Advanced PL/SQL Programming & Tuning Oracle Database 11g: Performance Tuning Oracle Database 11g: Implement Parallel SQL & Partitioning
Certification Examination This course covers information relevant for the certification test Exam 1Z0-054: Oracle Database 11g: Performance Tuning. Instructor-Led Training (ILT) / Live Virtual Training Schedule [kit] When delivered as a standalone instructor-led training (ILT) or live virtual training session, the suggested length of this module is between 3 4 days. It is most often joined with the mandatory prerequisite course Oracle Database 11g: Architecture & Internals for a combined 5-day presentation.
4|Page
Learning Resources Online resources and e-learning modules for this training course are available from the Sideris portal at http://www.SiderisPress.com.
These resources from the Sideris portal may be used along with this textbook for any of the following training formats:
Self-study This textbook includes extensive examples and workshop solutions, allowing it to be used both on a self-study basis and as a long-term individual reference. Enhanced ILT Integrate these online resources into the ILT presentations to improve the learning experience and extend beyond the traditional instructor-led training model. Distance-learning Use low-cost web-based conference and training services to deliver live virtual training sessions.
Resource Files Each course offers electronic resources useful for instructors and students. Included with these resources is a package which contains workshop files for exercises in this course. You can download these and other resources, from the appropriate course link within the Sideris portal.
5|Page
This is a summary of the resource files package available for this course module.
Open table as spreadsheet
Files EmployeeAdd1000.sql, EmployeeAdd1000Doe.sql, ProjectAdd1000.sql CompanyConstraintsPK.sql
EquitiesDefine.sql, EquitiesInsert.sql
BrokeragesAdd100000.sql
SQLTuningSetup.sql, SQLTuningTest.sql
SQLTuningMonitoredSQL.sql, SQLTuningProjectAdd1000.sql
Explanation Workshop files to quickly increase the size of tables within the sample COMPANY database. Workshop file to add primary key constraints and accompanying indexes to the sample COMPANY database. Workshop files to create a data warehouse star schema sample data model known as the EQUITIES database. This will be used for selected demonstrations and workshops to supplement the standard ELECTRONICS and COMPANY data models. Workshop file to quickly increase the size of table(s) within the sample EQUITIES database. Workshop files which create a large SQL statement execution processing load on the database based upon a huge expansion of the population of the sample EQUITIES database. Workshop files for Section 2 Viewing & Monitoring The Execution Plan
The following files provide solutions for the more complex workshop exercises.
6|Page
Files Solutions02ViewPlan.sql Solutions03Optimizer.sql Solutions05OptimizerStats.sql Solutions06 EnhancedOptimizerStats.sql Solutions07ExtendedStats.sql Solutions10 SQLAccessAdvisor.sql
Explanation Solutions for selected exercises from Section 2 Viewing & Monitoring The Execution Plan Solutions for selected exercises from Section 3 Understanding The Optimizer Solutions for selected exercises from Section 5 Managing Optimizer Statistics Solutions for selected exercises from Section 6 Enhanced Optimizer Statistics Solutions for selected exercises from Section 7 Histograms & Extended Statistics Solutions for selected exercises from Section 10 The SQL Access Advisor
To access these files, visit the Sideris portal, click on the course link which corresponds to this course and login to the site.
Your login credentials for this course are Username 978-1-936930-02-9 and Password sqltun.ng500 and these should be entered when you are prompted for these.
About the Sample Databases

7|Page
This course uses the sample data models known as the COMPANY and ELECTRONICS databases. These are highly simplified transactional data models which adequately support the objectives of the workshops without introducing unnecessary complexity. A useful description of these data models is available online from the Sideris portal.
It is usually good practice for one to reinitialize these sample databases at the start of each new workshop, unless specifically requested otherwise. The Workshop Setup Guide will provide instructions on initializing the sample databases.
Workshop Setup Guide

About the Workshop Setup
8|Page
Unless you have already done so, it is necessary to configure a workshop environment in order for one to complete the exercises within this course. Help is available online at the Sideris portal, under the link for this course. From this point one can find an extensive Workshop Setup Guide along with other workshop setup resources. We encourage you to download the Guide and complete the setup in advance of the start of the course.
Section 1: Tuning & the Oracle Database Advisory Framework

Overview
Objectives

Understand The Challenges Of Tuning Performance Metrics About The Management & Advisory Framework SQL Tuning Privileges
Section Overview
Tuning of database operations and application elements such as SQL statements is a fundamental task of database administrators and senior application developers. When tuning is to be performed within an Oracle database environment, there are some essential facts which one should understand before embarking on any tuning effort. Within this section we will explore these topics:
9|Page
Consider the basic principles of database and application tuning and the challenges associated with using those principles. Review fundamental database processing metrics and how these are used in tuning measurements and analysis. Introduce the Management and Advisory framework provided within the Oracle database architecture. Configure and use the Enterprise Manager interface for application tuning
Even the most functionally robust and well-built application would be considered a failure if its execution speed and overall performance did not meet acceptable service levels. Therefore, one of the prime considerations that administrators and developers must consider is the tuning of application code, including SQL statements.
The Challenges of Tuning

Tuning of information systems is one of the most challenging tasks and the true improvement of performance is an elusive goal. This is likewise true within an Oracle database environment and the application code which executes within that environment. Among the factors which complicate the tuning effort are these:

Isolating the problem Improving response time Identifying external factors Addressing application and logical database design
Isolating the Problem The first challenge is to isolate exactly where the performance problem lies. For example, in the case of a SQL statement which executes poorly, the performance of the statement may be only a symptom, not the actual problem. The underlying problem may lie within the overall database configuration or operation. Or it may be the PL/SQL application in which the SQL statement is found. Conversely, one may begin with a focus on the database or a PL/SQL program unit only to find that an embedded SQL statement is the true source of the problem.
10 | P a g e
Furthermore, SQL statement performance cannot be separated from the performance of the database in general. This often indicates that a collaborative approach to performance tuning is required. Database, system and network administrators typically address performance issues which arise from database configuration, host system configuration and network design. Senior database developers generally address issues related to SQL statement construction and database-resident program design using PL/SQL and Java. And both groups must work together in the diagnosis effort. In the comments which follow, we will discuss further how these various interrelated factors can affect database and application performance. About Response Time In the context of SQL statement execution, response time is the time to receive a response from the database for a SQL statement, as the response perceived by the user or the application. The ultimate goal of a tuning effort will primarily seek to improve the response time. Identifying External Factors Other, more distant, external factors can also have a dramatic impact on performance. One of the most important is the hardware and software environment within the overall systems infrastructure. Just as a SQL statement is affected by the database environment in which it executes, on an even larger level the entire database installation is itself affected by the execution environment. Therefore, tuning, configuring, troubleshooting the overall systems architecture is also critical. Similarly, adding additional hardware resources may be a necessary step. Database installations, in turn, exist within a systems area (SAN), local area (LAN) or wide area network (WAN). Network design and configuration is another important factor. This is especially true with modern 3-tier and n-tier application environments. In such cases SQL statements may be issued from application servers, clients and users may be connected to web and HTTP servers, and so on.
11 | P a g e
Application & Logical Database Design One of the most fundamental problems which can contribute to poor systems performance is poor application design. This could be the design of the logic within the application modules or the logical data model upon which the database application is based. It is nearly impossible to tune an application when its design is poor. Thus, the best database design and the most expensive hardware resources can all be squandered by poor application design. Curriculum Note For these reasons one should consider this course as only one in a series which address various aspects of Oracle database and application performance tuning. One should also consider the Sideris courses Relational Database Design & Data Modeling, Oracle Database 11g: Advanced PL/SQL Programming & Tuning, Oracle Database 11g: Resource Manager & Scheduler and Oracle Database 11g: Performance Tuning.
Performance Metrics
12 | P a g e
Performance is measured by means of timed statistics or metrics. These are measurements which are taken for specific elements of processing. The sum total of these values amounts to what are called timings. Once these timings have been computed, one can make a determination as to whether a particular statistic indicates acceptable or unacceptable performance. Certainly it is important for one to track changes to these metrics. In other words, while one could debate whether a particular metric value is acceptable or not, it is very obvious when comparing new and old metric values whether performance is progressing or regressing. One must have a clear understanding of these metrics and their meaning in order to succeed at any tuning endeavor. Timed Statistics Consider some basic operational statistics which are captured to measure elements of database processing. CPU Statistics CPU statistics measure CPU usage. Measurements are available for particular functions of the database, such as parsing SQL statements prior to execution or the actual execution of SQL statements. Other CPU statistics may be aggregated to a higher level, such as total CPU consumption for a database session. I/O Statistics I/O statistics are measurements of Input and Output operations performed by the database instance to database files. These may also be known as read and write operations. In the context of an Oracle database, these are mostly I/O operations to the data files and the log files. I/O or read and write operations may be either logical or physical. Consider a SQL operation which requires data from a table. The SQL statement execution will first attempt to find the required blocks within the database cache. If the blocks are found within memory, then a logical read is performed from the buffer cache. If not found, a physical read is performed from the tablespaces stored in the data files. Once fetched from a physical read, the block is retained in the buffer cache for later reference in a logical read.
13 | P a g e
Obviously, a logical read from memory is preferable as this is faster than a physical read from disk. Thus, in addition to reducing overall reads, another performance goal may be to reduce physical reads in favor of logical reads. Wait Events Wait events are actions performed by the database which were momentarily suspended while the instance was waiting for a resource or an action to complete.
Note Wait events are among the most important to monitor, and among the most
serious performance problems to correct. While CPU and I/O statistics are subject to interpretation as to whether those values are appropriate for the task at hand, a wait event clearly is a symptom of a problem since the database is forced to wait to perform an action that it is otherwise ready to perform. Timings Now consider how these statistics are collected to produce meaningful timings. Response Time The ultimate measurement of any database or system processing is that of response time. This, in turn, is comprised of the following subsidiary elements:
Service time this is the actual processing or computing time necessary to complete a task. If changes can be made which reduce the required service time then clearly the response time will be better. Wait time this is the delay a task must wait for necessary resources in order to start. Even if the service time were not reduced, if the wait time were reduced or eliminated then this would still have a significant impact on response time.
Thus, the response time may be improved by improving either or both of the elements which comprise response time. Of course, ideally one will seek to reduce both the service time and the response time. Database Time Each phase of SQL statement or database-resident program unit execution is considered to be a call. For example, the parse, the execution and the fetch phases for a given SQL statement are all considered to be calls. Each user login event is also considered as a call.
14 | P a g e
The service time of a database operation is known as database time is also known as db time. This is a most important fundamental measure of database performance. It represents the total amount of time the database instance spent processing database calls, and it is also measured on a per-call basis. Considering what you have learned, database time is the sum of these elements:

CPU time Wait time
Elapsed Time Elapsed time is also known as clock time. This is simply the duration as measured in human terms in which a monitored event occurs.
Management & Advisory Framework
A very robust framework is built into the Oracle database architecture which is devoted towards database, application and SQL statement performance monitoring and tuning. This is part of a design known as the management and advisory framework. The interface to this framework is the Oracle Enterprise Manager (EM) tool. While primarily a management interface for database administrators, it can also be used by senior application developers for PL/SQL and Java database-resident application module tuning and SQL statement execution monitoring and tuning. Some of its many duties relate to the collection, consolidation and interpretation of timed statistics and database timings for numerous operations. How Does This Help? Specific to SQL statement tuning, advisors exist within this framework which can perform the following tasks using sophisticated logic:
Isolate tuning problems by identifying poorly performing program units and SQL statements as measured by timed statistics.
15 | P a g e
Diagnose the underlying problem by identifying poorly constructed SQL statements which should be rewritten. Diagnose logical database design problems which affect SQL statement execution by suggesting logical objects which should be created, dropped or redesigned.
ADDM & AWR
The following are the major components within this framework that make this possible:
Automatic Workload Repository (AWR) the MMON statistics collection process is constantly collecting execution statistics for the database and SQL statements and storing these in a self-monitoring performance data warehouse. Automatic Database Diagnostics Monitor (ADDM) this is a highlyintelligent analysis tool which mines the data within AWR and produces performance tuning findings. Based upon the findings, recommendations
16 | P a g e
may be produced for the tuning specialist to run selected advisors from the advisory framework. Advisors such as the SQL Tuning Advisor or the SQL Access Advisor will recommend specific configuration changes either to the database, the application, or both.
While we will discuss more about the capabilities of the Advisory Framework, it is important that tuning specialists are able to access these features from the EM interface.
SQL Tuning Privileges

A variety of system and object privileges are required for one to perform SQL statement tuning. Database administrators often have such privileges, with the default administrator account SYSTEM having all such privileges. But in following established security principles, users should only be granted those privileges necessary to perform their duties. Therefore, the privileges required to authorize someone, such as a senior application developer, to use the EM interface and otherwise access the Advisory framework of the Oracle database must be explicitly granted. Object Privileges The EXECUTE object privilege is required for any system-supplied package to be used. Those packages which are most often used in the SQL statement tuning effort and for which the EXECUTE object privilege is required are as follows:

DBMS_ADVISOR() DBMS_APPLICATION_INFO DBMS_MONITOR() DBMS_OUTLN() DBMS_OUTLN_EDIT() DBMS_SERVER_ALERT() DBMS_SQLTUNE() DBMS_STATS() DBMS_SYSTEM() DBMS_WORKLOAD_REPOSITORY() DBMS_XPLAN()
17 | P a g e
EM Database Privileges The EM interface provides the easiest access to the Advisory framework. Many of the required system-supplied package object privileges can be obtained by authorizing EM access. The following system privileges should be considered when one wishes to provide access to the Advisory framework through the EM interface.
Privilege OEM_ADVISOR
ADVISOR
ADMINISTER SQL TUNING SET
CREATE JOB
SELECT ANY DICTIONARY
Explanation This role combines the ADVISOR, ADMINISTER SQL TUNING SET and CREATE JOB privileges. Together with the SELECT ANY DICTIONARY system privilege it would provide most rights needed for an application developer to perform SQL statement tuning. This system privilege essentially provides access to the advisory framework, primarily through the DBMS_ADVISOR() package. However, certain related tasks such as creating SQL Tuning Sets and SQL Profiles or scheduling SQL Tuning Advisor jobs, require additional privileges as shown below. This system privileges allows one to create and manage SQL Tuning Sets. ADMINISTER ANY SQL TUNING SET allows one to access STS in other schemas. This system privilege allows one to create jobs, schedules or programs using the database scheduler. CREATE ANY JOB allows one to create these objects in another schema. Since this latter privilege would essentially inherit the privileges of any other user for execution of jobs it should be carefully guarded. This system privilege permits SELECT access to any object within the SYS schema, including the actual base tables as well as the more common data dictionary views. This is the most basic system privilege required to be able to at least logon to EM
18 | P a g e
Privilege
Explanation and utilize its graphical interface. SELECT_CATALOG_ROLE This is a role which is more restrictive than SELECT ANY DICTIONARY and can often be used in its place. It provides SELECT access to all data dictionary views but not the underlying base tables. CREATE ANY SQL This system privilege, along with the related ones PROFILE of DROP ANY SQL PROFILE and ALTER ANY SQL PROFILE allow one to create and manage SQL Profiles suggested by the advisory framework. The following command might be used to authorize an application developer to perform SQL monitoring and tuning through the EM interface.
SQL> CONNECT / AS SYSDBA; Connected. SQL> GRANT oem_advisor, SELECT ANY DICTIONARY, CREATE ANY SQL PROFILE, DROP ANY SQL PROFILE, ALTER ANY SQL PROFILE TO student1; Grant succeeded.
If the same account which is authorized in this way to use the EM interface is also the owner of the application schema or data model, then one will be fully equipped to perform application monitoring, tracing and tuning.
Section Review
Remember These Points
The goals of database application tuning include (1) isolating the real problem, (2) improving response time (3) identifying any applicable external factors and (4) addressing application and logical database design issues.
19 | P a g e
Response Time is a combination of Service Time and Wait Time. Service Time is known as database time when measuring the duration of database calls. Wait Time is one of the most important metrics to measure and reduce. Elapsed Time is the duration of an operation as measured in human terms. The Advisory framework within the Oracle database allows one to reach the goals of database application tuning as these relate to SQL statements, collecting Specific privileges may be granted to allow one to access the Advisory framework, either programmatically or through the EM interface.
Workshop Section: Tuning & the Oracle Database Advisory Framework

Exercises
What You Will Do within This Workshop In this workshop you will:

Authorize an application developer account to use the Advisory framework and the EM interface. Verify the database installation and developer authorization by entering the EM interface.
Advisory Framework-1
Since you are likely using a sample database installation created for the purpose of this course, you could decide to use the default database administrator account SYSTEM and the super administrator account SYS for all the workshop exercises of this course. Alternatively, if you wish to authorize a separate account, you could do so by granting appropriate system privileges to the owner
20 | P a g e
of the sample database schemas. We recommend this latter option. Answers

SQL> CONNECT / AS SYSDBA; Connected. SQL> GRANT oem_advisor, SELECT ANY DICTIONARY, CREATE ANY SQL PROFILE, DROP ANY SQL PROFILE, ALTER ANY SQL PROFILE TO student1; Grant succeeded.
Advisory Framework-2
If you have successfully completed the installation process, you should be ready to use the Database Control. Launch a browser and enter the URL presented during the installation. If you are able to connect successfully, familiarize yourself with the presentation by navigating to these locations: o Home page sections o Performance page o Availability page o Server page o Schema page o Data Movement page o Software And Support page
Answers To connect to the database using the EM Database Control: 1. Open a browser window. 2. In the browser address or URL field enter https://host:port/em where HOST represents your database host system name and PORT represents the Database Control port number reported during the database software installation. 3. Type in the username and password for an administration account, perhaps
21 | P a g e
using the default EM administrator account SYSMAN. 4. If you authorized another account to use the EM interface, then login again using those credentials. You should be able to peruse the full range of presentation screens using this account as well.
You should see the home page similar to what is shown here, and you can briefly navigate through the interface if you are not already familiar with it. Advisory Framework-3
In addition to the standard sample data models named COMPANY and ELECTRONICS which are used throughout our curriculum, in this course we will also make periodic use of a more complex data model typical of that found within a data warehouse environment. This warehouse model is named the EQUITIES database. The EQUITIES sample database is based upon a star schema model. Using the same database account in which you already created the other sample databases, execute the EquitiesDefine.sql and EquitiesInsert.sql scripts to also create this advanced model. This will allow us to produce examples and demonstrations during this course from whichever of these data models is best suited to the
22 | P a g e
discussion at hand. Answers

SQL> CONNECT student1/student1; Connected. SQL> @ EquitiesDefine.sql ... SQL> @ EquitiesInsert.sql; ...
Section 2: Viewing & Monitoring the Execution Plan

Overview
Objectives

Learn More About The Execution Plan Collecting Operational Statistics Viewing The Execution Plan Real-Time SQL Monitoring
Section Overview
As you will soon learn, the efficiency with which a SQL statement executes is largely determined by its execution plan. The execution plan, in turn, is generated by a database facility known as the Optimizer. Thus, a critical capability which one must obtain is the ability to view the execution plan selected for a given SQL statement. Within this section we will therefore consider:
Understanding the basic structure and elements of an execution plan.
23 | P a g e
Viewing an execution plan using SQL*Plus, the EM interface and other methods. Enable the SQL*Plus AUTOTRACE facility. Isolating SQL statement candidates for tuning using EM features such as Top Activity, Top SQL and Top Sessions. Automatic real-time SQL statement execution monitoring. Enhancing the database performance statistics collected for evaluation of execution plan efficiency.
Once we consider how one finds and views the selected execution plan for a SQL statement, we will progressively consider exactly what the operations listed within the plan mean. Our ultimate goal will be to ensure that these operations within the overall plan are the best for the SQL statement in question, and if not, to learn to apply techniques by which a better plan can be produced.
About the Execution Plan

The Plan Generator within the Optimizer produces one or more execution plans during the parse phase of SQL statement execution. Rightly or wrongly, one of these plans is ultimately chosen for execution. The execution plan is a treestructured series of steps which identifies the following elements of the plan:

Sources these are the database objects from which rows will be fetched during execution of the statement. Access method this is the method by which the rows are fetched from each source. Join method when tables are joined there are a variety of join methods from which the Optimizer may choose. Data operations these are operations which may be performed upon the data. For example, a filter operation is used to filter the rows accessed from a table based upon a SQL predicate. A sort operation would be applied when an ORDER BY clause is used. An aggregation operation might be found when a GROUP BY clause exists.
Sample Execution Plan For example, the following SQL statement might produce the corresponding execution plan which is shown thereafter.
24 | P a g e
SQL> SELECT LName, DName, Salary FROM employee INNER JOIN department ON dnumber = dno WHERE LName = 'Smith' ORDER BY DName; LNAME DNAME SALARY ---------- --------------- ---------Smith Research 30000 Q_PLAN ----------------------------------------SELECT STATEMENT SORT ORDER BY HASH JOIN TABLE ACCESS FULL EMPLOYEE TABLE ACCESS FULL DEPARTMENT
One must be clear that the internal execution plan for a SQL statement is entirely different from the SQL statement syntax submitted by the user. For example, the following SQL statement is logically identical to the one just shown. However, in this case the statement is built using older SQL92 syntax. Since these are logically identical, the Optimizer correctly selects the exact same execution plan, although the syntax of the two is quite different from each other.
SQL> SELECT LName, DName, Salary FROM employee, department WHERE dnumber = dno AND LName = 'Smith' ORDER BY DName; LNAME DNAME SALARY ---------- --------------- ---------Smith Research 30000 Q_PLAN ----------------------------------------SELECT STATEMENT SORT ORDER BY HASH JOIN TABLE ACCESS FULL EMPLOYEE TABLE ACCESS FULL DEPARTMENT
Reading An Execution Plan

25 | P a g e
The operations are read from right-to-left and from top-to-bottom. For example, starting from the rightmost operation, and then the top, the operation TABLE ACCESS FULL EMPLOYEE is found. This is executed first. Starting from the right and the top once again, the next operation found is TABLE ACCESS FULL DEPARTMENT, which is executed next as the plan is invoked. Following the same logic, the results from the first operation are input to a HASH JOIN operation. This is followed by a SORT induced by the ORDER BY clause. Lastly, the columns projected from the final result table are selected and output. Using the Execution Plans for Tuning Actions taken by the database administrator and by the application developer can affect the execution plans generated and selected by the Optimizer. Thus, one of the primary methods by which the developer will tune a SQL statement will be to examine the execution plan generated by the database for a given SQL statement. Similarly the Advisors and other sophisticated tuning tools will likewise examine the operations within the plan. By working with the database administrator where necessary, and by modifying the SQL statement and other database objects, one hopes to induce the Optimizer to select a better execution plan. Changes to the Oracle software from one version of the database to another might also affect the execution plan produced for a given SQL statement. Therefore, SQL statement tuning should be performed even for previously tuned applications whenever a new database version is installed to ensure that the optimum execution plan available is being produced. However, a mechanism known as plan stability or stored outlines, discussed later within this course, provides a means to insulate applications from such database version changes.
Collecting Performance Statistics

The database instance, the user sessions operating the SQL statements, or both may be placed into hypersensitive modes where a large number of database performance statistics are collected and are available for tuning analysis. Normally, one will not want to utilize these modes since they are cost prohibitive and will interfere with the operation of the database. However, while one is focused on the
26 | P a g e
tuning effort, these modes provide for a wealth of added operational information which is not normally available. Database Performance Statistics The STATISTICS_LEVEL database parameter may be set to either increase or decrease the set of performance statistics collected by the database instance from its default value. For the reasons explained, one will want to increase the statistics collection to its highest level only during focused database tuning and troubleshooting periods. Options available for this parameter are:
Value BASIC
Explanation This retains the least amount of performance statistics and essentially disables all of the proactive manageability features discussed in this section. This setting is not recommended. TYPICAL This is the default value and it captures all of the performance statistics generally needed for the Management and Advisory framework to maintain a healthy database. ALL This is a very costly option which should only be employed for a limited period of time and when necessary. Additional detailed statistics regarding the operating system and individual SQL statement execution are added to those normally collected. One might modify this setting using the SQL interface and the ALTER SYSTEM command.
SQL> CONNECT dba1/dba1; Connected. SQL> ALTER SYSTEM SET statistics_level = ALL SCOPE = BOTH; System altered.
SQL Tracing
27 | P a g e
In a similar manner, detailed performance statistics on the execution of individual SQL statements may be collected by enabling SQL tracing using the SQL_TRACE database parameter. This may be set at the instance-level for all sessions by using the ALTER SYSTEM command and restarting the database instance. For reasons of performance however, this is not recommended on a production database. Another alternative is to enable SQL tracing at the session level, and only for as long as the SQL tuning effort is ongoing. This may be done using the ALTER SESSION command:
SQL> CONNECT student1/student1; Connected. SQL> ALTER SESSION SET SQL_TRACE = TRUE; Session altered.
Note While the SQL_TRACE parameter is still supported for the sake of backward
compatibility, and we will make use of it initially within this course for the sake of simplicity, its use is deprecated. In a production environment it should be replaced with usage of the system-supplied packages DBMS_MONITOR() and DBMS_SESSION(). The use of these packages is discussed later within this course.
iewing the Execution Plan

There are several utilities which allow one to view execution plans. In order to do so, within the application schema one must create a utility table named PLAN_TABLE. This table will be used to hold the execution plans. Any of the utilities we will discuss which show and explain the plan will be able to do so using this table. Create PLAN_TABLE The PLAN_TABLE table may be created in an application schema by executing the script utlxplan.sql. The exact name and location of this script is operating
28 | P a g e
system and database installation dependent but is found in the standard location where database administrator scripts are located.
SQL> CONNECT student1/student1; Connected. SQL> @ C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxplan.sql Table created. SQL> DESCRIBE plan_table Name Null? ----------------------------------------- -------STATEMENT_ID PLAN_ID TIMESTAMP ... Type ----------------VARCHAR2(30) NUMBER DATE
Populate & Examine PLAN_TABLE There are several methods by which the plan of a given SQL statement may be stored and examined. The method you choose will be determined by the amount and format of the information you require, and the environment in which you are obtaining and examining the plan information. The SQL Statement Explain Plan The most primitive method is to use the EXPLAIN PLAN command. This command must specify a unique STATEMENT_ID value for the SQL statement, which will then allow one plan within the PLAN_TABLE structure to be distinguished from another. Generally one will only find this method employed in SQL tuning utilities which may have been created in a legacy installation of the database. Generating & Storing the Plan This statement will generate an execution plan for a SQL statement and store it within the table PLAN_TABLE under a unique statement ID.
SQL> EXPLAIN PLAN SET statement_id = 'TEST' FOR SELECT LName, DName, Salary 29 | P a g e
FROM employee INNER JOIN department ON dnumber = dno WHERE LName = 'Smith' ORDER BY DName; Explained.
Viewing the Plan Referencing the same STATEMENT_ID, the execution plan for the statement may be fetched from PLAN_TABLE and formatted.
SQL> SELECT LPAD(' ',2*LEVEL) || operation || ' ' || options || ' ' || object_name Q_PLAN FROM plan_table WHERE statement_id = 'TEST' CONNECT BY PRIOR ID = PARENT_ID AND STATEMENT_ID = 'TEST' START WITH ID = 0; Q_PLAN ----------------------------------------SELECT STATEMENT SORT ORDER BY HASH JOIN TABLE ACCESS FULL EMPLOYEE TABLE ACCESS FULL DEPARTMENT
Deleting the Plan Details Thereafter, the individual rows for the statement may be deleted from PLAN_TABLE if desired.
SQL> DELETE FROM plan_table WHERE statement_id = 'TEST'; 5 rows deleted.
The utlxpl*.sql Scripts Another method involves executing system-supplied scripts. These will output the most recent execution plan entered into the PLAN_TABLE.
30 | P a g e
utlxpls.sql
which will examine the execution plan for serial SQL which will examine the execution plan for parallelized SQL
statements
utlxplp.sql
statements It is still good practice to delete the old rows from the table PLAN_TABLE. And once again the exact name and location of these files are operating system and installation dependent:
SQL> EXPLAIN PLAN SET statement_id = 'TEST' FOR SELECT LName, DName, Salary FROM employee INNER JOIN department ON dnumber = dno WHERE LName = 'Smith' ORDER BY DName; Explained. SQL> @ C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxpls.sql ...
Viewing the Output The output generated by this method clearly offers much more information than the previous one. While the same operations are presented in the same sequence, the execution operation is clearly distinguished from the database object name upon which the operation occurred. Important performance information is also shown, including the number of rows and bytes involved in the operation, the relative cost in terms of CPU time and the elapsed time.
SQL> @ C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxpls.sql ... PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1937138517 ---------------------------------------------------------------------------------
31 | P a g e
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 30 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 30 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 30 | 7 (15)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 14 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 48 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("LNAME"='Smith') Note ----- dynamic sampling used for this statement (level=2)
Also of use in this output are predicates which are an integral part of certain operations. For instance, plan ID number 3 performs a full table scan but filters for those rows with a LNAME value of Smith. At this point we can start to demonstrate how the execution plan might be analyzed by one performing SQL tuning. The EMPLOYEE table is filtered first and therefore becomes the driving table for the join with the DEPARTMENT table. This is exactly the behavior that we want since it results in a very small join to the DEPARTMENT table using only those specific EMPLOYEE table rows which are needed. The System-Supplied Package DBMS_XPLAN() Yet another method, but producing the same output, involves calling the DISPLAY() procedure from the DBMS_XPLAN() system-supplied package. It effectively executes the same statement as that contained within the utlxpl*.sql scripts.
SQL> SELECT * FROM table(dbms_xplan.display); 32 | P a g e
PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1937138517 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 30 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 30 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 30 | 7 (15)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 14 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 48 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("LNAME"='Smith') Note ----- dynamic sampling used for this statement (level=2) 21 rows selected.
Controlling the Level of Detail The reason one might employ the DBMS_XPLAN() call is that the DISPLAY() procedure can accept several parameter values to indicate the level of detail desired. In the example shown above, the default detail level TYPICAL was implied. However, in the next example, we revert to just the basic operations within the plan.
SQL> SELECT * FROM table (dbms_xplan.display (table_name
=> NULL, 33 | P a g e
statement_id format );
=> NULL, => 'BASIC')
PLAN_TABLE_OUTPUT --------------------------------------------------------------------Plan hash value: 1937138517 -----------------------------------------| Id | Operation | Name | -----------------------------------------| 0 | SELECT STATEMENT | | | 1 | SORT ORDER BY | | | 2 | HASH JOIN | | | 3 | TABLE ACCESS FULL| EMPLOYEE | | 4 | TABLE ACCESS FULL| DEPARTMENT | -----------------------------------------11 rows selected.
The most detailed display is produced using the ALL parameter value, as is shown next.
SQL> SELECT * FROM table (dbms_xplan.display (table_name => NULL, statement_id => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1821410742 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 55 | 6 (34)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 55 | 6 (34)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 55 | 5 (20)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 33 | 2 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 66 | 2 (0)| 00:00:01 | 34 | P a g e
--------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------1 - SEL$58A6D7F6 3 - SEL$58A6D7F6 / EMPLOYEE@SEL$1 4 - SEL$58A6D7F6 / DEPARTMENT@SEL$1 Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("EMPLOYEE"."LNAME"='Smith') Column Projection Information (identified by operation id): ----------------------------------------------------------1 - (#keys=1) "DEPARTMENT"."DNAME"[VARCHAR2,15], "EMPLOYEE"."LNAME"[VARCHAR2,10], "EMPLOYEE"."SALARY"[NUMBER,22] 2 - (#keys=1) "EMPLOYEE"."LNAME"[VARCHAR2,10], "EMPLOYEE"."SALARY"[NUMBER,22], "DEPARTMENT"."DNAME"[VARCHAR2,15] 3 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "EMPLOYEE"."SALARY"[NUMBER,22], "DNO"[NUMBER,22] 4 - "DEPARTMENT"."DNAME"[VARCHAR2,15], "DNUMBER"[NUMBER,22] Note ----- dynamic sampling used for this statement (level=2)
Later within this course you will learn how to utilize these additional elements of the execution plan report.
Note The advantage of the methods for generating the execution plan shown thus
far is that although the plan is generated, the SQL statement is not actually executed. While there may be cases in which you will want to actually execute the statement as well and measure the timed statistics generated, in many cases it will be advantageous to examine and tune the execution plan initially without executing the statement. SQL*Plus Command Autotrace One can operate a SQL*Plus session in AUTOTRACE mode as a means of automatically producing Optimizer execution plan and execution statistics immediately after every SQL statement is issued and executed. When developing or debugging application SQL statements this offers a convenient means of obtaining SQL execution summary information quickly and easily.
35 | P a g e
Enabling the Utility First one must create the PLUSTRACE role within the database. This may be done by executing the SQL*Plus administration script plustrce.sql while connected as the user SYS. The exact location and name of this file is version and operating system dependent:
SQL> CONNECT / AS SYSDBA; Connected. SQL> @ $ORACLE_HOME\sqlplus\admin\plustrce.sql; SQL> drop role plustrace; drop role plustrace * ERROR at line 1: ORA-01919: role 'PLUSTRACE' does not exist SQL> create role plustrace; Role created. SQL> grant select on v_$sesstat to plustrace; Grant succeeded. SQL> grant select on v_$statname to plustrace; Grant succeeded. SQL> grant select on v_$mystat to plustrace; Grant succeeded. SQL> grant plustrace to dba with admin option; Grant succeeded.
Note Note that the directory which contains the SQL*Plus administration scripts is
different from the directory which contains the database administration scripts. You are more likely to have used the latter at some point in time, but the directory which contains the script in question here is different. Next, one must grant the PLUSTRACE role to each user who will use the AUTOTRACE feature
SQL> GRANT plustrace TO student1; Grant succeeded.
Set Autotrace Options One can now enable the AUTOTRACE option within a database session by means of the SQL*Plus command SET AUTOTRACE. Note the available options:
36 | P a g e
Option SET AUTOTRACE ON EXPLAIN SET AUTOTRACE ON STATISTICS SET AUTOTRACE TRACEONLY
Explanation This option shows the execution plan, including predicate information and any applicable notes. This option shows only the Statistics section of the execution plan. This is similar to the default SET AUTOTRACE ON and SET AUTOTRACE ON EXPLAIN STATISTICS with the exception that this option does not include the actual table output. Only the full set of execution plan details are displayed. Disables AUTOTRACE for the session.
SET AUTOTRACE OFF
If one simple issues the SET AUTOTRACE ON command, this is equivalent to SET AUTOTRACE ON EXPLAIN STATISTICS. Using Autotrace Consider a sample database session which uses this feature:
SQL> SET AUTOTRACE ON; SQL> SELECT LName, dependent_name FROM employee INNER JOIN dependent ON ssn = essn ORDER BY LName; LNAME ---------Smith Smith Smith ... DEPENDENT_ ---------Alice Elizabeth Michael
Execution Plan ---------------------------------------------------------Plan hash value: 1434111244 --------------------------------------------------------------------------------
37 | P a g e
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 7 | 252 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 7 | 252 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 7 | 252 | 7 (15)| 00:00:01 | | 3 | TABLE ACCESS FULL| DEPENDENT | 7 | 126 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEE | 8 | 144 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("SSN"="ESSN") Note ----- dynamic sampling used for this statement Statistics ---------------------------------------------------------327 recursive calls 0 db block gets 64 consistent gets 0 physical reads 0 redo size 598 bytes sent via SQL*Net to client 381 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 11 sorts (memory) 0 sorts (disk) 7 rows processed
V$SQL_PLAN View One can directly examine the execution plan of any SQL statement which has been executed and is currently stored within the SQL cursor cache. This may be done using the SQL interface and accessing the view V$SQL_PLAN. This view is comparable to the structure of the table PLAN_TABLE, and as such it can be viewed using an alternate program unit within the DBMS_XPLAN() package. Notice how the SQL ID for the cursor can be used with a call to the
38 | P a g e
DISPLAY_CURSOR() program unit, similar to the DISPLAY() example shown earlier.

SQL> SELECT * FROM table (dbms_xplan.display_cursor ( sql_id => '4fy39u3m71t03', cursor_child_no => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1821410742 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 55 | 6 (34)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 55 | 6 (34)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 55 | 5 (20)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 33 | 2 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 66 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------------...
Note While one can obtain the SQL ID for statements currently being executed or
currently stored in the SQL cursor cache by directly querying dynamic performance views, the easiest method is to use the EM interface, as is demonstrated within this section. Using EM The most comprehensive look at a SQL statement, its execution plan, and the context in which it is executing is available from EM. EM is an elaborate and extensive monitoring, advisory and administration interface to the database.
39 | P a g e
While there are almost a limitless number of paths through which one might navigate to obtain SQL statement execution statistics and execution plans, the following demonstration of one such path may be useful. Home Page, Active Sessions From the database home page one can click on one of the Active Sessions links to obtain information about database sessions currently running and active at this moment.
For example, sessions currently waiting for resources or performing I/O may be viewed by clicking on the Wait or User I/O links respectively. In this case, we want to view database sessions currently and actively consuming CPU resources, thus likely executing a SQL statement at this moment. Therefore, we will click on the Active Sessions CPU link. Top Activity The top database activity is displayed. One can see which SQL statements are consuming the most database resources from the Top SQL list. One could see which sessions are doing the same in the Top Sessions list.
40 | P a g e
The logic behind this selective display of sessions is that one should concentrate their tuning efforts on those SQL statements or sessions which will have the greatest impact on performance. Even a marginal improvement in a SQL statement which executes thousands of times an hour is more important than a highly inefficient statement which only rarely executes. Therefore the Top Activity screen shows both the Top SQL statements and the Top Sessions issuing those statements. Search Sessions Suppose one wanted to track the activity of a particular database session which does not happen to appear in the list of top activity at the moment one is viewing these monitors. One could isolate any current database session clicking on the Search Sessions link found within the Additional Monitoring Links section.
41 | P a g e
As you can see this offers two methods to identify the sessions you wish to follow. The Specify Search Criteria provides a point-and-click method of searching the V$SESSION view using a single search column. In our example, we use the attribute DB User and provide the search criteria "student%" to find all sessions with that database user name prefix. The second method, Specify Search Criteria Using WHERE Clause, allows one to customize a SQL statement against this same view.
42 | P a g e
However one has defined the desired session list, in this screen you can see that the Results now include sessions for the user STUDENT1. Click on the appropriate SID link to drill into more details about this particular session. Session Details (General)
43 | P a g e
There is a wealth of useful information presented for each session, segmented by the links on the top of the page:

General Activity Statistics Open Cursors Blocking Tree Wait Event History Parallel SQL SQL Monitoring
Session Details (Activity)
44 | P a g e
The Activity link presents database activity for this session. The display is similar to the summary Top Activity information shown earlier, except that specific database measures and SQL statements are graphically plotted and pertain only to this session. One also has the option to click on the SQL ID link to view an actual SQL statement currently active in the session. It is the actual SQL statements which we are most interested in, of course, in our discussion of SQL statement tuning. Session Details (Statistics)
45 | P a g e
The Statistics link shows a host of detailed database performance statistics for the session. While these are largely of interest to database administrators, there are several statistics which will be of interest to developers and SQL tuners, which you will recognize in time. Session Details (Blocking Tree)
Skipping past the Open Cursors link for the moment, you will see in the screen example shown here that the Blocking Tree link displays locks currently held by
46 | P a g e
the database session. These can be very useful in understanding how locking and waits are responsible for performance of the application. Session Details (Wait Event History)
The Wait Event History is even more directly suited to administrators. It indicates the impact that components throughout the database installation have in producing wait events for this session. Session Details (Open Cursors)
47 | P a g e
But of primary interest to us is the information presented by means of the Open Cursors link. This displays the set of SQL statements currently stored within the SQL cache of the database. If you recall the Activity link, that page showed SQL statements which were currently executing. The Open Cursors link will show inactive statements that may not be executing at this moment, but which remain cached and ready for execution. In any event, by clicking on the SQL ID of the particular SQL statement we want to examine, we are able to obtain the actual SQL details we are seeking in this demonstration. In fact, you may have noticed that in several places throughout our navigation sequence the SQL ID link was presented. SQL Details (Statistics)
48 | P a g e
The SQL Details screen allows us to drill into the detailed database performance statistics consumed by a single SQL statement. For instance, in addition to seeing
49 | P a g e
the SQL text, we can readily determine how many times this statement has executed (Total Parses) and the database resources being consumed (Activity By Waits, Activity By Time, Elapsed Time Breakdown, Other Statistics). You can see that this display also includes a series of links providing a large amount of information for the SQL statement. At this moment we are mostly interested in the execution plan selected by the database Optimizer for this SQL statement, as presented by the Plan link. However, the Plan Control and Tuning History links are also of interest to SQL tuners.
SQL Details (Plan) From the Plan page the critical information we have been seeking is a display of the execution plan generated by the Optimizer. Detailed cost information is available for each step within the plan. One could investigate the reasons for the information presented using several paths available from this page. One could schedule a SQL Tuning Advisor task to obtain
50 | P a g e
advice about modifications which might improve the execution plan. Or one could examine the database objects included in the plan by clicking on the appropriate Object link The execution plan is available in two formats. In the example shown above, it is listed in the traditional tabular format, similar to what is seen outside of the EM environment.
But one also has the option to view the execution plan in graphical form, which is fascinating. It shows the progression of steps in the execution plan, including the sources and the join methods for each step. The number of rows which are included within each step is also shown. A sophisticated navigation pane allows one to focus on selected elements within the plan.
51 | P a g e
Note Not all browsers and client-side operating systems support the graphical view
option. When this is the case one should select the traditional tabular view of the plan.
Real-Time SQL Monitoring

Based upon what has been discussed, consider the various ways in which SQL statements may be identified and monitored from the EM interface:

Performance Top Activity SQL ID this lists the top consuming SQL statements currently active in the instance. Performance Search Sessions SID Open Cursors SQL ID this lists the top consuming SQL statements currently cached in the instance, although they may not at the moment be active.
About Real-Time Automatic SQL Monitoring Yet another way exists in the EM interface whereby critical SQL statements may be identified. Anytime a single SQL statements meets any one of the following criteria, it is placed on the monitoring list represented by the V$SQL_MONITOR view.

Executes in parallel Consumes 5 or more seconds of either CPU or I/O time in a single execution Is explicitly placed on the list by means of the MONITOR hint
Together with other related views such as V$SQL_PLAN_MONITOR, real-time monitoring will display the execution plan and timed statistics, updated on a realtime basis, as the statement executes. The database thus automatically selects and monitors execution of crucial SQL statements as each step of the execution plan is processed. Note This feature is available in Oracle 11g and later releases of the database. This list may be examined within EM by clicking on the Performance SQL Monitoring link.
52 | P a g e
Using this display one can see how the theoretical elements of timed statistics and database timings are applied as actual measurements presented on this screen. Consider these elements visible from the Monitored SQL Executions screen:
Status this indicates whether or not the SQL statement is currently active or running. Even if idle, it will likely remain in the SQL statement cache for a period of time. It will also indicate if the SQL statement failed, and if so, the database error which was the result. Duration this is the elapsed time in which the statement most recently executed. It is based upon the Start and Ended attributes. SQL ID this is a unique identification number assigned to each SQL statement cursor within the SQL statement cache. Parallel this reveals whether or not the statement execution has been parallelized, and if so, the degree of parallelism. Database time this is the all-important database time. It isolates the elements of CPU time, I/O wait time and other wait times. I/O requests these are physical reads and writes performed during SQL statement execution and along with Database Time represents a key performance metric. One may right mouse-click to toggle the statistic to I/O bytes, or the amount of physical data I/O. SQL text this is the actual SQL code submitted by the user or application for execution.
53 | P a g e
Notice in this alternate display of the Monitored SQL Executions screen some additional elements discussed:

Status you can see how some executions are underway, with the timed statistics still being accumulated. Parallel one execution has a degree of parallelism of 2.
Clicking on the Status link will produce the Monitored SQL Execution Details page.
54 | P a g e
From the Monitored SQL Execution Details page, important execution statistics are presented, such as Time & Wait Statistics, I/O Statistics and CPU consumption. Once again, drawing from our discussion of database performance metrics, note these items:

SQL ID by clicking on the SQL cursor ID it provides another path to the SQL Details screen, discussed earlier. IO Statistics IO Requests show physical read requests and bytes, physical write requests and bytes, and logical I/O from the database buffer cache in
55 | P a g e
the form of Buffer Gets. Thus, one can not only observe various metrics of I/O throughput but also quickly compare logical versus physical reads. Also important at the Details buttons Plan Statistics and Activity. As you can see in the example of the Plan Statistics shown, statistics consumed by each step of the plan are merged with the execution plan and then shown in a highly readable graphical format. You will learn more about the operations listed later in this course.
56 | P a g e
The Activity button will graphically plot Database Time elements over a timeline, placing these in the context of total available resources and other concurrent database sessions. Thus, one will see statistics for CPU usage together with all of the individual wait events which comprise the overall Database Time.
57 | P a g e
One can also obtain similar information in an elongated and consolidated report by clicking on the View Report button. Session Details, SQL Details
58 | P a g e
Both the Session Details and the SQL Details screens include a SQL Monitoring link. If statements for the session or the SQL cursor have been placed on the monitoring list, real-time monitoring information is repeated from these locations.
Section Review
The execution plan for a SQL statement describes the sources, accessed methods, join methods and data operations which are used to execute the statement. Enhanced database performance statistics collection may be enabled using the STATISTICS_LEVEL database parameter. Enhanced SQL statement execution statistics collection may be enabled using the SQL_TRACE database and session parameter. The execution plan for a statement may be fetched from the table PLAN_TABLE using the SQL command EXPLAIN PLAN.
59 | P a g e
An execution plan may be displayed using the utlxpl*.sql administrator scripts. An execution plan may be displayed using the DBMS_XPLAN() systemsupplied package. The execution plan of each SQL statement executed may be displayed immediately after the results using the SQL*Plus AUTOTRACE option. An execution plan may be presented SQL Details page of the EM interface. The EM interface will identify SQL statements which should be scrutinized for tuning by means of the Active Sessions, Top Activity, Top SQL, Top Sessions, Session Details and automatic SQL monitoring pages. The database maintains a monitoring list of SQL statements which should be examined closely as candidates for tuning. This is accessible from the Performance page of the EM interface and from the V$SQL_MONITOR view.
Workshop Section: Viewing & Monitoring the Execution Plan

Exercises
What You Will Do within This Workshop Within this workshop you will:

Request both enhanced database performance statistics collection and SQL tracing for the database instance. Create a plan table within your database ID. Using the EXPLAIN PLAN command and other methods for a hypothetical SQL statement, generate a plan and store it within the plan table. Examine and interpret the execution plans. Use the EM interface to follow the execution of a SQL statement, first at the session level and later at the SQL cursor level.
60 | P a g e
Monitor SQL statement execution statistics, hard parses and other internal mechanisms of the SQL statement as it executes. Examine the automatic SQL monitoring list and the elaborate set of database performance statistics and execution plan details which are produced.
Note These workshops assume that each student is using their own dedicated database instance. If you are using a shared database installation, then you will need to make appropriate adjustments to some of the exercises, with only one student performing certain steps in behalf of the installation. Furthermore, it is assumed that the workshop database is not a production database, as we will deliberately induce serious performance bottlenecks for the purpose of learning exercises. View Plan-1
Configure the database instance for enhanced collection of both database statistics and SQL tracing.
Answers One may enable enhanced collection of database statistics with the following parameter setting. The setting will not take effect until the instance is restarted. Therefore, at the end of this exercise, you will need to restart the instance.
SQL> CONNECT dba1/dba1; Connected. SQL> ALTER SYSTEM SET statistics_level = ALL SCOPE = BOTH; System altered.
The following command issued from this same session will enable SQL tracing. As mentioned, later within this course we will explore use of the preferred alternatives DBMS_MONITOR() and DBMS_SESSION, but for now we will utilize this feature which remains supported.
SQL> ALTER SYSTEM SET SQL_TRACE = TRUE SCOPE = BOTH; 61 | P a g e
System altered.
As you can see, these commands must be issued from a database administrator account. Finally, restart the database instance.
SQL> CONNECT / AS SYSDBA; Enter password: ******** Connected. SQL> SHUTDOWN IMMEDIATE; Database closed. Database dismounted. ORACLE instance shut down. SQL> STARTUP; ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted. Database opened. SQL>
849530880 1303216 587205968 255852544 5169152
bytes bytes bytes bytes bytes
View Plan-2
Create a database session for the account in which the sample database schemas have been created. Create the PLAN_TABLE as follows: o Locate the utlxplan.sql script on your database server. Execute the script to create the PLAN_TABLE table within your user ID. o Describe the PLAN_TABLE to confirm that it has been created.
Answers
SQL> CONNECT student1/student1 Connected. SQL> @ 62 | P a g e
C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxplan.sql Table created. SQL> DESCRIBE plan_table Name Null? --------------------------------------- -----STATEMENT_ID PLAN_ID TIMESTAMP ... Type --------------VARCHAR2(30) NUMBER DATE
View Plan-3
Consider the following query which fetches project information for employees. You will notice that a number of tables are referenced, and the query limits the result to employees who make more than $30,000 and who have at least some dependents. Use the EXPLAIN PLAN command to create a plan for the following SQL statement. Specify a unique statement ID as part of the EXPLAIN PLAN command.
SQL> SELECT LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); LNAME ---------Wong Wong Wong Wallace Wong Wallace PNAME --------------ProductY ProductZ Computerization Reorganization Reorganization Newbenefits
Answers
SQL> EXPLAIN PLAN SET statement_id = 'TEST' FOR 63 | P a g e
SELECT LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); Explained.
View Plan-4
Using the SELECT statement shown in your lecture notes, manually select the rows from the PLAN_TABLE to view the execution plan. Thereafter be sure to delete these rows by referring to the appropriate statement ID.
Answers Although this is probably the least usable option for examining an execution plan, perhaps you can try it for the sake of completeness. Such primitive methods are sometimes useful in understanding the underlying elements in use, but in a later exercise you will employ more flexible methods.
SQL> SELECT LPAD(' ',2*LEVEL) || operation || ' ' || options || ' ' || object_name Q_PLAN FROM plan_table WHERE statement_id = 'TEST' CONNECT BY PRIOR ID = PARENT_ID AND STATEMENT_ID = 'TEST' START WITH ID=0; Q_PLAN --------------------------------------------------SELECT STATEMENT HASH JOIN HASH JOIN HASH JOIN SEMI TABLE ACCESS FULL EMPLOYEE TABLE ACCESS FULL DEPENDENT TABLE ACCESS FULL WORKS_ON TABLE ACCESS FULL PROJECT 8 rows selected. 64 | P a g e
SQL> DELETE FROM plan_table WHERE statement_id = 'TEST'; 8 rows deleted.
Note that the specific execution plans generated on your database installation may be different from those shown in our examples. View Plan-5
Try to interpret the results of the plan shown in the PLAN_TABLE. Depending upon the current configuration of your database the results may differ from that shown in the lecture notes but to the degree that you can, try to understand the results. Which operations are performed first, and upon which objects?
Answers Carefully interpret the execution plan. The plan generated in our example may be interpreted as follows:
Since no indexes are yet created for any of our application tables, full table scan operations are always performed on each database object for the access method. The first table scan is performed on the EMPLOYEE table and the DEPENDENT table, with a hash semi-join combining these tables together. The WORKS_ON table is accessed next and is included in the intermediate result table by means of a standard hash join. The last table scanned is PROJECT which is also incorporated into the result table using a standard hash join. All selected rows are then included within the result table.
Q_PLAN --------------------------------------------------SELECT STATEMENT HASH JOIN HASH JOIN HASH JOIN SEMI TABLE ACCESS FULL EMPLOYEE TABLE ACCESS FULL DEPENDENT 65 | P a g e
TABLE ACCESS FULL WORKS_ON TABLE ACCESS FULL PROJECT
View Plan-6
Execute and explain SQL statement again, followed by execution of the utlxpls.sql script. Manually delete the rows from the PLAN_TABLE. Carefully examine the execution plan now shown with its added details.
Answers This method of viewing the execution plan is somewhat easier but also results in substantially more information.
SQL> SELECT LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); LNAME ---------Wong Wong Wong Wallace Wong Wallace SQL> PNAME --------------ProductY ProductZ Computerization Reorganization Reorganization Newbenefits
EXPLAIN PLAN SET statement_id = 'TEST' FOR SELECT LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); Explained. SQL> @ 66 | P a g e
C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxpls.sql PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1272493515 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 354 | 14 (15)| 00:00:01 | |* 1 | HASH JOIN | | 6 | 354 | 14 (15)| 00:00:01 | |* 2 | HASH JOIN | | 6 | 264 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN SEMI | | 3 | 93 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| EMPLOYEE | 7 | 147 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| DEPENDENT | 7 | 70 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | WORKS_ON | 16 | 208 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PROJECT | 6 | 90 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------1 - access("PROJECT"."PNUMBER"="WORKS_ON"."PNO") 2 - access("WORKS_ON"."ESSN"="EMPLOYEE"."SSN") 3 - access("ESSN"="EMPLOYEE"."SSN") 4 - filter("EMPLOYEE"."SALARY">30000) 22 rows selected.
View Plan-7
Use the DBMS_XPLAN() package to display the most recent SQL statement execution plan with the greatest amount of detail available. As you review the added detail provided, notice the following items: o How the query is decomposed into individual query blocks. Potentially these could operate in parallel, thus improving
67 | P a g e
o o
performance. Predicates used as input to various Optimizer operations. Detailed column projection information, both for columns which are ultimately included in the result table but also for columns needed within the lower-level operations of the SQL statement.
Answers Of all the methods available for examining an execution plan without execution, when one is using the command-line SQL interface this method is preferred. It is the easiest and provides the most detailed explanation of the execution plan.
SQL> SELECT * FROM table (dbms_xplan.display (table_name => NULL, statement_id => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------Plan hash value: 1272493515 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 354 | 14 (15)| 00:00:01 | |* 1 | HASH JOIN | | 6 | 354 | 14 (15)| 00:00:01 | |* 2 | HASH JOIN | | 6 | 264 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN SEMI | | 3 | 93 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| EMPLOYEE | 7 | 147 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| DEPENDENT | 7 | 70 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | WORKS_ON | 16 | 208 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PROJECT | 6 | 90 | 3 (0)| 00:00:01 | 68 | P a g e
--------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------1 - SEL$2C0D7645 4 - SEL$2C0D7645 / EMPLOYEE@SEL$1 5 - SEL$2C0D7645 / DEPENDENT@SEL$4 6 - SEL$2C0D7645 / WORKS_ON@SEL$1 7 - SEL$2C0D7645 / PROJECT@SEL$2 Predicate Information (identified by operation id): --------------------------------------------------1 - access("PROJECT"."PNUMBER"="WORKS_ON"."PNO") 2 - access("WORKS_ON"."ESSN"="EMPLOYEE"."SSN") 3 - access("ESSN"="EMPLOYEE"."SSN") 4 - filter("EMPLOYEE"."SALARY">30000) Column Projection Information (identified by operation id): ----------------------------------------------------------1 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "PROJECT"."PNAME"[VARCHAR2,15] 2 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "WORKS_ON"."PNO"[NUMBER,22] 3 - "EMPLOYEE"."SSN"[CHARACTER,9], "EMPLOYEE"."LNAME"[VARCHAR2,10] 4 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "EMPLOYEE"."SSN"[CHARACTER,9] 5 - "ESSN"[CHARACTER,9] 6 - "WORKS_ON"."ESSN"[CHARACTER,9], "WORKS_ON"."PNO"[NUMBER,22] 7 - "PROJECT"."PNAME"[VARCHAR2,15], "PROJECT"."PNUMBER"[NUMBER,22]
View Plan-8
Using the EM interface, locate the user SQL session. Examine the full set of details available for the session. In particular, take note of the execution plan for the SQL statement you have been executing. To ensure that the application query statement is cached and available, you may need to re-issue the statement one or more times from the user session before interrogating the session with EM. You will need to carefully review the lecture notes for reminders on how to locate session and individual cursor information with the EM interface. Once you have perused all the information discussed in the lecture notes for these objects, then consult the exercise solution as there are additional steps we will encourage you to attempt. Bear in mind that there may be some differences in your solution
69 | P a g e
depending upon the exact release of the database which you are using. Also, feel free to explore the EM interface and navigate through different paths to examine session and SQL execution information as it is presented on your workshop database. Answers Issue this statement from the user session. If you are not able to complete this exercise as outlined below, then try to re-issue this statement a few additional times.
Next, using the EM interface, perform these steps to obtain initial information about the user database session and the cursor containing the above SQL statement: 1. From the database home page, click on the Active Sessions CPU link. 2. From the Top Activity page, locate your user database session and click on the Session ID link. If you cannot locate your session here, try the Search Sessions link. 3. Once you have located your database session, from the Session Details page examine the information shown from the General, Activity, Blocking Tree and Wait Event History links. Next, in particular notice the following information from the Statistics link. It provides useful insights into the internal mechanisms related to SQL statement
70 | P a g e
execution:
As you repeatedly re-execute the application SQL statement from the user session, click on the Refresh button within the EM Session Details screen and notice how after a brief delay the session statistics are updated. Each time you re-execute the SQL statement the "db block gets" statistic remains static while the "consistent gets from cache" increases. This indicates that the data has been cached within the database block buffers. Notice how the "table scan rows gotten" continues to increase beyond the number of overall rows included in the result table. While the "execute count" increases each time, the "parse count (hard)" does not, indicating that the SQL statement itself has been cached within the SQL cache. You will also note with each new execution that the "physical reads" does not increase either.
You can learn quite a bit about these detailed statistics by repeating this process several times and probing into the inner workings of SQL statement execution once the statement has been parsed, prepared and cached for reuse, and once the data blocks have been fetched and cached. Next, we will drill down from the session details into the actual SQL statement cursor. From the Session Details screen, click on the Open Cursors link and try to locate the SQL statement which is the subject of this analysis. Click on the Statement ID link for the SQL statement you have been executing and thereby navigate to the SQL Details screen.
71 | P a g e
Notice the General, Execution Statistics, Activity By Waits, Activity By Time and Shared Cursors Statistics specific to this SQL statement. All of this information should help solidify the internal architectural and conceptual information discussed during the lecture section.
72 | P a g e
Notice the information available from the Plan link when requesting a Table view of the execution plan. As you might expect, the cost for the operations increases as we proceed through the steps of the execution plan while the number of rows decreases. The overall cost of each step is calculated as part of the Optimizer effort to compute the cost of the entire plan and thereby select the plan which has the least cost. There is yet another mini-exercise that you could do at this point to probe the execution environment of a SQL statement a bit further. First, create a new SQL user session connecting to the same schema containing the application database. But do so with a new independent session, while retaining the original session.
SQL> CONNECT student1/student1 Connected.
From this new user session, execute the script SQLTuningProjectAdd1000.sql. This will add 1000 redundant rows to the PROJECT table. While this denormalizes the data, we do not have any constraints defined at present which
73 | P a g e
would prevent this and it will serve a useful purpose in monitoring our original query.
SQL> @ SQLTuningProjectAdd1000.sql PL/SQL procedure successfully completed.
Now from the original user SQL session from which you have been issuing the query, re-execute the same SQL statement once more. You should see 1000 additional rows now included in the result table output.
SQL> SELECT LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); LNAME ---------Wong Wong Wong Wallace Wong Wallace Wong Wong Wong Wong ... PNAME --------------ProductY ProductZ Computerization Reorganization Reorganization Newbenefits project 50 project 51 project 52 project 53
1008 rows selected.
Next, navigate back to the Statistics page for the SQL cursor and refresh the statistics. You will notice that the Rows metric within Execution Statistics shows these additional rows being processed. However, the Plan link shows no change in the plan, including its estimated cost of the access method for the PROJECT table. Since we have not updated the Optimizer statistics for the database, and since the prepared SQL statement is cached and the execution plan already selected, the database is not considering the impact of the recent database changes in the plan. There are various ways in which we will later resolve this dilemma, but for now
74 | P a g e
make a slight syntax-only change to the SQL statement from the original SQL session, perhaps changing the case of one of the columns. This will be recognized by the database as an entirely new SQL statement, requiring a hard parse, a new cursor, and therefore a new execution plan.
SQL> SELECT LName, project.pname FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); LNAME ---------Wong Wong Wong Wallace Wong Wallace Wong Wong Wong Wong ... PNAME --------------ProductY ProductZ Computerization Reorganization Reorganization Newbenefits project 50 project 51 project 52 project 53
1008 rows selected.
Locate the modified SQL statement from the open cursors of the session within EM. From the SQL Details screen click on the Plan link and display the execution plan again. As you can see, while the execution plan selected has not changed, the database is now aware of its true cost. View Plan-9
Review the timed statistics and database metrics discussion within the lecture section and then compare that with the information captured and presented for SQL statements which are on the monitoring list. You could start with any SQL statements already on the monitoring list.
75 | P a g e
Next, you could launch two concurrent SQL sessions and execute the script SQLTuningMonitoredSQL.sql concurrently in each session. This script will produce a very elaborate execution plan and also generate a large volume of timed statistics. Although not all the elements for the SQL launched from script will be entirely meaningful to you at this point, it will be a very useful example. Since this script may run past the duration of the exercise, you may abort the SQL session once you have completed the exercise in the event that it continues to run. Answers Using the EM interface, perform these steps. If any of the SQL statements you recognize are visible then follow these steps using those statements. Otherwise, select the statement which represents the greatest duration or otherwise seems to have the most comprehensive statistics: 1. Click on the Performance SQL Monitoring link. Note the summary statistics for each statement on the monitoring list. 2. Click on the Status button and examine in detail the metrics presented in the various sections of the Overview. 3. Note the Plan Statistics and the execution plan. 4. Click on the View Report button to generate a comprehensive report. The actual point-and-click interface is trivial, but the significance of the information presented is not. Therefore, try to grasp and understand as many of the database metrics and execution plan operations shown as you can. As suggested in the exercise instructions, once you have become familiar with the SQL monitoring list, the EM interface and the timed statistics, you could generate an elaborate scenario using the following sequence: 1. Click on the Performance SQL Monitoring link and select the value 5 Minutes or 10 Minutes for the item Active In Last. Watch the list dynamically change as you proceed with the remaining steps listed next. 2. From one SQL session launch the script SQLTuningMonitoredSQL.sql. 3. From a second SQL session launch the script SQLTuningMonitoredSQL.sql again so that it runs concurrently with the first one.
76 | P a g e
Although there could be differences on your local workshop installation, almost surely you will see one or both of the SQL executions placed on the monitoring list. Because resource consumption is so high for this example, the execution may eventually even fail due to a lack of resources in some fashion. Should this happen, it will only serve to enhance the example and the learning exercise.
77 | P a g e
In this example you will see that the operation has been parallelized. Although the operations within a parallel execution of a SQL statement are somewhat outside the scope of this course, you can see how the execution plan steps highlight serial operations performed by the parallel server coordinator process and those which are performed in parallel by server processes. In terms of the timed statistics you will notice that the full range of these is produced by this execution.
78 | P a g e
Because this execution has been parallelized, the Details section of the screen adds a Parallel button. It distributes the database statistics among the parallel coordinator and parallel server processes in use, and provides a low-level view into the resource consumption.
79 | P a g e
The Activity button produces the Database Time graph. In this example you can see CPU consumption together with two different categories of wait events. View Plan-10
In this exercise you will consider yet another option available to you for producing an execution plan. Perform the following tasks: o Enable the AUTOTRACE utility using an administrator account. o Execute several SQL statements and examine the output produced from the application database account. Once you have confirmed the function of this feature, disable it for
80 | P a g e
your session. Answers Launch a separate administrator session within SQL*Plus and invoke the administration script which creates the PLUSTRACE role. Grant the role to the database account which owns the sample databases.
SQL> CONNECT / AS SYSDBA; Connected. SQL> @ $ORACLE_HOME\sqlplus\admin\plustrce.sql; SQL> drop role plustrace; drop role plustrace * ERROR at line 1: ORA-01919: role 'PLUSTRACE' does not exist ... SQL> GRANT plustrace TO student1; Grant succeeded.
Next, returning to your primary SQL session, enable AUTOTRACE and watch the results which are produced.
SQL> SET AUTOTRACE ON; SQL> SELECT LName, dependent_name FROM employee INNER JOIN dependent ON ssn = essn ORDER BY LName; LNAME ---------Smith Smith Smith ... DEPENDENT_ ---------Alice Elizabeth Michael
Execution Plan ---------------------------------------------------------Plan hash value: 1434111244 -------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------81 | P a g e
----------| 0 | SELECT STATEMENT | | 7 | 252 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 7 | 252 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 7 | 252 | 7 (15)| 00:00:01 | | 3 | TABLE ACCESS FULL| DEPENDENT | 7 | 126 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEE | 8 | 144 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("SSN"="ESSN") Note ----- dynamic sampling used for this statement Statistics ---------------------------------------------------------327 recursive calls 0 db block gets 64 consistent gets 0 physical reads 0 redo size 598 bytes sent via SQL*Net to client 381 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 11 sorts (memory) 0 sorts (disk) 7 rows processed
Disable this feature with the following command.

SQL> SET AUTOTRACE OFF;
View Plan-11
Using the EM screens you have now become familiar with, identify the SQL ID for a statement within the SQL cursor cache. Then, using the SQL interface, examine the execution plan using the DBMS_XPLAN() package.
82 | P a g e
Answers In this case we use the DISPLAY_CURSOR() program unit from the DBMS_XPLAN() system- supplied package.
SQL> SELECT * FROM table (dbms_xplan.display_cursor ( sql_id => '4fy39u3m71t03', cursor_child_no => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1821410742 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 55 | 6 (34)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 55 | 6 (34)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 55 | 5 (20)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 33 | 2 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 66 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------------...
View Plan-12
Reinitialize the COMPANY database in preparation for future workshops.
Answers
SQL> @ CompanyDefine.sql; 83 | P a g e
... SQL> @ CompanyInsert.sql; ...
Section 3: Understanding the Optimizer

Objectives

Optimization Mode & Goals Optimizer Components Execution Plan Operations
Section Overview
In this section we will present an in-depth discussion of the Optimizer and its effort to estimate the costs for various execution plans for a given SQL statement. We will also introduce some methods whereby one can influence and alter the way in which the Optimizer works. As part of our discussion we will consider these topics:

Selecting the appropriate optimization mode for a database installation. The role of the Optimizer components called the Transformation Engine, Estimator and Plan Generator. Understand the variety of operation alternatives generated and estimated by the Optimizer.
Optimization Methods
Legacy versions of the Oracle database employed what was known as a rulesbased optimizer (RBO). This was a primitive mechanism for selecting optimal execution plans and it relied upon manual SQL coding techniques within the SQL statement text. This required the developer to use the SQL statement not only to state what data was needed but also to incorporate procedural information as to
84 | P a g e
how it should execute. This, in turn, contravened the theoretical basis for SQL and its declarative language design. Now the optimization method used by the database is a sophisticated cost- (or statistics-) based optimizer (CBO). This uses a variety of dynamic database structures to automatically select the best execution plan for a SQL statement whenever it is parsed. Foremost among these database structures is the collection of Optimizer statistics which the Optimizer will use in selecting the best execution plan. What are the Optimizer Statistics Statistics for tables include the number of rows, the number of data blocks and the average row length. Statistics are also collected for each column within the table, and these include the number of distinct values, the number of nulls, and a histogram. Index statistics include the number of leaf blocks, the number of levels within the index and the clustering factor.
Note As you can see, Optimizer statistics, also sometimes known as schema
statistics, relate to the population of the application database objects within the schemas. This is not the same as database performance statistics discussed earlier, which are the timed statistics that measure the operational performance of the database instance and the SQL execution processes.
Optimization Goals
Like most components within the database, the Optimizer is affected by the settings of certain database parameters. We will consider some of these within this section. OPTIMIZER_MODE The Optimizer can be directed to optimize SQL statement execution, and select execution plans, based upon stated goals. These goals may be specified at the following levels by means of the OPTIMIZER_MODE parameter.
The instance
85 | P a g e
The current session A specific SQL statement
The Optimizer mode or goal permits these values, each of which is explained in the table that follows:
OPTIMIZER_MODE = ALL_ROWS | FIRST_ROWS | FIRST_ROWS_x
Goal ALL_ROWS
FIRST_ROWS
Explanation The Optimizer will optimize plan selection for overall throughput. This is generally selected for data warehouse and batch reporting databases where a large number of rows are commonly fetched and overall transaction performance is crucial. This is also the default. The Optimizer will optimize plan selection for response time. This selects plans which will return the best response time for the first few rows of the result set even if overall throughput for the SQL statement as a whole would be slightly diminished. This is often selected for online transaction processing (OLTP) environments, such as web-based applications. Ideally one should not use the generic FIRST_ROWS goal in favor of a more precise setting available from the parameters listed next. These modes allow the Optimizer to achieve the best response time for a more specific target of rows. In order to achieve the desired goal of this mode the Optimizer will favor the use of nested loops joins and index lookups for FIRST_ROWS_1 or FIRST_ROWS_10. Conversely, it will favor hash joins and full table scans for FIRST_ROWS_100 or FIRST_ROWS_1000.
FIRST_ROWS_1 FIRST_ROWS_10 FIRST_ROWS_100 FIRST_ROWS_1000
Current Session Setting

86 | P a g e
An Optimizer goal may also be specified for the current session with the ALTER SESSION command. Note that the Optimizer goal will only affect user-defined SQL statements and not internal SQL processing initiated by the database. Furthermore, since it is only a goal, any recursive SQL statements generated internally by the database will use the instance Optimizer mode.
SQL> ALTER SESSION SET optimizer_mode = ALL_ROWS | FIRST_ROWS | FIRST_ROWS_x;
Specific SQL Statement Setting Embedded Optimizer hints may be used for various purposes. One can be used to determine the Optimizer mode for the current SQL statement only. When this is done this overrides both the Optimizer mode of the instance and the Optimizer goal of the session. A complete discussion of hints is covered later within this course.
SQL> SELECT /*+ FIRST_ROWS(x) | ALL_ROWS */ LName FROM employee; ...
As will be discussed elsewhere within this course, the cost computed by the Optimizer includes both database (I/O cost) and host system (CPU cost). The hint NO_CPU_COSTING ignores CPU cost and computes the plan cost solely based upon I/O. Which Instance Mode is in Effect? The V$PARAMETER view indicates the current value for all initialization parameters. Using this view one can examine the current setting for OPTIMIZER_MODE for the instance. Generally the V$ dynamic performance views are restricted to database administrators although any user may be granted rights to see these views.
SQL> SELECT value FROM v$parameter WHERE name = 'optimizer_mode'; VALUE ---------------------------------------------ALL_ROWS
87 | P a g e
All database parameters which affect the Optimizer can be examined using the EM interface too. From the database home page, select the Administration All Initialization Parameters link and navigate to the Optimizer category.
Throughout this course we will explore how these other parameters influence the Optimizer. OPTIMIZER_FEATURES_ENABLE One additional parameter we will consider now is OPTIMIZER_FEATURES_ENABLE. This static parameter very broadly impacts the actions of the Optimizer. It directs that the Optimizer behave according to the
88 | P a g e
features of a specific release of the Oracle database. For instance, the example below sets the Optimizer behavior to that of an earlier database release:
OPTIMIZER_FEATURES_ENABLE = 10.2.0
Why Does This Parameter Exist? Normally whenever an upgrade or patch to the database is made, this parameter is automatically incremented to reflect the latest version. Then why would one want to operate the Optimizer as if the upgrade never took place? Periodically we may make reference to certain Optimizer features which are specific to a particular version of the Oracle database. As one can imagine, therefore, upgrading from one release of the Oracle database to another will have a dramatic impact on the optimization of SQL statements. Given the enhancements and bug fixes which are introduced with each release of Oracle, this should be a beneficial impact. However, if one wanted to upgrade the database to a newer version and yet preserve optimization results based upon an older version, this parameter may be used. How This Parameter Should Be Used The following guidelines will help one decide if, and how, this parameter should be used:
Generally one should not set this parameter. When omitted, the Optimizer will behave according to the features of the current database release. Any performance problems resulting from a database version upgrade should be resolved on a case-by-case basis using the features described within this textbook. As part of a troubleshooting effort, one may temporarily wish to set the Optimizer features back to a previous release. This will help to rule in, or rule out, a database version upgrade as the source of a widespread problem. Otherwise, performance problems which might occur after an upgrade should be handled on a case-by-case basis using the session and SQL statement hint options discussed above.
89 | P a g e
Optimizer Components
The process of estimating the cost and choosing an optimal execution plan is performed in multiple steps and using several different components. Optimization Overview Consider the primary components which exist within the Optimizer:
After the original SQL statement text is confirmed as valid by the Parser, it is passed through a transformation process and a revised and possibly rewritten SQL statement produced. The Estimator will compute the cost of executing the SQL statement based upon a particular plan produced by the Plan Generator. The Plan Generator may iteratively compute alternate plans and estimate the cost of each. This process may repeat several times until the optimal plan is chosen.
90 | P a g e
91 | P a g e
This process applies to any DML statement, not just SELECT statements or queries. Bear in mind that DML statements such as an UPDATE statement may include an elaborate selection criteria and require optimization as well. What is SQL Statement Tuning? This now brings us to what is the essence of SQL statement tuning. Using a variety of tools, such as collecting up-to-date Optimizer statistics, setting appropriate database parameters, rewriting the SQL text, and selectively incorporating manual hints within SQL statements, the SQL tuner seeks to influence the behavior of the Optimizer to produce and select an optimal execution plan. In order to accomplish this goal, in the pages which follow we will explore each of the major Optimizer components in further detail, and consider how they work to produce and select an execution plan. Transformation Engine The Optimizer may decide to rewrite a SQL statement in a process known as query transformation. A component known as the transformation engine performs this task.
The following are some of the examples where this may be done:
View merge Normally the parse will isolate each view into its own query block (e.g. a segment of the parsed query) and this would result in a subplan for each block. With the view merge transformation, however, the view is merged into the containing query block and a consolidated subplan is
92 | P a g e
developed following the merge. For most views it will be advantageous for the query to be simplified by means of a view merge. Predicate pushing If a view is not merged, relevant SQL predicates from containing query blocks are moved into the view query block to filter the view. This will improve the plan even of non-merged views by allowing indexes to be accessed or otherwise for the table to be filtered. Subquery Unnesting Similar to views, nested subqueries are parsed into their own query block and a separate subplan is generated. Where it is possible to do so, the nested subqueries are transformed into joins which makes a separate subplan unnecessary. Materialized View Query Rewrite When materialized views contain precomputed results sought by the query, and when the cost of using the materialized view is less than existing plans, the Optimizer will rewrite the user query to reference the materialized view object. The original SQL statement and the developer may have no knowledge that the materialized view even exists, but through this process may still use it. Cursor peeking This is discussed in greater detail elsewhere within this course but basically the Optimizer will peek at the first value of a bind variable and incorporate the selectivity implied by that value into the execution plan chosen for all executions of the statement.
The transformation engine which performs this task inside the database has been specially architected in an extensible structure, meaning that additional algorithms for query transformation can be, and are, regularly added.
Curriculum Note
The subject of materialized views and materialized view query rewrite is significant but mostly outside the scope of this text. It is considered in detail within the Sideris course Oracle Database 11g: Data Warehousing & Oracle Warehouse Builder.
Estimator Once a query has potentially been transformed, the cost to execute the statement must be estimated. There are several ingredients which go into the algorithm used by the Estimator. Selectivity The Optimizer assigns a cost value between 0.0 and 1.0 based upon the selectivity of the query. The selectivity attempts to estimate how selective, or how many rows
93 | P a g e
for a given table, are likely to be chosen. Selectivity is determined using the following inputs:
When a query will retrieve only a small number of the total set of rows from a table the query is considered to have good selectivity. When it will select a large percentage of the rows from the table then it has poor selectivity. When Optimizer statistics have been collected and are fresh, the statistics are compared against the query to determine selectivity. When Optimizer statistics have not been collected, the selectivity is estimated based upon the SQL predicate used. For example, a predicate of equal (=) has a lower estimated selectivity than one of greater than (>) even though in actuality the selectivity may not be any different. When there is a great disparity between the number of distinct values in a column, a histogram can be of much help to the selectivity calculation. A histogram must be created and maintained by the developer or database administrator. Not every SQL statement performs selectivity by means of a primitive SQL predicate within the WHERE clause. In some cases selectivity is affected by the inclusion of SQL functions or when multiple columns are interrelated and both are included within the predicate. In such cases expression and multi-column statistics must be gathered to allow the Optimizer to cope with such complexities.
Cardinality Cardinality is the number of rows for a given row set.
Initially the row set for a table is all of the rows which exist within the table. Thecardinality of a row set is refined as various operations take place on the row set, such as filters due to SQL predicates, joins with other row sets, GROUP BY expressions which reduce the number of rows down to distinct groups, etc. If Optimizer statistics have not been collected then the cardinality is estimated based upon the number of physical extents assigned to the database object.
Cost The cost is the estimated number of disk I/O operations, CPU consumption and memory usage required to perform an operation. For example, a full table scan operation which references multiple adjacent blocks may be read with one I/O, and
94 | P a g e
the estimated I/O cost reflects that fact. On the other hand, a different table access method which references the same number of blocks dispersed throughout the tablespace will have a higher estimated cost. Or, consider what is known as a Sort-Merge Join operation. In that case the I/O cost considers the fact that the tables are in a pre-sorted order and the cost of joining such sorted interim tables is less than tabular data in random order. It is with regard to the cost Estimator that the subject of Optimizer or schema statistics is critical. In order for the Estimator to properly calculate the relative cost of various operations, such as a full table scan operation versus an index range scan, it must have accurate statistics about the schema objects being accessed. Thus, a crucial dependency for proper functioning of the Estimator, and therefore the correct selection of the least costly execution plan by the Optimizer, is for fresh and accurate statistics to be available.
Elsewhere within this course you will learn a variety of methods whereby these statistics may be collected and updated.
95 | P a g e
It must be emphasized that the matter of Optimizer statistics collection is not trivial. In some cases specialized procedures must be implemented locally to account for unique performance problems which have manifested themselves. In other cases, inadequate collection of statistics results in tuning issues which cannot be solved unless the collection procedures are customized.
Note In the event that Optimizer statistics are missing for referenced database
objects, the Estimator will use internal statistics, such as the number of data blocks used by a table. This is known as dynamic sampling and while it is not as desirable as having true statistics, it is a useful contingency strategy for coping with missing statistics. Plan Generator The Plan Generator may interact with the Estimator on an iterative basis. It could generate a series of alternate execution plans for a single SQL statement, and compare the estimated execution cost of each one as part of its effort to select an optimal plan. Why Multiple Plans are Needed? A variety of plans are useful for the Optimizer to choose from since there are multiple ways in which a SQL statement could be executed. To illustrate, consider the table access methods to which we have periodically referred throughout this course. When the rows of a table are needed by a particular SQL statement, there are different ways in which these could be accessed. One access method is a Full Table Scan, and based upon the Optimizer statistics available to the Estimator, it will compute the cost of using that access method. On the other hand, if there is an index which the statement could utilize, then the needed rows from the table could be accessed using an Index Range Scan access method. Once again, depending upon the selectivity of the SQL statement and the table statistics, the Estimator will compute the cost of the plan which uses this alternate access method. Similar alternatives are discovered by the Plan Generator for the join methods. Depending upon the order in which tables are joined together, one plan could utilize a Sort-Merge join operation for one step while an alternative plan could use a Hash join. The cost of each alternative is estimated and included in the calculation for selecting the least costly and thereby the most efficient plan.
96 | P a g e
The Optimizer will vary the number of alternate plans that it generates and compares based upon the costs of plans generated thus far. For example, if all plans generated have a high cost, then additional plans may be generated. Conversely, if plans have been generated with comparable low costs, then a cutoff is reached and no further plans are generated and compared. Once the plan generation ceases, the plan with the lowest cost is chosen and the SQL statement proceeds to its execution.
Execution Plan Operations

As you progress through this course and gain experience in understanding the internal execution of a SQL statement, we will eventually discuss in exhaustive detail the various operations found within an execution plan. But for now, consider some examples of operations which you should start to scrutinize as you find these within the SQL statements you are monitoring:

Access methods Join methods Data operations
Access Methods The rows highlighted within the execution plan shown here indicate the access method for each table. As you have no doubt already noticed and recognized, the access method TABLE ACCESS FULL indicates a Full Table Scan where block within the table is fetched sequentially. As each block is read, individual rows are examined looking for last name values equal to Smith. If only a few employees were to have the last name of Smith, then this access method would be inefficient for such a highly selective statement. On the other hand, if we were searching a table where many or most of the rows contained the desired value then this might be judged the most efficient access method.
--------------------------------------------------------------------------------97 | P a g e
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 30 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 30 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 30 | 7 (15)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 14 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 48 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("EMPLOYEE"."LNAME"='Smith')
You will learn about the remaining access methods and how these compare with a Full Table Scan later within this course. Join Methods The row highlighted here in the execution plan indicates the join method for the tables which have been accessed. There are many types of join methods available to the Plan Generator, such as Hash joins, Sort-merge joins, Nested Loops joins and others.
--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 30 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 30 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 30 | 7 (15)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 14 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 48 | 3 (0)| 00:00:01 | 98 | P a g e
--------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("EMPLOYEE"."LNAME"='Smith')
Perhaps even more important than the join method selected for a plan is the join order. When more than two tables are joined within a statement, the Plan Generator must determine for a given alternative plan the order in which the result of one join is used for subsequent joins. Consider another execution plan where multiple joins are organized into a particular join order. In this plan, the EMPLOYEE and DEPENDENT tables are first joined together using a form of a Hash join known as the Hash Join Semi method. This first join result is then included in another Hash join with the WORKS_ON table. Finally, the result of that join is included in yet another Hash join operation with the PROJECT table.
--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 354 | 14 (15)| 00:00:01 | |* 1 | HASH JOIN | | 6 | 354 | 14 (15)| 00:00:01 | |* 2 | HASH JOIN | | 6 | 264 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN SEMI | | 3 | 93 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| EMPLOYEE | 7 | 147 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| DEPENDENT | 7 | 70 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | WORKS_ON | 16 | 208 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PROJECT | 6 | 90 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------
99 | P a g e
If you recall the graphical view of an execution plan which was available from the EM interface, you can see how the join order becomes clearly apparent. Perhaps you can also now see how the join order is critical to the overall cost of the plan. If the highly selective tables with the least number of rows are accessed and joined first in the join order, then the cost of the remaining joins are lower as fewer rows need to be processed during the subsequent joins. Thus the Plan Generator will not only experiment with different join methods but will also ascertain the optimum join order based upon the table statistics. Data Operations (Sort) Returning to the original plan for this discussion, the row highlighted here indicates the sort operation to be applied to the result table. In this example last
100 | P a g e
operation performed upon the result table following the access and join methods is a sort. This was generated due to the presence of an ORDER BY clause within the SQL statement.
--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 30 | 8 (25)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 30 | 8 (25)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 30 | 7 (15)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMPLOYEE | 1 | 14 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| DEPARTMENT | 3 | 48 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("DNUMBER"="DNO") 3 - filter("EMPLOYEE"."LNAME"='Smith')
Section Review
The OPTIMIZER_MODE database parameter allows one to specify an optimum goal for Optimizer operations within a given database installation. The OPTIMIZER_MODE may be set at the instance, session or statement level. The Transformation Engine within the Optimizer may rewrite the text of a SQL query so that it is more suitable for execution plan optimization. The Estimator within the Optimizer estimates the cost of the operations included within a given execution plan.
101 | P a g e
A critical dependency for successful functioning of the Estimator is the availability of complete and fresh schema or Optimizer statistics. The Plan Generator will work with the Estimator to generate and estimate the cost of several alternative plans. The lowest cost plan will be selected for execution. Different plans created by the Plan Generator for evaluation may include a variety of alternative access methods, join methods, join orders and data operations.
Workshop Section: Understanding the Optimizer

Exercises

List the modes in which the Optimizer may operate. Check the current mode of the Optimizer for the instance. Set the Optimizer mode and goal for the session and an individual SQL statement. List the components of the Optimizer. List the factors which influence the computed cost for an execution plan.
Optimizer-1
What are the available modes for the Optimizer? 1. __________ 2. __________ 3. __________ 4. __________ 5. __________
102 | P a g e
Which mode(s) are not recommended? 6. __________ 7. __________ 8. __________ Answers The recommended and supported modes are: 1. 2. 3. 4. 5. ALL_ROWS FIRST_ROWS_1 FIRST_ROWS_10 FIRST_ROWS_100 FIRST_ROWS_1000
Those modes which are no longer supported or no longer recommended are: 1. RULE 2. CHOOSE 3. FIRST_ROWS We did not discuss the RULE and CHOOSE method since these are no longer supported, but they are legacy settings which you may find within a particular database installation. They have no effect within the parameter OPTIMIZER_MODE in current releases. But as you may have surmised, the RULE mode was used to operate the Optimizer according to primitive rulesbased algorithms. Optimizer-2
This exercise requires that you have administrator access to the database. Examine the Optimizer mode for your instance by querying the V$PARAMETER view from an administrator session. The mode for your database should be ALL_ROWS, which is the default. If this is not the case and you have the authority to change it, change the OPTIMIZER_MODE parameter within the initialization file and memory.
103 | P a g e
Answers
SQL> CONNECT / AS SYSDBA; Connected. SQL> SELECT value FROM v$parameter WHERE name = 'optimizer_mode'; VALUE ----------------------------------------------------------------------ALL_ROWS
In the event that your database does not have this setting and you must change it, the following command will accomplish this task:
SQL> ALTER SYSTEM SET optimizer_mode = ALL_ROWS SCOPE = BOTH; System altered.
Optimizer-3
Within this exercise you will see how one can influence the execution plan selected by the Optimizer. First, from the user session, explain once again the same SQL statement which we have been analyzing since the previous workshop. Ideally, use the DBMS_XPLAN() system-supplied package which will allow you to request the most detailed plan information. Carefully examine the output.
Next, alter the goal for your session to FIRST_ROWS_1 and then explain the same SQL statement again. Notice how a different execution plan is selected to achieve the desired goal. Answers
SQL> EXPLAIN PLAN SET statement_id = 'TEST' FOR SELECT LName, project.PName FROM employee 104 | P a g e
INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); Explained. SQL> SELECT * FROM table (dbms_xplan.display (table_name => NULL, statement_id => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1272493515 --------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 528 | 14 (15)| 00:00:01 | |* 1 | HASH JOIN | | 6 | 528 | 14 (15)| 00:00:01 | |* 2 | HASH JOIN | | 6 | 396 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN SEMI | | 3 | 126 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| EMPLOYEE | 4 | 124 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| DEPENDENT | 7 | 77 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | WORKS_ON | 16 | 384 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PROJECT | 6 | 132 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------1 - SEL$2C0D7645 4 - SEL$2C0D7645 / EMPLOYEE@SEL$1 5 - SEL$2C0D7645 / DEPENDENT@SEL$4 6 - SEL$2C0D7645 / WORKS_ON@SEL$1 7 - SEL$2C0D7645 / PROJECT@SEL$2 105 | P a g e
Predicate Information (identified by operation id): --------------------------------------------------1 - access("PROJECT"."PNUMBER"="WORKS_ON"."PNO") 2 - access("WORKS_ON"."ESSN"="EMPLOYEE"."SSN") 3 - access("ESSN"="EMPLOYEE"."SSN") 4 - filter("EMPLOYEE"."SALARY">30000) Column Projection Information (identified by operation id): ----------------------------------------------------------1 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "PROJECT"."PNAME"[VARCHAR2,15] 2 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "WORKS_ON"."PNO"[NUMBER,22] 3 - "EMPLOYEE"."SSN"[CHARACTER,9], "EMPLOYEE"."LNAME"[VARCHAR2,10] 4 - "EMPLOYEE"."LNAME"[VARCHAR2,10], "EMPLOYEE"."SSN"[CHARACTER,9] 5 - "ESSN"[CHARACTER,9] 6 - "WORKS_ON"."ESSN"[CHARACTER,9], "WORKS_ON"."PNO"[NUMBER,22] 7 - "PROJECT"."PNAME"[VARCHAR2,15], "PROJECT"."PNUMBER"[NUMBER,22] Note ----- dynamic sampling used for this statement
Notice in the output above the following items:

The hash semi join operation has been highlighted as the first join operation included in the plan. Since Optimizer statistics have not yet been collected dynamic sampling was employed by the Estimator.
Now change the goal for this session as follows:

SQL> ALTER SESSION SET optimizer_mode = FIRST_ROWS_1; Session altered.
Explain the plan for the SQL statement a second time, using the techniques provided in the solution above. In this case, focus on the operations selected for this new plan and notice below how this has changed as per the goal.
PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------Plan hash value: 3405705238 ---------------------------------------------------------------------106 | P a g e
-----------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 528 | 13 (8)| 00:00:01 | | 1 | NESTED LOOPS | | 6 | 528 | 13 (8)| 00:00:01 | |* 2 | HASH JOIN SEMI | | 6 | 396 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN | | 8 | 440 | 7 (15)| 00:00:01 | | 4 | TABLE ACCESS FULL| WORKS_ON | 16 | 384 | 3 (0)| 00:00:01 | |* 5 | TABLE ACCESS FULL| EMPLOYEE | 4 | 124 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | DEPENDENT | 7 | 77 | 3 (0)| 00:00:01 | |* 7 | TABLE ACCESS FULL | PROJECT | 1 | 22 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------
You can also observe that the amount of data or Bytes included in this plan is greater than the earlier plan and is therefore less efficient from an overall throughput perspective, which is just what we would expect with FIRST_ROWS_1. Optimizer-4
Having seen the Optimizer in action, it would be good to recall to mind some of its internals which we discussed. Can you list below the primary components found within the Optimizer: 1. __________ 2. __________ 3. __________
Answers 1. Transformation engine 2. Estimator 3. Plan generator
107 | P a g e
Optimizer-5
Focusing your attention on the Estimator component within the Optimizer, can you list below the primary factors which influence the algorithm when computing the cost of an execution plan: 1. __________ 2. __________ 3. __________
Answers 1. Selectivity 2. Cardinality 3. Cost Optimizer-6
This exercise is more of a learning exercise than something which you will use in your production work. But it should help you gain further insight into the Optimizer and SQL statement execution plans.
Recall the brief mention that Optimizer hints may be embedded within the SQL statement. These will be discussed at length later within this course. For now, we want to mention that RULE is an example of a hint which will direct the Optimizer to function according to the legacy rules-based optimization algorithms. Modify the SQL statement under discussion in this workshop to include this hint. Then, examine the execution plan. This will demonstrate not only an entirely different plan that you can read and understand, but will also make clear how the Optimizer can be induced to generate very different plans. While this particular primitive rules-based plan would not actually be useful in a production environment, it does serve as a helpful example. Answers Notice first the inclusion of the hint requiring rules-based optimization.
108 | P a g e
SQL> EXPLAIN PLAN SET statement_id = 'TEST' FOR SELECT /*+ RULE */ LName, project.PName FROM employee INNER JOIN works_on ON works_on.essn = employee.ssn INNER JOIN project ON project.pnumber = works_on.pno WHERE employee.Salary > 30000 AND EXISTS (SELECT * FROM dependent WHERE essn = employee.ssn); Explained.
When the resulting plan is viewed, you can see how dramatically it is changed. Far less efficient SORT JOIN and MERGE JOIN operations are employed. These selections have been made without any concept of the cost, since blind adherence to the hard coded rules is followed. It is also clear that a more intricate and lengthy plan is used. Regardless of how efficient the plan may or may not be, it provides another learning opportunity in reading a complex execution plan. Note the following in this plan:

The PROJECT and then the WORKS_ON tables are scanned first, sorted and then combined in a SORT MERGE JOIN operation. The EMPLOYEE and DEPENDENT tables are then processed similarly, subjected to full table scans, sorts and then a SORT MERGE JOIN. The result tables are then passed up to the higher portions of the plan and progressively combined with additional sorts and then SORT MERGE JOIN operations. Finally, the selected rows are filtered from the largest of the result tables. As the last step the columns are projected.
SQL> SELECT * FROM table (dbms_xplan.display (table_name => NULL, statement_id => NULL, format => 'ALL') ); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 212142887 -------------------------------------------------------------------109 | P a g e
| Id | Operation | Name | Rows | Bytes | Cost | -------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | | |* 1 | FILTER | | | | | | 2 | MERGE JOIN | | | | | | 3 | SORT JOIN | | | | | | 4 | MERGE JOIN | | | | | | 5 | SORT JOIN | | | | | | 6 | TABLE ACCESS FULL| PROJECT | | | | |* 7 | SORT JOIN | | | | | | 8 | TABLE ACCESS FULL| WORKS_ON | | | | |* 9 | SORT JOIN | | | | | |* 10 | TABLE ACCESS FULL | EMPLOYEE | | | | |* 11 | TABLE ACCESS FULL | DEPENDENT | | | | -------------------------------------------------------------------... Note ----- rule based optimizer used (consider using cbo)
For obvious reasons the notes highlight this inefficiency of this optimization method and encourage switching to the cost-based Optimizer. Optimizer-7
Return the optimization mode for your session to its original value.
Answers
SQL> ALTER SESSION SET optimizer_mode = ALL_ROWS; Session altered.
Section 4: Execution Plan Methods & Operations

Objectives
110 | P a g e
Discuss Table Access Operations Discuss Join Operations Discuss Index Operations
Section Overview
Thus far we have considered in progressive detail the methods and operations used within an execution plan. It is essential that one have an indepth understanding of these elements in order to properly read and interpret an execution plan, and to thereby tune SQL statements and obtain an optimal plan. We will discuss the following topics within this section:

Table access methods Join methods Index access methods
Using this understanding, you will be able to fully interpret the execution plans produced throughout the remainder of this course.
Table Access Methods
One of the most basic operations in an execution plan is obviously fetching the data from tables. These operations provide access methods for this to be done.
Curriculum Note
External tables are mentioned only briefly in these comments. To learn more about external tables please see the Sideris course Oracle Database 11g: New & Advanced Features for Developers.
111 | P a g e
Operation Explanation TABLE ACCESS Reads every block in the table sequentially, from beginning to FULL end. At first this might seem to be the worst access method. The availability of an index, for example, offers alternative index scan operations. On the other hand, if the selectivity is such that most rows must be read, then a full table scan might be preferable. This operation may be parallelized and if a high degree of parallelization is used then a full table scan may also be chosen as the best access method. EXTERNAL The database is using the external table access agent to access TABLE ACCESS an external table. FULL TABLE ACCESS The fastest method to find data, using the direct address BY ROWID RowID. RowIDs are found either when explicitly listed in the WHERE clause of a SQL statement or immediately following an Index Scan operation which produced RowIDs. TABLE ACCESS This is a statistical sample which is done when the user has SAMPLE specifically requested such with the SAMPLE clause of a SELECT statement. TABLE ACCESS This is used when rows that are part of a cluster are joined and CLUSTER when the primary key (or unique key) is matched against a single value. TABLE ACCESS Nearly identical to TABLE ACCESS CLUSTER with the HASH exception that the tables are part of a hash cluster rather than a standard indexed cluster. VIEW The stored query for a relational view is fetched and executed. More about Full Table Scans In the event that many plans utilize this operation and that is a desired result, one can improve the efficiency of full table scans by increasing the size of the database parameter DB_FILE_MULTIBLOCK_READ_COUNT. By increasing the number of data blocks indicated by this parameter, each physical I/O fetch operation will get more data.
112 | P a g e
Note The impact of such parameter settings are bi-directional or recursive. To
illustrate, increasing DB_FILE_MULTIBLOCK_READ_COUNT will not only increase the efficiency of full table scans that are chosen. Conversely, increasing this value may also reduce the computed cost of a full table scan, thereby causing the Optimizer to select a plan with table scans which it otherwise might not have. The default value is platform dependent but generally 1MB for most platforms. OLTP databases typically have a value between 4 and 16. Data warehouse databases frequently perform full table scans and can benefit from larger values. Very small tables are often affected by a larger value for this parameter. If most or all of a small table is within the range of this parameter, then a full table scan would be preferable to other access methods.
Note If the information written above seems vague in terms of allowing one to
specify the appropriate value for this parameter, that is exactly the case. It is not easy to select a value which is appropriate for so many different statement execution plans. DB_FILE_MULTIBLOCK_READ_COUNT is an automatically and dynamically tuned parameter. The database will constantly evaluate the I/O capabilities of the host server system and together with the size of the shared global area (SGA) buffer cache will automatically set the appropriate parameter value.
Join Methods
The join operation selected is related to other components within the plan. Which access method is chosen will impact the corresponding join operation chosen, and vice-versa. Also, the order in which the join operations are performed is critical to the amount of data passed up to the next join operation within the plan.
Curriculum Note
This information pertains to internal join operations but is related to logical join operations found within the SQL statement text. For more information about the logical join operations outer join, semi join, anti join and so on, see the prerequisite Sideris course
113 | P a g e
Oracle Database 11g: Introduction To SQL Part II.

Operation HASH JOIN
Explanation Hash joins are very efficient but are only selected for an equality join condition. The steps of a hash join are as follows:
The database will perform a full-table scan of both tables and divide the tables into as many partitions as possible based upon available memory. The database will create a temporary, in-memory bitmap of the smaller table involved in the join and use a hashing algorithm to locate rows in the second table.
The Optimizer will choose this method as the preferred method for joining tables with a large number of rows. When the tables are able to fit within memory this join method is especially fast. There are variations to this join operation, such as HASH JOIN OUTER, HASH JOIN SEMI and HASH JOIN ANTI which employs a hash join for outer join, semi join or anti join operations. The same variations exist with the other join operations shown next. SORT MERGE When indexes are not available for use in joins the database will JOIN sort two tables first and then merge them together based upon the join condition. This method can be effective when the table data is already sorted due to earlier operations within the execution plan. Also, when a non-equality join condition is used this method is often faster than nested loops. NESTED A driver table is designated as the source for providing rows to LOOPS JOIN be joined with another table. This is not efficient when more than 10,000 rows are selected for a join and will thus generally be eliminated by the Optimizer when selecting an optimal plan. However, when indexes are available for many of the columns included within the query and the join operation, and when these indexes are stored within the SGA buffer cache, this operation can be an efficient alternative to a SORT MERGE JOIN.
114 | P a g e
Operation CLUSTER JOIN CARTESIAN JOIN

Note
Explanation This is a join between two tables which are part of the same cluster. This is a form of a NESTED LOOPS JOIN. This is a join operation which involves no key values but involves a multiplication of table data. A largely internal but interesting note pertains to the in-memory sort algorithm used in the newer releases of the database. This algorithm has been largely reengineered from what was found in legacy versions of the database. This means that SORT MERGE JOIN, SORT ORDER BY, PARTITION OUTER JOIN and CREATE INDEX operations are much less costly, and far more efficient now. This magnifies the importance of having sufficient memory for sorts to be performed in-memory rather than using temporary disk segments. Oracle Corporation estimates a 50% performance gain for these operations when they are performed inmemory using the new algorithm.
Nested Loop Join Enhancement A significant enhancement to the internal processing of nested loop joins has been implemented and will be used when the index or table blocks for a join are not entirely cached within the SGA. First of all, consider some background about database I/O operations. As you perhaps know, anytime a needed data block is not available, these must be read from storage by means of a physical I/O. The database can now employ what is known as a vector I/O operation. This means that a series of read operations can be issued and the results stored in an array of buffers. Provided that there is no ordered requirement for the data within the different buffers, then this allows one vectored read call to be issued in place of multiple ordinary read calls. In the context of a nested loops operation, this means that sometimes combining two nested loops operations with vectored reads will be more efficient than a single nested loops join with many more ordinary reads. With this enhancement, a single nested loops operation may be replaced by the Optimizer with the following:
The first nested loops operation will join a table with an index. Those data blocks which are not in memory will be read by means of fewer vectored reads and the results placed within buffers.
115 | P a g e
Since the index reads result in RowID values, the order of the RowIDs between the different buffers produced by the vectored read is not significant. Therefore, another nested loops operation will join the RowID values with the second table of the join. This enhancement to nested loop joins is available starting with Oracle 11g and later releases of the database.
Version note
Join Sub-Methods As you have noticed and we have mentioned, there are variations to some join methods. Consider for example the Hash join. One will sometimes see the Hash Join Semi sub-method within an execution plan.
--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6 | 354 | 14 (15)| 00:00:01 | |* 1 | HASH JOIN | | 6 | 354 | 14 (15)| 00:00:01 | |* 2 | HASH JOIN | | 6 | 264 | 10 (10)| 00:00:01 | |* 3 | HASH JOIN SEMI | | 3 | 93 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| EMPLOYEE | 7 | 147 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| DEPENDENT | 7 | 70 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | WORKS_ON | 16 | 208 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PROJECT | 6 | 90 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------
This method is used when circumstances similar to the EXISTS clause are found within the SQL text. Once the Hash join results in a hit, or the first row is found and joined, the operation terminates and a full hash join of the tables is not needed in this case. This is therefore known as a Hash Join Semi.
116 | P a g e
Index Operations
When indexes are available the Optimizer might judge their use as the most costeffective method of accessing table data.
Operation INDEX UNIQUE SCAN
Explanation Selects a single row using a unique search value against a unique index to fetch the RowID. This is generally followed by TABLE ACCESS BY ROWID to access the table when the query references columns which are not in the index. Columns which are part of the search criteria and which have a unique B-tree index defined are those which might cause such an operation to be selected. Such indexes are created explicitly by the developer, and implicitly for columns with either a UNIQUE or PRIMARY KEY constraint. Similar to INDEX UNIQUE SCAN with the exception that the index is scanned looking for a range of RowIDs rather than a single RowID. Once again this is generally followed by TABLE ACCESS BY ROWID to access the table when the query references columns which are not in the index.
INDEX RANGE SCAN
117 | P a g e
Operation
INDEX SKIP SCAN
BITMAP INDEX SINGLE VALUE BITMAP INDEX RANGE SCAN INDEX FULL SCAN
Explanation If the order of the index corresponds to the ORDER BY clause of the SQL statement then the Optimizer might well use the index to avoid a more costly sort. When a composite index contains some portion of the search value, then an index scan might be faster than a table scan. In this operation, higher levels of the index are skipped in order to access and scan the lower index levels which contain the desired data. Performs a single value lookup using a bitmap index.
This indicates that a range scan is performed on a bitmap index to obtain RowIDs from the bitmap which are then converted to physical RowIDs using the BITMAP CONVERSION TO ROWIDS operation. This operation can be used to avoid a sort since the index is ordered. An INDEX FULL SCAN operation is performed when the predicate references at least one column which is in the index. This operation is also selected when there is no predicate but when all columns referenced by the query are part of the index. INDEX FAST This operation is selected when all columns referenced in the FULL SCAN query are part of the index. This operation is faster than an INDEX FULL SCAN since multiple block reads are performed. This operation may also be parallelized. INDEX JOIN This operation is selected when tables are joined together and when all query columns are part of the index definitions. This performs a HASH JOIN of all applicable indexes.
Data Operations
Various data operations may be included in a plan to implement the objectives contained within the SQL text. These are a selection of data operations which you might see.
118 | P a g e
Operation SORT AGGREGATE SORT UNIQUE SORT GROUP BY HASH GROUP BY SORT ORDER BY FILTER
Explanation Sort operation used when an aggregate function is applied to a set of rows. The built-in function SUM() is one such example. Sort operation which precedes an operation to remove duplicate values from a result set. Sort operation to accommodate a GROUP BY clause within the SQL text. As an alternative to a sort, a hashing operation is used to accommodate a GROUP BY clause. Sort operation to accommodate an ORDER BY clause within the SQL text. Selects a subset of rows from a result set, often to implement a SQL predicate contained within the WHERE clause of the SQL text.
Section Review
Table access methods are used to fetch data blocks from the database objects used by a SQL statement. An access method by be sequential, as is the case with TABLE ACCESS FULL. Or, an access method could be selective, such as with the methods TABLE ACCESS BY ROWID and TABLE ACCESS CLUSTER. Join methods are used to join tables or interim result tables within a plan. Common examples are HASH JOIN, SORT MERGE JOIN and NESTED LOOPS JOIN. Table access methods may utilize index objects. Such access methods may be INDEX UNIQUE SCAN and BITMAP INDEX RANGE SCAN. Data operations may supplement an execution plan, with examples being SORT GROUP BY, SORT ORDER BY and FILTER.
119 | P a g e
Workshop Section: Execution Plan Methods & Operations

Exercises

Build several SQL statements which include joins and observe the various execution plans that are selected. Observe many of the operations we have discussed actually being used within execution plans.
Operations-1
Within the next several exercises we will list a SQL statement to be executed and invite you to execute the statement on your own database and then use your preferred method of explaining the statement to review the execution plan. Do your best to decipher the individual steps of the execution plan selected from the Optimizer of your workshop database and reconcile these operations with the explanations provided within the lecture notes of this section.
In our first example we will build a SQL statement which will query transactions within the EQUITIES sample database. For each brokerage office we want to list the number of transactions processed as well as the sum total of transactions handled by the office. List this information ordered by the sum total transaction amount.
SQL> SELECT office_name, COUNT(*), SUM(number_shares * price) transaction_amount FROM brokerages, transactions WHERE brokerages.brokerage_id = transactions.brokerage_id GROUP BY office_name ORDER BY transaction_amount; 120 | P a g e
OFFICE_NAME COUNT(*) TRANSACTION_AMOUNT ------------------------- --------- -----------------Eastern Securities 28 87280 NYC Securities 28 92344 Wall Street Funds 28 97464 Quebecois Investments 28 102640 Canadian Fiduciary 28 107872 Midwest Trust 28 113160
Answers In the execution plan shown below, and presumably in the execution plan selected by your workshop database when you execute the query locally, notice the following operations:

The small tables are quickly and ideally accessed with a full table scan. With these tables entirely stored within memory, a hash join operation represents the best join method. A sort or a hash is performed in preparation for summarization of data as directed by the GROUP BY clause. The final result table is sorted as directed by the ORDER BY clause. The columns chosen are projected.
-----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -----------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 168 | 11088 | 9 (34)| 00:00:01 | | 1 | SORT ORDER BY | | 168 | 11088 | 9 (34)| 00:00:01 | | 2 | SORT GROUP BY | | 168 | 11088 | 9 (34)| 00:00:01 | |* 3 | HASH JOIN | | 168 | 11088 | 7 (15)| 00:00:01 | | 4 | TABLE ACCESS FULL| BROKERAGES | 6 | 162 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| TRANSACTIONS | 168 | 6552 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------------
Operations-2
121 | P a g e
The latter part of the calendar year tends to have more trading volume than other parts of the year due to tax-related transactions, post-summer activity, etc. Therefore, modify the SQL statement to include only those transactions which were processed during the Autumn or Winter seasons.
SQL> SELECT office_name, COUNT(*), SUM(number_shares * price) transaction_amount FROM brokerages, transactions, time WHERE brokerages.brokerage_id = transactions.brokerage_id AND time.time_id = transactions.time_id AND season IN ('Autumn', 'Winter') GROUP BY office_name ORDER BY transaction_amount; OFFICE_NAME COUNT(*) TRANSACTION_AMOUNT ------------------------- --------- -----------------Eastern Securities 14 43640 NYC Securities 14 46172 Wall Street Funds 14 48732 Quebecois Investments 14 51320 Canadian Fiduciary 14 53936 Midwest Trust 14 56580
Answers In the execution plan produced in our database notice the following operations. Bear in mind that your local results may differ, but the larger point is the ability to understand whatever execution plan is produced:
The TIME table is scanned to find those rows for which the SEASON column value matches our search condition. Optimizer statistics correctly indicate that the entire table may be scanned and loaded into memory quickly. The TRANSACTIONS table is subject to a full table scan as well since it had poor selectivity. The TIME and TRANSACTIONS tables are included in a hash join as we would expect for in-memory tables. Since information will be presented by brokerage office, the BROKERAGES table is scanned in sorted order using the index. With BROKERAGES available in a sorted order, a nested loops join is performed between this table and the result of the hash join of TIME and
122 | P a g e
TRANSACTIONS. The result table is further sorted in preparation for the GROUP BY summarization. The end result is sorted again for the ORDER BY clause and the columns are projected.
----------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 84 | 7644 | 95 (4)| 00:00:02 | | 1 | SORT ORDER BY | | 84 | 7644 | 95 (4)| 00:00:02 | | 2 | SORT GROUP BY | | 84 | 7644 | 95 (4)| 00:00:02 | | 3 | NESTED LOOPS | | 84 | 7644 | 93 (2)| 00:00:02 | |* 4 | HASH JOIN | | 84 | 5376 | 9 (12)| 00:00:01 | |* 5 | TABLE ACCESS FULL | TIME | 2 | 32 | 4 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | TRANSACTIONS | 168 | 8064 | 4 (0)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID| BROKERAGES | 1 | 27 | 1 (0)| 00:00:01 | |* 8 | INDEX UNIQUE SCAN | BROKERAGES_PK | 1 | | 0 (0)| 00:00:01 | -----------------------------------------------------------------------------------------------
Operations-3
Modify the query again to isolate only those transactions during the latter part of the year which involved equities in non-USA companies.
SQL> SELECT office_name, COUNT(*), SUM(number_shares * price) transaction_amount FROM brokerages, transactions, time, stocks WHERE brokerages.brokerage_id = transactions.brokerage_id AND time.time_id = transactions.time_id AND stocks.stock_id = transactions.stock_id 123 | P a g e
AND season IN ('Autumn', 'Winter') AND nation <> 'USA' GROUP BY office_name ORDER BY transaction_amount; OFFICE_NAME COUNT(*) TRANSACTION_AMOUNT ------------------------- --------- -----------------Eastern Securities 4 11584 NYC Securities 4 12278 Wall Street Funds 4 12980 Quebecois Investments 4 13690 Canadian Fiduciary 4 14408 Midwest Trust 4 15134
Answers In the execution plan please notice the following operations:

The STOCKS table is referenced by a full table scan to select only those equities for non-USA companies. A series of nested joins are performed with each of the tables specified. Hash joins are preferred unless an operation allows a table to be in sorted order.
----------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 24 | 2976 | 39 (8)| 00:00:01 | | 1 | SORT ORDER BY | | 24 | 2976 | 39 (8)| 00:00:01 | | 2 | SORT GROUP BY | | 24 | 2976 | 39 (8)| 00:00:01 | | 3 | NESTED LOOPS | | 24 | 2976 | 37 (3)| 00:00:01 | |* 4 | HASH JOIN | | 24 | 2328 | 13 (8)| 00:00:01 | |* 5 | HASH JOIN | | 48 | 3888 | 9 (12)| 00:00:01 | |* 6 | TABLE ACCESS FULL | STOCKS | 2 | 40 | 4 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | TRANSACTIONS | 168 | 10248 | 4 (0)| 00:00:01 | |* 8 | TABLE ACCESS FULL | TIME | 2 | 32 124 | P a g e
| 4 (0)| 00:00:01 | | 9 | TABLE ACCESS BY INDEX ROWID| BROKERAGES | 1 | 27 | 1 (0)| 00:00:01 | |* 10 | INDEX UNIQUE SCAN | BROKERAGES_PK | 1 | | 0 (0)| 00:00:01 | -----------------------------------------------------------------------------------------------
Section 5: Managing Optimizer Statistics

Overview
Objectives

Learn More About Optimizer Statistics Automatic Maintenance Tasks Manually Gathering Optimizer Statistics Using Historical Statistics Dynamic Sampling Of Statistics Locking Statistics
Section Overview
The Optimizer does a remarkable, albeit not infallible, job of determining the best execution plan for a SQL statement based upon the current state of the application tables involved. However, in order for the Optimizer to function properly, adequate schema statistics must be collected and stored. And these statistics must be periodically updated as the tables change so that they do not become stale. Within this section we will discuss the following subjects related to Optimizer statistics and their management:

Understand Optimizer statistics and the statistics collection algorithms. Discuss how the Auto-Task infrastructure is used to automatically gather Optimizer statistics and how one can customize and otherwise manage that infrastructure.
125 | P a g e
Manually gather database statistics using the DBMS_STATS() systemsupplied package and the EM interface. Consider customized options available for statistics gathering and how these may be applied both to the Auto-Task automated collection infrastructure and to manual procedures. Understand the importance of statistics for dictionary and fixed objects. Implement dynamic sampling Learn how to use historical statistics Consider the benefit of locking statistics
Note Collecting or gathering Optimizer statistics for database objects such as tables is sometimes referred to as analyzing a table since essentially a statistical analysis of the object is performed. In fact, in legacy versions of the database one collected Optimizer statistics using the ANALYZE command, although this method is no longer supported.
More about Optimizer Statistics

Gathering Optimizer statistics is a common maintenance task for which the database administrator is responsible and application developers are sometimes asked to assist. Schema statistics are essential for the Optimizer to function and for the advisory framework to succeed. And once statistics are gathered, if they become stale then inefficient SQL execution can result. Among the application objects for which statistics are essential are tables, columns, indexes, partitions and sub-partitions. While Optimizer statistics cannot be collected at the cluster level, the individual tables which comprise a cluster will have statistics collected. Note System statistics are a different set of measures and these are considered later within this section. Statistics Collection Algorithms Optimizer statistics may be collected using any of several different algorithms as shown next.
126 | P a g e
Computed this performs a full-table scan and by reading each row an exact count of statistical measures of the object is gathered. This is a timeconsuming process for large tables and also requires temporary space for sorts which are performed during the process. Generally it is not necessary to collected computed statistics. Estimated this will use the random sampling capabilities of the database to extrapolate statistics based upon a subset of the table data. Generally a 10% to 20% sample is more than sufficient to collect useful statistics and no sort or temporary space is required. Note that some statistics are always computed regardless of which method is selected. While one can specify the estimated sampling percentage, there also exists the option AUTO_SAMPLE_SIZE which automatically computes the appropriate sample based upon the statistical properties of the database object. User-defined user-defined statistical sampling may be created and used. This method is outside the scope of this course.
Estimated Optimizer Statistics When one has selected estimate Optimizer statistics, then following options are available:
Row sampling this will include a specified percentage of the rows for the sample. This is the most time-consuming method of estimated sampling and is generally not necessary. Block sampling this will include a specified percentage of the blocks for the sample. While this is more efficient than row sampling and generally results in a high-quality sample, a poor sample may be obtained if rows are concentrated within certain blocks and not well distributed throughout the data blocks. Index statistics cannot use block sampling.
Effect upon Parsed SQL Statements When Optimizer statistics are updated for SQL statements which have already been parsed, such as those being cached within the SGA, the following will occur:

All such SQL statements are invalidated and will require a new hard parse. During the new parse fresh execution plans are generated based upon the latest statistics. Based upon the new statistics, the Optimizer may therefore change the selected plan.
127 | P a g e
Automatic Maintenance Tasks

A variety of maintenance tasks must be regularly performed by nearly any database instance. These tasks are essential components in allowing the advisory and management framework to operate successfully. About Auto-Task Traditionally there were various ways in which the administrator both manually and automatically attempted to schedule these tasks for regular execution. This effort is replaced with the automatic maintenance tasks infrastructure, also known as Auto-task. Using this infrastructure, one can quickly enable, disable or configure the automatic execution of these maintenance tasks. The Auto-Task infrastructure currently includes these tasks:

Optimizer statistics collection Periodic examination of physical storage using the Segment Advisor Periodic examination of SQL execution efficiency using the SQL Tuning Advisor
Each of these tasks can and sometimes should be launched manually. But as part of the self-monitoring and self-diagnosing capabilities of the database, they have been included in the Auto- Task infrastructure. Auto-Task is implemented using the database Scheduler. We will briefly review the implementation of the Auto-Task infrastructure, and then demonstrate how the infrastructure may be managed.
Curriculum Note
The database Scheduler is an entire database subsystem which is used by several components within the database architecture. The Scheduler may also be employed in customer-defined utilities and applications. While a detailed discussion of Scheduler options which apply to the topics of this section is not considered here, one can learn about this facility from the Sideris course Oracle Database 11g: Resource Manager & Scheduler.
128 | P a g e
Auto-Task Architecture & Implementation If one were to click on the Server Jobs link while connected to the database as the SYS super administrator, among other jobs one will find the jobs ADV_SEGMENTADV_* and BSLN_MAINTAIN_STATS_JOB.
These are system-defined jobs which are deployed to the database Scheduler whenever the AutoTask maintenance framework is enabled. Specifically those jobs launch the Segment Advisor and the Optimizer statistics collection. If one were to click on the History link, then the actual execution history of these jobs as they are regularly started can be seen.
129 | P a g e
The job names ORA$AT_* apply to the Auto-Task infrastructure. The ORA$AT_OS_OPT_*, ORA$AT_SA_SPC_*, and ORA$AT_SQ_SQL_* jobs are used for the Optimizer statistics, Segment Advisor and SQL Tuning Advisor tasks respectively. Scheduler Windows
130 | P a g e
A maintenance window defines a window of opportunity in which a job, such as optimizer statistics collection, can execute safely without affecting the production environment system. It is defined as an allocated period of time in which jobs are permitted to execute. By default, several maintenance windows already defined and can be used immediately From the database home page, click on the Server Windows link to manage Scheduler windows. The pre-defined windows may be modified or new ones created.
The Scheduler also supports the concept of a window group. This is a combination of scheduler windows. For example, by default a window group named MAINTENANCE_WINDOW_GROUP is defined which includes the windows MONDAY_WINDOW through SUNDAY_WINDOW. The Auto-Task infrastructure uses a different window group for each automatic maintenance task. Click on the EM link Server Window Groups.
131 | P a g e
The window groups ORA$AT_WGRP_* apply to the Auto-Task infrastructure. The window groups ORA$AT_WGRP_OS, ORA$AT_WGRP_SA and ORA$AT_WGRP_SQ are used for the Optimizer statistics, Segment Advisor and SQL Tuning Advisor tasks respectively. In this way, each one of the Auto-Task tasks is able to run according to its own unique schedule. These tasks execute automatically, as frequently as is needed, and at a time least likely to interfere with normal database operations. The specific schedule for any one of these can be seen by clicking on the appropriate window group, and then examining the time for each window within these groups.
132 | P a g e
So in the example of the Optimizer statistics gathering, this structure allows fresh statistics to be gathered on a regular basis, automatically, and at an unobtrusive time.
Note The STATISTICS_LEVEL database parameter must be set to at least
TYPICAL in order for the Optimizer Statistics Gathering task to operate. Managing Auto-Task Using EM
With this understanding of some of the internal mechanisms used for the Auto-Task framework, consider now how one would manage this environment. The starting point is the EM link Server Automated Maintenance Tasks. This screen provides a clear summary of the tasks included within the Auto-Task implementation. It also shows the time when they last executed and the future window in which they will execute next.
133 | P a g e
In the case of the Segment Advisor and Automatic SQL Tuning one can click on these links and observe the results of the task and any tuning advice which has been proposed. In the case of the Optimizer Statistics Gathering, the primary result is that the statistics have been collected and are now fresh, so there are no further details to examine. By default Auto-Task is enabled and the infrastructure has a set of default settings. One can customize the configuration by clicking on the Configure button. Configure Auto-Task
As you can see, one has the option to globally enable or disable the entire infrastructure, or to do the same with individual tasks, by clicking on the respective Enabled and Disabled buttons, followed by the Apply button. Within the Maintenance Window Group Assignment section of the page, one has the option to enable or disable specific Scheduler windows within the window group.
134 | P a g e
Managing Auto-Task Using SQL
The infrastructure can also be managed using the system-supplied package DBMS_AUTO_TASK_ADMIN(). Configuration settings and maintenance task history are reflected in a series of views named DBA_AUTOTASK_*. Notice how the Auto-Task job history can also be obtained from the view DBA_AUTOTASK_JOB_HISTORY.
SQL> SELECT client_name, job_name, window_name FROM dba_autotask_job_history; CLIENT_NAME JOB_NAME ----------------------------------- -------------------------auto optimizer stats collection ORA$AT_OS_OPT_SY_32 auto optimizer stats collection ORA$AT_OS_OPT_SY_37 auto optimizer stats collection ORA$AT_OS_OPT_SY_1 auto optimizer stats collection ORA$AT_OS_OPT_SY_21 SATURDAY_WINDOW auto optimizer stats collection ORA$AT_OS_OPT_SY_26 SATURDAY_WINDOW auto optimizer stats collection ORA$AT_OS_OPT_SY_30 SATURDAY_WINDOW auto optimizer stats collection ORA$AT_OS_OPT_SY_43 auto optimizer stats collection ORA$AT_OS_OPT_SY_46 TUESDAY_WINDOW auto optimizer stats collection ORA$AT_OS_OPT_SY_75 SATURDAY_WINDOW auto optimizer stats collection ORA$AT_OS_OPT_SY_77 SATURDAY_WINDOW .. auto space advisor ORA$AT_SA_SPC_SY_33 auto space advisor ORA$AT_SA_SPC_SY_36 auto space advisor ORA$AT_SA_SPC_SY_38 auto space advisor ORA$AT_SA_SPC_SY_40 auto space advisor ORA$AT_SA_SPC_SY_42 auto space advisor ORA$AT_SA_SPC_SY_2 auto space advisor ORA$AT_SA_SPC_SY_25 SATURDAY_WINDOW auto space advisor ORA$AT_SA_SPC_SY_29 SATURDAY_WINDOW ... sql tuning advisor ORA$AT_SQ_SQL_SW_3
WINDOW_NAME ------------SUNDAY_WINDOW SUNDAY_WINDOW FRIDAY_WINDOW
MONDAY_WINDOW
SUNDAY_WINDOW SUNDAY_WINDOW SUNDAY_WINDOW SUNDAY_WINDOW SUNDAY_WINDOW FRIDAY_WINDOW
FRIDAY_WINDOW 135 | P a g e
sql tuning advisor SATURDAY_WINDOW sql tuning advisor sql tuning advisor TUESDAY_WINDOW sql tuning advisor SATURDAY_WINDOW sql tuning advisor WEDNESDAY_WINDOW sql tuning advisor THURSDAY_WINDOW ...
ORA$AT_SQ_SQL_SW_23 ORA$AT_SQ_SQL_SW_45 ORA$AT_SQ_SQL_SW_48 ORA$AT_SQ_SQL_SW_74 ORA$AT_SQ_SQL_SW_65 ORA$AT_SQ_SQL_SW_68 MONDAY_WINDOW
The CLIENT_NAME column is the name of an Auto-Task client or task. Enable & Disable Tasks Using the ENABLE() and DISABLE() program units within the DBMS_AUTO_TASK() package, one could name a particular client and selectively enable or disable it. As you can see in this example, The Optimizer Statistics Gathering task or client is disabled.
BEGIN dbms_auto_task_admin.disable( client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); END; /
Enable & Disable Auto-Task One could also call the ENABLE() and DISABLE() programs without any parameters to globally enable or disable all tasks.
BEGIN dbms_auto_task_admin.disable(); END; /
Enable & Disable Scheduler Windows One can enable or disable individual windows within the assigned window group, thereby modifying the frequency with which the task is scheduled.
136 | P a g e
BEGIN dbms_auto_task_admin.disable( client_name => 'auto optimizer stats collection', operation => NULL, window_name => 'FRIDAY_WINDOW'); END; /
Beyond just the scheduling, the actual operation of the tasks may also be configured. This is outside the scope of the Auto-Task infrastructure, and the available options are dependent upon each individual task.
Manually Gathering Statistics

In most cases, you will automatically gather Optimizer statistics via the Auto-Task framework. However, there are circumstances in which manually gathered statistics will be suitable. Why Manually Gather Statistics? Consider some scenarios which demonstrate circumstances in which a custom or even manual statistics collection scheme may need to be implemented. Suppose the maintenance window is scheduled to execute at night, which in fact is the default structure within Auto-Task. This may suit most of the database since these tasks will execute during what are off-hours for the database installation. But suppose further that a number of critical historical tables are subject to mass updates each morning. In the cases of these few but critical tables, the statistics collected the night before will be stale before they are even used. In such a case one might collect statistics manually right after the bulk load. Thus the gathering of statistics would be incorporated into the application processing rather than the database administration framework. In another scenario, some web-based applications will dynamically create and drop large numbers of tables as part of the background processing for online users. This sometimes occurs for shopping-cart functionality, where lists of products are selected, considered for purchase, but then dropped. A newly created object will not have statistics.
137 | P a g e
Of course, an Auto-Task operation can also simply fail due to some unrelated circumstance. Once one addressed the underlying cause for the failure, one would still need to update the statistics using a manual operation. Statistics may be manually gathered using either the programmatic or commandline interface, or the EM interface, as shown here.
Note Beyond what has been mentioned here, there are several potentially serious
performance problems which can result when relying upon standard Optimizer statistics collection procedures. As you will see later within this course, in a production environment circumstances may occur in which SQL execution issues cannot be resolved unless customized Optimizer statistics collection procedures are built. This can be especially true in data warehouse, business intelligence and online e-commerce environments. Therefore, while this subject can be extensive, it remains necessary. Dictionary Objects & Fixed Objects SQL statement execution utilizes internal metadata objects from the data dictionary, in addition to the schema objects directly referenced by the SQL text. These are known as dictionary objects and collecting statistics for these tables is at least as important as it is for the application schema objects. During the operation of the database instance and the execution of SQL statements, in-memory data structures sometimes called the dynamic performance views are created. These are generally named with the prefix V$ or GV$, and they are based upon underlying internal tables named with the prefix X$. These tables are known as fixed objects and they too must have statistics collected. One can examine a list of the fixed objects, and the view which accesses the underlying tables upon which they are based, by consulting V$FIXED_VIEW_DEFINITION.
SQL> SELECT * from v$fixed_view_definition; VIEW_NAME VIEW_DEFINITION ------------------------------ -------------------------------------------GV$CR_BLOCK_SERVER select inst_id, reqcr, reqcur, reqdata, requndo, reqtx, reqother, rescur, respriv, reszero, resdisk, resfail, stale, fairdc, faircl, 0, flush, 0, 138 | P a g e
flushf, flushmx, light, signal from x$kclcrst GV$CURRENT_BLOCK_SERVER pin1000, select inst_id, pin1, pin10, pin100, pin10000, flush1, flush10, flush100, flush1000, flush10000, write1, write10, write100, write1000, write10000, cleandc, rcvdc, queuedc, evictdc, writedc from x$kclcurst GV$ENCRYPTED_TABLESPACES 'NONE', select INST_ID, TS#, decode(ALG, 0, 1, '3DES168', 2, 'AES128', 3, 'AES192', 4, 'AES256'), decode(ENCTS, 0, 'NO', 'YES') from X$KCBTEK where ENCTS <> 0 and DROPPEDTS = 0 ...
Therefore, if it becomes necessary to manually collect Optimizer statistics one must consider the dictionary objects and fixed objects as well as application schema objects. Managing Optimizer Statistics Using EM One can manage optimizer statistics using the Server Manage Optimizer Statistics link, found within the Query Optimizer section of the Server page.
From the resulting page, one can perform both standard and specialty tasks related to Optimizer statistics. We will discuss most of these options later in this section in the context of the DBMS_STATS() system-supplied package.
139 | P a g e
The primary option for manual collection of statistics is the Gather Optimizer Statistics link, and we will demonstrate that choice next.
Note Among the most critical objects for which to gather statistics are the internal
metadata objects. This requires the ANALYZE ANY DICTIONARY system privilege. Therefore, in order to demonstrate the full range of available options we will use the SYSDBA super administrator role for the EM connection in the screen shots shown next. Gather Optimizer Statistics
140 | P a g e
A wizard is presented as a guide to the operation, with the Scope page shown first. One has the option to collect statistics for the entire database, or to isolate an individual schema or even selected tables and indexes within schemas. One can also reference the fixed objects and dictionary objects. If one has selected the Database scope, then one can customize options for such a broad collection of statistics, or one can rely upon Oracle-recommended settings. The navigation path presented by the remaining pages of this wizard will be based upon the following selections:
141 | P a g e
If one chooses the Schema, Tables or Indexes scope, then the Objects screen is presented. Otherwise that step is omitted by the wizard. If one chooses Customize Options, then the Customize Options screen is presented. Otherwise that step is omitted.
This example of the Objects screen is based upon a selection of Tables from the Scope screen. Enter the appropriate schema or click the Search icon to search available schemas. One could also use the Object, Partition and Subpartition items to filter the list of objects to be shown. Then click on the Search button to obtain a list of tables based upon these elements.
142 | P a g e
Details about each object and when statistics were last collected are shown, and one can use the Select checkbox to determine exactly which objects should be included in the operation. Click the OK button to proceed.
The Objects screen will show the set of objects to be included in the operation. One can click the Remove icon to remove one of those selected. And one can click the Lock Optimizer Statistics checkbox to lock the statistics after the operation has completed. Finally one would click the Next button to proceed. locate those objects. The Select All or Select controls would allow one to specify which objects should be selected. As you can see from the Last Analyzed column, there are several tables for which there are no Optimizer statistics. Click the OK button followed by the Next button to proceed. If one has chosen the Customize Options selection from the Scope page, then the Options screen is presented next by the Wizard. One can choose the desired selections and click the Next button to proceed.
143 | P a g e
Note The meaning and significance of each of these options is explained next
during the discussion of the DBMS_STATS() package.
144 | P a g e
The manual statistics gathering task will be executed using the database Scheduler. The Schedule screen presents the standard selections available for scheduling a job using this facility.
145 | P a g e
A summary of the options selected during the wizard dialog is presented. One can use the Back button to modify the selections made or click the Submit button to submit the job as defined. The job will call appropriate program units within the DBMS_STATS() systemsupplied package to perform the operation.
If successfully submitted, a Confirmation message is displayed as one navigates automatically back to the Manage Optimizer Statistics page within EM. One could click the Job Name link and follow the progress of the job execution, including examining the log file produced by the Scheduler for all database jobs.
146 | P a g e
These are the job details shown for the sample operation launched in this demonstration. About the Related Links
147 | P a g e
As you recall, the Manage Optimizer Statistics page also includes a Related Links section where additional features related to managing Optimizer statistics are available. As you have seen, customized options are available for each call to the DBMS_STATS() package, whether this call is made directly from the SQL interface or indirectly through the wizards of the EM interface. Additionally, one can modify the defaults which are implied any time the DBMS_STATS() package is invoked and these customized options are not explicitly stated. Such default options are known as preferences, and they may be managed using the links Global Statistics Gathering Options and Object Level Statistics Gathering Preferences. These links will, in turn, invoke the following program units from the DBMS_STATS() package. Once again, we will discuss these options in detail when considering calling the package from the SQL interface.

SET_DATABASE_PREFS() SET_SCHEMA_PREFS() SET_TABLE_PREFS() SET_GLOBAL_PREFS()

148 | P a g e
The Object Statistics link provides another very useful vantage point from which Optimizer Statistics may be managed. In particular, before one performs any manual Statistics gathering operation or customization of the Auto-Task framework, it may be helpful to examine the state of statistics as they currently exist. Object Statistics
Using the Search elements one can identify the objects to be examined and click the Go button. A Summary of the statistics status for each such object is presented.
149 | P a g e
Based upon the information shown, the Action list allows one to invoke appropriate program units from the DBMS_STATS() package and manually manage the statistics. Managing Optimizer Statistics Using DBMS_STATS() The DBMS_STATS() package is used by the EM interface and the Auto-Task framework to collect Optimizer statistics. One can also directly invoke the program units within this package to create a customized statistics collection utility. This customer-defined utility could be incorporated into the application logic, so that whenever application maintenance operations occur which could affect SQL statement execution, appropriate Optimizer statistics operations are run at the same time. By default the EXECUTE object privilege for this package is granted to all users. Some of the primary program units within this package which we will consider next are:

GATHER_TABLE_STATS() GATHER_INDEX_STATS() GATHER_SCHEMA_STATS() GATHER_DATABASE_STATS() GATHER_DICTIONARY_STATS() GATHER_FIXED_OBJECTS_STATS()
Note While one may have the EXECUTE privilege on this package, the objects to
which this package may be applied will be dependent upon object privileges for those schema objects. GATHER_TABLE_STATS() This procedure will collect statistics for the specified table and optionally for any associated indexes. In this example the first parameter is omitted indicating that the object is located within the current schema. The second parameter is the name of the table for which new statistics should be gathered. There are other optional parameters which follow but these have been omitted for this call and the default values applied. An explanation of available parameters is shown below.
BEGIN 150 | P a g e
dbms_stats.gather_table_stats (ownName => NULL, tabName => 'employee'); END; /
The data dictionary table USER_TABLES is then queried to confirm the results of the gathering task. This is illustrative of the location where the Optimizer statistics are stored.
SQL> SELECT table_name, last_analyzed, avg_row_len FROM user_tables WHERE table_name = 'EMPLOYEE'; TABLE_NAME LAST_ANAL AVG_ROW_LEN ------------------------------ --------- ----------EMPLOYEE 01-FEB-11 76
The data dictionary table views where one can find the majority of schema statistics are:

DBA_TABLES DBA_TAB_STATISTICS DBA_TAB_COLUMNS DBA_INDEXES DBA_IND_STATISTICS
General Parameters
Parameter ownName tabName partName
Explanation Name of the schema or owner of the table to be statistically analyzed. Name of the table to be statistically analyzed. If applicable the name of a specific partition to be analyzed. For very large tables and when mass updates are implemented on a partition basis, as is frequently the case in data warehouse environments, then analysis of just a partition is often all that is needed. For example, suppose that a transactional history table partitioned by month contains millions of rows for the past several years. The creation of a new partition for the latest month which is then uploaded with data would be the only portion of the table which would then need to be analyzed to maintain current statistics.
151 | P a g e
Functional Parameters
Parameter Explanation estimate_percent The following values are permitted:

NULL this specifies computed statistics. Numeric value must be in the range of .0001 to 100 and specifies the percentage of sampling for estimated statistics. dbms_stats.auto_sample_size this is a package constant name which performs an automatically computed estimated sample. This should generally be used as explained earlier in this section.
block_sample
The following possible values may be supplied:
NULL When ESTIMATE_PERCENT is NULL and computed statistics are being collected then this parameter is not applicable and should also be NULL. TRUE When ESTIMATE_PERCENT is specified and estimated statistics are collected this states that a sample of blocks should be used. FALSE When ESTIMATE_PERCENT is specified and estimated statistics are collected this states that a sample of rows should be used.
method_opt
degree
This option is used to control statistics collection for individual columns and is most helpful when creating histograms or when extended statistics are needed. The default value is FOR ALL COLUMNS SIZE AUTO. For very large tables parallelization of the analyze process is very helpful. Valid values are:

Number an explicit degree of parallelization. NULL the default parallelization degree specified for the table, if any, will be used.
152 | P a g e
Parameter
Explanation
this package constant states that the degree of parallelization should be determined by the instance default, if such has been enabled by the administrator. Automatic parallelization tuning is enabled when the database parameter PARALLEL_ADAPTIVE_MULTI_USER is set to TRUE. dbms_stats.auto_degree a constant which states that parallelization degree should be automatically determined according to the rules of the DBMS_STATS() package, which is not necessarily the same degree computed by the database instance using the previous option.
dbms_stats.default_degree
granularity
This is only relevant if the table is partitioned. The following values are possible:

AUTO is the default and determines the level of statistics depending upon the type and degree of partitioning. GLOBAL will collect global statistics only. PARTITION will collect partition-level statistics only. SUBPARTITION will collect subpartition-level statistics only. GLOBAL AND PARTITION will gather global and partition-level statistics but not subpartition statistics. ALL will collect global, partition-level and subpartitionlevel statistics.
cascade
The following possible values may be supplied:
TRUE indicates that statistics should be collected for all indexes associated with this table. This will invoke the program GATHER_INDEX_STATS() for each index. FALSE will not collect index statistics and this must be manually done at a later time if desired. dbms_stats.auto_cascade is a package constant which will automatically determine whether or not the operation should cascade to indexes. This is the default.
no_invalidate
This determines whether or not shared SQL cursors should be

153 | P a g e
Parameter
Explanation invalidated, requiring a hard-parse and a new execution plan based upon the new statistics. Options are:

TRUE do not invalidate the shared cursor and retain existing execution plans. FALSE invalidate shared cursors and reparse SQL statements dependent upon the analyzed object(s). dbms_stats.auto_invalidate is a package constant which will automatically determine whether or not the new statistics are significant enough such that invalidation is beneficial. This is the default.
force
When set to TRUE this will gather statistics even if the table is locked for update.
With these options in mind, notice the following example in which a 20% estimated sample is used and Block sampling is chosen rather than row sampling.
BEGIN dbms_stats.gather_table_stats (ownName tabName partName estimate_percent block_sample END; /
=> => => => =>
NULL, 'employee', NULL, 20, TRUE);
Note These are the customized options that one can also select when using the EM
interface and the Manage Optimizer Statistics link. These are also the options for which default preferences may be set using both the EM interface and the SET_*_PREFS() program units of the DBMS_STATS() package. Statistics Table Parameters Parameters are available which allow one to store statistics these within private user-defined statistics tables. While only statistics stored within the data dictionary affect the Optimizer, one could export and import to the data dictionary from these private statistics tables. In this way one could experiment with sets of statistics for one application versus another to judge which provides the best overall performance for all applications which might reference the database objects.
154 | P a g e
When one wishes to collect the statistics into such private statistics tables, these parameters would be specified.
Parameter Explanation statTab This indicates the name of the statistics table to be used. statID This allows a unique identifier for the statistics to be added to the statTab parameter. In this way a series of statistics for a single object may be maintained. statOwn If the user-defined statistics table is stored in a different schema than the one which owns the table being analyzed, this parameter identifies the schema in which the statistics table is created. GATHER_INDEX_STATS() This procedure will collect statistics for the specified index. Under rare circumstances one might need to rebuild and recollect statistics for an index while the table remained relatively static. Otherwise, the call to this program unit is similar to what was outlined above for tables.
BEGIN dbms_stats.gather_index_stats (ownName => NULL, indName => 'employee_pk'); END; / SQL> SELECT distinct_keys, avg_leaf_blocks_per_key, avg_data_blocks_per_key FROM user_indexes WHERE index_name = 'EMPLOYEE_PK'; DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY ------------- ----------------------- ----------------------168 1 1
The following parameters, discussed earlier, are available for this program unit:

ownName indName partName estimate_percent statTab

155 | P a g e
statID statOwn degree granularity no_invalidate force
GATHER_SCHEMA_STATS() Since the proper functioning of the Optimizer is dependent upon fresh statistics for all major database objects, this procedure is very useful in collecting statistics for all tables within a schema. Optionally, any associated indexes may also be included. The AUTO_SAMPLE_SIZE option discussed earlier is especially important for this procedure since the optimal sampling will differ from one object to another, and the database should be permitted to decide for itself. In the example shown below you will notice that the actual call to the procedure is similar to what we have seen for the other program units. However, an output parameter named objectList is included in the call.
DECLARE objectList
dbms_stats.objectTab;
BEGIN dbms_stats.gather_schema_stats ( ownName => 'student1', estimate_percent => 20, block_sample => TRUE, method_opt => NULL, degree => NULL, granularity => 'AUTO', cascade => NULL, statTab => NULL, statID => NULL, options => 'GATHER', objList => objectList, statOwn => NULL, no_invalidate => NULL, force => NULL, obj_filter_list => NULL); END; /
OPTIONS Parameter
156 | P a g e
The OPTIONS parameter qualifies which objects within the schema should be analyzed. Valid values are:

GATHER will collect statistics on all tables within the schema. This is the default. GATHER STALE will collect statistics on all objects that currently have stale statistics. This requires that tables have the MONITORING option enabled. The objList parameter must be supplied so that the procedure may return a list of objects which have been judged to be stale. GATHER EMPTY will collect statistics on all objects that currently have no statistics. The objList parameter must be supplied so that the procedure may return a list of objects which have been analyzed as a result of this procedure. GATHER AUTO will automatically determine which objects need statistics gathering and the best method to collect those. Most other options must be omitted when choosing this option as they are mutually exclusive. LIST STALE will not collect any statistics but will return a list of objects in the objList parameter which have stale statistics. This requires that tables have the MONITORING option enabled. LIST EMPTY will not collect any statistics but will return a list of objects in the objList parameter which have no statistics. LIST AUTO will not collect any statistics but will return a list of objects in the objList parameter which will be processed if the GATHER AUTO option is specified.
objList Parameter The parameter objList is an output parameter which will hold a list of objects when the Options parameter has been given a non-default value. This parameter must be an object table which conforms to the requirements of the procedure. Such a table has been declared within the DBMS_STATS() package and may be referenced using as dbms_stats.objectTab. About dbms_stats.objectTab The dbms_stats.objectTab object is a PL/SQL collection which is used as a complex type for package parameters. One can reference an instance of this type to obtain results after executing a program within the package. Or, one could set elements within this type before execution of the package to control how the program will function. The structure of this object is shown here.
157 | P a g e
Parameter ownName objType objName partName subPartName confidence
Explanation Schema owner for the database objects listed within the collection. Type for the database objects listed. Database object name. For partitioned database objects, the partition name. For sub-partitioned database objects, the subpartition name. Reserved for future use.
objList Example For instance, suppose that we called the GATHER_SCHEMA_STATS() procedure with the GATHER EMPTY option. It might be useful to know exactly which objects were selected. The collection may be examined as follows, as seen the example below.

The local program variable name is the primary object name. In our example this is objectList. Each entry within the collection is referenced by means of an index. For example, objectList(1), objectList(2) and so on. The element names which comprise the collection definition are the secondary object names. These would be referenced as objectList(x).objName, objectList(x).objType, and so on. Each element may be iteratively processed within a PL/SQL program unit using a LOOP construct. The symbols FIRST and LAST are useful in identifying the beginning and ending entries within the collection.
DECLARE objectList
BEGIN dbms_stats.gather_schema_stats ( ownName => 'student1', estimate_percent => 20, block_sample => TRUE, method_opt => NULL, degree => NULL, granularity => 'AUTO', cascade => NULL, 158 | P a g e
statTab => NULL, statID => NULL, options => 'GATHER', objlist => objectList, statOwn => NULL, no_invalidate => NULL, force => NULL, obj_filter_list => NULL); FOR i IN objectList.FIRST .. objectList.LAST LOOP dbms_output.put_line (objectList(i).objName || ' ' || objectList(i).objType); END LOOP; END; /
In this case we use the GATHER option to process all objects within the schema. When executed the output would be as seen here.
BROKERAGES TABLE DEPARTMENT TABLE DEPENDENT TABLE DEPT_LOCATIONS TABLE EMPLOYEE TABLE PROJECT TABLE STOCKS TABLE TIME TABLE TRANSACTIONS TABLE WORKS_ON TABLE ... PL/SQL procedure successfully completed.
obj_filter_list Parameter The parameter obj_filter_list is an input parameter which can define a filter list of objects within a schema which should be analyzed by GATHER_SCHEMA_STATS(). This parameter is also of the type objectTab. In this example, another instance of objectTab is created under the name filterList. The elements of this collection are set in order to define a filter for the schema objects which should be analyzed. Then, rather than the ownName parameter identifying a schema, the filter list will define both schemas and tables which should be analyzed.
DECLARE 159 | P a g e
objectList filterList
dbms_stats.objectTab; dbms_stats.objectTab := dbms_stats.objectTab();
BEGIN filterList.EXTEND(3); filterList(1).ownName := 'STUDENT1'; filterList(1).objName := 'B%'; filterList(1).ownName := 'STUDENT1'; filterList(1).objName := 'D%'; filterList(3).ownName := 'STUDENT1'; filterList(3).objName := 'T%'; dbms_stats.gather_schema_stats ( ownName => NULL, estimate_percent => 20, block_sample => TRUE, granularity => 'AUTO', objlist => objectList, obj_filter_list => filterList); FOR i IN objectList.FIRST .. objectList.LAST LOOP dbms_output.put_line (objectList(i).objName || ' ' || objectList(i).objType); END LOOP; END; /
Notice how passing a filter list to the parameter obj_filter_list affects the objects which are analyzed.
BROKERAGES TABLE DEPARTMENT TABLE DEPENDENT TABLE DEPT_LOCATIONS TABLE TEAMS TABLE TIME TABLE TRANSACTIONS TABLE PL/SQL procedure successfully completed.
Curriculum Note
To learn more about these and other advanced programming features within PL/SQL see the Sideris course Oracle Database 11g: Advanced PL/SQL Programming & Tuning.
160 | P a g e
GATHER_DATABASE_STATS() This procedure will collect statistics on a database-wide scope. Again, one may also include any associated indexes and the set of objects processed may be examined by referencing objectList.
DECLARE objectList dbms_stats.objectTab; BEGIN dbms_stats.gather_database_stats( estimate_percent => 20, block_sample => TRUE, method_opt => NULL, degree => NULL, granularity => 'AUTO', cascade => NULL, statTab => NULL, statID => NULL, options => 'GATHER EMPTY', objlist => objectList); END; /
GATHER_SYS Parameter GATHER_SYS is an additional parameter available in this program. It is a Boolean which indicates whether or not fixed objects owned by SYS should be included. This is a time-consuming but potentially useful option, especially when performance diagnosis indicates that these internal objects are the source of performance bottlenecks. Dictionary & Fixed Objects Statistics Calls One can gather statistics specifically for database objects and fixed objects, using appropriate calls from the DBMS_STATS() package.
Note Remember that the ANALYZE ANY DICTIONARY system privilege is
required to invoke these calls. GATHER_DICTIONARY_STATS()

SQL> CONNECT / AS SYSDBA; Connected. 161 | P a g e
DECLARE objectList
BEGIN dbms_stats.gather_dictionary_stats ( comp_id => 'ORDIM', estimate_percent => 20, block_sample => TRUE, method_opt => NULL, degree => NULL, granularity => 'AUTO', cascade => NULL, statTab => NULL, statID => NULL, options => 'GATHER', objlist => objectList, statOwn => NULL, no_invalidate => NULL, obj_filter_list => NULL); END; /
One can limit the data dictionary scope for which this procedure applies by using the COMP_ID parameter. Using the appropriate component ID, one can select a particular database component for which its dictionary objects are analyzed. Component IDs and their associated database components can be obtained by querying the DBA_REGISTRY view. For example, imagine that one is concerned about the performance of the Oracle Multimedia database component. As part of the tuning effort, one might gather dictionary statistics for just this component. One could obtain the component ID by the following query:
SQL> SELECT comp_id, comp_name FROM dba_registry; COMP_ID -----------------------------OWB APEX EM AMD SDO ORDIM XDB CONTEXT COMP_NAME ---------------------------------OWB Oracle Application Express Oracle Enterprise Manager OLAP Catalog Spatial Oracle Multimedia Oracle XML Database Oracle Text 162 | P a g e
EXF ...
Oracle Expression Filter
Then a subsequent call to the GATHER_DICTIONARY_STATS() package as explained above could reference the component by means of the COMP_ID parameter. GATHER_FIXED_OBJECTS_STATS() This procedure will gather statistics for all in-memory fixed objects.
BEGIN dbms_stats.gather_fixed_objects_stats ( statTab => NULL, statID => NULL, statOwn => NULL, no_invalidate => NULL); END; /
Using Historical Statistics
Whenever statistics are updated, the previous statistics are filed away for future use, if needed. One has the option to then restore the previously collected statistics and put them into use once again. This is useful in situations where newly collected statistics do not lead to an optimal execution plan, and you want to revert to previously collected statistics from which acceptable performance was realized. Example In this example, the statistics restored for the specified table will be as of the timestamp indicated.
SQL> EXECUTE dbms_stats.restore_table_stats ('student1','CUSTOMERS', ' 01163 | P a g e
FEB-11 12.46.35 PM -05:00'); PL/SQL procedure successfully completed.
The DBMS_OPTSTAT_OPERATIONS view contains the history of all schemalevel and database-level statistics gathering operations.
SQL> DESCRIBE dba_optstat_operations; Name Null? ----------------------------------- -------OPERATION TARGET START_TIME ZONE END_TIME ZONE Type ------------------------VARCHAR2(64) VARCHAR2(64) TIMESTAMP(6) WITH TIME TIMESTAMP(6) WITH TIME
By querying this view and then using the timings shown one can decide which set of historical statistics for a given object or target might be useful.
SQL> SELECT operation, end_time FROM dba_optstat_operations WHERE LOWER(target) LIKE '%employee%'; OPERATION END_TIME -------------------- -------------------------------------gather_table_stats 27-JAN-11 09.07.34.775001 PM -05:00 gather_table_stats 27-JAN-11 09.11.27.866484 PM -05:00 gather_table_stats 27-JAN-11 09.15.14.378740 PM -05:00 gather_table_stats 01-FEB-11 10.54.49.245215 AM -05:00 gather_table_stats 01-FEB-11 12.00.06.450316 PM -05:00
Managing Historical Statistics The following program units within the DBMS_STATS() package allow one to manage these historical statistics:

ALTER_STATS_HISTORY_RETENTION() changes the retention period from the default of 31 days. GET_STATS_HISTORY_RETENTION() reports the current retention period. GET_STATS_HISTORY_AVAILABILITY() reports the oldest timestamp supported by the historical statistics on hand.
164 | P a g e
PURGE_STATS() will manually purge the historical statistics if these are no longer needed or useful.
Dynamic Sampling
The Optimizer must have statistics in order to function. But when statistics are missing or have been deleted, then an alternate method must be employed. This is done by means of dynamic sampling. With dynamic sampling, as part of the parse of a SQL statement a recursive SQL statement is automatically issued which performs a small random sample of statistics for the table. The options of Block level sampling and estimated sampling are employed. This statistical sample is then used for the SQL statement. Why Use Dynamic Sampling? Clearly there is a performance cost incurred when introducing dynamic sampling into the parsing of a SQL statement. But under the following combined set of circumstances this might be useful:

A very resource-intensive query is executed frequently. The tables referenced by the query are highly volatile, thus at least partially invalidating the quality of the statistics collected. It is not practical to increase the frequency of the statistics collection to match the updates to the tables.
Forcing Dynamic Sampling One could force dynamic sampling to be employed for an object by the following process:

Call DELETE_TABLE_STATS() to delete statistics for the object. Call LOCK_TABLE_STAT() to lock the missing statistics for the object, thus inducing dynamic sampling.
Controlling Dynamic Sampling
165 | P a g e
Dynamic sampling is controlled by setting the OPTIMIZER_DYNAMIC_SAMPLING database parameter. The following table lists values permitted for this parameter.
Value 0 1
Explanation Dynamic sampling disabled. Dynamic sampling issued for all tables within the statement where the following is true:

Statistics are missing for a table which is included in a join operation The table does not have any indexes The table consumes more than 32 blocks of storage space
2, 3, 4, 5, Dynamic sampling is issued as described above except that the table size 6, 7, 8, 9 threshold is 32 blocks multiplied by this value. 10 Dynamic sampling is issued as described above except that the table size is irrelevant and the sample will read all blocks within the table. This option should be used with caution as it frequently will be counterproductive.
Locking Statistics
As you have seen, while in many cases the automatic collection of statistics is sufficient, in a production environment there are always real-world scenarios within the local installation which do not fit the standard solution. In such cases, one might decide to lock the collection of statistics for one or more objects, while allowing the standard collection process to continue.
166 | P a g e
Consider several reasons why this might be helpful. Some reference tables are almost entirely static. Information like lists of countries, provinces, postal codes and such are updated rarely. In such a circumstance the regular and automatic collection of statistics for that object would be unnecessary, and the resources necessary to do this would be wasted. In other cases one may be engaged in a troubleshooting effort where unpredictable optimization results are occurring. For the time being one might wish to ensure that statistics for certain tables do not change. Finally, one may wish to induce dynamic sampling, and this process would involve locking statistics.
The DBMS_STATS() package provides these procedures for locking and unlocking statistics:

LOCK_TABLE_STATS() LOCK_SCHEMA_STATS() UNLOCK_TABLE_STATS() UNLOCK_SCHEMA_STATS()
Statistics can be locked at the schema or table level. When statistics are locked for a table, all dependent statistics such as those for dependent indexes are also considered locked. Lock Statistics The first example demonstrates the locking of statistics at the table level, whereas the second example locks the collection of statistics for the entire STUDENT1 schema.
SQL> EXECUTE dbms_stats.lock_table_stats ('student1', 'employee'); PL/SQL procedure successfully completed. SQL> EXECUTE dbms_stats.lock_schema_stats ('student1'); PL/SQL procedure successfully completed. 167 | P a g e
Unlock Statistics These next examples unlock the collection of statistics at the table level and at the schema level.
SQL> EXECUTE dbms_stats.unlock_table_stats ('student1', 'employee'); PL/SQL procedure successfully completed. SQL> EXECUTE dbms_stats.unlock_schema_stats ('student1'); PL/SQL procedure successfully completed.
Metadata Storage To determine which tables have been locked, execute the following query on the DBA_TAB_STATISTICS data dictionary table. In this case the EMPLOYEE table statistics are listed as being locked.
SQL> SELECT owner, stattype_locked, table_name FROM dba_tab_statistics WHERE owner = 'STUDENT1'; OWNER STATT TABLE_NAME ------------------------------ ----- -----------------------------STUDENT1 ALL EMPLOYEE STUDENT1 STOCKS STUDENT1 DEPARTMENT STUDENT1 DEPT_LOCATIONS STUDENT1 PROJECT STUDENT1 WORKS_ON STUDENT1 TIME STUDENT1 DEPENDENT STUDENT1 BROKERAGES STUDENT1 TRANSACTIONS
Section Review
Optimizer statistics may be collected using precise, computed statistics or the more efficient estimated sampling algorithm.
168 | P a g e
When one is sampling schema statistics one can use the more precise row sampling method or the more efficient block sampling method. Auto-Task is an infrastructure which exists to automatically perform important database maintenance tasks, including Optimizer statistics collection. Various circumstances exist where one would need to manually gather statistics, and this is done by calling the DBMS_STATS() package either directly from the SQL command-line interface or the using EM graphical interface. It is important that valid statistics exist both for schema objects as well as internal dictionary and fixed objects. On occasion one may wish to revert to a historical set of Optimizer statistics, or to lock the current set of statistics which are in effect. Whenever Optimizer statistics are missing, as a contingency the Optimizer will perform dynamic sampling within the parse phase of each SQL statement to avoid reverting to the primitive rules-based optimization.
Workshop Section: Managing Optimizer Statistics

Exercises

Examine the different execution plans selected by the Optimizer under various circumstances and consider how to influence the plan chosen. Collect and view the database Optimizer statistics. Consider the impact of indexes upon chosen access methods. a different execution plan for the sample queries than that shown within our
169 | P a g e
Note It is certainly possible that due to local circumstances your database will select
solutions. If this is the case, try to draw conclusions from the spirit of the exercises even if the details may differ. Any differences should not impact the point of each exercise. Stats-1
To begin this workshop from a known starting point, recreate the Equities application database. Also, write below what impact will this have on statistics for these objects?
Answers
SQL> @ EquitiesDefine.sql ... SQL> @ EquitiesInsert.sql ...
Any statistics previously collected for the objects which comprise the EQUITIES database will be dropped when the tables are dropped and recreated. Stats-2
Examine the Optimizer statistics stored within the data dictionary for the BROKERAGES table. It would seem from the previous exercise that no such statistics exist.
Answers Just as we expected, the statistics were cleared when the table was recently dropped and recreated.
SQL> SELECT num_rows, last_analyzed FROM user_tables WHERE table_name = 'BROKERAGES'; NUM_ROWS LAST_ANAL ---------- ---------
Stats-3
170 | P a g e
Is it possible at this point that for a query to the BROKERAGES table the Optimizer would still be able to utilize statistics, without any effort on our part to collect such statistics? If so, explain and confirm that such is in effect.
Answers Yes, if dynamic sampling is enabled. The following query would confirm this option and its level of operation.
SQL> CONNECT dba1/dba1; Connected. SQL> SELECT value FROM v$parameter WHERE name = 'optimizer_dynamic_sampling'; VALUE -------2
Stats-4
Using any of the methods which you learned earlier, explain the execution plan chosen for the following SQL statement from a database session connected to the sample database schema for EQUITIES. As you can see, this summarizes all transactions by brokerage office. It filters the results by selecting only those brokerages located in one particular city and only those transactions which pertained to a specific number of shares.
SQL> SELECT office_name, COUNT(*), SUM(number_shares * price) transaction_amount FROM brokerages NATURAL JOIN transactions WHERE brokerages.City = 'New York' AND transactions.Number_shares = 210 GROUP BY office_name ORDER BY transaction_amount; OFFICE_NAME COUNT(*) TRANSACTION_AMOUNT ------------------------- ---------- -----------------Wall Street Funds 4 20160 171 | P a g e
Review the plan and explain why this was chosen by the Optimizer. Answers With dynamic sampling in effect, the Optimizer correctly understands that the tables remain small and a full table scan will quickly load the tables into memory into their entirety. Therefore, this access method is chosen following by an inmemory hash join. The appropriate operations to summarize and order the final result table complete the plan.
-----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -----------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 3 | 219 | 9 (34)| 00:00:01 | | 1 | SORT ORDER BY | | 3 | 219 | 9 (34)| 00:00:01 | | 2 | SORT GROUP BY | | 3 | 219 | 9 (34)| 00:00:01 | |* 3 | HASH JOIN | | 3 | 219 | 7 (15)| 00:00:01 | |* 4 | TABLE ACCESS FULL| BROKERAGES | 2 | 68 | 3 (0)| 00:00:01 | |* 5 | TABLE ACCESS FULL| TRANSACTIONS | 8 | 312 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------------
Stats-5
We want to dramatically alter the number of rows within the Brokerages table and see the impact that this will have on the Optimizer. Execute the script BrokeragesAdd100000.sql.
Answers
SQL> @ BrokeragesAdd100000.sql; Table altered.
172 | P a g e
PL/SQL procedure successfully completed. Commit complete.
Stats-6
With dynamic sampling in effect, explain the query again and note the new plan chosen. Why was this plan chosen by the Optimizer?
Answers
The TRANSACTIONS table had poor selectivity so a full table scan was still performed. However, selectivity was much better with the BROKERAGES table. Therefore, the rows were first fetched using INDEX UNIQUE SCAN and TABLE ACCESS BY INDEX ROWID. Furthermore, since the index presented the rows in a sorted order, a NESTED LOOPS operation was ideal for the join with TRANSACTIONS. The TRANSACTIONS table is designated the driver table (or the outer table) for the NESTED LOOPS JOIN with the BROKERAGES table. The Optimizer elects to access the BROKERAGES table using its primary key index and considers it to be the inner table within this operation. Following the join the tables must be sorted for the purpose of reducing the detailed result tables into summarized rows to satisfy the GROUP BY clause. Finally, the remaining summarized rows are sorted again to comply with the instructions of the ORDER BY clause.
----------------------------------------------------------------------------------------------| Id Time | Operation | | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT 00:00:01 | | 1 | SORT ORDER BY 00:00:01 | | 2 | SORT GROUP BY 00:00:01 | | 3 | NESTED LOOPS | | 5 | 365 | 13 (16)|
5 |
365 |
13
(16)|
5 |
365 |
13
(16)|
5 |
365 |
11
(0)|
173 | P a g e
00:00:01 | |* 4 | 00:00:01 | |* 5 | 00:00:01 | |* 6 | 00:00:01 | TABLE ACCESS FULL | TRANSACTIONS | 8 | 312 | 3 (0)|
TABLE ACCESS BY INDEX ROWID| BROKERAGES
1 |
34 |
(0)|
INDEX UNIQUE SCAN
| BROKERAGES_PK |
1 |
(0)|
-----------------------------------------------------------------------------------------------
Stats-7
To observe the impact which objects such as indexes can have on the access method chosen, drop the primary key for the BROKERAGES table. Explain the query again and note the impact of this change.
Answers
SQL> ALTER TABLE Brokerages DROP CONSTRAINT Brokerages_PK CASCADE; Table altered.
The execution plan reverts back to the original selection without the benefit of the index.
------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 5 | 365 | 79 (14)| 00:00:01 | | 1 | SORT ORDER BY | | 5 | 365 | 79 (14)| 00:00:01 | | 2 | SORT GROUP BY | | 5 | 365 | 79 (14)| 00:00:01 | |* 3 | HASH JOIN | | 5 | 365 | 77 (12)| 00:00:01 | |* 4 | TABLE ACCESS FULL| BROKERAGES | 3 | 102 | 73 (11)| 00:00:01 | |* 5 | TABLE ACCESS FULL| TRANSACTIONS | 8 | 312 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------
-------------
Stats-8
We do not want to always incur the cost of dynamic sampling so we will now give attention to collecting statistics. First, using the EM interface, confirm the automatic statistics collection job is defined,
174 | P a g e
active and has run. Note that there are more privileges required for this task than has been granted to a standard EM user; therefore you must connect to EM using the SYS administrator account. Answers From the database home page, click Administration Jobs to access the Scheduler jobs. You should see GATHER_STATS_JOB. Click on the History link to see previous runs of this job. Click on the job name GATHER_STATS_JOB and the resulting links General, Schedule and Options to view the job details. Stats-9
One cannot rely entirely upon the automatic Optimizer collection of statistics, but there are manual statistics which we must collect and we want these to occur immediately.
Before doing so, however, create once again the PRIMARY KEY constraint on the BROKERAGES table. Then, collect statistics for these application objects using the DBMS_STATS() package:

Collect statistics for the BROKERAGES and TRANSACTIONS tables. Collect statistics for the TRANSACTIONS_PK index.
Answers
SQL> ALTER TABLE brokerages ADD CONSTRAINT brokerages_PK PRIMARY KEY (Brokerage_ID); Table altered. SQL> EXECUTE dbms_stats.gather_table_stats (NULL, 'brokerages'); PL/SQL procedure successfully completed. SQL> EXECUTE dbms_stats.gather_table_stats (NULL, 'transactions'); PL/SQL procedure successfully completed. 175 | P a g e
SQL> EXECUTE dbms_stats.gather_index_stats (NULL, 'transactions_pk'); PL/SQL procedure successfully completed.
Stats-10
Explain the execution plan once more. What is different this time from all the previous plans?
Answers
While the plan looks the same as one we saw earlier, this is the first time in which dynamic sampling did not occur. Rather the stored Optimizer statistics were used, allowing this plan to be the fastest for the query which we have produced thus far in the workshop.
-----------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 26 | 5 (40)| 00:00:01 | | 1 | SORT ORDER BY | | 1 | 26 | 5 (40)| 00:00:01 | | 2 | SORT GROUP BY | | 1 | 26 | 5 (40)| 00:00:01 | | 3 | NESTED LOOPS | | 1 | 26 | 3 (0)| 00:00:01 | |* 4 | TABLE ACCESS FULL | TRANSACTIONS | 8 | 80 | 3 (0)| 00:00:01 | |* 5 | TABLE ACCESS BY INDEX ROWID| BROKERAGES | 1 | 16 | 0 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | BROKERAGES_PK | 1 | | 0 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------
Stats-11
Use the DBMS_STATS() package to collect statistics for all objects within your schema. This time, though, examine the package output based upon the type dbms_stats.objectTab to determine exactly which objects we processed.
Answers The following anonymous PL/SQL block will call the

176 | P a g e
GATHER_SCHEMA_STATS() program and output the results indicating which objects were processed.
DECLARE objectList
BEGIN dbms_stats.gather_schema_stats ( ownName => 'student1', estimate_percent => 20, block_sample => TRUE, method_opt => NULL, degree => NULL, granularity => 'AUTO', cascade => NULL, statTab => NULL, statID => NULL, options => 'GATHER', objlist => objectList, statOwn => NULL, no_invalidate => NULL, force => NULL, obj_filter_list => NULL); FOR i IN objectList.FIRST .. objectList.LAST LOOP dbms_output.put_line (objectList(i).objName || ' ' || objectList(i).objType); END LOOP; END; / BROKERAGES TABLE DEPARTMENT TABLE DEPENDENT TABLE DEPT_LOCATIONS TABLE EMPLOYEE TABLE PROJECT TABLE STOCKS TABLE TIME TABLE TRANSACTIONS TABLE WORKS_ON TABLE ... PL/SQL procedure successfully completed.
177 | P a g e
178 | P a g e

Sideris-Oracle Database 11g R2 Tuning-1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sideris-Oracle Database 11g R2 Tuning-1

Încărcat de

Drepturi de autor:

Formate disponibile

Oracle Database 11g R2: SQL Tuning 1

Workshop Section - Managing Optimizer Statistics Section 6 - Enhanced Optimizer Statistics

Oracle Database 11g R2: SQL Tuning 1

Workshop Section - Histograms & MultiColumn Statistics Section 8 - Application Tracing

Workshop Section - The SQL Access Advisor Section 11 - Plan Management

Workshop Section - Optimizer Hints List of Sidebars

About This Textbook About The Sample Databases

About This Textbook

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

The primary target audiences for this course are:

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Files EmployeeAdd1000.sql, EmployeeAdd1000Doe.sql, ProjectAdd1000.sql CompanyConstraintsPK.sql

Oracle Database 11g R2: SQL Tuning 1

Open table as spreadsheet

Files Solutions02ViewPlan.sql Solutions03Optimizer.sql Solutions05OptimizerStats.sql Solutions06 EnhancedOptimizerStats.sql Solutions07ExtendedStats.sql Solutions10 SQLAccessAdvisor.sql

About the Sample Databases

Oracle Database 11g R2: SQL Tuning 1

Workshop Setup Guide

Oracle Database 11g R2: SQL Tuning 1

Section 1: Tuning & the Oracle Database Advisory Framework

Oracle Database 11g R2: SQL Tuning 1

The Challenges of Tuning

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

CPU time Wait time

Management & Advisory Framework

Oracle Database 11g R2: SQL Tuning 1

ADDM & AWR

Oracle Database 11g R2: SQL Tuning 1

SQL Tuning Privileges

Oracle Database 11g R2: SQL Tuning 1

ADMINISTER SQL TUNING SET

SELECT ANY DICTIONARY

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Workshop Section: Tuning & the Oracle Database Advisory Framework

Oracle Database 11g R2: SQL Tuning 1

of the sample database schemas. We recommend this latter option. Answers

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

discussion at hand. Answers

Section 2: Viewing & Monitoring the Execution Plan

Understanding the basic structure and elements of an execution plan.

Oracle Database 11g R2: SQL Tuning 1

About the Execution Plan

Oracle Database 11g R2: SQL Tuning 1

Reading An Execution Plan

Oracle Database 11g R2: SQL Tuning 1

Collecting Performance Statistics

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

iewing the Execution Plan

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

SQL> @ C:\app\Administrator\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlxpls.sql ... PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------Plan hash value: 1937138517 ---------------------------------------------------------------------------------

Oracle Database 11g R2: SQL Tuning 1

Oracle Database 11g R2: SQL Tuning 1

SQL> SELECT * FROM table (dbms_xplan.display (table_name