QuestSQLOptimizerForOracle UserGuide PDF

7.4.
1
User's Guide
-1-
© 2008 Quest Software, Inc.
ALL RIGHTS RESERVED.
This guide contains proprietary information protected by copyright. The software described in this guide is
furnished under a software license or nondisclosure agreement. This software may be used or copied only in
accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in
any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other
than the purchaser’s personal use without the written permission of Quest Software, Inc.
If you have any questions regarding your potential use of this material, please contact:
Quest Software World Headquarters

LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
Web site: www.quest.com

Email: legal@quest.com
Please refer to our Web site for regional and international office information.
Disclaimer
Disclaimer: The information in this document is provided in connection with Quest products. No license, express or
implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection
with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN
THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS
ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-
INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE,
SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS
DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no
representations or warranties with respect to the accuracy or completeness of the contents of this document and
reserves the right to make changes to specifications and product descriptions at any time without notice. Quest
does not make any commitment to update the information contained in this document.
Trademarks
Quest, Quest Software, the Quest Software logo, Tuning Lab, Benchmark Factory, Quest Central, Spotlight, SQL
Navigator, Toad, T.O.A.D. are trademarks and registered trademarks of Quest Software, Inc. Other trademarks
and registered trademarks used in this guide are property of their respective owners.
About Quest Software
Quest Software, Inc., Microsoft’s Global Independent Software Vendor Partner of the Year, delivers innovative
products that help organizations get more performance and productivity from their applications, databases and
infrastructure. Through a deep expertise in IT operations and a continued focus on what works best, Quest helps
more than 18,000 customers worldwide meet higher expectations for enterprise IT. Quest Software lets
organizations deliver, manage and control complex database environments through award-winning products for
Oracle, SQL Server, IBM DB2, Sybase, and MySQL. Quest Software can be found in offices around the globe and at
http://www.quest.com.
Contact Quest Support
Quest Support is available to customers who have purchased a commercial version and have a valid maintenance
contract or who have a trial version of Quest software. Quest Support provides around the clock coverage with
SupportLink, our web self-service. Visit SupportLink at: http://support.quest.com
Table Of Contents
Quest SQL Optimizer Overview .................................................................................................................... 1
Performance Assurance Process ................................................................................................................... 2
Database Privileges .................................................................................................................................... 4
Batch Optimizer Overview ........................................................................................................................... 6
Batch Optimizer Tutorial.............................................................................................................................. 8
SQL Scanner Overview.............................................................................................................................. 10
SQL Scanner Tutorial ................................................................................................................................ 11
SGA Inspector Overview ........................................................................................................................... 13
SGA Inspector Tutorial .............................................................................................................................. 14
Tuning Lab Overview ................................................................................................................................ 16
SQL Optimizer Overview ........................................................................................................................... 17
SQL Optimizer Tutorial .............................................................................................................................. 19
Deploy Outline Tutorial ............................................................................................................................. 20
Index Expert Overview.............................................................................................................................. 21
Index Expert Tutorial ................................................................................................................................ 22
Index Impact Analysis Tutorial ................................................................................................................... 23
Best Practices Tutorial .............................................................................................................................. 24
Global Indexing Overview .......................................................................................................................... 25
Global Indexing Tutorial ............................................................................................................................ 26
Impact Analyzer Overview ......................................................................................................................... 27
Save SQL Statements to Impact Analyzer Tutorial ........................................................................................ 29
Impact Analyzer Tutorial ........................................................................................................................... 29
Outline Manager Overview ......................................................................................................................... 32
Outline Manager Tutorial ........................................................................................................................... 33
Options Settings ...................................................................................................................................... 34
Quest SQL Optimizer for Oracle – Users Guide
Quest SQL Optimizer Overview
Quest SQL Optimizer for Oracle maximizes SQL performance by automating the manual, time-intensive, and
uncertain process of ensuring that SQL statements are performing as fast as possible. Quest SQL Optimizer
automatically analyzes, rewrites, and evaluates SQL statements within multiple database objects, files, or
collections of SQL statements from the SGA. The process of optimizing problematic SQL from multiple source code
locations is completely automated. Whether you are a developer, DBA, or performance tuner, you can just let
Quest SQL Optimizer for Oracle analyze and optimize in batch all problem SQL from multiple sources and then
Quest SQL Optimizer will provide you with the replacement code which includes the optimized SQL statements.
Quest SQL Optimizer also provides you a complete index optimization and plan change analysis solution, from
index recommendations for multiple SQL statements to simulated index impact analysis, through comparison of
multiple SQL execution plans.
Quest SQL Optimizer consists of the following:
Batch Optimizer
The Batch Optimizer enables you to submit files, database objects, text, or a Performance Analysis SQL repository
for batch processing. It first scans the code to extract the SQL statements, then optimizes the SQL statements and
tests the SQL alternatives to find the best performing SQL for your database environment. It provides the
replacement code with the optimized SQL statements.
SQL Scanner
The SQL Scanner identifies SQL statements from source code and database objects without requiring the execution
of the SQL statements. Once the SQL statements are identified, the SQL Scanner analyzes and categorizes them
according to suspected levels of performance problems.
SGA Inspector
The SGA Inspector offers an easy way to view and analyze previously executed and currently running SQL
statements from Oracle’s system global area (SGA). You can specify your own criteria to retrieve the SQL
statements and their corresponding statistics to review SQL performance.
Tuning Lab
The Tuning Lab contains the SQL Optimizer, the Index Expert, Deploy Outline, Test for Scalability and Best
Practices along with the testing of the alternative SQL statements and the index candidates.
Tuning Lab - SQL Optimizer
The SQL Optimizer automates the optimization of SQL statements. It first analyzes the original SQL statement
and then exhaustively rewrites the syntax of the SQL statement and apply the Oracle optimization hints. It
produces a list of semantically equivalent and syntactically correct SQL statements. By test running these SQL
statements, it is then possible to identify which SQL statement best suits the needs of your database
environment.
Tuning Lab - Find Best SQL Alternative
The execution of the SQL statements enables you to test run the original and optimized SQL statements to
select which SQL statement gives the best performance. The execution times and run time statistics help you
identify which SQL statement is most suitable for the needs your database application environment.
Tuning Lab - Deploy Outline
Deploy Outline stores an Oracle stored outline for a specific SQL statement. Oracle will use the stored outline
when executing the SQL statement in place of using the execution plan.
-1-
Tuning Lab - Index Expert
The Index Expert enables you to determine the best possible indexes for your SQL statements. It analyzes the
syntax of a SQL statement and the relation between tables to generate index alternatives. It provides all the
alternative index sets that generate a unique execution plan for a SQL statement. It creates these index sets
without physical creating the indexes in your database.
Tuning Lab - Find Best Index Alternative
The performance of a SQL statement with the index candidates can be tested to help you determine which
indexes should be permanently created in your database.
Tuning Lab - Best Practices
Best Practices proposes common techniques to improve performance on your database.
Test for Scalability
The user workload that SQL statements may encounter can be simulated with Quest Benchmark Factory to see
how the best SQL alternatives will perform under different workload conditions.
Global Indexing
Global Indexing analyzes a group of SQL statements and determines the best common index set for all of those
SQL statements.
Impact Analyzer
The Impact Analyzer helps you to ensure reliable database performance by tracking execution plan and Oracle cost
changes for SQL statements. It keeps track of execution plan changes to allow you to estimate the impact on the
SQL statements' performance due to database changes. You can simulate different database scenarios with a
selected group of SQL statements that will give you a good representation of what will happen if a proposed
database change actually occurred. Or, you can track the actual changes in the execution plan over time or as the
result of actual changes in the database environment.
Outline Manager
The Outline Manager organizes the stored outlines used to improve the performance of SQL statements when you
cannot or do not want to change the SQL syntax in the source code.
Performance Assurance Process
Quest SQL Optimizer for Oracle enables you to assure that your SQL statements will run as fast as possible in your
database environment. Use the following process to identify the SQL that needs to be optimized, to find the
alternative SQL statements, and select the best SQL for your application.
1. Identify problematic SQL, optimize SQL statements, and test SQL alternatives
The first step in optimizing a database application is to find which statements are causing the performance
problems. Use the Batch Optimizer to extract embedded SQL statements from your database objects (such as
stored procedures, views, etc), application source code files, or executable files. The scanning process extracts the
SQL statements directly from the source code without requiring you to execute your application.
-2-
Note: Dynamic SQL statements, which are not created until the application is executed, can be captured by the
SGA Inspector. For dynamic SQL statements, capture them first with the SGA Inspector and then use the Batch
Optimizer to extract and identify the problematic SQL statements from the Inspector file.
The scanning process, by analyzing the operations in the execution plan, identifies potential performance
bottlenecks such as performing full table scans on large tables or multiple table scans. These thresholds are user-
defined under the SQL Classification definitions. The analysis identifies the problematic SQL that should be
optimization.
The Batch Optimizer automatically optimizes the problematic and complex SQL to find alternative SQL statements
that have unique execution plans. The optimization process explores all possible ways to rewrite the original SQL
statement. First, the syntax of the SQL statement is analyzed along with the tables and indexes and it is rewritten
to provide all the SQL alternatives that produce the exact same result. It applies the optimization hints that are
specific to Oracle, such as ALL_ROWS, HASH, and ORDERED. The use of these Oracle hints is optional.
Once the optimization process has generated all the semantically equivalent SQL alternatives, the Batch Optimizer
determines which one is the most efficient for your database environment by executing the original SQL statement
and the SQL alternatives. It generates a script that you can use to replace the original SQL statement with the
better performing alternatives.
Note: You can also use the SQL Scanner module to extract and identify problematic SQL. Then you can use the
SQL Optimizer and Execute function in the Tuning Lab to generate the SQL alternatives and to test them.
4. Improve SQL coding skills and optimization knowledge
In the Tuning Lab, use the Compare Scenario layout after the original SQL statement is optimized to view side-by-
side the alternative SQL statements in order to learn what alternate SQL syntax accomplishes the same result.
Also, view the execution plans side-by-side to improve your knowledge of how Oracle executes a SQL statement
based on the SQL syntax. Use the context sensitive help for each keyword in the execution plan to further your
understanding of execution plan steps.
5. Replace poor performing SQL
Once you have found the best SQL for your application, copy the SQL alternative to the source code. You can also
create a report in the Tuning Lab or the Batch Optimizer with the alternative SQL statements and execution plans.
Note: The Batch Optimizer will create a replacement script for you.
6. Generate index alternatives
If optimizing a SQL statement does not improve the performance enough to meet your performance requirements,
index alternatives can be generated for a single SQL statement with the Index Expert in the Tuning Lab or for a
group of SQL statements with Global Indexing to further enhance the database performance.
7. Predict and track changes to performance
You can predict the performance changes to your database before you migrate to another database, make
configuration changes, or add new indexes. You can also track the changes that take place in the performances of
SQL statements as the result of changes like updating database statistics, changes in data volume, or program
upgrades.
8. Improve Vendor Applications
You can use Oracle stored outlines to improve the performance of SQL statements when you cannot replace the
original SQL statement in your source. In the Tuning Lab, you can deploy an outline after you have optimized a
SQL statement and then use the Outline Manager to organize your stored outlines.
-3-
Database Privileges
Oracle database privileges limit the access of individual users. The following lists the functionality that requires
specific Oracle database privileges. If you do not have one of these privileges, you can still use the functionality in
the other features of the program.
Module Functionality Privilege

SGA Inspector SQL to Collect: Executed Access is needed to these system views:
SQL from SQL Area SYS.V_$SQLAREA and
SYS.V_$SQLTEXT_WITH_NEWLINES (or
SYS.V_$SQLTEXT depending on your version of Oracle)
In Oracle 9 or later, SYS.V$_SQL_PLAN
SQL to Collect: Currently Access is needed to these system views:
executing SQL SYS.V_$OPEN_CURSOR, SYS.V_$SESSION,
SYS.V_$SQLAREA and
SYS.V_$SQLTEXT_WITH_NEWLINES (or
SYS.V_$SQLTEXT depending on your version of Oracle)
In Oracle 9 or later, SYS.V$_SQL_PLAN
Flush Oracle shared pool ALTER SYSTEM privilege is needed.
Execution Plan Information Oracle 9 or above is required.
Access is needed to this system view: SYS.V_$SQL_Plan
Tuning Lab and Batch Execution Method option: Access is needed to this package: SYS.DBMS_SQL
Optimizer Run on Server setting
Tuning Lab, Global Retrieve Run Time Access is needed to these system views:
Indexing, and Batch Statistics SYS.V_$PARAMETER, SYS.V_$MYSTAT, and
Optimizer SYS.V_$STATNAME
Tuning Lab, Global Retrieve time related The TIMED_STATISTICS parameter in the INIT.ORA file
Indexing, and Batch statistics must be set to TRUE.
Optimizer
Tuning Lab – Index Generate Virtual Indexes Oracle 8i or above is required.
Expert and Global
Indexing
All Modules If the Oracle init parameter
O7_DICTIONARY_ACCESSIBILITY (Oracle 8 or above) is
set to false, objects under SYS are not accessible, even
for a user with the SELECT ANY TABLE privilege granted.
In this case, the SELECT ANY DICTIONARY privilege or
the SELECT_CATALOG_ROLE role is needed to access the
objects under SYS.
Tuning Lab Altering session Access is needed to this system view:
parameters for executing SYS.V_$PARAMETER
SQL
Global Indexing Generate Virtual Indexes Oracle 8i or above is required.

Outline Manager and Creating and managing Oracle 8i or above is required.
Deploy Outlines stored outlines CREATE ANY OUTLINE and DROP ANY OUTLINE
privileges are needed.
Access to this package is needed: SYS.OUTLN_PKG
Access is needed to these system views:
OUTLN.OL$
SYS.USER_OUTLINES and SYS.USER_OUTLINE_HINTS
or
-4-
SYS.DBA_OUTLINES and SYS.DBA_OUTLINE_HINTS

Update privilege is needed to: OUTLN.OL$,
OUTLN.OL$HINTS.
For Oracle 9i or later, update privilege is needed to:
OUTLN.OL$NODES
ALTER SYSTEM is needed to enable a stored outline

category.
-5-
Batch Optimizer Overview
The Batch Optimizer combines the scanning of source code, the optimization of SQL statement, and testing of the
SQL alternatives with the original SQL into one simple process. So, it automates the whole process of identifying
problematic SQL in your database application, rewriting the SQL statements, and executing the original SQL
statement along with the alternative SQL statements to find the fastest alternative. Then it creates a script from
your original source code in which the slower SQL statements are replaced with better performing SQL alternatives.
Add Jobs to a Batch
To start the process, you must a add a job to a batch. A job consists of text which is expected to contain one or
more SQL statements. A job may be a block of text, a database object, an ASCII file, a binary file, a SQL Scanner
job, a SGA Inspector job, or a Performance Analysis SQL repository.
You can use the Add Batch Optimizer Jobs wizard to put the jobs into a batch. You can also submit a job to the
Batch Optimizer from other Quest products, such as Toad, SQL Navigator, Performance Analysis, or Spotlight. You
can submit a SQL statement from the SQL Text window of the SGA Inspector or the SQL Scanner.
Scanning
The first step of the Batch Optimizer process is to scan through the text in each job to find the INSERT, UPDATE,
DELETE, and SELECT SQL statements. This scanning process works exactly the same as the scanning process in
the SQL Scanner.
Optimization
The second step of the Batch Optimizer process is to optimize the SQL statements that were found during the
scanning process. This optimization is the same process that is used in the SQL Optimizer.
-6-
Execution
The third step of the Batch Optimizer process is to execute the original SQL statement and the alternative
statements to see if any of the SQL alternatives outperform the original SQL statement.
If a SQL statement has a bind variable, it is not executed until you enter the value for the variable.
You may select to execute the SQL statements in a different schema or using a different database connection from
the one used for the scanning and optimizing processes.
Generate Optimized Script
After the SQL alternatives are executed, if one of the alternatives is faster than the original SQL statement then a
replacement script can be generated. This script is a copy of the original text that was scanned with the poor
performing SQL statements replaced with the best SQL alternatives. You can then take this script and replace the
code in the database object or application source code file.
Options Settings
The Batch Optimizer process can be fully automated by using the settings in the Batch Optimizer options. Or, can
manually control the process.
Scanning Options
Jobs will be automatically scanned as soon as they are placed in a batch if you select the Automatically start
extracting SQL when job is added setting.
The jobs are scanned using the settings in the SQL Scanner settings.
Optimizing Options
When the scanning process is finished, the optimization process can automatically be started based on the SQL
classification that you select in the SQL to automatically optimize setting. For example, if you select Problematic,
only those SQL statements that are classified as Problematic will automatically be optimized. If you do not select
any of the SQL classifications, then you must manually select each SQL statement you would like optimized.
The SQL statements are optimized using the Optimizer settings.
Executing Options
When the optimization process is finished, the execution of the original SQL statement and the selected
alternatives are automatically started if you select one type of SQL statement under the Types of SQL statement
to execution automatically after optimization option.
The SQL alternative that are executed are determined by these settings.
SQL type to execute—The Types of SQL statement to execution automatically after optimization enables
you to select whether the INSERT, UPDATE, DELETE, or SELECT statements are automatically executed.
SQL alternatives to execute—The Number of SQL alternatives to select as the representatives and Execute
these additional SQL alternatives settings determine which SQL alternatives are to executed.
When executing the SQL statements in the Batch Optimizer, the default execution method is Run on server. By
that, it is meant that all SQL statements are executed on the server and do not return the data from the SELECT
statements to the client. Executing the SQL statements with this method provides you with the run time on the
CPU for the SQL statement. Using this method, your logon account must have the SYS.DBMS_SQL package
privilege to retrieve the run time from the server.
-7-
Selecting Best Alternative Options
The best alternative is selected based on the Total elapsed time or the First row elapsed time in the Best SQL
Alternative Selection Criteria setting. The Total elapsed time is how long it takes to retrieve all the records
returned by a SELECT statement. The First row elapsed time is how long it takes to retrieve only the first record.
Batch Optimizer Tutorial
The Batch Optimizer combines the scanning, the SQL optimization, and testing of the SQL alternatives with the
original SQL into one simple process. So, it automates the whole process of identifying problematic SQL in your
database application, rewriting the SQL statements, and executing the original SQL statement along with the
alternative SQL statements to find the fastest alternative. Then it creates a script from your original source code in
which the problematic SQL is replaced with a better SQL alternative.
1. Click the Batch Optimizer tab.
2. In the Batch Job List window, click Add Code to Optimize and select All Types to
open the Add Batch Optimizer Jobs wizard so you can select which files, database objects, SQL Scanner
files, SGA Inspector files, text, or Performance Analysis SQL repository you want to scan for and optimize
the SQL statements that are found.
Connection page
a. In the Connection box, click Down Arrow to select a previously created database connection or
click Ellipsis to create a new connection.
Database Objects page
b. Expand the database user branch in the Database Objects box.
c. Highlight the schema, a database object type, or an individual database object, and click Add
Database Objects to move the item to the Select Objects box. (Whether or not you can scan
all of the selected database objects depends on your database privileges.)
Source Code page
d. Click the Text or binary files, Oracle SQL*Plus scripts, or COBOL programming source code option.
e. Click Add and select the files you want to scan.

f. Click Open to insert the files in the Add Scanner Jobs wizard.
g. Set the schema in the Scan using Schema list to correspond with the SQL that you are scanning.
SQL Text page
h. Paste or type the text which contains one or more SQL statements.
i. Set the schema in the Scan using Schema list to correspond with the SQL that you are scanning.
SQL Scanner page
j. In the Group box, select the Scanner group which contains the SQL statement you want to scan to
identify the problematic SQL.
k. From the Available Scanners box, select the Scanner jobs.
l. Click Add selected Scanner jobs to move the Scanner jobs to the Selected Scanners box.
m. Set the schema in the Scan using Schema list to correspond with the SQL that you are scanning.
The scanning process will use this schema and not the database connection that is associated with the
Scanner group you select in step a.
SGA Inspector page
n. In the Group box, select the Inspector group which contains the SQL statement you want to scan to
-8-
o. From the Available Inspectors box, select an Inspector job.
p. Click Add selected Inspector jobs to move the Inspector to the Selected Inspectors box.
q. Set the schema in the Scan using Schema list to correspond with the SQL that you are scanning.
Inspector group you select in step a.
Performance Analysis page
r. Click Check for PA Repository.
s. Check Add the PA Repository as a job checkbox.
t. Enter the selection criteria for the SQL statement you would like to extract.
Batch Info page
u. Select Create a new batch.
v. In the Batch Name box, enter a name.
3. After you have made all your selections in the Add Batch Optimizer Jobs wizard, click Finish.
4. The Batch Optimizer will automatically start scanning the jobs that you created.
Note: The scanning automatically starts when the Automatically start extracting SQL when job is
added option is checked on the Batch Optimizer | Options page. The option is checked by default.
5. The SQL statements that are classified as Problematic or Complex will automatically start optimizing after
the scanning process is finished.
Note: Which SQL statements are optimized is determined by the SQL classifications selected in the SQL to
automatically optimize option on the Batch Optimizer | Options page. By default, the Problematic and
Complex SQL are optimized.
6. After the SQL statements are optimized, the original SQL statement and some of the alternatives SQL
statements are executed.
Note: The specific SQL statements that are executed is determined by the option selected under the
Number of SQL alternatives to select as the representatives and the Execute these additional SQL
alternatives settings on the Batch Optimizer | Execution | Auto Execution Options page.
7. You can review the details of the an optimized SQL statement in the Tuning Lab module by clicking the
row for the SQL statement in the SQL List window and clicking Open in Tuning Lab .
8. If a faster SQL alternative is found for a SQL statement, you can generate a replacement script for the
source code by click the job in the Job List window and clicking Generate Optimized Script . Review
the script before using it to replace your original source code.
-9-
SQL Scanner Overview
Database applications typically contain thousands of SQL statements that may need to be optimized for better
performance. Without the SQL Scanner, you have to find and extract each SQL statement manually — a very
tedious and time-consuming task. Once you have found the SQL statements, you need to analyze the execution
plan of each SQL statement to see if the execution plan represents a potential performance problem. The SQL
Scanner relieves you of this tedious task.
The SQL Scanner extracts SQL statements embedded in database objects, captured from the SGA, stored in
application source code and binary files, or saved in a Performance Analysis SQL repository. It retrieves and
analyzes the execution plans for the extracted SQL statements. It then categorizes the SQL statements according
to the complexity of the execution plan and determines whether it has the characteristics that typically cause
performance problems. The SQL Scanner allows you to quickly review SQL statements in existing code and detect
potential problems. With this approach, you can be proactive in the detection of performance problems and identify
the SQL statements that need to be optimized without executing the applications.
Once the problematic SQL statements have been identified, you can determine the best solution by
• Sending a SQL statement to the Tuning Lab for optimization.

• Sending a SQL statement to the Tuning Lab for index generation.
• Sending a SQL statement to the Batch Optimizer for optimization.
• Sending a group of SQL statements to Global Indexing for index generation.
• Saving a group of SQL statements to the SQL Repository for further analysis.
- 10 -
Each item that is scanned is referred to as a "job" which can be a database object, text file, binary file, SGA
Inspector file, or Performance Analysis SQL repository.
The Scanning options allow you to include SQL statements that are found in a comment or that use only the
SYS.DUAL table. If your code has tags at the beginning of each line, you can have the scanning process skip them.
You can specify a continuation character if your code uses one at the end of each line of a SQL statement that is
displayed on several lines. And you can specify that it searches for the whole word when it looks for the INSERT,
UPDATE, DELETE, and SELECT statements, so that it does not try to build a SQL statement when it finds text like
UPDATERECORD.
SQL Scanner Tutorial
Use the SQL Scanner to analyze SQL statements embedded within database objects, text/binary files, SGA
Inspector files, and application source codes. The SQL Scanner extracts each SQL statement embedded within the
scanned database objects and files, retrieves their respective execution plans from Oracle, and then performs an
analysis that determines which of these SQL statements are likely to contain performance bottlenecks. You can
send the SQL statements analyzed as problematic (top priority) or complex (second priority) to the Tuning Lab or
Batch Optimizer to provide alternative SQL statements that may improve the performance and/or examine the
extracted SQL statements with their execution plans.
Best Practices: An effective use of the SQL Scanner is to review existing code to proactively identify the SQL
statements that can potentially cause performance problems without the need of executing the applications. In this
way, you can prevent performance degradation.
Another effective use of the SQL Scanner is to locate the SQL that is causing performance problems in your
applications. For example, if you know that you have a slow running report, you can scan the program text or
binary file to extract the SQL statements that it contains without having to execute it. The SQL Scanner identifies
SQL statements that are likely to create performance problems. You can then use the Tuning Lab or Batch
Optimizer to provide alternative SQL statements that may improve the performance.
1. Click the Scanner tab.
2. In the Group list, click

Down Arrow and select a group or click Ellipsis to create a new group.
3. Click Add Scanner Jobs to open the Add Scanner Jobs wizard so you can select which files, database
objects, or SGA Inspector files you want to scan.
4. In the Add Scanner Jobs wizard, click Next until you are at the page for the item that you want to scan.
Database Objects page
a. Expand the database user branch in the Database Objects box.
b. Highlight the schema, a database object type, or an individual database object, and click Add
Database Objects to move the item to the Select Objects box. (Whether or not you can scan
all of the selected database objects depends on your database privileges.)
Source Code page
c. Click the Text or binary files, Oracle SQL*Plus scripts, or COBOL programming source code option.
d. Click Add and select the files you want to scan.

e. Click Open to insert the files in the Add Scanner Jobs wizard.
f. Set the Scan using Schema in the Schema list to correspond with the SQL that you are scanning.
SGA Inspector page
g. In the Group box, select the Inspector group which contains the SQL statement you want to scan to
h. From the Available Inspectors box, select an Inspector job.
i. Click Add SGA Inspector to move the Inspector to the Selected Inspectors box.
- 11 -
j. Set the Scan using Schema in the Schema list to correspond with the SQL that you are scanning.
Inspector group you select in step a.
5. After you have made all your selections in the Add Scanner Jobs wizard, click Finish.
6. Click Scan and select Scan All.

7. Details are filled in the Job Grid as the scanning process completes each job. It shows you how many SQL
statements classified Problematic, Complex, or Simple.
8. To view the scanned SQL statements, highlight the job by clicking the row and then click the individual
SQL statement in the SQL List window to see the text SQL statement in the SQL Text window, the
execution plan in the Execution Plan window.
9. To view the classification, clicking the SQL Classification tab displaying the execution plan to change the
displayed window to the SQL Classification window.
10. Select one SQL statement you think can be improved. In the SQL Text window, click the arrow to the right
of Optimize in Batch and select Optimize in Tuning Lab to copy the

SQL statement to the Tuning Lab where you can optimize it with the SQL Optimizer or generate index
candidates with the Index Expert. Or, click the Optimize in Batch Optimizer to send the SQL statement
to the Batch Optimizer where the optimizing and testing process is automated.
11. To generate one index set that will maximize the performance of the SQL statements in one or more jobs,
select the arrow to the right of Send to Global Indexing .
- 12 -
SGA Inspector Overview
The SGA Inspector offers an easy way to capture, view, and analyze executed and currently running SQL
statements from Oracle’s system global area (SGA). You can specify your own criteria to determine which SQL
statements and statistics to retrieve from the SGA. Since the information in the SGA is not static, all the SQL
statements and information retrieved are stored on your client computer for you to review now or a later time.
You can schedule the date and time of when the SQL statements and statistics are collected. Then you can identify
the impact of the SQL activities on database performance.
The SQL Scanner can also be used to review the SQL statements after they are collected from the SGA to classify
the SQL statements based on the characteristics of the execution. Once you have identified poor performing SQL
statements, you can use the Batch Optimizer or the SQL Optimizer to rewrite the syntax of the SQL statement to
find a better execution plan.
- 13 -
SGA Inspector Tutorial
You can retrieve executed SQL statements from the Oracle SQL Area or currently running SQL statements from
Oracle’s open cursor. After you have captured the SQL statements and statistics according to the retrieval criteria
you selected, the SQL statements and their run time statistics are displayed to help you identify the resource
intensive SQL statements. After you have identified these SQL statements, you can then move a specific SQL
statement to the Tuning Lab so you can generate SQL alternatives or index candidates. Or, you can use the SQL
Scanner to enable you to identify potentially problematic SQL statements. You can also use the Add Jobs function
in the Batch Optimizer to automatically optimize all the collected SQL statements.
Retrieve previously executed SQL statements from Oracle SQL Area
Note: To retrieve previously executed SQL statements, you must have the privilege to view SYS.V_$SQLAREA, and
either SYS.V_$SQLTEXT_WITH_NEWLINES or SYS.V_$SQLTEXT.
1. Click the SGA Inspector tab.

3. Click Add Inspector Job to open the Add Inspector Job wizard.
4. On the General Information page, select Executed SQL from SQL Area for the Job Type.
5. Enter a Job name.
6. On the Collecting Criteria page, select Top n records and set the Number of records to be displayed
to your desired number.
7. In the First by box, select the statistic to use to extract the SQL statements when you are not displaying
all records. So if you are displaying only 100 records, it will extract the top 100 records based on the
statistic you select in this box.
Note: If you have a large SGA, it will take some time to sort the SQL statements before the extraction is
done.
8. On the SQL Filter page, select the type of SQL statements you want to collect.
9. On the Collection Time page, select Start collecting when you click the Inspect button.
10. On the Statistics page, review the selected statistics and remove any that you do not want collected.
11. Click Finish.
12. Click Inspect to start retrieving the SQL statements and statistics from the Oracle SQL Area.
13. In the SQL Statistics window, review the statistics.
14. The SQL statement in the SQL Text window corresponds to the selected statistics row in the SQL Statistics
window, which also displays the in the left grid border.

15. Select one SQL statement that you feel should be optimized. In the SQL Text window, click Optimize in
Batch Optimizer and select Optimize in Tuning Lab and then continue from the SQL Optimizer
Tutorial.
16. If you would like to optimize all the SQL statements in the collection, use the Batch Optimizer Tutorial and
add an Inspector Job to the batch queue.
17. Another way of identifying problematic SQL statements is to scan the Inspector file using the SQL Scanner
Tutorial.
Retrieve currently running SQL statements
Note: To retrieve previously executed SQL statements, you must have the privilege to view SYS.V_$SESSION,
SYS.V_$OPEN_CURSOR, and either SYS.V_$SQLTEXT_WITH_NEWLINES or SYS.V_$SQLTEXT.
1. Click the Inspector tab.
- 14 -
2. In the Group list,

click Down Arrow and select a group or click Ellipsis to create a new group.
3. Click Add Inspector Job to open the Add Inspector Job wizard.
4. On the General Information page, select Currently running SQL for the Job Type.
5. Enter a Job name.
6. On the Session page, select to collect the SQL from the Whole server, a specific Session ID, or a
particular Connection identity.
7. On the SQL Filter page, select the type of SQL statements you want to collect.
8. On the Collection Time page, set the amount of time you want to collect the executing SQL statements.
9. On the Statistics page, review the selected statistics and remove any that you do not want collected.
10. Click Inspect to start the collecting process.

11. The collecting process will stop according to the duration or end time defined in the Add Inspector Job
wizard. If you want to stop the monitor before the specified time, click Abort .
12. Select one SQL statement that you feel should be optimized. In the SQL Text window, click Optimize and
select Optimize in Tuning Lab and then continue from the SQL Optimizer Tutorial, Step 3.
13. If you would like to optimize all the SQL statements in the collection, use the Batch Optimizer Tutorial and
add an Inspector Job to the batch queue.
14. Another way of identifying a problematic SQL statement is to scan the Inspector file using the SQL
Scanner Tutorial.
- 15 -
Tuning Lab Overview
The Tuning Lab contains the SQL Optimizer and the Index Expert along with the testing of the alternative SQL
statements created by the SQL Optimizer and the index candidates generated by the Index Expert.
SQL Optimizer
The SQL Optimizer automates the optimizing of SQL statements. It first analyzes the original SQL statement and
then exhaustively rewrites the syntax of the SQL statement and applies the Oracle optimization hints. It produces a
list of semantically equivalent and syntactically correct SQL statements that produce the same result set as the
original SQL statement.
Find Best SQL Alternative
The execution of the SQL statements enables you to test run the original and optimized SQL statements to select
which SQL statement gives the best performance. The execution times and run time statistics help you identify
which SQL statement is most suitable for the needs of your database application environment.
Index Expert
The Index Expert enables you to determine the best possible indexes for your SQL statements. It analyzes the
syntax of a SQL statement and the relation between tables to generate index alternatives. It provides all the
alternative index sets that generate a unique execution plan for the SQL statement. It creates these index sets
without physical creation of indexes in your database.
Find Best Index Alternative
The performance of a SQL statement with and without the index candidates can be tested to help you determine
which indexes should be permanently created in your database. This process does create the indexes in your
database.
- 16 -
Components of the Tuning Lab
The Tuning Lab contains the following parts:
• Toolbar
The Toolbar has the most frequently used commands available for easy selection.
• Header Bar
The Header Bar contains the text links which displays the current selection and selection lists that enable
you to select a layout, to select a Scenario for review, to open a window not currently in the Layout, to
change the Intelligence Levels, and to change the current schema.
• Layout Buttons
Layouts have specific windows grouped together to enable you to quickly enter a SQL statement, compare
the alternative SQL statements and index candidates, and review the results of the testing.
• Tuning Lab Windows
Several windows are provided to help you quickly enter SQL statements and analyze the results of the
optimization and index generation processes.
• Status Bar
The Status Bar displays the progress of the current function and contains the Abort button.
SQL Optimizer Overview
The SQL Optimizer in the Tuning Lab automates the optimization of SQL statements. It employs a unique engine
that uses Artificial Intelligence to generate all the possible SQL alternatives that can be mathematically proven to
be "semantically equivalent" to the original SQL statement which guarantees that the SQL alternatives will produce
the exact same results as the original SQL statement. After the alternatives are generated, you can compare each
SQL statement to any other SQL statements to see the different SQL coding techniques for achieving the same
results. You can then test these alternative SQL statements in your environment to find the best one for your
database environment.
SQL Syntax Transformation
During the optimization of a SQL statement, the SQL Optimizer employs a unique engine that uses Artificial
Intelligence to execute several SQL syntax rules to produce the alternative SQL statements. The first step of this
engine transforms the original SQL statement and produces a group of alternative SQL statements where the
- 17 -
syntax was rewritten. Then, the SQL Optimizer rewrites each newly created SQL statement to produce another
group of alternatives. The engine continues rewriting each alternative until all the SQL statements cannot be
rewritten any further or until the user-defined quota for the number of SQL statements generated by syntax
transformation is reached.
One of the syntax transformation rules is illustrated in the following example:
SELECT *
FROM table_a
WHERE table_a.key IN (SELECT table_b.key
FROM table_b)
If table_b.key is an indexed column, the following transformation rule is applied:
SELECT *
FROM table_a
WHERE EXISTS (SELECT 'x'
FROM table_b
WHERE table_b.key = table_a.key)
In the Optimization settings, you can also control whether the optimization process will merge the SELECT
statement from a VIEW used in the original SQL so that it is rewriting the original SQL and the SELECT statements
from all the views accessed by the SQL statement. You can also specify to include a transformation rule that will
transform the query to an inline view, that is take a subquery and use it as a table in a FROM clause. You can also
select to use the JOIN clause (INNER JOIN, CROSS JOIN) from the Ansi-92 SQL standard or to use the original SQL
syntax for joining tables.
Applying Oracle Hints
After the SQL Optimizer has exhausted rewriting the syntax of the SQL statement, the Oracle optimization hints
which are selected in the Optimizer options are applied to the original SQL statement and each of the SQL
alternatives until all selected hints have been applied to all the SQL alternatives or until the user-defined quota is
reached.
Eliminating Duplicate Execution Plan
For each rewritten SQL statement, the execution plan is compared to all the other execution plans. One SQL
alternative is selected for each unique execution plan. Although the optimization process may generate hundreds of
SQL alternatives, you will see only some of the alternatives since the alternatives with a duplicate execution plan
are eliminated.
Testing for Best Alternative
Although all the SQL alternative statements produce the same result, Oracle will likely use a different path to
retrieve the data for each one. It is difficult to decide which SQL statement will run faster without taking into
account the database structure, indexes, and data volume, so it is important to test the SQL alternatives in your
database environment using the Execute function to determine the best SQL alternative from the run time
statistics.
Intelligence Level Settings
The settings in the Optimizer options affect the amount of time it takes and the number of alternatives that are
generated by the optimization process. You can quickly select to increase or decrease the intensity of the
optimization process using the Intelligence Level settings to automatically select more or less options.
- 18 -
Create Your Own Alternative SQL
You also have the ability to test and compare your own SQL alternatives using the Create User-Defined SQL
function.
SQL Optimizer Tutorial
In the SQL Optimizer within the Tuning Lab, the SQL optimization is a two-step process. In the first step, the SQL
optimization process automatically transforms the original SQL statement and generates semantically equivalent
alternative SQL statements with unique execution plans. For every alternative execution plan, the Oracle Cost
estimation is displayed. Once the SQL alternatives have been generated, the second step consists of locating the
most-efficient SQL alternatives for your database environment by testing the SQL alternatives against your
database. The results obtained from the second step indicate the time required to execute each SQL statement, as
well as, run time statistics.
Tip: The Oracle Cost is only an estimate of the resources it takes to execute a SQL statement. It is essential to
execute the alternative SQL statements in order to determine which statement performs the best in your
environment.
Optimize SQL
1. Click the Tuning Lab tab.
2. If the Create a New Tuning Lab window does not appear, click Create a new session .
3. In the Connection box, click Down Arrow and select a previously created database connection or click
Ellipsis to create a new Connection Profile. Click OK.
4. Enter a SQL statement in the SQL text window.
5. In the Header Bar upper right corner of the Tuning Lab, click the Set Schema option and select the
schema which matches your SQL statement.
6. Click Optimize .
This step launches the SQL Optimizer that automatically transforms the SQL statement. The use of hints
and other optimization options such as transforming a view to an inline view and the ANSI JOIN syntax
are optional. In the Options, the intensity of the SQL transformation process is controlled by the
Intelligence Level. The Intelligence Levels control how many Oracle hints are applied to transform SQL and
how many SQL alternatives are created.
7. Look at the progress bar in the bottom right corner of the Tuning Lab to see the progress optimization
process.
Compare Scenarios
When the optimization is finished, the Compare Scenarios Layout is displayed. At this point since you have not yet
run the SQL statements, the top window in the layout displays only the Oracle Cost values. These are only
estimations of how each statement will perform. You need to test each statement to obtain its actual run time
statistics.
8. To compare the original SQL statement and the execution plan to the alternative SQL statements, click the
SQL list at the top of the SQL Text panes to select the SQL statements you want to compare.
Test the Alternative SQL statements
The Execute function provides an efficient way of testing SQL. It runs the selected SQL statements in the database
and the SQL statements that exceed the termination time are cancelled. For SQL statements such as INSERT,
DELETE and UPDATE, each statement is run in a transaction that is ROLLBACK, therefore maintaining the
consistency of your data.
- 19 -
9. To prepare to execute the source and the alternative SQL statements, click Options .
10. Select the Tuning Lab | Execution | Execution Criteria branch.
11. In the Run Time Retrieval Method section, select the following option that best suits your SQL statement.
Original SQL twice using second run time and all others once
The first time you access data from table, the data is cached into memory. This process takes a few
moments. The next time you access that data, it is already in memory so the following SQL statements
run faster. So to have a comparable test, the first SQL is run twice and the time from the second run is
compared to the time from the other statements.
All SQL twice using the second run time
Running all SQL twice enables you to eliminate some factor that can affect the accuracy of the results. If
some SQL statements have been recently executed, then the SQL information is likely to be resident in
the cache and it may execute faster because of that. Also, if the SQL statements use different indexes,
one index may be resident in the cache and the other not. This option eliminates these factors since it
runs all SQL statements twice, throws out the first execution time and uses the second one when all SQL
statements and indexes should have the necessary items in the cache.
All SQL Once
For long running SQL there is no need to run any statement twice since the effect from caching is
diminished over time.
12. In the SQL Termination Criteria section, select Cancel execution by the fastest SQL run time.
13. Click the Tuning Lab | Execution | Execution Method branch.
14. In the Execution Method section, select Run on server. With this option, the Execute function retrieves
the time the SQL statement executes in the database and does not retrieve the result set from the
database server to the client. Therefore it does not create additional network traffic.
15. Click the down arrow on the right of Execute and select Execute All.
16. Look at the progress bar in the bottom right corner of the Tuning Lab to see the progress of the execution
process. When the execution is finished, the Execution Statistics layout is displayed.
17. Once you have identified the alternative SQL statement you want to use, you can copy and paste it back
in your application.
Deploy Outline Tutorial
The Deploy Outline feature leverages the Oracle plan stability strategy called stored outlines. In Oracle 9i and
above, the stored outlines enables you to influence the execution plan of a SQL statement without having to modify
the SQL statement syntax. The major advantage of deploying a outline is that you can optimize the SQL statement
without altering the SQL text. This is an ideal solution for when you do not have the source code from a vendor but
want to improve the performance of the database application. In this case, you cannot change the source code that
contains a poor performing SQL statement, but you can deploy a stored outline to force Oracle to use a specific
execution plan for that SQL statement.
In the Tuning Lab, you can optimize to find the semantically equivalent SQL statements with alternative executions
plans and then choose the best SQL statement and deploy it as a outline.
Creating a Stored Outline for the Original SQL Statement
1. In the Tuning Lab, optimize and execute a SQL statement using the SQL Optimizer Tutorial.
2. Select the alternative SQL statement whose execution plan you want Oracle to use in place of the
execution plan for the original SQL statement.
3. In the Scenario Explorer window, click the Green Push Pin icon.
Note: The Green Push Pin is only an indication that the alternative SQL statement should be able to be
deployed as a stored outline. It is not 100% accurate, so you many find that SQL alternatives without the
green push pin may also be deployed for the original SQL statement.
4. In the Outline name box, enter a name for the stored outline.
- 20 -
5. In the Category box, select a category name or enter a new name to create a new category. The default
category name is SQL_OPTIMIZER.
Note: At this point, it is a good idea to put this outline in a category that is disable until you have finished
testing the execution of the SQL statement with and without the use of the outline. You can move the
stored outline to another category using the Outline Manager.
7. Click Deploy.
Moving the Outline to another Category
If you are satisfied with the performance improvement for the SQL statement with the stored outline, then move
the stored outline to a category that is enabled.
8. Click the Outlines tab to open the Outline Manager window.
9. In the Category/Outline pane, select the stored outline.
10. Click Move Outline .

11. Enter either a new category name or the name of an existing category.
12. Click OK.
Enabling an Outline Category
Outlines are stored in a category. A category is either set as enabled or disabled. If the category is enabled, all
outlines in the category will be used when corresponding SQL statement is executing. If a category is disabled,
then when the SQL statement is executed, Oracle retrieves the execution in the normal manner at the time of
execution.
13. Click the category name in the Category/Outline tree.
14. Click Enable Category .

Note: The category named DEFAULT is always enabled, so that outlines stored in the DEFAULT category are always
used when the corresponding SQL statement is executed.
Index Expert Overview
The Index Expert in the Tuning Lab enables you to determine the best possible indexes for a SQL statement. The
Index Expert generates multiple index sets for a single SQL statement.
- 21 -
Index Set Generation
The Index Expert generates index sets by analyzing the syntax of a SQL statement and the tables it references. It
generates the individual index candidates and then groups these indexes into index sets of one or more indexes.
In the Index Type options you can select to generate B-Tree and Bitmap indexes. You can specify to parallelize the
indexes and to what degree. For B-Tree indexes, you can specify key-compressed.
When generating the indexes, it determines the selectivity of the data from the sample data size that you specific
in the Index Options. You can also determine the maximum number of columns that will be used in a composite
index, the maximum number of indexes in an index set, along with setting quotas for how many individual indexes
and index sets are generated.
Note: Index Expert requires Oracle 8i or above. It also requires the use of the Oracle cost-based optimizer. If your
are using the rule-based optimizer, cost-based optimization will be enforced by using the ALL_ROWS or
FIRST_ROWS hint. This is required in order to create virtual indexes in Oracle. If the SQL statement has the rule
hint /*+ RULE */, you must remove it before generating the Index sets.
Eliminating Duplicate Execution Plan
The virtual execution plan for the SQL statement is retrieved using each index set that is generated. Each plan is
compared to all the other virtual execution plans. One index set is selected for each unique virtual execution
plan. Although the index generation process may generate several index sets, you will see only some of the index
sets since the sets with a duplicate virtual execution plan are eliminated.
It retrieves the virtual execution plan for every index set without physically creating of the indexes in your
database because it uses virtual indexes.
Testing Performance Improvement with the Index Sets
You can review the virtual execution plans and the Oracle cost estimations to assist you in selecting which Index
Sets to test and implement. The original SQL statement can be executed using index sets to identify which index
set will yield the greatest performance gain for the SQL statement. The execution process physically creates the
indexes in the index set on your database, executes the original SQL statement, and then drops the indexes from
the database.
Index Impact Analysis
You can do an Index Impact Analysis to see the impact that creating new indexes would have on the execution
plans of your SQL statements before you actually create the indexes on your database. The Index Impact Analysis
evaluates the effect of the creation of the indexes in the database system without affecting database performance.
It shows which SQL statements are impacted by the index sets and identifies the index set that yields the highest
performance gain with the least impact on the database system.
Index Expert Tutorial
Index Expert analyzes the syntax of a SQL statement, the relation between tables, and selectivity of the data to
identify columns as index candidates. Index candidates are combined into multiple index sets and it gives you all
the alternative index sets that generate a unique execution plan for the SQL statement. It does this without
physically creating the indexes in the database. Index Expert provides performance estimations for every index set
to assist you in selecting which index set alternatives to test, evaluate, or implement. The SQL statement can be
executed using the index alternatives to identify which set will yield the greatest performance gain for the SQL
statement.
Generate Index Alternatives
- 22 -
4. Enter the SQL statement in the SQL Text window.
5. Click Generate Virtual Indexes .
Compare the Index Sets with the Original SQL statement
The Execute function provides an efficient way of testing the indexes. It physically creates the indexes on the
database, runs the SQL statement, and then drops the indexes.
Note: This process may impact the performance of other SQL statements.
6. Select the index sets that you would like to test.
7. Click the down arrow on the right of Execute and select Execute Selected.
8. Look at the progress bar in the bottom right corner of the Tuning Lab to see the progress of the batch run
process. When the batch run is finished, the Execution Statistics layout is displayed for you to review the
results
9. Before creating new indexes you can do an Index Impact Analysis.
Index Impact Analysis Tutorial
You can analyze the impact that creating new indexes would have on the execution plans of your SQL statements
before you actually create the indexes on your database. To do this, you use the Impact Analyzer module to store
the current execution plans of your SQL statements. Then you can do a simulation of creating the indexes by
creating virtual indexes and compare the execution plans before and after the index simulation to see what affect
the indexes would have on the execution of your SQL statements. You can do an Index Impact Analysis from the
Tuning Lab or Global Indexing. This tutorial starts from the Tuning Lab.
1. In order to do an Index Impact Analysis, you must have already created an Analyzer in the Impact
Analyzer module. If you have not done this, following the steps in the Impact Analyzer Tutorial.
2. Generate Index candidates using the Index Expert Tutorial in the Tuning Lab.
3. From the Scenario Explorer window in the SQL Details layout in the Tuning Lab, right-click the virtual
index you want to do an analysis on and select Index Impact Analysis.
4. The Select a Group window appears. Select the Impact Analyzer Group which contains the SQL Repository
that you want to analyze.
5. The Impact Analyzer window is opened and you are prompted with the Impact Analysis - Add Snapshot
wizard.
6. The Impact Analysis - Add Snapshot wizard consists of the following:
General Page
7. Select the Analyzer which contains the SQL statements you want to analyze in the Analyzer tree.
Box Description
Name The name is automatically generated for a virtual index snapshot.
Type The snapshot type of Virtual Index Simulation is automatically entered.
Description Enter the description for the Snapshot to be created.
Last generated Displays the last generated date and time. This will be blank since you are
creating the Snapshot for the first time.
Add to Analyzer Displays the Analyzer location where the Snapshot will be saved.
Select an Analyzer to From the tree structure, select an Analyzer. When you are doing an Index
analyze its SQL Impact Analysis from the Tuning Lab, the Analyzer must have been
statements previously created in the Impact Analyzer.
- 23 -
8. Click Next.
Virtual Indexes Page
9. The virtual index set that you selected in the Scenario Explorer is selected. You may select addition index
sets.
10. Click Finish.
Best Practices Tutorial
Best Practices within the Tuning Lab does an overall analysis of a SQL statement and your database and then
proposes common ways to improve performance. However, review these recommendations to see if they are the
correct solution for your database environment and thoroughly test the recommendations before you apply them to
your production system. A recommendation may help to improve a specific SQL performance, but it may affect
other SQL statements as well. When evaluating the recommendations, you need to take into account that database
performance is a result of the complex mix of the following:
• System resources (CPU, I/O, memory, database architecture, and more)

• Data distribution
• System architecture
• SQL execution plans
• User's usage behavior
1. Click Options . Select Tuning Lab | Best Practices | General. Check Include Best
Practices module in Tuning Lab. Click OK.
5. Enter a SQL statement into the SQL Text window.
6. Click Get Best Practices .

7. Review the recommendations in the Best Practices layout.
- 24 -
Global Indexing Overview
Global Indexing analyzes a group of SQL statements and determines the best common index set for all of the SQL
statements in the group. It does the analysis and index generation without physically creating the indexes on the
database. It is necessary to create the indexes if you want to do a comparison of the run times with and without
the indexes.
Note: Global Indexing is only available for Oracle 8i or above.
Index Set Generation
Global Indexing generates a set of indexes by analyzing all the SQL statements in a group of statements and the
tables that are referenced by all the statements. While generating the index set, no indexes are physically created
on the database. Instead, each index in the proposed set of indexes is created as a virtual index and an virtual
execution plan is retrieved for each SQL statement in the group. This virtual execution plan simulates the execution
plan that Oracle would generate if the indexes were physically created.
Testing SQL Performance Improvement with the Index Set
The SQL statements can be executed first without and then with the index set to compare the run times to see
whether there would be any performance gain from creating the proposed index set. The execution process
executes the SQL statement before creating the indexes. Next, it physically creates the indexes on the database,
executes the SQL statements again, and then drops the indexes from the database. You can compare the run times
with and without the indexes and also compare the virtual execution plan to the actual execution plan.
Index Impact Analysis
You can do an Index Impact Analysis to see the impact that creating the indexes would have on the execution
plans of other SQL statements used in your application before you permanently create the indexes on your
database. The Index Impact Analysis evaluates the effect of the creation of the indexes in the database system
without affecting database performance since it uses virtual indexes instead of creating indexes on the database. It
identifies the SQL statements which have execution plans that are impacted by the creation of the indexes.
Note: The options for executing SQL statements are shared between the Tuning Lab and Global Indexing. The
execution settings for Global Indexing are found under the Tuning Lab Execution Criteria and Execution Method
options. Some of the options for generating indexes are shared between the Tuning Lab/Index Expert and Global
Indexing. These settings are found under the Tuning Lab/Index Expert Options and Index Type.
- 25 -
Global Indexing Tutorial
Global Indexing enables you to analyze a set of SQL statements and determine the best common index for all of
the SQL statements.
Generate Index Set Using SQL Statements in a File
1. Gather the SQL statements you want to analyze into a file.

2. Click the Indexing tab.
3. If the Create a New Global Indexing window does not appear, click Create a new session .
5. Click Add SQL and open the file.
6. Click Generate Virtual Indexes to use the expert knowledge to formulate a

set of proposed indexes for the group of SQL statements. This retrieves the execution plan for the SQL
statements, creates all of the indexes as virtual indexes and then retrieves a virtual execution plan for
each SQL statement. When the index generation is finished, the Advice layout displays. The changes in
cost and optimizer paths can be seen in by comparing the execution plan to the virtual execution plan
retrieved while the virtual index was present on the data.
7. Click Execute . This executes the all the SQL statement to obtain the run time. Then, it
creates the indexes in the tablespace you specify and executes all of the SQL statements again. After the
execution is finished, the indexes are dropped. The Results layout displays showing execution statistics in
the Scenario Explorer window.
Note: This physically creates the indexes on the database, runs the SQL statement, and then drops the
indexes. This may impact the performance of other SQL statements.
8. Before creating new indexes you can do an Index Impact Analysis.
9. Deploy the index advice into a production environment by using Index Script . This
button sends the index scripts and statistic generation commands to the SQL Editor for editing and final
deployment opens another Quest product such as Toad or SQL Navigator and copies a index script that
you can use to create the set of indexes. If you do not have a Quest product that can execute the script,
the script is copied into a dialog where you can save the it to a file or copy and paste it to another
program.
- 26 -
Impact Analyzer Overview
Impact Analyzer provides a way to determine the effects on SQL performance before a change is made to the
database or after a change has occurred. You can find out what will happen to the performance of the SQL
statements if you were to add an index or change a database configuration parameter before you make the change
in the database. You can also find the SQL statements that have been affected as the result of changes that have
occurred in the database environment. The Impact Analyzer helps you to ensure reliable database performance by
tracking execution plan and Oracle cost changes for SQL statements.
All kinds of changes can affect SQL performance. Before and after these changes take place, you can predict and
track the impact of changes. Impact Analyzer helps you find where the SQL statements that are effect by changes
and to fix the problem quickly. The following are some of the changes that can have significant impact on the
performance of your SQL:
• Database Configuration changes

• Index creation, rebuilding, or dropping
• Hardware upgrades
• Database upgrades
• Database migration
• Updating database statistics
• Database restructure
• Database reorganization
• Fragmentations
• SQL Repository
- 27 -
The Impact Analyzer enables you to save the SQL statements whose performance you would like to track in a “SQL
Repository”. The execution plan is saved along with the SQL text. You can then use those SQL statement in one or
more "Analyzers."
Analyzer
An Analyzer is set up so that you can find the changes in the execution plans for SQL statements that are critical to
the performance of your production application. In an Analyzer, you create a "Baseline Snapshot" which saves the
execution plan for each SQL statement you have placed in the Analyzer. The execution plans in the Baseline
Snapshot are used as the bases for comparison to execution plans for the same SQL statements under differing
database conditions.
Script
"Scripts" are used so that you can do various "what if" analysis to determine what impact changing the database
configuration would have on the performance of the SQL statements.
Use for Analyzer – Changes that have occurred in the database
You can set up an Analyzer so that you can take a snapshot on a periodic bases to obtain the current execution
plan to find out if any of the execution plans have changed over a period of time. You can also take a snapshot
each time a change has taken place in the database such as a updating of the statistics for tables and indexes. For
those statements with changes, you can use the SQL Optimizer to see if a SQL statement performance would be
improved by optimizing it.
Use for Analyzer – Move application from development to production
You can set up an Analyzer to save the execution plans for the SQL statements in the development environment.
Then when the application is ready to be placed into the production environment, you can take a snapshot to
obtain the execution plans on the production server to find the SQL statements that have different execution plans
and need to be optimized for the production environment.
Use for Analyzer – Upgrade from one version of Oracle to another
You can set up an Analyzer to save the execution plans for the SQL statements in your current version of Oracle.
Then you can connect to a new version of Oracle and take a snapshot to obtain the execution plans on the new
version to find the SQL statements that have different execution plans and need to be optimized for the Oracle
version.
Use for Analyzer – What If analysis for adding new indexes
You can set up an Analyzer to analyze what effect adding an index will have on the execution plans for SQL
statements. This way you can evaluate the affect the new index will have on performance before you create the
index. You can analyze the effect the index will have on the execution plan for each SQL and also see the total
effect on all SQL. This aids you in determining if the index is right for the overall performance of your database.
Note: Virtual indexes are use to create the snapshot so that no indexes are created on your database by this
analysis.
Use for Analyzer – What If analysis for database parameter changes
You can set up an Analyzer to analyze what effect changing various database parameter will have on the execution
plans for SQL statements. This way you can evaluate the affect of a change on performance before you actual
make the change. To simulate the change before it is made, you create an script that would make the proposed
change. Then create a snapshot using the script to obtain what the execution plan would be for each SQL
statement in the Analyzer if you actually made the change. You can analyze the effect that change will have on the
execution plan for each SQL and also see the total effect on all SQL. This aids you in determining if the change is
right for your database.
- 28 -
Scripts
When creating a Script, you set up a Pre-script and a Post-script. The Pre-script is run to change the database
environment. Then the execution plan is retrieved for each SQL statement in the Analyzer. The post-script can be
used to set the database back to its original state.
Note: It is recommended that you use the ALTER SESSION command in the scripts so as to not affect other users
on the database.
Save SQL Statements to Impact Analyzer Tutorial
SQL statements are saved to the Impact Analyzer so that you can track and analyze changes to the execution plan
of a SQL statement under different database environments. This allows the prediction of the overall performance
improvement or degradation in different database environments.
1. In the SQL Scanner or SGA Inspector, highlight a job in the Job Grid.
2. Click Save to Repository .

3. In the Save SQL to Impact Analyzer wizard, select the folder where you want the SQL stored or click Add
Folder to create a new folder for the SQL statements.

4. Click Finish.
You can also save one SQL statement at a time from within in the Impact Analyzer module or from the SQL Text
window in the Batch Optimizer, SQL Scanner, or SGA Inspector.
Impact Analyzer Tutorial
The Impact Analyzer saves the execution plan for SQL statements so that you can track changes to the database
environment such as: parallel processing, database system changes, data growth, database migration, database
version upgrade, development to production deployment, data reorganization, index changes, virtual index
simulation, database re-design, rule-based to cost-based optimizing, and any other database environment change.
The Impact Analyzer shows how these changes affect the execution plans. It enables you to save and compare the
execution plans before and after these changes so that you can see how these changes impact the performance of
your SQL statements.
The Impact Analyzer stores the SQL statements and their execution plan information in this directory on your PC:
C:\Documents and Settings\user\Application Data\Quest Software\Quest SQL Optimizer for Oracle\Analyzer Data
The location of the directory can be changed in the Options window under the Analyzer page.
Impact Analyzer Window
1. Click the Impact Analyzer tab.

SQL Tab – Entering a SQL statement
The SQL statements that you save in the Impact Analyzer are listed under the SQL tab located at the bottom left of
the Impact Analyzer window. You may save a SQL statement from another module (see Save SQL Statements to
the Impact Analyzer Tutorial) or from within Impact Analyzer module.
3. Click the SQL tab at the bottom left corner of the window.
4. Right-click in the SQL pane and select Add SQL to open the Add SQL wizard.
- 29 -
5. On the General page, enter a name for your SQL statement in the Name box.
6. If you would like to create a new folder to store the SQL statement, click Add Folder .
7. In the pane at the bottom of the Add SQL page, click the folder where you want to store the SQL
statement.
8. On the SQL Information page, enter your SQL statement.
9. Click Check SQL to check the syntax and retrieve the execution plan.
10. Click Finish to save the SQL.
Analyzer Tab – Analyzing Execution Plan Changes
You must have saved a SQL statement before you can perform any comparison in the Impact Analyzer. (See Save
SQL Statements to the Impact Analyzer Tutorial or SQL Tab, step 3.)
The Analyzer tab can contain more than one Analyzer. Every Analyzer is an individual unit that contains the
analysis of different SQL statements’ execution plans. Every Analyzer can have one or more SQL statements
grouped in what is called a SQL Repository. For the SQL statements in the SQL Repository, you can take one or
more execution plan snapshots under different database environments.
11. Click the Analyzer tab at the bottom left corner of the window.
12. Right-click in the Analyzer pane and select Add Analyzer to open the Add Analyzer wizard.
13. On the General page, enter a name for your Analyzer in the Name box.
14. If you would like to create a new folder to store the Analyzer, click Add Folder .
15. In the pane at the bottom of the General page, select the folder where you want to store the Analyzer.
16. On the SQL page, select the SQL statements you would like to add to the Analyzer from your predefined
SQL statements, or you may add a statement to this Analyzer by clicking Add SQL in the right corner
of this window.
17. On the Plan Snapshot page, the first time you are on this page, it brings up the Add Baseline Snapshot
wizard. This snapshot of the SQL statements and execution plans is used as the comparison for all other
snapshots in the Analyzer.
After the first execution plan is saved, if you would like to add another SQL snapshot to this Analyzer, click
Add Snapshot under the Plan Snapshot page.

18. In the Add Baseline Snapshot or Add Plan Snapshot wizard under the General page, enter a name for this
Snapshot in the Name box.
19. Under the Connection Information page, select the options for retrieving your execution plan.
• Copy existing execution plan from SQL
Use the execution plan that was saved with the SQL statement at the time that statement was saved
to the Impact Analyzer.
• Current connection
Get the execution plan from the current logon that you are using
• New connection
Get the execution plan with a different user logon.
20. If you would like to run one or more of the Oracle scripts, under the Script page, select the script you
would like to use. If you select to use scripts, the pre-script will be executed after connecting to the
database and before getting the execution plan. After retrieving the execution plan, if there is a post-
script it will be executed. You can use scripts to change your database environment. For instance, you can
use a pre-script to change some of the dynamic init.ora parameters such as optimizer_mode, and then
use the post-script to reset the parameter to its original value. (See Script Tab, step 26.)
Note: You can add a new Oracle script by clicking the Add Script .
21. Click Finish to close the Add Baseline or Plan Snapshot wizard.
22. To add more snapshots, repeat from step 17.
- 30 -
23. Click Finish to close the Add Analyzer Wizard. The Analyzer makes the connection to the database and
retrieves the execution plan under the different snapshots.
24. The Plan Generation Summary window displays information regarding the retrieval of the execution plans.
There you can see if the retrieval is successful or if an error occurred. Click OK to close the window.
25. To review the Plan Analyzer summary, see View the Execution Plan Changes, step 34.
Script Tab – Creating Scripts for Analyzing Configuration Changes
26. Click the Script tab at the bottom left corner of the window.
27. Right-click in the Script pane and select Add Script to open the Add Script wizard.
28. On the General page, enter a name for your Script in the Name box.
29. One the Scripts page, you will see an area for a Pre-Script and a Post-Script.
30. In the Pre-Script area, enter the Oracle commands to be executed before the execution plan is retrieved.
31. In the Post-Script area, enter the Oracle commands to be executed after the execution plan is retrieved.
32. In order to check your script in a pre-selected database, click Check Script . This will allow you to
verify that you your scripts execute.
33. Click Finish to save the scripts.
View the Execution Plan Changes
34. Click the Analyzer tab at the bottom left corner of the window.
35. Expand the tree in the left pane to find the SQL statement for which you would like to analysis the various
execution plans.
36. To view the SQL text and the execution plans for each snapshot, click the name you gave the SQL
statement in the left pane.
37. In the right pane, you will see the SQL statement with tabs at the bottom of the pane to display the
execution plan and SQL classification for each snapshot. This interface allows you to compare side by side
the execution plan for the SQL statement under different snapshots. It also displays the SQL Classification
associated with every execution plan.
38. To view a summary of the performance change from the SQL statement in the Baseline snapshot and a
comparison snapshot, click the name of the comparison snapshot in the left pane.
39. In the right pane, you will see a table (in the center pane) that summarizes the comparison of the
Baseline execution plan and the snapshot execution plan. It shows the Baseline Snapshot Oracle Cost, the
Snapshot Oracle Cost, Cost difference (Snapshot cost – Baseline cost), YES/NO Plan Changed, SQL
Classification for the Baseline Snapshot, SQL Classification for the Snapshot, and what type of change
occurs, Improved/Unchanged/Degraded.
From here you can identify the SQL statements that may experience performance improvement (Oracle
cost in the comparison snapshot is smaller than the cost in the Baseline snapshot), or performance
degradation (Oracle cost in comparison snapshot is higher than the cost in the Baseline snapshot). You
can also analyze how the complexity of the execution plan changes between snapshots by comparing
changes in the SQL Classification.
Note: Oracle only provides a cost for the execution plan for SQL statements under the cost-based
optimizer. If no cost is displayed, this means that the SQL statement is using the rule-based optimizer.
40. At the top right pane, you can see a graph or a summary of Oracle cost changes, which indicate overall
performance improvement or degradation. The summary also displays overall performance improvement
or degradation of the SQL Classification. Clicking any portion of one of these graphs will highlight the
statements that are being represented in these graphs in the table summary discussed in the previous
point (step 39).
- 31 -
Outline Manager Overview
What is a stored outline?
A stored outline consists primarily of a set of "hints" that is equivalent to the Oracle optimizer's execution plan for a
particular SQL statement.
What is the function of a stored outline?
In Oracle, stored outlines enable you to influence the optimization of a SQL statement without having to modify the
SQL statement syntax. If you cannot change the source code that contains your SQL statement, you can use a
stored outline to force Oracle to use a specific execution plan for a SQL statement. This is particularly useful if you
have third party applications where you do not have access to the source code.
Stored outlines are used to preserve the performance characteristics of SQL statements by stabilizing the execution
plan. The execution plan for a SQL statement can change due these and other factors:
• Increase or decrease in data volume

• Moving from rule-based to cost-based optimization mode
• Upgrade in database version and application programs
• Statistics changes
• Database parameter changes particularly those affecting the size of memory structures
- 32 -
When these changes occur, the Oracle optimizer may select a different execution plan which in turn affects the
performance of the SQL statement. By creating a stored outline for a SQL statement, you can stabilize and
preserve performance characteristics of the statement. Therefore, using outlines can prevent performance
degradation of SQL statements due to database environment changes.
Warning: The SQL text that is saved with the outline needs to be identical to the SQL statement in the source
code or the outline will not be used. Oracle will consider two SQL statements as not identical if there is any
difference in spacing, carriage return, embedded hints, comments, and upper/lowercase.
What is a stored outline category?
A stored outline is saved to a category. A category must be "enabled" before the stored outlines that are saved in it
are used when the SQL statements are executed. When a SQL statement is executed, Oracle first searches the
enabled category and then the DEFAULT category to see if the SQL statement has a stored outline associated with
it. If a stored outline is found, then Oracle will use the hints in the outline to determine the execution path for the
SQL statement instead of using the execution plan.
Note: By default the Outline Manager module is not displayed. You can specify to display this module from the
General page of the Outlines options.
The current plan is to remove the Outline Manager module from Quest SQL Optimizer for Oracle in the next
release.
Outline Manager Tutorial
The Outline Manager allows you to manage Oracle outlines after they have been deployed.
1. Click Options . Select Outlines. Check Show Outline Manager. Click OK.
2. Click the Outlines tab.
3. If the Create a New Outline window does not appear, click Create a new session .
5. For a category, use the Outline Manager to drop, enable, or rename it.
6. For an outline, use the Outline Manager to drop, move, or rename it, or reset the "unused flag".
- 33 -
Options Settings
General Options
General Options
Load data dictionary after database connection (Default = Unchecked)

Specify that the database dictionary is automatically loaded into the memory of the client computer every time you
connect to a database. When this option is not selected, the specific information needed from the database is
loaded when the SQL statement is parsed for functions such as scanning, optimization, and index generation. This
save time when you are initially connecting to the database from each module, but it adds a slight bit of time later
when the SQL statement is parsed.
Specify the plan used to retrieve the execution plan
Allow Quest SQL Optimizer to create plan table automatically (Default)
Specify to have the program create the table needed when retrieving an execution plan. If the program can
create a temporary table (QUEST_SL_TEMP_EXPLAIN), it will do so. If not, it will create a permanent table
(QUEST_SL_EXPLAIN). It will create the table in the default schema for the logon.
Use the following plan table
Specify the schema and the name for table used to retrieve the execution plan. This table must already exist
as Quest SQL Optimizer will not create it.
- 34 -
Restore layouts
You may customize any of the module windows by arranging the individual windows within the module. The default
layout can be restored.
Click Restore .
Select the modules to restore the default arrangement of the windows.
Restore All (Default)
Specify to restore all the default window arrangements for every module.
Restore selected layouts
Specify to restore the default window arrange for the layouts that you select from the following modules:
Assistant
Batch Optimizer
SQL Scanner
SGA Inspector
Tuning Lab
Global Indexing
Impact Analyzer
Outline Manager
Launching from Other Applications
Select Batch Optimizer or Tuning Lab to optimize SQL sent from other applications
Batch Optimizer
Specify to send text to the Batch Optimizer. You can send multiple SQL statements embedded in text to the
Batch Optimizer.
Tuning Lab
Specify to send the text to the Tuning Lab. Only a single SQL statement can be optimized in the Tuning Lab.
Ask me every time (Default)
Specify to prompt you to select the module each time text is send to Quest SQL Optimizer from another
application.
Create a new batch every time when sending to Batch Optimizer
Specify to automatically create a new batch or to be prompted to select an existing batch each time you send text
to the Batch Optimizer.
- 35 -
Launching Quest SQL Optimizer from other applications

(when multiple copies of Quest SQL Optimizer are installed)
If you have two or more copies of Quest SQL Optimizer 7.4 or later installed, you need to select which copy will be
launched when you send text from another application.
Click Setting .
Select the copy to be launched.
Quest SQL Optimizer for Oracle
Quest SQL Optimizer for Oracle Trial
Quest SQL Optimizer for Oracle Beta
Ask me every time
SQL Classification Options
SQL Classification Definitions
When the execution plan for a SQL statement is retrieved from Oracle, the SQL statement is classified as Simple,
Complex, or Problematic. SQL statements are categorized according to their suspected level of performance to help
you focus on the SQL statement that are more likely to be causing performance problems. These SQL
classifications are user defined in the Options.
Problematic SQL Statements
Problematic SQL statements are the highest level of potentially under-performing SQL statements that should be
optimized. Using the default settings, a SQL statement is classified as Problematic SQL when the execution plan
contains at least one of the following:
Rule Description Rule Name

6 or more references to database objects. Object References (Count >= 6) - Excluding DUAL
2 or more full table scans. TABLE ACCESS FULL (Count >= 2) - Excluding DUAL
A full table scan in a step where the bytes TABLE ACCESS FULL (BYTES >= 4 MBytes) - Excluding
is four mbytes or more. DUAL
A full table scan in a step where the TABLE ACCESS FULL (CARDINALITY >= 100,000) -
cardinality is 100,000 or higher. Excluding DUAL
A nested loop in a step where the bytes is NESTED LOOP Iteration (BYTES >= 2 MBytes) - Excluding
two mbytes or more. DUAL
A nested loop in a step where the NESTED LOOP Iteration (CARDINALITY >= 10,000) -
Note: You have the option to include or exclude the SYS.DUAL table in each definition.
Complex SQL Statements
Using the default settings, a SQL statement is classified as Complex SQL when the execution plan contains at least
one of the following and does not meet any rules for Problematic SQL.
Rule Description Rule Name

2 or more references to database objects. Object References (Count >= 2) - Excluding DUAL
A full table scan in a step where the bytes TABLE ACCESS FULL (BYTES >= 2 MBytes) - Excluding
is two mbytes or more. DUAL
A full table scan in a step where the TABLE ACCESS FULL (CARDINALITY >= 10,000) -
- 36 -
3 or more fast full index scans. INDEX FAST FULL SCAN (Count >= 3) - Excluding DUAL
Note: You have the option to include or exclude the SYS.DUAL table in each definition.
Simple SQL Statements
A SQL statement is classified as Simple SQL when the execution plan does not meet any of the rules for either the
Problematic or Complex SQL classifications.
No Plan SQL Statements classified as "Invalid SQL"
If the execution plan is not retrieved successfully, then the SQL statement is classified as "Invalid SQL". A SQL
statement can be can be classified as Invalid SQL if the database object it references does not exist, the database
user does not have privileges to access the database object, or the schema used is not the correct one for the SQL
statement.
SQL Classification Rules
The SQL Classification rules which determine whether a SQL statement is classified as Simple SQL, Complex SQL,
or Problematic SQL.
To create a SQL classification rule
1. Click New Rule .
- 37 -
2. Under Step 1, select the template to use for the new rule.
Template Description
Count the number of references to This rules determines the maximum number of times one
database objects or more database objects is referenced before the SQL
statement is placed in the classification that you select.
Count the number of a specific This rules determines the maximum number of times a
operation specific operation, which you select, can be performed
before the SQL statement is placed in the classification
that you select.
Check the BYTES in a specific This rules determines the maximum number of bytes that
operation can be in a operation, which you select, before the SQL
Check the BYTES in the child steps This rules determines the maximum number of bytes that
under a specific operation can be in the child steps of a operation, which you select,
that you select.
Check the CARDINALITY in a specific This rules determines the maximum size of the cardinality
operation of a specific operation, which you select, before the SQL
Check the CARDINALITY in the child This rules determines the maximum size of the cardinality
steps under a specific operation of the child steps in a specific operation, which you select,
that you select.
- 38 -
Check the BYTES in a step that is This rules determines the maximum number of bytes that
iterated by a NESTED LOOP can be in a step that is in a NESTED LOOP before the SQL
Check the CARDINALITY in a step before the SQL statement is placed in the classification
that is iterated by a NESTED LOOP that you select.
3. Under Step 2, click the underlined text to select or enter your desired value for the rule you selected.
4. Under Step 3, select Complex SQL or Problematic SQL.
5. Under Step 4, edit the default name for the rule.
6. Click Create.
SQL Statement with no Execution Plan
In addition to being classified as Simple, Complex, or Problematic, some SQL statements are classified as "Invalid
SQL" to indicated that execution plan could not be retrieved from the database. The Oracle error message which
indicates that the execution plan was not retrieved is displayed to help you determine why the SQL statement was
classified as invalid. The Invalid SQL classification may result from one of the following:
No permission to tables or views
The current user does not have privilege to the tables, views, or other database objects referenced in the SQL
statement even though the syntax of the SQL statement is correct.
Dynamic SQL statements
The SQL Scanner is unable to identify SQL statements that are dynamically constructed at run time. This type of
SQL is found in the source code on several command lines and the exact construct of the SQL statement is not
determine until the application is executed. The SGA Inspector can be used to trap all executed or real-time SQL
statements.
Database object does not exist
A database object references in the SQL statement does not exist.
Incorrect Schema
The schema that was used when the execution plan was retrieved was not the correct schema for the SQL
statement.
- 39 -
Trace Setup Options
Each time a SQL statement is executed in the Tuning Lab and Global Indexing, the trace statistics from the
execution can be retrieved. The Oracle SQL tracing function writes the statistics to a trace log on the server. In
order to view this information in the Tuning Lab after the execution is finished, you must set up the file access
method for retrieving the statistics from the log files on the server.
Note: By default, the trace log is stored in the location specified by the Oracle USER_DUMP_DEST parameter.
However, you can customize the location of the trace log in the init.ora file.
Three methods are provided for retrieving the information from the trace log.
• File Transfer Protocol (FTP)

• Network File System (NFS)
• Oracle UTL_FILE
Note: To use the UTL_FILE option, the UTL_FILE package must be installed on the Oracle instance and valid
directory specification parameters must exist in the Oracle initialization file for USER_DUMP_DEST and
UTL_FILE_DIR.
Trace Setup
Select database connection for Oracle trace file
In the Connection box, click Down Arrow to select a previously created database connection or click Ellipsis
to create a new connection.
Access Method
To select the file access method

1. Select a database connection and then the Access Method box appears.
2. Select one of the access methods from the Select the access method box: FTP, NFS, UTL_FILE.
- 40 -
3. Follow the prompts for the access method you have chosen.
4. Click Validate to validate the trace log location and access method.
or
Click Run Trace Wizard to use the Trace Setup wizard which will guide you
through these steps.
Note: The size of the trace log file is determined by the setting for the MAX_DUMP_FILE_SIZE Oracle parameter.
To disable the trace

• Select Disable from the Select the access method box.
To enable or disable the trace when executing SQL statement multiple times
Since the trace information is retrieved each time the SQL statement is executed, it may be desirable to not select
the Include trace statistics when you are executing the SQL statements multiple times with the Multi-Execute
option. Including the trace statistic may add extra time to the test.
1. In the Options window, select the Tuning Lab—Execution—Execution Method.
2. In the Multi-Execute section, select or clear Include trace statistics.
Trace Setup Wizard
The Trace Setup options can be entered with the help of the Trace File Setup Wizard. This wizard allows you to
setup one of the following trace file options for transferring the statistics from the server to your local computer:
• File Transfer Protocol (FTP)

• Network File System (NFS)
• UTL_FILE package
• Disable Tracing
File Transfer Protocol (FTP)
An File Transfer Protocol connection must exist for the Oracle instance to which you want to connect. The wizard
FTP option window contains the following:
To setup the Trace File Transfer Protocol option

1. In the Trace Log Setup Wizard, select File Transfer Protocol (FTP).
2. Click Next.
3. Enter a host name in the Host Name box. Remote users may need to include the .networkname.com
extension with the host name.
4. Enter an account name in the Account Name box.
5. Enter a password in the Password box.
6. Enter or browse to find the trace log file path in the Fully Qualified Trace Log Directory box.
7. Click Validate to test the supplied setup information.
8. Click Next.
9. Click Finish.
Network File Server (NFS)
Using the Network File Server option, you can select any directory that you can directly access from your local
computer.
To setup the Network File Server option

1. In the Trace Log Setup Wizard, select Network File Server (NFS).
2. Click Next.
- 41 -
3. Enter, or browse for, the trace file path by using the Fully Qualified Trace Log Directory field. For
remote NFS connections the Browse path and the user_dump_dest path are different. The Browse path
contains the mapped path and the user_dump_dest path displays the local path for the remote machine.
Tip: You can copy the user_dump_dest value displayed in the wizard and paste it in this box.
3. Click Validate to test the supplied setup information.
4. Click Next.
5. Click Finish.
UTL_FILE Package
If you cannot access the trace log files using the File Transfer Protocol (FTP) or Network File Server (NFS) options,
you can use the Oracle UTL_FILE package option. The transfer of the statistics from the trace log to the local
computer will be slower with this option than with the other options.
The directory specification for the Oracle parameters USER_DUMP_DEST and UTL_FILE_DIR must be defined in
INIT.ORA. The UTL_FILE package must be installed on the Oracle instance. If it is not installed, the wizard will
install it for you.
To setup the UTL_FILE package option

1. In the Trace Log Setup Wizard, select UTL_FILE package.
2. Click Next.
3. In the package is not already install, click Install package.
4. Click Validate to test the connection.
5. Click Next.
6. Click Finish.
Disable Tracing
If you do not want to see the trace statistics after the a SQL statement is executed in the Tuning Lab or Global
Indexing, you can disable the function so that the statistics are not retrieved from the trace log files.
To disable the retrieval of the Oracle trace run time statistics

1. In the Trace Log Setup Wizard, select Disable Tracing.
2. Click Next.
3. Click Finish.
- 42 -
Execution Plan Options
Execution Plan
The Execution Plan page of the Options window allows you to select the settings for all execution plan windows
displayed throughout all the modules.
TABLE ACCESS FULL warning threshold (Default = 1000, Range 0 to 32,767)
Specify the number of rows that must exist in a table before the icon in the execution plan is changed from green
to red to draw your attention to the full table scan.
Abbreviate JOIN Text (Default = unchecked)
Specify to abbreviate the text that is displayed in the execution plan for the table joins. The abbreviation feature
reduces the large amount of join text associated with a large query so that you can focus on the overall steps in
the execution plan.
Execution Plan Display Settings
The color and font can be set for each item in the execution plan which is listed in the Name column.
Color
Specify the color of the individual items in the execution plan by clicking the Color column in the row for the
item and selecting the new color from the Color dialog.
Font
Specify the font settings of the individual items in the execution plan by clicking the Font column in the row
for the item and selecting the new settings from the Font dialog.
Note: The execution plan is displayed in several layouts. The color and font settings in this Option windows
controls the settings in all the Execution Plan windows. You can customize which elements of the execution plan
are displayed in each individual Execution Plan window using the Execution Plan Options window.
- 43 -
Execution Plan Options Per Window
The display of the Execution Plan window can be customized for each module or layout in which it is included. You
can select which elements of the execution plan you would like displayed in the text of the execution plan. You can
also have the element displayed in a separate column.
To customize an individual Execution Plan window

1. Right-click the Execution Plan window and select Plan Options.
2. In the Visible column, select the elements you want displayed in the execution plan text.
3. In the As Column column, select the elements you want displayed in a separate column in the Execution
Plan window.
4. Click OK.
- 44 -
Note: The execution plan is displayed in several module and layouts. The color and font settings for all the
Execution Plan windows is set using the General—Execution Plan page of the Options window.
Test for Scalability Options
The Test for Scalability function sends the selected SQL statements to Quest's Benchmark Factory program. If you
have Benchmark Factory 5.0.1 or earlier installed on your computer, you will be prompted by the Benchmark
Factory wizard to select the settings for the test for scalability If you have Benchmark Factory 5.5 or later installed
on your computer, you can set up the test with the following options.
Number of virtual users to execute the SQL statements
Specifies the number of users that Benchmark Factory will simulate to test the performance of each SQL
statement.
Latency Think Time
Latency Think Time is used to simulate an amount of time "to think" about the results of a previous transaction. It
controls the period between receiving results of one transaction and sending the next transaction to the server. The
distribution model is used to calculate the exact milliseconds that are used each time for the delay between the
execution of the SQL statement.
Distribution Model
Select the Distribution module.
Distribution Module Description

None No delay occurs between the execution of the SQL statement.
Absolute Absolute is a fixed length delay.
Uniform Uniform is an random delay with an equal probability of being the
minimum value, the maximum value, or any value in between.
Negative Exponential Similar to the Normal distribution, Negative Exponential inserts a
random delay based on a mathematical model.
Normal Normal distributions differ from Uniform delays in that most of
the delays chosen by Benchmark Factory will be close to the
average, but can vary by as much as ±10% of the mean.
Poisson A Poisson distribution is very similar to the Normal distribution.
The biggest difference is that Poisson selects discreet values.
- 45 -
Duration (milliseconds)
Specify the number of milliseconds to delay between each execution of a SQL statement.
Execute each SQL statement by
Select either to execute the SQL statement a certain length or a certain number of times.
Duration (seconds)
Specify to continually execute each SQL statement with latency for the specified number of seconds.
Number of times
Specify to execute each SQL statement the specified number of times.
Directory Setup Options
Data Directories
Batch Optimizer data directory

The Batch Optimizer data directory is used to store the data files created while scanning and optimizing SQL
statements in the Batch Optimizer. The default directory is:
C:\Documents and Settings\User\Application Data\Quest Software\Quest SQL
Optimizer for Oracle\Batch Optimizer Data
Note: You cannot change the data directory while the Batch Optimizer module is open.
SQL Scanner data directory

The SQL Scanner data directory is used to store the data files created while scanning in the SQL Scanner module.
The default is:
C:\Documents and Settings\User\Application Data\Quest Software\Quest SQL Optimizer for

Oracle\SQL Scanner Data
Note: You cannot change the data directory while the SQL Scanner module is open.
The scanning process in the Batch Optimizer stores the data in Batch Optimizer data directory.
- 46 -
SGA Inspector data directory

The SGA Inspector data directory is used to store the data files created while retrieving SQL statements from the
SGA. The default is:
Optimizer for Oracle\SGA Inspector Data
Note: You cannot change the data directory while the SGA Inspector module is open.
Impact Analyzer data directory

The Impact Analyzer data directory is used to store the SQL Repository, Analyzer, and script files created in the
Impact Analyzer. The default is:
Optimizer for Oracle\Impact Analyzer Data
Note: You cannot change the data directory while the Impact Analyzer module is open.
Batch Optimizer Options
Batch Optimizer Settings
The Batch Optimizer settings consists of the following pages that allow you to select the options settings used
throughout the three processes preformed in the Batch Optimizer: scanning for SQL statements, transforming the
SQL text through optimization, and executing the SQL statements to test the run times and find a best alternative
SQL.
Options
Execution
Execution Criteria
Execution Method
Auto Execution
- 47 -
Options
The Batch optimization consists of three steps: scanning to find SQL statements, rewriting the SQL syntax, and
executing the SQL alternatives to find the best. Each one of these steps has option settings that control how the
Batch Optimizer works.
1. Search for SQL statements in your code
Automatically start extracting SQL when job is added (Default = checked)
Specify to start the first step of the Batch Optimizer process, which is to scan the text of the job, when the job is
added to a batch. If this option is not selected, then you must manually start the scanning process using the Job
Status column in the Job Grid or click Optimize Job .

View Scanning options shared between Batch Optimizer and SQL Scanner
The options for the scanning process are shared between the SQL Scanner and the Batch Optimizer. The scanning
settings for both modules are found under the SQL Scanner options.
2. Optimize the SQL statements found by generating different alternatives
SQL to automatically optimize (Default = Problematic, Complex)
Specify the classification of SQL statements that will be automatically be optimized after the scanning process is
completed. If you do not select any classification, then you must manually select which SQL statements you want
optimized after the scanning process is finished.
Problematic
Complex
Simple
- 48 -
View Optimization options shared between Batch Optimizer and SQL Optimizer in Tuning Lab
The options for the SQL optimization process are shared between the SQL Optimizer in the Tuning Lab and the
Batch Optimizer. The optimization settings are found under the Optimizer options in the Tuning Lab section.
3. Execute the alternatives to determine the best replacement SQL
Types of SQL statements to execute automatically after optimization
Specify which type of SQL statement, along with its alternatives, that will be automatically executed to retrieve the
run time statistics. When a INSERT, UPDATE, or DELETE statement is executed, it is always rolled back. This
maintains the integrity of your data and provides that the initial data is the same for each SQL alternative so that
the test is comparable.
SELECT (Default = checked)
INSERT (Default = cleared)
UPDATE (Default = cleared))
DELETE (Default = cleared))
View Execution options that are used by the Batch Optimizer
The Executions options used by the Batch Optimizer are not shared with any other module,
Execution
Execution Criteria
- 49 -
Run Time Retrieval Method
Retrieve run time executing

Caching the data, the indexes, and the SQL statement can affect the comparison times if one SQL statement does
the caching and others do not. Therefore, the following options are available so that you can select the one that
provides you with the most accurate comparison of the run times.
Original SQL twice using second run time
All others twice only if the original runs faster than (mins/secs)
(Default = 5 seconds) (Default)
This option always executes the original SQL statement twice to make sure that the data is cached. It only
executes the SQL alternatives twice to make sure that the indexes and SQL statements are cached if the
original SQL statement runs faster than the time you specify. When it executes the SQL alternatives twice, it
uses the second run time.
Original SQL twice using second run time and all others once
The first time you access data from a table, the data is cached into memory. This process takes a few
moments. The next time you access that data, it is already in memory. Therefore, the first SQL statement
will have the additional time it takes to cache the data included in the run time whereas the following SQL
statements do not have the additional time included in their run time. So to have a comparable test, the first
SQL is run twice and the time from the second run is compared to the time from the other statements which
are run once. It this case, all SQL statements are executed with the data cached.
For fast running SQL statements, executing all SQL statements twice enables you to eliminate two caching
factors that can affect the accuracy of the comparison results: caching the SQL statement and caching the
indexes. If some SQL statements have been recently executed, then the SQL information for those
statements is likely to be resident in the cache and the statements may execute faster because the SQL
statement does not need to be cached. Also, if some of the SQL statements use different indexes, one index
may be resident in the cache and the other may not. So running all the SQL statements twice ensure that
each index is cached.
This option eliminates time variation caused by caching since it runs all SQL statements twice, throws out the
first execution time when the caching would occur and uses the second run time when all SQL statements
and indexes should have the necessary items in the cache. Consequently, the time to cache has been
eliminated and you get a more accurate comparison of the run time of each alternative SQL statement.
All SQL once
For long running SQL, there is no need to run any statement twice since the effect from caching is diminished
over time.
Best SQL Alternative Selection Criteria
Best alternative selected based on lowest

At the end of the execution of the SQL statements, one alternative is marked as the "best alternative." Specify to
have this alternative selected based on the fastest run time using the total time to retrieve all rows or the time to
retrieve the first row.
Total elapsed time (Default)
The Total elapsed time shows the actual elapsed time required to retrieve all records from the database. If
the SQL statement is used to retrieve all the records from the database as may be the case for reports or
batch processes, this is the best option to select.
First row elapsed time
The First row elapsed time indicates the time it takes for the first record to be returned. For some online
retrieval screens, interactive applications, or processes that do not retrieve all records for the SQL statement
at once, this option should be used as a criteria for selecting the best alternative SQL statement.
- 50 -
SQL Termination Criteria
Terminate execution of SQL alternative if it run longer than

The SQL optimization process produces every alternative SQL statement that will run faster than the original SQL
statement. But it also produces every SQL alternative that will run longer than the original SQL statement. This
option specifies when the longer running alternatives will be terminated.
Run time of fastest SQL (Default)
Allows you to retrieve the run time of SQL statements that run faster than the current best run time. With
this option, the original SQL statement is run first and the time from that statement is used as the
termination time for the next SQL statement. When a SQL statement runs faster than this time, the faster
time is used as the new termination time. So you are always using the currently fastest run time as the
termination time for the next SQL statement.
Run time of original SQL
Enables you to retrieve the run time of SQL statements that run faster than the original SQL statement. It
terminates all SQL statements that run longer than the run time from the original SQL.
User defined time (mins/secs)
Enables you to set your own termination time. It retrieves the run time of the SQL statements that are less
than the defined time. With this option, the original SQL statement is always run to completion in order to
used it as a comparison to find a better time.
Execution Method
Execution Method
Run on server (Default)

Specify to execute all SQL statements on the server and to not return the data from the SELECT statements to the
client. Executing the SQL statements under this option provides you with the run time on the CPU for the SQL
statement. Your logon account must have the SYS.DBMS_SQL package privilege to retrieve the run time from the
server.
When SELECT SQL statements are executed, a comparison of the result is done to further insure that result set for
an alternative SQL statement is the same as the original SQL statement. When you select the Run on Server
option, the comparison made between the original SQL statement and the SQL alternatives is the number of row
returned. No comparison of the result data is performed.
Run on client
Specify to execute the SQL statement and return the data to the client. Executing the SQL statement under this
option provides you with the run time that includes the time it takes to transfer the data to the client computer.
an alternative SQL statement is the same as the original SQL statement. When you select the Run on Client
option, the comparison is done between the hash values of the data. To compare the result set of the original and
alternative SQL statements, each row of the result set is hashed and then the hash values are stored in the
memory of the client computer to compare the hash results of the original SQL statement with the hash results of
the SQL alternatives. The data is not stored in memory nor on the disk drive of the client computer.
Limit rows retrieved to (Default = unchecked) (Range 100 to 32,767, Default = 100)
Specify the number of rows you want retrieved during the execution. The default value is 100.
- 51 -
Important Note: If you enable this feature, remember that this is not comparing the way the SQL
statement is actually being executed in the application since you are not retrieving all of the data. It is good
only for a quick test. The execution results may be different when you retrieve all the records.
Number of rows returned in a single network transfer (Range 25 to 32,767, Default = 1000)
Specify the number of rows that will be retrieved at one time when fetching the data from the server. The
default value is 1000.
Auto Execution
When SQL statements are optimized in the Batch Optimizer, hundreds of alternative SQL statements may be
generated. When the original SQL statement and the alternative SQL statements are executed, you can limit the
alternatives that are executed.
Two options are provided for selecting the SQL alternatives. The first option selects a representative selection from
all the SQL alternatives. It uses an Intelligence engine to first group the SQL statements based on the Oracle cost
and then selects one SQL statement from each group. The second option adds more SQL alternatives to the SQL
alternatives selected by the first option.
This process of selecting which SQL alternatives to execute starts by selecting the SQL alternatives from each
group using the value you specify in Number of SQL alternative to select as the representatives. Then it
checks the setting for Execute these additional SQL alternatives to determine if additional SQL alternatives
should be selected.
Use Intelligence Engine to execute best representation of SQL Alternatives
- 52 -
Number of SQL alternative to select as the representatives

Specify to have the SQL alternatives selected for execution by an Intelligence engine. This engine uses a unique
process that determines a grouping of the SQL statements based on the Oracle cost. It then selects SQL
statements from each group until it has reached the number of SQL alternatives that you specify.
Select Additional SQL Alternatives to Execute
Execute these additional SQL alternatives

Select one of the following options to add more alternatives to the one selected using the Number of SQL
alternative to select as the representatives option.
Note: If you do not want to add any additional alternatives, select % of alternatives with lowest cost and set
the Maximum alternatives executed to match the value you set for Number of SQL alternative to select as
the representatives.
% of alternatives with lowest cost: (Default, Default = 25, Range 1 to 99)
Executes the specified percentage of the SQL alternatives starting with the lowest Oracle cost and moving to
the highest.
Minimum alternatives executed: (Default = 5, Range 1 to 99)
Specify the minimum number of SQL statements to be executed. If there are not enough SQL
statements within the original selected group, then the SQL statements with the next lowest cost will be
executed until the specified minimum number of SQL statements is executed.
Maximum alternatives executed: (Default = 20, Range 1 to 999)
Specify the maximum number of SQL statements to be executed. If there are more SQL statements
selected for execution than this value, the SQL statements with the lowest Oracle cost will be executed
first until it reaches this value.
Number of alternatives with lowest cost: (Default = 10, Range 1 to 99)
Executes the specified number of SQL alternatives, which are sorted by the Oracle cost, starting with the SQL
statement with the lowest Oracle cost.
All alternatives with cost less than or equal to original SQL
Executes all the SQL alternatives whose Oracle cost is less than or equal to the Oracle cost of the original
SQL statement.
All alternatives with cost less than average of all alternatives
Executes all the SQL alternatives whose Oracle cost is less than the average Oracle cost for all of the SQL
alternatives.
All alternatives with cost less than the original SQL by percentage (Default = 50, Range 1 to 99)
Executes only the SQL alternatives that have an Oracle cost that is the specified percentage lower than the
Oracle cost of the original SQL statement.
All alternatives with cost less than the original SQL by N times (Default 50, Range 2 to 10)
Executes all the SQL alternatives whose Oracle cost is the specified number of times lower that the original
SQL statement.
All alternatives
Executes every alternative SQL statement.
- 53 -
SQL Scanner Options
The Scanner page of the Options window allows you to select the settings for the scanning of database objects,
source code files, or SGA Inspector files in the SQL Scanner and the Batch Optimizer.
Scanner Options
Skip SQL within comments (Default = unchecked)

Specify whether the scanning algorithm will ignore any SQL statements within comments enclosed within /* */ or
following -- found in the source code. By default, the scanning algorithm will search for any SQL statements
contained in comments.
Skip SQL that involves only SYS.DUAL table (Default = unchecked)
Specify whether to ignore any SQL statements that use only the SYS.DUAL table.
Whole word matching for the first SQL keyword (Default = unchecked)
Specify to search for the words SELECT, INSERT, UPDATE, or DELETE as a whole word. When this option is
selected, these keywords must be preceded and followed by a space or end of line character. When this option is
selected, the SQL Scanner will not find the word INSERT in something like PROCEDUREINSERT or INSERTRECORD
and attempt to build a SQL statement from it.
Number of characters skipped at the beginning of every line for all files (Default = 0, Range = 0 to 9)
When a file is scanned, the SQL Scanner skips the specified number of characters at the beginning of every line.
This is useful when scanning programming languages that allow tags at the beginning of each line.
Skip end of line continuation character
If the text of the SQL statement is on more than one physical line and there is a continuation character at the end
of each physical line of the SQL text, then specify what the continuation character is so that it will be skipped. If
this character is not skipped, it may cause the SQL Scanner to miss part of the SQL statement. Three options are
included: <Do not skip>, / (forward slash character), and _ (underscore character). In addition, you may add your
own character. This character will be saved in the box as long as it is the selected character. Once you make
another selection, your own character will not be remembered.
Tuning Lab Options
Optimizer
Optimizer Settings
The Optimizer settings for the Tuning Lab and the Batch Optimizer in the Options window consists of the following
pages that allow you to select the options settings used when a SQL statement is optimized.
- 54 -
• Intelligence
• Optimization
• Hints
• Access Path
• Join Order
• Optimization Approaches
• Parallel Execution
• Query Transformation
• Other
• Quota
Intelligence (Optimizer)
Optimization Intelligence settings enables you to either customize all the optimization settings used during
optimization or allows you to select the predefined levels for these settings.
Intelligence Level
Custom
Use Custom to enable you to select the individual settings on the Optimization, Access Paths Hints, Join Order
Hints, Optimization Approach Hints, Parallel Execution Hints, Query Transformation Hints, Other Hints, and Quota
pages.
- 55 -
Predefined (Default)
Use Predefined to enable you to select an Intelligence Level which has all the optimization settings pre-selected for
you. The items selected on the Optimizer options pages change according to the level you select. The higher the
level the more intelligent the SQL Optimizer is, the more options are selected, and the more likely you are to find a
better SQL alternative. It may also take more time to optimize a SQL statement at the higher Intelligence Levels.
The Predefined settings are groups into these setting categories:
Predefined Settings Description

Use Oracle optimization hints Uses all the optimization settings.
Use Data Warehouse / OLAP Uses all the settings on the Optimization page and only the Oracle
hints which are commonly used in Data Warehouse or OLAP
databases.
Do not use Oracle optimization Uses only the settings on the Optimization page.
hints
Use Access Paths hints only Uses all the settings on the Optimization page and only the Oracle
hints that control access paths.
Use Query Transformations hints Uses all the settings on the Optimization page and only the Oracle
only hints that control query transformations.
Use Join Orders / Operations hints Uses all the settings on the Optimization page and only the Oracle
only hints that control join orders and join operations.
Use Parallel Execution hints only Uses all the settings on the Optimization page and only the Oracle
hints that control parallel execution.
Intelligence Level Settings
Use Oracle Optimization Hints
The Predefined Intelligence Level Use Oracle Optimization Hints uses all the optimization settings. The
intelligence levels range from 1 to 10. Level 4 is the default setting. As the level is increased more options are
selected.
Use Data Warehouse / OLAP
The Predefined Intelligence Level Use Data Warehouse / OLAP Hints only uses the options on the Optimization
pages and the Oracle optimization hints that are commonly used in Data Warehouse or OLAP databases. The
intelligence levels range from 1 to 5. Level 3 is the default setting. As the level is increased more options are
selected.
All Data Warehouse and OLAP hints are applied at every intelligence level. Only the settings on the Optimization
page and the Quota page are changed for each intelligence level.
Do Not Use Oracle Optimization Hints
The Predefined Intelligence Level Do Not Use Oracle Optimization Hints uses only the settings on the
Optimization page and the Quota page. None of the Oracle optimization hints are applies to the original SQL
statement or the SQL alternatives. The intelligence levels range from 1 to 5. Level 3 is the default setting. As the
level is increased more options are selected.
- 56 -
Use Access Paths Hints Only
The Predefined Intelligence Level Use Access Paths Hints only uses the options on the Optimization pages and
the Oracle optimization hints that control access paths. The intelligence levels range from 1 to 5. Level 3 is the
default setting. As the level is increased more options are selected.
All Access Paths hints are applied at every intelligence level. Only the settings on the Optimization page and the
Quota page are changed for each intelligence level.
Use Query Transformations Hints Only
The Predefined Intelligence Level Use Query Transformations Hints only uses the options on the Optimization
pages and the Oracle optimization hints that control query transformations. The intelligence levels range from 1 to
5. Level 3 is the default setting. As the level is increased more options are selected.
All Query Optimization hints are applied at every intelligence level. Only the settings on the Optimization page and
the Quota page are changed for each intelligence level.
Use Join Orders / Operations Hints Only
The Predefined Intelligence Level Use Join Orders / Operations Hints only uses the options on the Optimization
pages and the Oracle optimization hints that control join orders and join operations. The intelligence levels range
from 1 to 5. Level 3 is the default setting. As the level is increased more options are selected.
All Join Order and Join Operations hints are applied at every intelligence level. Only the settings on the
Optimization page and the Quota page are changed for each intelligence level.
Use Parallel Execution Hints Only
The Predefined Intelligence Level Use Parallel Execution Hints only uses the options on the Optimization pages
and the Oracle optimization hints that control parallel execution. The intelligence levels range from 1 to 5. Level 3
is the default setting. As the level is increased more options are selected.
All Parallel Execution hints are applied at every intelligence level. Only the settings on the Optimization page and
the Quota page are changed for each intelligence level.
- 57 -
Optimization
On the Optimization page, you can control whether a few of the SQL transformation rules are applied. Most of the
transformation rules used to rewrite the syntax of your original SQL statement are always reviewed during the
optimization process to see if the rule can be applied. The transformation rules on the Optimization options page
are only applied if they are selected.
View to inline view transformation
The View to inline view transformation is only applicable if the SQL statement is using a view to access
information from the database. When a SQL statement is using a view, the SQL Optimizer rewrites the view's SQL
statement along with the original SQL statement as one of the SQL transformations. The SQL Optimizer inserts the
view's SELECT SQL statement into the original SQL statement in every place the view is referenced. Therefore the
view's SQL is going to be rewritten along with the original SQL. This is very useful when you want to optimize a
SQL statement that is using a poor performing view but you do not want to change the view's SQL.
Original SQL
SELECT *
FROM V_DEPT
WHERE DPT_MANAGER = 'SMITH'
Original SQL with View inserted

SELECT *
FROM (SELECT DPT_ID, DPT_MANAGER FROM DEPARTMENT)
- 58 -
WHERE DPT_MANAGER = 'SMITH'
Transform view to inline view
Specify whether to transform the view in the text of the SQL statement to an inline view, or in other words, to
transform the view to a subquery used as a table in the FROM clause.
Transformation level (Range = 1 to 99)
Specify how many levels to search for a view. This is applicable if a view uses another view so that lower
level views can also be inserted into the original SQL statement.
Ignore SYS Views
Specify whether to ignore SYS schema views when applying the View to inline view transformation.
Apply MERGE hint to transformed inline view
Specify whether to apply the Oracle MERGE hint to the View's SELECT statement.
Apply NO_MERGE hint to transformed inline view
Specify whether to apply the Oracle NO_MERGE hint to the View's SELECT statement.
Query to inline view transformation
The Query to inline view transformation is applicable only to SQL statements with an IN or an EXISTS. It takes
an original SQL statement and transforms the IN or EXISTS to a derived table.
Transform query to inline view
Specify whether to transform the query to an inline view – a subquery used as a table in a FROM clause.
Original SQL
SELECT *
FROM DEPARTMENT
WHERE DPT_ID IN (SELECT EMP_DEPT
FROM EMPLOYEE)
Alternative SQL
SELECT DEPARTMENT.*
FROM DEPARTMENT,
(SELECT DISTINCT EMPLOYEE.EMP_DEPT COL1
FROM EMPLOYEE) TEMP0
WHERE DEPARTMENT.DPT_ID = TEMP0.COL1
Join Tables
Rewrite SQL using the Ansi-92 JOIN syntax
Specify to use the JOIN clause from the Ansi-92 SQL standard when generating the SQL alternatives. During the
optimization, the SQL statement is converted to the Ansi-92 SQL standard and then the SQL syntax transformation
rules are applied to rewrite the converted SQL statement. Next, the Oracle hints are applied to the original SQL and
the transformed SQL. So you may see SQL alternatives that use the join syntax from the original statement SQL,
but these SQL alternatives are simply the original SQL with an Oracle hint applied.
The OUTER JOIN is not including in this conversion because Ansi-92 OUTER JOIN syntax does not always retrieve
the same result set as the OUTER JOIN using the (+) operator. So to avoid producing the wrong result set, the
conversion of the OUTER JOIN syntax cannot be applied.
- 59 -
For example:
SELECT DPT_ID
FROM EMPLOYEE
INNER JOIN DEPARTMENT
ON EMP_DEPT = DPT_ID
Rewrite SQL without using the Ansi-92 JOIN syntax
Specify to join tables in the FROM clause without the JOIN syntax or using a comma. The join analysis occurs in the
WHERE clause which specifies that the column in one table is compared to a column in another table. During the
optimization, the SQL statement is converted from the Ansi-92 SQL standard and then SQL syntax transformation
rules are applied to rewrite the converted SQL. Next, the Oracle hints are applied to the original SQL and the
transformed SQL. So you may see SQL alternatives that use the JOIN syntax from the original SQL statement, but
these SQL alternatives are simply the original SQL with an Oracle hint applied.
The OUTER JOIN is not including in this conversion because Ansi-92 OUTER JOIN syntax does not always retrieve
the same result set as the OUTER JOIN using the (+) operator. So to avoid producing the wrong result set, the
conversion of the outer join syntax cannot be applied.
For example:
SELECT DPT_ID
FROM EMPLOYEE,
DEPARTMENT
WHERE DPT_ID = EMP_DEPT
Both of the above
Specify to join tables in the FROM clause with or without join type syntax (excluding OUTER JOIN operator).
Hints
Optimization Approaches
The Optimization Approaches hints page under the Optimizer branch of the Options window allows you to decide
which Oracle optimization hints are applied to the original SQL statement and the alternative SQL generated during
the optimization process. The optimization hints are selected from 6 pages: Access Paths Hints, Join Order Hints,
Optimization Approaches Hints, Parallel Execution Hints, Query Transformation Hints, and Other Hints.
By adding hints, the Oracle optimizer can be forced to choose a particular execution plan.
- 60 -
Optimization Approaches
Hint Description
ALL_ROWS The ALL_ROWS hint suggests executing a SQL statement with the objective of
returning all rows as fast as possible.
FIRST_ROWS The FIRST_ROWS hint suggests executing a SQL statement with the objective of
finding the shortest time for the return of the first row from the query.
FIRST_ROWS (N) The FIRST_ROWS(N) hint return the first n rows as fast as possible.
RULE The RULE hint suggests using the rule-based approach even if statistics are
available.
Note: The RULE optimization hint does not retrieve an Oracle Cost value.
CPU _COSTING The CPU_COSTING hint turns CPU costing on for the SQL statement. The Oracle
optimizer estimates the number and type of I/O operations and the number of CPU
cycles that will be performed during execution. System statistics are used to convert
the CPU cycles and I/O operations to the estimated query execution time. The
CPU_COST column of the PLAN_TABLE stores the CPU cost.
NO_CPU _COSTING The NO_CPU_COSTING hint turns off CPU costing for the SQL statement. The Oracle
optimizer uses the I/O cost model, which measures everything in single-block reads
and ignores the CPU cost.
Access Paths
The Access Paths hints page under the Optimizer branch of the Options window allows you to decide which Oracle
optimization hints are applied to the original SQL statement and the alternative SQL generated during the
optimization process. The optimization hints are selected from 6 pages: Access Paths Hints, Join Order Hints,
- 61 -
Access Paths
Hint Description
FULL The FULL hint suggests using a full table scan to access a table.
ROWID The ROWID hint suggests that a table is scanned using the rowid.
CLUSTER The CLUSTER hint suggests that a table is scanned using a cluster scan. This hint is only
useful if you have clustered objects.
HASH The HASH hint suggests that a table is scanned using a hash scan. It is used only if the
tables are stored in a cluster.
INDEX The INDEX hint suggests to use a specific index to access a table.
NO_INDEX The NO_INDEX hint will not use an index scan to access a table.
INDEX_ASC The INDEX_ASC hint suggests to use a specific index to access a table. The index entries
are scanned in ascending order.
INDEX_DESC The INDEX_DESC hint suggests to use a specific index to access a table. The index entries
are scanned in descending order.
INDEX_COMBINE The INDEX_COMBINE hint suggests that a table is accessed using a bitmap access path.
INDEX_JOIN The INDEX_JOIN hint suggests that an index join be used to access a table.
INDEX_FFS The INDEX_FFS hint suggests that a fast full index scan be used to access a table.
NO_INDEX_FFS The NO_INDEX_FFS hint suggests that an index full fast scan not be used.
INDEX_SS The INDEX_SS hint suggests to use an index skip scan.
NO_INDEX_SS The NO_INDEX_SS hint suggests not to use an index skip scan.
INDEX_SS_ASC The INDEX_SS_ASC hint suggests to use an index skip scan in ascending mode.
INDEX_SS_DESC The INDEX_SS_DESC hint suggests to use an index skip scan in descending mode.
- 62 -
Query Transformation
The Query Transformation Hints under the Optimizer branch of the Options window allows you to decide which
optimization hints are applied to the original SQL statement and the alternative SQL generated during the Oracle
Query Transformation
Hint Description
STAR_TRANSFORMATION The STAR_TRANSFORMATION hint forces the Oracle optimizer to use the best
execution plan in which the internal transformation has been used. This hint
can be beneficial when many small tables are joined to a central large table
via single column bitmap indexes.
NO_STAR_TRANSFORMATION Suggests to not use the star query transformation.
USE_CONCAT Suggests that all ORs in the WHERE cause be transferred to a query using
UNION ALL.
NO_EXPAND Suggests not using the OR expansion for SQL statements which have an OR
or IN condition in the WHERE clause.
MERGE Suggests merging a view on a per-query basis so that it will evaluate
complex views or subqueries before the main query.
NO_MERGE Suggests not to merge views specified in the FROM clause.
REWRITE The REWRITE hint enables internal transformation from a SQL statement and
transforms tables or views into a SQL statement accessing one or more
materialized views.
NO_REWRITE Suggests disabling internal SQL rewrites.
FACT Suggests using the specified table as a fact table.
- 63 -
NO_FACT Suggests that the specified table should not be used as a fact table.
NO_QUERY_TRANSFORMATION Prevents the Oracle optimizer from performing query transformations.
UNNEST Suggests that the a subquery be merged into the main portion of a statement
which enables the Oracle optimizer to evaluate the tables in the subquery
along with the tables in the main portion when determining joins and access
paths.
NO_UNNEST Suggests disabling subquery unnesting.
Join Order
The Join Order hints page under the Optimizer branch of the Options window allows you to decide which Oracle
optimization hints are applied to the original SQL statement and the alternative SQL generated during the
Join Order
Hint Description
LEADING Suggests using the specified tables be used first in the join order.
USE_HASH Suggests using a hash join method for joining two tables.
NO_USE_HASH Suggests using some other join method besides a hash join to join for joining two
tables.
USE_MERGE Suggests using sort-merge joins for joining two tables.
NO_USE_MERGE Suggests using some other join method besides a sort-merge join for joining two
tables.
USE_NL Suggests using a nested loops join for joining two tables.
NO_USE_NL Suggests excluding nested loops joins.
- 64 -
USE_NL_WITH_INDEX Suggests using a Use a nested loop join with an index join.
HASH_SJ Suggests using a hash semi-join to access a table in the EXISTS sub-query.
HASH_AJ Suggests using a hash anti-join to access a table for a NOT IN sub-query.
MERGE_SJ The MERGE_SJ hint forces merge semi-join to access a specified table for a
correlated EXISTS sub-query.
MERGE_AJ The MERGE_AJ hint forces merge anti-join to access a specified table for a NOT IN
sub-query.
NL_SJ The NL_SJ hint forces a nested loop anti-join to access a specified table for a
correlated EXISTS sub-query.
NL_AJ The AL_AJ hint forces a nested loop anti-join to access a specified table for a NOT IN
sub-query.
ORDERED The ORDERED hint forces the Oracle optimizer to join tables in the order in which
they appear in the FROM clause.
STAR The STAR hint forces the Oracle optimizer to use nested loop joins to join the largest
table in the SQL statement last. The STAR hint should be applied to SQL statements
with at least 3 tables with the largest table’s concatenated index having at least 3
columns.
Parallel Execution
The Parallel Execution hints page under the Optimizer branch of the Options window allows you to decide which
Parallel Execution
Hint Description
PARALLEL Suggests using parallel processing with the specified number of concurrent servers
(Degree) during an operation.
PARALLEL_INDEX Suggests using parallel processing for a index scan using the specified number of
(Degree) concurrent servers during an operation.
NO_PARALLEL Suggests using serial processing for the execution of this SQL state.
NO_PARALLEL_INDEX Suggests overriding a PARALLEL attribute setting on an index to avoid a parallel index
scan operation.
- 65 -
Other
The Other hints page under the Optimizer branch of the Options window allows you to decide which Oracle
Other
Hint Description
DRIVING_SITE Suggests that the rows retrieved from one table are sent to the remote site to be
joined there and the results are returned to the local site. This hint is only
applicable for distributed SQL statements.
ORDERED_PREDICATES Suggests that the items in the WHERE clause be evaluated in the order they are
presented, except for a predicate that is used as an index key.
CURSOR_SHARING_EXACT If the Oracle CURSOR_SHARING parameter is enabled, this hint will disable it for
the execution of this SQL statement.
PUSH_SUBQ Suggests that, when a subquery is not being joined using the merge join method,
it be evaluated as soon as possible.
PUSH_PRED Pushes the outer join predicate between a table and a view into the view.
NO_PUSH_PRED Prevents pushing the outer join predicate between a table and a view into the
view..
NO_PUSH_SUBQ Suggests that, when a subquery is not being joined using the merge join method,
it be last.
DYNAMIC_SAMPLING Suggests performing a dynamic sampling to provide more accurate estimates of
the cardinality and selectivity of the data.
SPREAD_MIN_ANALYSIS Minimizes the rules' compile time on spreadsheets.
- 66 -
Quota
Quotas are used to control the number of SQL alternatives that are generated by the optimization process since
thousands of alternatives may be generated for a complicated SQL statement.
The first step of the SQL optimization process is to rewrite the syntax of the original SQL statement. The Syntax
transformation quota is applied to this step. Then the Oracle optimization hints are added to the original SQL
statement and the SQL alternatives. The Hints Quota is applied to this second step.
Note: Bear in mind that the higher the quotas, the longer it may take to optimize a complicated SQL statement.
Quota for SQL Alternatives Generated
Syntax transformation quota (Range = 1 to 99,000)

Specify the maximum number of SQL statements generated by applying the syntax transformation rules during the
optimization process. The default quota of 100 (at intelligence level 4) is normally sufficient for most of the
complicated SQL statements. However you can increase the quota to tackle exceptionally complicated SQL
statements with very high levels of table joins or multiple levels of nested subqueries.
This value controls the number of SQL statements that are generated during the process of rewriting the syntax of
the SQL statement.
Hints quota (Range = 1 to 99,999)
Specify the maximum number of SQL statements that may be created when the Oracle optimization hints are
applied. This value determines the number of SQL alternatives that are generated by applying the Oracle hints to
the original SQL and the SQL alternatives that were created by transforming the SQL syntax.
Click here for a detailed explanation of how the hints are applied when a SQL statement contains multiple SELECT
statements.
Total quota
Read-only field that calculates the maximum number of SQL statements generated during optimization. This figure
consists of: Syntax Transformation Quota + Hints Quota.
Number of hints selected
A calculated value indicating the number of hints selected on all the Hints Options pages.
Quota for Rearranging the Driving Path
Table join permutation quota (Range = 50 to 999,999)

Specify the maximum number of table join rearrangements that will be tried in order to find a new table join access
path.
- 67 -
This table order rearrangement is actually one of the rules in the Syntax Transformation rules which are applied in
the first step of the optimization process. The Table join permutation quota is used to control how many SQL
syntax transformations are created using only this one rule. This is to prevent all syntax transformations from
being created using only this one rule.
If you use 2 tables in a SQL statement, there are 2 ways you can join the tables. If you use 3 tables, the number of
ways you can join the tables is 3! (3*2*1) or 6 ways, which means the optimization process could generate 6 SQL
statements.
If you have 6 tables using 6! which is 720, the optimization process could generate 720 SQL statements using this
one syntax transformation rule. If the quota for SQL syntax (the Syntax transformation quota) is 100, then you can
see that one rule which could generate 720 statements could use up the entire quota. The SQL Optimizer Engine
has more than 60 other rules to apply to the original SQL statement to find alternative ways to write syntax. So,
the Table join permutation quota limits the number of attempts that the SQL Optimizer Engine will try to find a
driving path by rearranging the order in which the tables are joined.
Hints Quota Explanation
After the syntax of a SQL statement is transformed during the optimization process, the Oracle optimization hints
are applied to the original SQL statement and the SQL alternatives. When a SQL statement has several SELECT
statements contained within it, the hints are applied in the following manner.
For a SQL statement with multiple SELECTs such as this one:
SELECT *
FROM DEPARTMENT
WHERE DPT_ID IN (SELECT EMP_DEPT
FROM EMPLOYEE
WHERE EMP_ID > @emp_id)
AND exists (SELECT *
FROM EMPLOYEE E
WHERE NOT EXISTS (SELECT 'X'
FROM EMP_SMALL S
WHERE S.EMP_ID = E.EMP_ID))
AND DPT_MANAGER IN (73716, 73745, 76777)
The hints are applied in a manner like this:
First Transformation
SELECT /*+ First Rows*/ *
&ldots;IN (SELECT &ldots;
&ldots; (SELECT 'X' &ldots;))
Second Transformation
&ldots;IN (SELECT /*+ First Rows*/ &ldots;
Third Transformation
- 68 -

AND exists (SELECT /*+ First Rows*/ *
Fourth Transformation
&ldots; (SELECT/*+ First Rows*/ 'X' &ldots;))
Fifth Transformation
&ldots;IN (SELECT /*+ First Rows*/ &ldots;
AND exists (SELECT /*+ First Rows*/ *
The SQL Optimizer tries every possible combination of the first hint, in this case /*+ First Rows*/. In this example,
there are 15 different transformations using only the first hint. Then it moves on to the second hint. It applies the
first hint to one SELECT and the second hint to another SELECT and so one until it tries every possible combination
of applying all the selected hints or it has reached the Quota. This method requires a large Hints Quota if you
would like the optimization process to apply several of the Oracle optimization hints when there are multiple
SELECT statements in one SQL statement.
Index Expert
Index Expert Settings
The Index Expert settings on the Options window consist of 3 pages that allow you to select the level of index
generation intelligence for creating indexes and index types while using the Index Expert.
Settings include:
Intelligence
Options
Index Type
- 69 -
Intelligence (Index Expert)
The Index Expert Intelligence settings enables you to either customize all the index generate settings used during
creation of index candidates in the Tuning Lab or allows you to select the predefined levels for these settings.
Intelligence Level
Custom
Use Custom to enable you to select the individual settings on the Index Options page.
Predefine
Use Predefined to enable you to select an Intelligence Level which has all the index generation settings preselected
for you. The Index Options page will change according to the level selected. Levels range from 0 to 10. The higher
the level the more intelligent the Index Expert is and the more likely that you will find a better index
recommendation.
The Index Type page settings can be adjusted independent from the Intelligence Level.
- 70 -
Options
The Options settings for the Index Expert allows you to select index options used when generating index
alternatives. Some of these options are also used by Global Indexing.
Index Expert Options
Retrieve index selectivity by using

Sampling Block with maximum size (Range = 10 to 99999)
Specify the Sample Block size used to estimate the selectivity of the data for a potential index. This value is
used if you are connect to Oracle 9i or higher.
or maximum number of records (if Sample Block not available) (Range = 10 to 99999)
Specify the number of records used for the estimate of the selectivity of the data only if Oracle Sample Block
command is unavailable. This value is used if you are connected to Oracle 8i or earlier since in these version
of Oracle the Sample Block command is not available.
Maximum number of columns in a composite index (Range 1 to 30)
Specify the maximum number of columns that may be used in a composite index.
Maximum number of indexes in an index set (Range 1 to 99)
Specify the maximum number of indexes that the index generation process will include in one Index Set.
- 71 -
Automatically enforce cost based index simulation when statistics are not collected
Using ALL_ROWS
Using FIRST_ROWS
Specify whether to force cost-based index simulation when statistics are not available on a table. You can
select that the Oracle ALL_ROWS and FIRST_ROWS hints added to the original SQL statement to force the
use of the cost-based optimizer.
Important Note: The Oracle virtual index function used by the Index Expert is only available for the cost-
based optimizer. Therefore, if your original SQL statement uses the rule-based optimizer, the index
generation process must force it to use the cost-based optimizer in order for the Index Expert to be able to
generate index candidates for the SQL statement. In this case, you need to take into consideration that the
virtual execution plans that are generated for each index set will naturally be different from the actual
execution plan retrieved if you actually created these indexes and executed the SQL statement using the
rule-based optimizer.
Eliminate index sets which produce similar execution plan with the same cost
Specify whether to eliminate similar execution plan which has the exact same Oracle cost. Similar execution plans
are plans with the same structure and cost. Selecting this option will possibly reduce the number of Index Sets
generated.
Evaluate columns in SELECT list
Specify whether to consider creating an index on the columns specified in the SELECT list.
Quota
Index Generation Quota

Specify the maximum number of individual indexes generated.
Index Set Generation Quota
Specify the maximum number of Index Sets generated by combining 1 or more individual indexes into sets.
Index prefix
Default prefix of index name (Default: QUEST_SX_IDX)

Specify the prefix that is placed on the index name when the Index Expert generates index candidates.
- 72 -
Index Type
The Index Type settings for the Index Expert allows you to select the index type. Some of these options are also
used by Global Indexing.
Index Type
B-Tree index (Default = checked)

Specify whether to generate an index candidate that is a B-Tree index.
Bitmap index (Default = unchecked)
Specify whether to generate an index candidate that is a bitmap index.
Parallel Degree: (Default = unchecked) (Range 1 to 64)
Specify whether to generate an index candidate that is parallelized and also specify the degree for the parallel
index.
Key-Compressed for B-Tree index when selectivity is less than or equal to (0.001 - 1) (Default =
unchecked) (Range 0.001 to 1)
Specify whether to key-compress a B-Tree index candidate when the selectivity of the data is less than or equal to
the amount you specify.
Execution Plan
Retrieve execution plan upon run time (Default = checked)

Specify whether to retrieve the execution plan when creating the Index Set on the database and retrieving the run
time of the SQL statement. This can be done so that the "actual" execution plan and be compared to the "virtual"
plan.
- 73 -
Best Practices
Best Practices Settings
The Best Practices module in the Tuning Lab reviews the tables, indexes, database statistics, and the execution
plan used in your original SQL statement and provides recommendations. By default, this is not displayed in the
Tuning Lab. You can select to display this module from the Best Practices General option page.
Some of the recommendations are based on the values in Best Practices option settings.
The Option settings include:
General
Table
Index
Statistics
Plan
Note: If the Best Practices function is taking a long time to complete, you can set one or more of these option
settings to speed up the process.
Type Option Setting

Table Check for chained rows Ignore
Index Determine Selectivity when there are no statistics Ignore
Index Compute selectivity by sampling(%) 0.0001%
Index Determine if index tree is unbalanced Ignore
General (Best Practices)
Include Best Practices module in Tuning Lab

Specify to show the Best Practices module in the Tuning Lab window. By default, the Best Practices module is not
displayed.
Note: The current plan is to remove the Best Practices module from Quest SQL Optimizer for Oracle in the next
release.
- 74 -
Table
The Best Practices module in the Tuning Lab reviews the tables used in your original SQL statement and provides
recommendations for improving SQL performance. Some of these recommendations are based on the values in
these option settings.
Table
Check for chained rows: (Default = Ignore)

Specify to check the table for chained rows.
Note: For a large table, checking for chained rows make take a while to complete.
Ratio of the smallest partition to the largest partition is less than (%): (Default = 40, Range 1 to
99,999)
Specify the percentage value for how much smaller one partition in a table is in comparison to the largest partition.
The value is used to determine when you should consider changing the partitioning range setting.
Consider partitioning table when size greater than (GB): (Default = 2, Range 1 to 99,999)
Specify the size in gigabits that a table reaches when you should consider partitioning the table.
Consider rebuilding table if table has more extents than: (Default = 10, Range 1 to 99,999)
Specify the number of extents a table can have before you should consider rebuilding the table.
Index
The Best Practices module in the Tuning Lab reviews the indexes on the tables used in your original SQL statement
and provides recommendations for improving SQL performance. Some of these recommendations are based on the
values in these option settings.
- 75 -
Index
Consider rebuilding index if % of deleted rows in index is more than (%): (Default = 20, Range 1 to
100)
Specify the percentage of rows that have been deleted to the total number of rows in an index when you should
consider rebuilding the index.
Consider re-creating or rebuilding index if the index has more extents than: (Default = 10, Range 1 to
99,999)
Specify the number of extents an index can have before you should consider rebuilding the index.
Determine selectivity when there are no statistics: (Default = Compute)
Select one of the followin76g:
Options Description
Compute Specify to calculate the selectivity of the index only when the index does not have statistics. If
the index has statistics, than the value from the statistics is used.
Compute All Specify to calculate the selectivity for all indexes even if an index has statistics.
Note: This option may take some time as the selectivity value is calculated for every index.
Ignore Specify to skip an index that does not have statistics and consequently, you will not be warned
when the selectivity of the index is low. If the index has statistics, than the value from the
statistics is used.
Warning when selectivity for the index is less than (%): (Default = 20, Range 1 to 100)
Specify the percentage for the selectivity of the index when you should consider disabling the index for a SQL
statement so that SQL statement will be executed using a full table scan instead of using the index.
Compute selectivity by sampling (%): (Default = 0.10, Range 0.0001 to 99.99)
Specify the percentage of the data that will be used to calculate the selectivity when you have selected the
Compute or Compute all option to determine the selectivity. This option is used when you are connected to
Oracle 9i and later. It uses the SAMPLE BLOCK clause to determine the selectivity: SELECT * FROM TABLE SAMPLE
BLOCK n. With this clause, only part of the table is scanned to calculated the selectivity for the index.
For 8i and below, the selectivity is calculated by sending a "SELECT COUNT(*)..." to the database.
The selectivity is calculated using the following formula:
Selectivity=count(unique values of a column) / count(all values of a column) * 100%
Note: If the table has a large number of rows, this action will take a while to complete.
Determine if index tree is unbalanced (Default = Ignore)
Specify to check an index to see if the tree is unbalanced, or in other words if one branch has more nodes than
another branch. When the index tree is unbalanced, an index scan will take longer.
Balanced Index Tree Unbalanced Index Tree

Note: Checking the index to see if the tree is unbalance may take a while to complete.
- 76 -
Statistics
The Best Practices module in the Tuning Lab reviews the statistics for the tables and indexes used in your original
SQL statement and provides recommendations for improving SQL performance. Some of these recommendations
are based on the values in this option setting.
Statistics
Warning for stale statistics when data changes are greater than (%): (Default = 10, Range 1 to 100)
Specify what percentage of the data in a table must have been modified since the last time the statistics were
updated in order to receive a message that the statistics may need to update again.
Plan
The Best Practices module in the Tuning Lab reviews the execution plan for your original SQL statement and
provides recommendations for improving SQL performance. Some of these recommendations are based on the
values in these option settings.
Plan
Threshold for small table with full table scan when it has fewer blocks than: (Default 10, Range 1 to
99,999)
Specify your definition for the size of a small table by entering the number of blocks in the table. This is the table
size when you would consider keeping a small table in cache. This message will appear when a table is less than or
equal to the value you specify.
Warning for large table with full table scan when it has more blocks than: (Default 200, Range 1 to
99,999)
Specify your definition for a large table by entering the number of blocks in the table. This is the table size when
you would consider optimizing a SQL statement that is doing a full table scan. This message will appear when a
table is greater than or equal to the value you specify and a TABLE ACCESS FULL operation is found in the
execution plan of the SQL statement.
- 77 -
Execution
Execution Criteria
The Execution Criteria page under the Tuning Lab allows you to select the options when executing the SQL
alternatives and index sets.
Run Time Retrieval Method
Retrieve run time executing

Caching the data, the indexes, and the SQL statement can affect the comparison times if one SQL statement does
the caching and others do not. Therefore, the following options are available so that you can select the one that
provides you with the most accurate comparison of the run times.
Original SQL twice using second run time and all others once (Default)
The first time you access data from a table, the data is cached into memory. This process takes a few
moments. The next time you access that data, it is already in memory. Therefore, the first SQL statement
will have the additional time it takes to cache the data included in the run time whereas the following SQL
statements do not have the additional time included in their run time. So to have a comparable test, the first
SQL is run twice and the time from the second run is compared to the time from the other statements which
are run once. It this case, all SQL statements are executed with the data cached.
For fast running SQL statements, executing all SQL statements twice enables you to eliminate two caching
factor that can affect the accuracy of the comparison results: caching the SQL statement and caching the
indexes. If some SQL statements have been recently executed, then the SQL information for those
statements is likely to be resident in the cache and the statements may execute faster because the SQL
- 78 -
statement does not need to be cached. Also, if some of the SQL statements use different indexes, one index
may be resident in the cache and the other may not. So running the SQL statements twice, makes sure that
each index is cached.
This option eliminates time variation caused by caching since it runs all SQL statements twice, throws out the
first execution time when the caching would occur and uses the second run time when all SQL statements
and indexes should have the necessary items in the cache. Consequently, the time to cache has been
eliminated and you get a more accurate comparison of the run time of each alternative SQL statement.
All SQL once
For long running SQL, there is no need to run any statement twice since the effect from caching is diminished
over time.
Best SQL Alternative Selection Criteria
Best alternative selected based on lowest

The best SQL alternative or best index set is selected after the SQL alternatives or index sets are testing. The best
SQL alternative or index set is displayed in the Resolution layout. You select the run time statistic to use as the
criteria to select the SQL alternative or index set that provides the best performance. This statistic is also charted
in the Optimize:statistic column in the Scenario Explorer. This can help you quickly find the SQL statements that
help to reduce the use of a specific system resource.
Total elapsed time (Default)
Specify to use the total elapsed run time as criteria for selecting the best SQL alternative or best index set.
This is the sum of the First Rows Elapsed time and the Last Rows Elapsed time.
First row elapsed time
Specify to use the time it takes to retrieve the first record as criteria for selecting the best SQL alternative or
best index set.
Last row elapsed time
Specify to use the time it takes to retrieve the second through the last record as criteria for selecting the best
SQL alternative or best index set.
Logical reads
Specify to use the logical reads as criteria for selecting the best SQL alternative or best index set.
Physical reads
Specify to use the physical reads as criteria for selecting the best SQL alternative or best index set.
CPU time
Specify to use the execution CPU time as criteria for selecting the best SQL alternative or best index set.
SQL Termination Criteria
Cancel execution by the fastest SQL run time (Default)

Cancels SQL statements that run longer than the current best run time. With this option, the first SQL statement is
run and the time from that statement is used as the termination time. When a SQL statement runs faster than this
time, the faster time is used as the new termination time. So you are always using the current fastest run time as
the termination time for the next SQL statement.
Cancel execution at this percentage of the original SQL run time (Range 1 to 32,767)
Cancels SQL statements whose total elapsed time is the specified % of the total elapsed time for the original SQL
statement. It terminates all SQL statements that run past the calculated termination time. The default value is 100.
Cancel execution by the user defined time (mins/secs)
Cancels SQL statements that run longer than a specified time. If your original statement takes a long time to
execute and there are many alternative statements, executing all statements may take considerable time. In that
event, consider setting an aggressive user defined termination time. If the original SQL takes 1 hour, try a 5
minute termination time. If no alternative statements execute in under that period, raise the termination time to
10 minutes, etc.
- 79 -
Run selected scenarios without termination

Retrieves the run time of the SQL statements without any termination criteria. All SQL statements run to
completion.
Cancelation delay (seconds) (Range 2 to 10,000, Default = 5)
Specify the value for the number of seconds that will be added to the termination time. It is important to
factor a delay into the overall termination time for the time needed for sending the SQL statement to the
database server from the client before the SQL statement starts to run. The default value is 2.
Show canceled scenarios (Default = checked)
Specify whether to remove all SQL statements from the Scenario Explorer window whose execution was terminated
because they exceeded the termination time.
Retrieve statistics for canceled scenarios (Default = unchecked)
Specify to show the statistics for a SQL statement when the execution was aborted.
Show scenarios that return a different result set (Default = checked)
Specify whether to remove all SQL statements from the Scenario Explorer window that return a different result set
from the original SQL statement.
Execution Method
The Execution Method page under the Tuning Lab allows you to select the options when executing the SQL
Execution Method
Run on server (Default)

Specify to execute all SQL statements on the server and to not return the data from the SELECT statements to the
client. Executing the SQL statements under this option provides you with the run time on the CPU for the SQL
statement. Your logon account must have the SYS.DBMS_SQL package privilege to retrieve the run time from the
server.
an alternative SQL statement is the same as the original SQL statement. When you select the Run on Server
option, the comparison made between the original SQL statement and the SQL alternatives is the number of rows
returned. No comparison of the result data is performed.
Run on client
Specify to execute the SQL statement and return the data to the client. Executing the SQL statement under this
option provides you with the run time that includes the time it takes to transfer the data to the client computer.
- 80 -
an alternative SQL statement is the same as the original SQL statement. When you select the Run on Client
option, the comparison is done between the hash values of the data. To compare the result set of the original and
alternative SQL statements, each row of the result set is hashed and then the hash values are stored in the
memory of the client computer to compare the hash results of the original SQL statement with the hash results of
the SQL alternatives. The data is not stored in memory nor on the disk drive of the client computer.
Limit rows retrieved to (Default = unchecked) (Default = 100, Range 100 to 32,767)
Specify the number of rows you want retrieved during the execution. The default value is 100.
Important Note: If you enable this feature, remember that this is not comparing the way the SQL
statement is actually being executed in the application since you are not retrieving all of the data. It is good
only for a quick test. The execution results may be different when you retrieve all the records.
Number of rows returned in a single network transfer (Default = 1000, Range 25 to 32,767)
Specify the number of rows that will be retrieved at one time when fetching the data from the server.
Multi-Execute
Number of time to execute each scenario (Default = 2)

Specify the number of times you want the selected SQL statements executed when you execute using the Multi-
Execute option. This option provides the most accurate run time comparison for SQL statements with very short
run times, mainly those running in milliseconds. The elapsed run time of a SQL statement that run in milliseconds
can easily be skewed by other activity running on the CPU at the same time since the run time is calculated from
the clock time when the SQL statement starts to run until the clock time when it finishes. With this option, the SQL
statement is run multiple times and run time is calculated as the average elapsed run time of all the executions.
Include trace statistics (Default = unchecked)
Specify to retrieve the run time statistics from the Oracle trace log during the execution of the SQL statement. This
captures detailed statistics from the Oracle trace log files from the server and transfers them to the PC.
When you are executing a SQL statement several time, it transfers the statistics for each execution. Therefore,
including the statistics from the Oracle trace log will add to the amount of time it takes to test because the trace
log statistics are retrieved for each execution.
In order to retrieve the statistics from the Oracle trace log, you must have selected an access method in the Trace
Setup Options.
- 81 -
Auto Execution
The Auto Execution page under the Tuning Lab allows you to select the options used when executing the SQL
Auto Select SQL Rewrites for Execution
No pre-selected SQL after optimization is finished

Specify that no SQL statements are automatically selected in the Scenario Explorer after the optimization process is
finished.
Pre-select ALL rewrites
Specify to select all the alternative SQL statements after the optimization process is finished. An x is placed in the
box to the left of all alternative SQL statements in the Scenario Explorer window.
Pre-select ONLY rewrites if cost is no higher than this number of times over the original (Default)
Specify to select only the alternative SQL statements that have an Oracle cost estimation which is less than the
specified % of the Oracle cost of the original SQL statement. An x is placed in the box to the left of the selected
alternative SQL statements in the Scenario Explorer window.
Auto Select Index Sets for Execution
No pre-selected index sets after index generation (Default)

Specify that no index sets are automatically selected in the Scenario Explorer after the index generation process is
finished.
- 82 -
Pre-select ALL index sets

Specify to select all the index sets after the index generation process is finished. An x is placed in the box to the
left of each index set in the Scenario Explorer window.
Pre-select ONLY index sets if cost is no higher than this number of times over the original
Specify to select only the index sets that have an Oracle cost estimation which is less than the specified % of the
Oracle cost of the original SQL statement. This Oracle cost is taken from the virtual execution plan for the SQL
statement using the virtual indexes. An x is placed in the box to the left of the selected index sets in the Scenario
Explorer window.
Auto Execution
Automatically execute selected rewrites after optimization (Default = unchecked)

Specify to automatically execute all the SQL statements that are selected at the end of the optimization process.
Automatically create selected index sets and execute SQL statement after index generation (Default =
unchecked)
Specify to start a process to create each set of indexes, run the SQL statement, and drop the indexes as soon as
the generation of indexes is finished for all selected index sets.
Memory Thresholds
The chart below these options shows the current memory usage on your client computer and the values that you
select for these options.
• Stop optimization if memory exceeds (%) (Default = 85, Range 17 to 100)

Specify to stop the optimization process if memory usage exceeds the specified percent of the memory on
your computer.
• Stop all processing if memory exceeds (%) (Default = 85, Range 17 to 100))
Specify to stop all operations in the Tuning Lab (SQL Optimizer, Index Expert, Deploy Outlines, and Best
Practices) if the memory usage exceeds the specified percent of the memory on your computer.
Global Indexing Options
The options for executing SQL statements are shared between the Tuning Lab and Global Indexing. The execution
settings for Global Indexing are found under the Tuning Lab Execution Criteria and Execution Method options.
Some of the options for generating indexes are shared between the Tuning Lab/Index Expert and Global Indexing.
These settings are found under the Tuning Lab/Index Expert Options and Index Type.
- 83 -
Index Analyzer Options
The Impact Analyzer page in the Options window allows you to select the language for the data in the database for
the Impact Analyzer module.
Character Set
Character set
Specify the language set that is used to enter and display the SQL text and the data from the database. This
setting does not affect the language of the program interface. It is always in English.
Outlines Options
General
Show Outline Manager

Specify to display the Outline tab so that you can use the Outline Manager module.
Note: The current plan is to remove the Outline Manager module from Quest SQL Optimizer for Oracle in the next
release.
- 84 -

QuestSQLOptimizerForOracle UserGuide PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

QuestSQLOptimizerForOracle UserGuide PDF

Загружено:

Авторское право:

Доступные форматы

7.4.

ALL RIGHTS RESERVED.

Quest Software World Headquarters

Web site: www.quest.com

About Quest Software

Contact Quest Support

Quest SQL Optimizer Overview

Tuning Lab - SQL Optimizer

Tuning Lab - Find Best SQL Alternative

Tuning Lab - Deploy Outline

Tuning Lab - Index Expert

Tuning Lab - Find Best Index Alternative

Tuning Lab - Best Practices

Best Practices proposes common techniques to improve performance on your database.

Test for Scalability

Performance Assurance Process

4. Improve SQL coding skills and optimization knowledge

5. Replace poor performing SQL

6. Generate index alternatives

7. Predict and track changes to performance

8. Improve Vendor Applications

Module Functionality Privilege

Global Indexing Generate Virtual Indexes Oracle 8i or above is required.

SYS.DBA_OUTLINES and SYS.DBA_OUTLINE_HINTS

ALTER SYSTEM is needed to enable a stored outline

Batch Optimizer Overview

Add Jobs to a Batch

Generate Optimized Script

Selecting Best Alternative Options

Batch Optimizer Tutorial

e. Click Add and select the files you want to scan.

o. From the Available Inspectors box, select an Inspector job.

SQL Scanner Overview

• Sending a SQL statement to the Tuning Lab for optimization.

SQL Scanner Tutorial

2. In the Group list, click

d. Click Add and select the files you want to scan.

6. Click Scan and select Scan All.

of Optimize in Batch and select Optimize in Tuning Lab to copy the

select the arrow to the right of Send to Global Indexing .

SGA Inspector Overview

SGA Inspector Tutorial

Retrieve previously executed SQL statements from Oracle SQL Area

2. In the Group list, click

window, which also displays the in the left grid border.

Retrieve currently running SQL statements

2. In the Group list,

10. Click Inspect to start the collecting process.

Tuning Lab Overview

Find Best SQL Alternative

Find Best Index Alternative

Components of the Tuning Lab

The Tuning Lab contains the following parts:

SQL Optimizer Overview

SQL Syntax Transformation

WHERE table_b.key = table_a.key)

Applying Oracle Hints

Eliminating Duplicate Execution Plan

Testing for Best Alternative

Intelligence Level Settings

Create Your Own Alternative SQL

SQL Optimizer Tutorial

1. Click the Tuning Lab tab.