PERFORMANCE EVALUATION OF ORACLE PARALLEL EXECUTION
Pramukh Narayan Rao Jadhav
B.E, Visveswaraiah Technological University, India, 2006
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
SPRING
2011
PERFORMANCE EVALUATION OF ORACLE PARALLEL EXECUTION
A Project
by
Pramukh Narayan Rao Jadhav
Approved by:
__________________________________, Committee Chair
William J. Mitchell, Ph.D
__________________________________, Second Reader
Ying Jin, Ph.D
____________________________
Date
ii
Student: Pramukh Narayan Rao Jadhav
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit is to
be awarded for the Project.
__________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D
Department of Computer Science
iii
________________
Date
Abstract
of
PERFORMANCE EVALUATION OF ORACLE PARALLEL EXECUTION
by
Pramukh Narayan Rao Jadhav
To utilize the vast number of resources like multi-processors and large amount of
memory that are available with the new age computers, Oracle has come out with Oracle
Parallel Execution that enables to enhance the performance of queries by reducing the
execution time and cost of execution.
In this project, we will explain the types of queries that are eligible to be executed in a
parallel order and analyze the enhancement in the performance of running these queries
as compared to running them in a serial order. We will be using Oracle 11g RDBMS and
associated tools to gather and analyze data.
We will be using Oracle's Explain Plan utility to gather data about the execution plan
used during the execution of the query and TKPROF to calculate the execution time,
count the reads and writes, paging and the other resources used during the execution.
In this project we will also see how tuning certain system parameters can further enhance
the performance of parallel query execution.
To estimate the performance of Oracle’s Parallel Execution feature, we will compare the
performance of executing certain SQL statements using parallel execution versus the
same statements run in serial order. By optimizing query construction and by tuning the
iv
oracle database to facilitate for maximum utilization of the available resources, we can
achieve a high degree performance enhancement both in execution time and in cost of
execution.
_______________________, Committee Chair
William J. Mitchell, Ph.D
_______________________
Date
v
ACKNOWLEDGMENTS
Appreciation is due to many people who have helped, often without knowing they were
doing so, for inspiration, exhortation, and consolation throughout the time it has taken to create
this work. Although the list of individuals I wish to thank extends beyond the limits, I am
thankful to Dr. William J. Mitchell, with the Department of Computer Science, California State
University, Sacramento, for giving me the opportunity and guiding me throughout the project. I
wish to thank Dr. Ying Jin for being the Second Reader. I also thank Dr. Nikrouz Faroughi for
his ideas and suggestions during the course of the project. I would personally like to thank my
friends, Pradeep Manjuraj, Shashi Kumar, Chetan Krishna, Chandrashekar Madalli, Deepak
Gujjar, Shreyas, Swetha Raghavendra and Pooja Ramesh for their invaluable support and
friendship that helped to get through some of the tough times.
I would like to take this opportunity to thank my parents, Mr. R. Narayan Rao Jadhav and Smt.
Shashikala for their undying support in all aspects of life during the course of my studies. They
were instrumental in driving my goals and help me achieve my dream for being a Master of
Computer Science. I would also like to thank my younger brother Mr. Prabath Jadhav for his
valuable thoughts and comments.
vi
TABLE OF CONTENTS
Page
Acknowledgements ........................................................................................................ vi
List of Tables .................................................................................................................. x
List of Figures ................................................................................................................ xi
Chapter
1. INTRODUCTION ...................................................................................................... 1
1.1 Operations that can be parallelized ................................................................... 1
1.2 Kinds of parallel implementations .................................................................... 2
1.3 How parallel execution works .......................................................................... 3
1.4 When not to use Parallel Execution .................................................................. 5
1.5 Query Optimizer ............................................................................................... 6
1.5.1 Cost Based Optimization (CBO) ..................................................... 6
1.5.2 Rule Based Optimization (RBO)..................................................... 7
2. BACKGROUND ........................................................................................................ 9
2.1 Purpose and Scope ............................................................................................ 9
2.2 Explain Plan .................................................................................................... 10
2.2.1 Syntax for Explain Plan................................................................. 11
2.2.2 Explain Plan for Parallel Processing ............................................. 11
2.2.3 Factors for Cost calculation in a Query Execution Plan ............... 13
2.3 SQL Trace and TKProf utility ........................................................................ 13
2.3.1 How to use SQL Trace and TKProf .............................................. 13
vii
2.3.2 Understanding TKProf Output file................................................ 16
3. DATA MODEL & CONFIGURATION .................................................................. 20
3.1 System Configuration ..................................................................................... 22
3.2 Oracle Configuration Parameters for Parallel Execution................................ 22
3.2.1 Parallel_execution_message_size ................................................. 22
3.2.2 Parallel_execution_message_size ................................................. 23
3.2.3 Parallel_automatic_tuning ............................................................. 24
3.2.4 Parallel_max_servers .................................................................... 24
3.2.5 Parallel_min_percent ..................................................................... 24
3.2.6 Parallel_min_servers ..................................................................... 24
3.2.7 Parallel_threads_per_cpu .............................................................. 25
3.3 Hints ................................................................................................................ 25
3.4 Speedup and Efficiency .................................................................................. 27
4. PERFORMANCE OF PARALLEL QUERY – SELECT & PROJECT .................. 29
4.1 Purpose............................................................................................................ 29
4.2 Preparation ...................................................................................................... 29
4.3 Findings........................................................................................................... 31
5. PERFORMANCE OF PARALLEL QUERY - JOIN OPERATION ....................... 33
5.1 Introduction ..................................................................................................... 33
5.2 Preparation ...................................................................................................... 33
5.3 Results ............................................................................................................. 36
viii
6. PERFORMANCE OF PARALLEL DML - UPDATE OPERATION ..................... 38
6.1 Purpose............................................................................................................ 38
6.2 Preparation ...................................................................................................... 38
6.3 Results ............................................................................................................. 41
7. PERFORMANCE OF PARALLEL SQL RUN CONCURRENTLY ...................... 43
7.1 Purpose............................................................................................................ 43
7.2 Serial Update and Serial Select Statement Executed Concurrently ................ 43
7.3 Parallel Update and Parallel Select statement Executed Concurrently ........... 45
7.4 Results ............................................................................................................. 46
8. SUMMARY AND FUTURE WORK ...................................................................... 48
Appendix A. Oracle Initialization Parameters .............................................................. 49
Appendix B. Execution Statistics for Select & Project Query ..................................... 57
Appendix C. Execution Statistics for Join Operation ................................................... 66
Appendix D. Execution Statistics for Parallel DML – UNION Operation .................. 73
Appendix E. Execution Statistics Concurrent Executions ............................................ 80
Bibliography ................................................................................................................. 93
ix
LIST OF TABLES
Page
1.
Table 1 : Parameters for SQL Trace and TKProf ..................................................... 14
2.
Table 2 : System Configuration ................................................................................ 22
3.
Table 3 : Parallel Query Initialization Parameters .................................................... 22
4.
Table 4: Oracle 11g Initialization Parameters .......................................................... 49
5.
Table 5: Oracle 11g Initialization Parameters (Cont'd) ............................................ 50
6.
Table 6: Oracle 11g Initialization Parameters (Cont’d) ............................................ 51
7.
Table 7: Oracle 11g Initialization Parameters (Cont'd) ............................................ 52
8.
Table 8: Oracle 11g Initialization Parameters (Cont'd) ............................................ 53
9.
Table 9: Oracle 11g Initialization Parameters (Cont'd) ............................................ 54
10. Table 10: Oracle 11g Initialization Parameters (Cont'd) .......................................... 55
11. Table 11: Oracle 11g Initialization Parameters (Cont'd) .......................................... 56
x
LIST OF FIGURES
Page
1.
Figure 1: Select All from Employee and Department Tables. .................................... 4
2.
Figure 2: Query Execution Plan .................................................................................. 5
3.
Figure 3: Parallel Consumer and Parallel Producer .................................................. 12
4.
Figure 4: SQL Trace to Select Employees with Salary > 65000 .............................. 16
5.
Figure 5 : Example of TKProf Header ...................................................................... 16
6.
Figure 6: Example of TKProf Body.......................................................................... 17
7.
Figure 7 : Example of TKProf Summary .................................................................. 19
8.
Figure 8 : ER Diagram of the Employee Database ................................................... 20
9.
Figure 9 : ER Diagram for SH Database .................................................................. 21
10. Figure 10: Max and Average Salary of Employees Without Parallel ....................... 29
11. Figure 11: Explain Plan for Serial Execution .......................................................... 30
12. Figure 12 : Max and Average Salaries of Employees With Parallel Hint ................ 30
13. Figure 13: Explain Plan for Parallel Execution ........................................................ 31
14. Figure 14 : List Customers who Purchased for Amounts > 50 Without Parallel ..... 33
15. Figure 15: Customers who Purchased for Amounts > 50 Using Parallel Hint ......... 34
16. Figure 16: Serial Execution Elapsed Times .............................................................. 35
17. Figure 17: Parallel Execution Elapsed Times ........................................................... 35
18. Figure 18: Update Statement Without Parallel ......................................................... 39
19. Figure 19: Update Statement With Parallel Execution ............................................. 39
20. Figure 20: Elapsed Time for Update Query Without Parallel .................................. 40
xi
21. Figure 21: Elapsed Time for Update Query With Parallel ....................................... 40
22. Figure 22: Serial Update ........................................................................................... 43
23. Figure 23: Select Statement Without Parallel ........................................................... 43
24. Figure 24: Elapsed Time for Serial Update .............................................................. 44
25. Figure 25 : Elapsed time for Serial Select statement ................................................ 44
26. Figure 26 : Parallel Update ....................................................................................... 45
27. Figure 27: Select Statement With Parallel Clause .................................................... 45
28. Figure 28 : Execution Time of Parallel Update ........................................................ 46
29. Figure 29 : Elapsed Time for Parallel Select ............................................................ 46
xii
1
Chapter 1
INTRODUCTION
Oracle Parallel Execution refers to the process of dividing a large SQL query into chunks
of manageable smaller queries and then working on each of these smaller queries in
parallel, simultaneously. This is also known as Intra-query parallelism. The goals of
using Oracle’s Parallel Query feature are to primarily reduce the execution time of these
large queries, and secondarily, do so with optimal cost. As we will detail later, these
goals are inherently conflicting and therefore execution time reduction is the greatest
priority.
Oracle Parallel Execution improves performance for many SQL operations, including [1]:

Queries

Creation of large indexes

Bulk inserts, updates, and deletes

Aggregations
1.1 Operations that can be parallelized
There are many ways in which performance of a SQL statement can be improved, two of
which are using Indexes on tables and Partitioned Tables [1]. We will be referring to
these two methods as we go further into this thesis.
On creating an Index on a field in the table, oracle creates another data structure that
holds the pair of values, the value of the field and a pointer or a reference to the record it
relates to. Hence, when a record is searched, the index is looked up and is taken to the
2
actual record being searched based on the pointer field, thereby reducing the time to
search for a record.
The approach of partitioned tables, as the name suggests involves the partitioning of a
large table into smaller objects referred to as “partitions”. It allows for easy achieving of
data as well as provide for faster access. Oracle employs a method called pruning where
oracle queries the data dictionary to determine the contents of a given partition without
having to actually search through the partition’s data [2].
Any operation that involves a full table scan or scanning an entire partition can be
parallelized using the Oracle Parallel Query operation. These operations include [3]:

SQL queries requiring at least one full table scan or queries involving an index
range scan spanning multiple partitions.

Operations such as creating or rebuilding an index or rebuilding one or more
partitions of an index.

Partition operations such as moving or splitting partitions

CREATE TABLE AS SELECT operations, if the SELECT involves
a full table or partition scan.

INSERT INTO . . . SELECT operations, if the SELECT involves a full table scan.
Update and delete operations on partitioned tables
1.2 Kinds of parallel implementations
Parallel Query: This is the most widely used parallel execution feature that involves
parallel execution of large queries, in the event that the query requires a full-table scan of
3
a significantly large table. Parallel Execution of such queries can vastly reduce the
execution time.
Parallel DML: Using the Oracle’s Parallel Execution feature, Data Manipulation
Language (DML) operations such as INSERT, DELETE and UPDATE statements, can
be executed quicker when compared to the execution of these statements in a Serial
fashion [4]. This is highly advantageous when there is a need for running batch jobs and
in Data Warehousing applications that require the maintenance of large summary or
historical data.
Parallel DDL: Data Definition Language (DDL) statements for both Tables and Indexes,
can also take advantage of the Oracle Parallel Execution feature to reduce execution time
and costs, whether they are using partitioned tables/indexes or non-partitioned
tables/indexes [5].
1.3 How parallel execution works
As we move forward in this paper, we will be referring to Parallel Execution as “PX”, as
it is a standard abbreviation used in Oracle 11g. During Oracle’s 9i and 10g releases, it
used to be referred to as “PS”.
Parallel Execution consists of breaking up of large operations into smaller simpler
operations that take less time for execution.
Oracle re-assigns the user connection’s dedicated Oracle process as the Parallel
Execution Coordinator (aka QC). The coordinator in turn delegates the execution of a
4
statement to several other parallel execution processes and in the end coordinates the
results from these processes into the final result.
Let us consider the following sample query:
SELECT /*+ Parallel (Employee) */
*
FROM EMPLOYEE E, DEPARTMENT D
WHERE E.DNO = D.DEPTNO
Figure 1: Select All from Employee and Department Tables.
The steps involved in the processing the query in Figure 1 is as follows [1]:

The table is dynamically divided into load units called granules

The parallel query coordinator assigns each granule to a slave process

Results from slave processes are assembled as the complete final result of the
query.

Slave processes are released once they have completed execution of their granule.

The execution plan for this statement is as shown below in Figure 2.
5
Figure 2: Query Execution Plan
1.4 When not to use Parallel Execution
Parallel Execution does not help when using the Parallel Hint for queries that involve
very small operations, as the overhead of parallelizing the query far exceeds the actual
execution time for the query. In transaction processing (tp) environments, we could
consider operations that take less than 10-15 seconds as a relatively small operation.
Later, we look at Data Warehousing in which PX usually has more justified usage.
Also, in systems where the resources such as, CPU, memory and I/O resources are
always heavily utilized, the use of parallel execution will only lead to resource contention
and also tend towards system crash.
6
1.5 Query Optimizer
The Query Optimizer determines the most efficient way in which a SQL statement can be
executed [6]. Historically, Oracle has used the following two optimization techniques:
Cost Based Optimization (CBO) and Rule Based Optimization (RBO).
The optimizer does the following operations in order to optimize any give SQL statement
[6]:

It first evaluates the expressions and conditions specified in the query.

It then goes on to transform the statement, by converting the correlated subqueries
and views into equivalent join statements.

The optimizer then decides on the optimization technique to employ in order to
achieve optimal execution times.

It then makes a choice of the order and method in which the joins are to be
executed. For example to use a Hash join or a Simple Join on the tables employed
in the query.
With the advent of Oracle 10 g, Oracle has done away with Rule Based Optimization.
Hence, in our project’s use of Oracle 11g, all database queries will be optimized using the
Cost Based Optimization techniques.
1.5.1
Cost Based Optimization (CBO)
Cost – is an estimation of the resources required to execute a statement, using a particular
execution plan.
7
“The cost based optimizer generates a set of potential plans for the SQL Statement based
on the paths and hints that are specified in the query. The optimizer then estimates the
cost of each of these plans based on statistics from the data dictionary and storage
characteristics of the tables, partitions, indexes, that are accessed in the query statement.
The optimizer then chooses the plan with the lowest cost” [6].
CBO requires the use of cost statistics store in database objects that would help in
judging the performance difference and also help in choosing which indexes and joins to
follow. In order to efficiently use CBO, Oracle requires that these cost statistics are the
most current values. This can be easily automated with the following command:
dbms_stats.gather_schema_stats('SCOTT',options=>'GATHER AUTO');
1.5.2
Rule Based Optimization (RBO)
When using RBO for optimizing a query statement, the optimizer evaluates all the
available access paths that are available for execution of the query and ranks these access
paths [7]. The optimizer then chooses the access path with the lowest rank as the
execution plan for the given query.
Oracle ranks access paths based on some heuristic rules that determine the efficiency of
execution.
RBO only considers the ranking of access paths to judge the performance and does not
include the cost of execution of these access paths. For example, if a table had a unique
index and the columns are fully qualified, then this table becomes the driving table for the
8
rest of the query execution. But, it does not consider the size of this table and the costs
involved in fully accessing these tables. Hence, RBO does not always provide the most
efficient execution plan for a query.
9
Chapter 2
BACKGROUND
With the growing need for storing historical data as part of any software application,
databases are growing far and wide and getting bigger each day in order to maintain
information. Also, applications and people that use these databases require querying this
information in order to perform reports and also do searches on the data. This raises the
issue of performance.
In modern day computers, there are a vast number of resources that are available such as
multi-core processors, huge amount of memory and vast storage. For good performance,
SQL requires that all these resources are allocated appropriately in order to achieve better
speeds of execution, in terms of time for execution, attain better scalability and also
higher availability.
Oracle implemented the Oracle Parallel Execution feature to help take advantage of the
multiple CPU’s and vast amount of memory. Oracle Parallel Query was first
implemented in the Oracle Release 7.2, to be able to break a SQL statement into smaller
more manageable sub-queries and execute each of these sub-queries by a separate
processor.
2.1 Purpose and Scope
The purpose of this project is to analyze how some queries can take advantage of the
Oracle Parallel execution features and demonstrate, by examples, when to use parallel
queries and when not to. Also we will explain how the query plan varies with the
10
execution of every query and see how the query coordinator allocates granules of a query
to various slave processes in order to perform the parallel execution.
In this project we will start by discussing how certain configuration parameters need to be
initialized in order to allow for parallel execution of queries. We will be analyzing the
performance of certain query statements, DML statements and a few DDL scripts when
executed using the parallel query hints and do a comparison of these same queries when
executed in a serial fashion. We will use Oracle’s Explain Plan, SQL Trace, and TKProf
utilities to see the query plan that was used during the execution and gather statistics on
various lower-level operations costs.
2.2 Explain Plan
The Explain Plan utility from Oracle displays the execution plan that is chosen by the
Oracle optimizer in order to execute the issued statement. It is a sequence of steps
followed by Oracle to execute the query. Although the explain plan utility gives us cost
and time statistics, it is an estimation of the way in which Oracle thinks is the best way to
go. But, the cost and time elapsed can vary considerably upon actual execution of the
query.
The core of the Execution Plan feature is the row source tree, which provides information
about the following [8]:

The ordering of the tables referenced in the query statement

An access method for each of the tables referenced

Nature of the join (if any) employed for the operation and,
11

Any of the data operations that will be required to generate the results for the
query. These data operations could be things like sorting, aggregation, filters (for
row elimination), etc.

Also, we can gather information about the cost, cardinality and distribution
methods for Parallel execution.
2.2.1
Syntax for Explain Plan
Explain Plan For
Query Statement;
Upon issuing the Explain Plan query, Oracle writes the execution plan into a special table
PLAN_TABLE, after doing the analysis of the query statement. The most important
attributes of the PLAN_TABLE are: Operation, option, object_name, id and parent_id.
The operation field specifies the type of operation that will be performed on the given
object identified by the object_name. The parent_id and the id fields specify that way in
which data moves up the ladder from child processes to the parent process.
2.2.2
Explain Plan for Parallel Processing
Explain plan can also be used for parallel queries. The driving force behind reducing
execution times is to apply parallel processing on the tables that require full-table scans
on very large tables.
The parallel operations that can be performed are as follows [8]:

PARALLEL_TO_SERIAL
12

PARALLEL_TO_PARALLEL

PARALLEL_COMBINED_WITH_PARENT

PARALLEL_FROM_SERIAL

PARALLEL_COMBINED_WITH_PARENT

PARALLEL_TO_PARALLEL
PARALLEL_TO_PARALLEL operations generally produce the best performance as
long as the workloads in each step are relatively equivalent. If this kind of an operation
exists in a query plan, it means that there are two sets of parallel server processes and,
that data from one set of parallel server processes would be distributed among the second
set of parallel server processes, that is, both the consumer and the producer are parallel
processes as shown in Figure 3 below [9].
Figure 3: Parallel Consumer and Parallel Producer [9]
A PARALLEL_COMBINED_WITH_PARENT operation occurs when the step is
performed simultaneously with the parent step.
13
A PARALLEL_TO_SERIAL operation is the step that occurs when rows from a parallel
operation are consumed by the query coordinator.
2.2.3
Factors for Cost calculation in a Query Execution Plan
The cost of an operation is an estimate of the execution plan that is employed by Oracle’s
optimizer and is not related to the access method used by the operation. It is a weighted
value that helps in comparing costs of queries. The value of this column is a function of
the CPU_Cost and IO_Cost columns of the Query Execution Plan table.[14] . Oracle
Optimizer uses these cost estimates to decide on which QEP to use while actually
executing the SQL statement.
2.3 SQL Trace and TKProf utility
The SQL Trace and TKProf utilities can help us better understand query execution
statistics such as:
1. Count of Parses, Executions and Fetched associated with a query
2. CPU utilization and Execution times
3. Number of Physical and Logical Reads
4. Number of rows that were processed during the execution of the issued query
2.3.1
How to use SQL Trace and TKProf
Step 1: Instance Initializing parameters to consider are described in Table 1 [10] below.
14
Table 1 : Parameters for SQL Trace and TKProf
Parameter
TIMED_STATISTICS
MAX_DUMP_FILE_SIZE
USER_DUMP_DEST
Description

This enables and disables the collection of timed
statistics, such as CPU and elapsed times, by the SQL
Trace facility, as well as the collection of various
statistics in the dynamic performance tables. The default
value of false disables timing.

A value of true enables timing. Enabling timing causes
extra timing calls for low-level operations.

This is a dynamic parameter and a session parameter

When the SQL Trace facility is enabled at the instance
level, every call to the server produces a text line in a
file in the operating system's file format.

The maximum size of these files (in operating system
blocks) is limited by this initialization parameter.

The default is 500.

If you find that the trace output is truncated, then
increase the value of this parameter before generating
another trace file.

It is a dynamic parameter and also a session parameter.
This must fully specify the destination for the trace file
according to the conventions of the operating system. The
default value is the default destination for system dumps on the
operating system. This value can be modified
with ALTER SYSTEM SET USER_DUMP_DEST= newdir.
This is a dynamic parameter. It is also a session parameter.
Step 2: Enabling SQL Trace
a. SQL Trace can be enabled for a whole session in two ways:

Execute procedure DBMS_SESSION.SET_SQL_TRACE
15

ALTER SESSION SET SQL_TRACE = TRUE;
This creates a separate trace file for each session.
b. To find a trace file for your session:
SELECT VALUE
FROM V$DIAG_INFO
WHERE NAME = 'Default Trace File';
c. To disable SQL Trace:

ALTER SESSION SET SQL_TRACE = FALSE;
Step 3: Formatting Trace Files using TKProf
The trace file created by using SQL Trace utility requires considerable amount of
formatting in order to make it humanly readable. This can be achieved using TKProf.
To do this,
a. Open command window
b. Navigate to the folder where Oracle writes it trace files. This can be found using
the query in Step 2 – b.
c. Run TKProf on the SQL Trace file for the current session.
Save the TKProf output into a text file, to make it readily accessible.
16
2.3.2
Understanding TKProf Output file
Figure 4: SQL Trace to Select Employees with Salary > 65000
TKProf for the SQL statement in Figure 4 above is divided in 3 parts:
1. TKProf Header :
Figure 5 : Example of TKProf Header
Figure 5 above consists of the header, which has a description of the terms used in
the remainder of the TKProf output. The header also gives the name of the trace
file and the timestamp value that defines when the output was generated. Also if
any sort options were applied to create the output file.
2. TKProf Body: The Body gives us the statistics for each of the queries that were
executed as part of the session.
17
Figure 6: Example of TKProf Body
As we can see in Figure 6 above, the body describes the number of parses,
executes and fetches that were required to complete the SQL statement that was
issued. It also shows us the misses in the library cache during parsing the query.
Optimizer mode – describes the optimization technique used to execute the query
most efficiently using Cost Based Optimization.
From Oracle 10g onwards, we no longer have the “Choose” optimizer mode.
Hence in this document, we will only come across the following two types of
optimizer modes.
All_rows: This indicates that Oracle favors full table scans over the use of indexes
for the execution of the specified query. It is the default mode in which the
optimizer operates in order to minimize the computing while using indexes.
18
First_rows_n: It involves choosing an index scan and will return the first n rows
by looking at the indexes. This method however requires considerable amount of
I/O operations. [13]
The TKProf Body contains the execution plan that was employed for the
execution of the query. This gives an elaborate description of the execution time,
cost of execution and cardinality involved in each step of the query execution.
3. TKProf Summary:
The summary gives us resource utilization statistics for all Recursive and NonRecursive statements that were executed in the session For completeness
purposes, and our own understanding, explain difference between recursive and
non-recursive SQL porcessing And count of the number of misses in the cache
library as shown in the Figure 7 below.
19
Figure 7 : Example of TKProf Summary
The recursive statements table indicates the statistics of all the non-user
statements that were executed as part of the session. Recursive calls are generally
issued when firing database triggers, execution of SQL within PL/SQL blocks,
executing functions or stored procedures [11]. In some cases recursive calls are
made even when executing a user statement, such as, while trying to insert a row
into a table and we run out of space to store that row, oracle requires allocating
the space dynamically which is done using some recursive calls.
Non-recursive statements are those statements that were actually issued by the
user, and oracle lists the totals of all such statements that were executed in this
particular session in the Non-recursive statements table.
20
Chapter 3
DATA MODEL & CONFIGURATION
For the rest of our project we will be using the Employee Database to perform our
experiments and gather the results of our queries.
The entity-relationship model for the Employee Database is as shown in Figure 8.
DEPARTMENT
DEPTNO
MGRNO
ADMRDEPT
LOCATION
DEPT_LOCATIONS
DNUMBER
DLOCATION
DEPENDENT
PROJECT
PROJNO
PROJNAME
DEPTNO
RESPEMP
PRSTAFF
PRSTDATE
PRENDATE
MAJPROJ
ESSN
DEPENDENT_NAME
SEX
EMPLOYEE
FIRSTNAME
MINT
LASTNAME
SSN
DOB
ADDRESS
SEX
SALARY
DEP_SSN
DNO
WORKSON
ESSN
PNO
HOURS
Figure 8 : ER Diagram of the Employee Database
Another database that we will reference during the course of this project is the SH
Database. This is a sample database provided as part of Oracle 11g Database and is
automatically created during database instance install. The schema diagram for the
database is as shown in Figure 9. Also, the complete database configuration can be found
in Appendix A of this report.
21
COSTS
PROMOTIONS
Prod_id
Time_id
Promo_id
Channel_id
Unit_Cost
Unit_price
Promo_id
Promo_name
Promo_subcategory
Promo_subcategory_id
Promo_category
Promo_category_id
Promo_cost
Promo_begin_date
Promo_end_date
Promo_total
Promo_total_id
PRODUCTS
Prod_id
Prod_name
Prod_desc
Prod_subcategory
Prod_subcategory_id
Prod_subcategory_desc
Prod_category
Prod_category_id
Prod_category_desc
Prod_weight_class
Prod_uint_of_measure
Prod_pack_size
Supplier_id
Prod_status
Prod_list_price
Prod_min_price
Prod_total
Prod_total_id
Prod_src_id
Prod_eff_from
Prod_eff_to
Prod_valid
CHANNELS
Channel_id
Channel_desc
Channel_class
Channel_class_id
Channel_total
Channel_total_id
SALES
Prod_id
Cust_id
Time_id
Channel_id
Promo_id
Quantity_sold
Amount_sold
CUSTOMERS
Cust_id
Cust_first_name
Cust_last_name
Cust_gender
Cust_year_of_birth
Cust_marital_status
Cust_street_address
Cust_postal_code
Cust_city
Cust_city_id
Cust_state_province
Cust_state_province_id
Country_id
Cust_income_level
Cust_credit_level
Cust_email
Cust_total
Cust_total_id
Cust_src_id
Cust_eff_from
Cust_eff_to
Cust_valid
Figure 9 : ER Diagram for SH Database
TIMES
Time_id
Day_name
Day_number_in_week
Day_number_in_month
Calendar_week_number
Fiscal_week_number
Week_ending_day
Week_ending_day_id
Calendar_month_number
Fiscal_month_number
Calendar_month_desc
Calendar_month_id
Fiscal_month_id
Days_in_cal_month
Days_in_fis_month
end_of_cal_month
end_of_fis_month
Calenday_month_name
Fiscal_month_name
Calendar_quarter_desc
Calenday_quarter_id
Fiscal_quarter_desc
Fiscal_quarter_id
Days_in_cal_quarter
Days_in_fis_quarter
End_of_cal_quarter
End_of_fis_quarter
Calendar_quarter_number
Fiscal_quarter_number
Calendar_year
Calendar_year_id
Fiscal_year
Fiscal_year_id
Days_in_cal_year
Days_in_fis_year
End_of_cal_year
End_of_fis_year
COUNTRIES
Country_id
Country_iso_class
Country_name
Country_subregion
Country_subregion_id
Country_region
Country_region_id
Country_total
Country_total_id
Country_name_hist
22
3.1 System Configuration
Table 2 lists the configuration of the machine on which we will be conducting our
experiments.
Table 2 : System Configuration
System Component
Manufacturer
Model
Processor
Memory
Operating System
Hard Drive
Description
Dell
Latitude E6410 (Laptop)
Intel® CoreTM i7 (640M) – Quad Core Processor
8GB DDR3 SDRAM at 1333Mhz - 2 DIMMS
Windows 7 Professional : 64-bit
300 Gigabytes
3.2 Oracle Configuration Parameters for Parallel Execution
Table 3 below lists the Parallel Execution related parameters and the values assigned to
them for our execution. Later on we describe these parameters in more detail.
Table 3 : Parallel Query Initialization Parameters
Name
Dynamic
Modified
16384
TRUE
FALS
E
40
0
0
2
Integer
Boolean
Boolean
Parallel Executions
Parallel Executions
Parallel Executions
Integer
Integer
Integer
Integer
Parallel Executions
Parallel Executions
Parallel Executions
Parallel Executions
Basic
3.2.1
Type
parallel_max_servers
parallel_min_percent
parallel_min_servers
parallel_threads_per_cpu
Value
parallel_execution_message_size
parallel_adaptive_multi_user
parallel_automatic_tuning
Category
Parallel_execution_message_size
This parameter must be in the range between 2148 and 65535. It signifies the size of
messages that can be employed for parallel execution. Default value is 2148. Larger the
23
value of this parameter, implies that we will require a larger shared pool of processes.
And also, larger the value better is the performance. But, it comes with a cost of high
memory usage.
3.2.2
Parallel_execution_message_size
The default value for this parameter is FALSE. With such a configuration, the degree of
parallelism that is set in the HINT for a query is applied to the query while processing.
On setting the parallel_adaptive_multi_user = TRUE, Oracle enables an adaptive
algorithm that reduces the degree of parallelism that is specified in the Parallel Query
Hint. This is done to manage the system load in a multi-user environment and effectively
use the resources among the contending applications.
This parameter plays an important role in system resource utilization. In cases when the
system resources are already heavily being utilized, on issuing a query that spawns
multiple processes it injects a fair amount of contention between these resources, there by
leading to slowing of all the operations being executed. In such a scenario, if
parallel_adaptive_multi_user parameter is set to “true”, Oracle decides on how many
processes to spawn and still keep the system stable. This is called downgrading
parallelism.
For example, if we issue an SQL statement with a hint to use 8 parallel processes to
execute the query and that many system resources are unavailable, Oracle downgrades
the parallel execution and uses a fewer number of processes to execute the statement.
24
This can be recognized when we see the query execution statistics using the Database
Console.
3.2.3
Parallel_automatic_tuning
The value of this parameter decides the values parameters such as the shared pool size. If
this parameter is set to TRUE, Oracle decides an optimal value for these parameters.
By default, this parameter is set to FALSE. Now, Oracle just assumes the default values
for all parameters that affect the performance of parallel execution.
3.2.4
Parallel_max_servers
This parameter is derived by the CPU_Count for the system on which we are executing
the parallel queries. It also depends on the value of parallel_automatic_tuning.
In general, the formulation for this parameter is (4 * CPU_Count ).
But, when parallel_automatic_tuning = TRUE, the formula applied for
parallel_max_servers = (10 * CPU_Count)
3.2.5
Parallel_min_percent
This parameter indicates the minimum percentage of parallel execution processes that are
required for parallel execution. This parameter allows DBA’s to allocate the minimum
number of parallel execution processes to be allocated to every query at the database
level. It can range from 0 to 100.
3.2.6
Parallel_min_servers
This parameter is usually set to the value of (2 * CPU_Count).
25
The value of this parameter initializes the number of parallel execution processes that
Oracle creates on startup.
3.2.7
Parallel_threads_per_cpu
This parameter determines the number of processes that a CPU can allocate during
parallel execution. It is dependent on the operating system, and is usually set to 2.
If for instance, a system gets overloaded while executing a parallel query, the value of
this parameter should be reduced.
3.3 Hints
Hint is a mechanism by which the user can specifically change the execution plan and
force the Oracle optimizer to execute a particular statement the in a different way. . It lets
the user make the decision on behalf of the optimizer. This can be very useful in large
database applications where in, the Database developer or a DBA has a better
understanding of how data is structured in the system. Using hints is completely optional
when coding a given SQL statement.
In Oracle, the syntax for specifying hints is as follows:
{DELETE|INSERT|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */
or
{DELETE|INSERT|SELECT|UPDATE} --+ hint [text] [hint[text]]...
The different kinds of hints that Oracle allows are:
i.
Hints for Optimization
26
ii.
Hints for Access Paths
iii.
Hints for Query Transformation
iv.
Hints to specify the Join Order
v.
Hints to actually change the Join Operations
vi.
Hint for Parallel Execution
In the rest of our thesis, we will be using a set of hints in order to simulate the need for
using PX. They are:
a. PARALLEL Hint:
This hint allows the user specify to the optimizer that we would like to go with
parallel processing for this statement, and also allows the user to optionally decide
on the degree of parallelism for the current operation.
The syntax for Parallel Hint
/* + PARALLEL ( table_name , degree_of_parallelism ) */
The degree_of_parallelism can have the following values:

Default

Interger – to specify the degree
b. NOPARALLEL Hint
Some tables are usually created with the parallel degree specified for that table.
Using the Noparallel hint allows the user to override the default degree of
parallelism.
The syntax is as follows:
/* + NOPARALLEL ( table_name ) */
27
c. NOCACHE Hint
This is another hint that we use often in this paper. It orders Oracle to actually go
and fetch the data from the table and not use the data that is already available in
the cache. This hint, in our project, serves as a benchmark as we require using the
actual times of execution and the data is not always available in a cache. The
syntax for this hint is as follow:
/* + NOCACHE ( table_name ) */
d. MONITOR Hint
This hint does not optimize the query. We will be using this hint in our project to
allow the SQL Monitoring utility to pick up these queries for monitoring
purposes.
3.4 Speedup and Efficiency
In our report, we will be using Speedup and Efficiency as our quantities to measure the
performance of SQL statements.
Amdahl’s law states that “Speedup is defined as the time it takes for a program to execute
in serial (with one processor) divided by the time it takes to execute in parallel (with
many processors)” [12].
This can be applied for SQL statements as
Speedup = Execution Time in Serial / Execution Time in Parallel.
The same equation can also be applied to the cost of execution as
Speedup = Cost of Execution in Serial / Cost of Execution in Parallel.
28
Efficiency is defined as the speed up, divided by the number of processors used. In the
context of our project, we can safely assume that the number of processors is in direct
correlation to the number of parallel slaves that Oracle allocates to the execution of each
of the parallelized SQL statements.
Hence, Efficiency = Speedup / Number of Parallel Slaves.
29
Chapter 4
PERFORMANCE OF PARALLEL QUERY – SELECT & PROJECT
4.1 Purpose
In this experiment, we will compare the performance of some Queries when
executed in Parallel versus Serial.
4.2 Preparation
Let us consider the query to calculate the Maximum and Average Salaries of employees
in an organization. The query is as shown in the Figure 10.
Figure 10: Max and Average Salary of Employees Without Parallel
This involves a join operation on the two tables: Employee and Department. It also
involves a full scan of the Employee table, and a “Group By” clause that groups the result
by Employee - Department Number.
The Explain plan for the Serial Execution of this query is as shown in Figure 11 below.
This example requires a full table scan for the Employee table and the Group By clause is
executed using a hashing function.
30
Figure 11: Explain Plan for Serial Execution
This query can be executed using the Parallel Hint in the following manner as shown in
Figure 12 below. Here, we are ordering the Oracle Query Optimizer to process the table
scans for both Employee and Department tables in Parallel and also, to use Hash Join for
the “Group By” ordering.
Figure 12 : Max and Average Salaries of Employees With Parallel Hint
The execution plan for the Parallel Execution of this query shows us how the Oracle’s
QC splits up the task among slave processes. This is depicted in out explain plan output
shown in Figure 13.
31
Figure 13: Explain Plan for Parallel Execution
4.3 Findings
Comparing the execution plans for the two queries with and without the Parallel Hint, we
can see that
1. Cost of Execution: The cost of the execution in Figure 13 is half the cost of
execution in Figure 11.
2. Cardinality: This is the measure of the number of unique data rows in the result of
the query. This remains the same for the both the operations.
3. Efficiency :
a. Speedup = (cost of sequential execution of query) / (cost of parallel
execution)
In our experiment,
32
Cost of sequential execution of query is 6 and,
Cost of parallel execution of the same query is 3
Speedup = 6/3
Hence, we have achieved a speed up of 2. In other words, the query when
executed in Parallel, executed 2 times faster than when executed in serial.
b. Efficiency = Speedup / number of processes requested
The default degree of parallelism in our database is 8. Hence, we assume
that the number of parallel slaves spawned could be 8, which may very
during execution as the parallel_adaptive_multi_user parameter is set to
true (as discussed in chapter 2).
Therefore, Efficiency = 2 / 8 = 0.25
Hence, we achieved an efficiency of 25 %.
33
Chapter 5
PERFORMANCE OF PARALLEL QUERY - JOIN OPERATION
5.1 Introduction
In this experiment, we will execute a join operation and compare the execution of the
statement using both with and without parallel execution.
5.2 Preparation
For this experiment we shall consider the SH Database and list all the customers who
have purchased for an amount greater than.
The execution plan using serial execution is as shown in Figure 14.
Figure 14 : List Customers who Purchased for Amounts > 50 Without Parallel
34
When the same query is executed in parallel using the parallel hint on both sales and
customer tables, the execution plan shown in the lower half of Figure 15 shows how the
optimizer applies parallel processes to perform the execution.
Figure 15: Customers who Purchased for Amounts > 50 Using Parallel Hint
We notice that there is a considerable gain in cost of execution based on the execution
plans. The cost when executing the query in a serial fashion is 2k, whereas the cost of
executing the query in parallel as shown in the execution plan in is 226.
The actual elapsed wall-clock times for these two executions are as show in the Figure 16
and Figure 17 below:
35
Figure 16: Serial Execution Elapsed Times
Figure 17: Parallel Execution Elapsed Times
It can be seen by the wall clock elapsed times that the query took nearly 5 seconds lesser
while executing in parallel. The TKProf output shows the exact amount of Database time
36
and the CPU times taken for these executions are shown in Appendix-C and the SQL
Monitoring Report shows us the number of Parallel slave processes where spawned
during execution of the same query.
5.3 Results
Comparing the execution plans for the two queries with and without the Parallel Hint, we
can see that
1. Cost of Execution: The cost of the execution in Figure 15 is lower than the cost of
execution in Figure 14.
2. Cardinality: This is the measure of the number of unique data rows in the result of
the query. This remains the same for the both the operations.
3. Efficiency :

With respect to the estimation of the Explain Plan:
a. Speedup = (cost of sequential execution of query) / (cost of parallel
execution)
In our experiment,
Cost of sequential execution of query is 2000 and,
Cost of parallel execution of the same query is 226
Speedup = 2000/226 = 9.78
Hence, we have achieved a speed up of 9.78. In other words, the query
when executed in Parallel, executed more than 9 times faster than when
executed in serial.
37
b. Efficiency = Speedup / number of parallel slaves used
Both the tables were parallelized, so we can say that degree of parallelism
for this query would be 16.
Efficiency = 9.78 / 16 = 0.611
Hence, we achieved an efficiency of 60 %. But this is just an estimate.

When we compare the actual elapsed times:
a. Speed-up: Time for serial execution = 133.23 sec and time for parallel
execution = 128.78 seconds.
Therefore, Speedup = 133.23 / 128.78 = 1.035 seconds
b. Efficiency:
Looking at the SQL Monitoring Report from Appendix-C, we can see that
16 servers were allocated while execute the query in parallel, which means
that the parallelization was not downgraded during actual execution.
Hence, Efficiency = 1.035 / 16 = 0.064
Which states that the execution in parallel is nearly 6% more efficient
compared to execution without parallel option.
38
Chapter 6
PERFORMANCE OF PARALLEL DML - UPDATE OPERATION
6.1 Purpose
Parallel Data Manipulation Language statement (not queries!) are meant to
manipulate data within tables based on certain conditions specified in the where clause.
In this chapter we will compare the execution of the UPDATE statement using parallel
execution and the execution of the same statement without parallel execution.
6.2 Preparation
For this experiment we created a copy of the Sales table and called it the
Sales_Temp, as we do not want to actually manipulate the data in the original table. In
this statement, we are updating the quantities sold to 2 during the serial execution and
then later updating it to 1 while executing the update using parallel execution, for all
those sales table entries that are linked to customers in the Customers table in the SH
Schema.
The execution plan using serial execution is as shown in Figure 18 below.
39
Figure 18: Update Statement Without Parallel
The same query when issued using the parallel clause portrays an execution plan as
shown in Figure 19.
Figure 19: Update Statement With Parallel Execution
40
The wall-clock elapsed time for the serial execution is shown in Figure 20, whereas the
time taken by the parallel execution of the same query is shown in Figure 21 below.
Figure 20: Elapsed Time for Update Query Without Parallel
Figure 21: Elapsed Time for Update Query With Parallel
41
6.3 Results
The TKProf outputs for the above queries can be found in Appendix-D of this
thesis. Comparing the execution plans and elapsed wall clock times for the two queries
with and without the Parallel Hint, we can see that:
1. Cost of Execution: The cost of the execution in Figure 19 is lower than the cost of
execution in Figure 18.
2. Cardinality: Remains the same for both kinds of implementations
3. Efficiency :

With respect to the estimation of the Explain Plan:
a. Speedup = (cost of sequential execution of query) / (cost of parallel
execution of query)
In our experiment,
Cost of sequential execution of query is 1000 and,
Cost of parallel execution of the same query is 189
Speedup = 1000/189 = 5.29
Hence, we have achieved a speed up of 5.29. In other words, the query
when executed in Parallel, executed more than 5 times faster than when
executed in serial.
b. Efficiency = Speedup / number of Parallel Slaves used during execution.
By the default degree of parallelism = 8
Efficiency = 5.29/ 8 = 0.66
42

When we compare the actual elapsed times:
c. Speed-up: Time for serial execution = 29.52 sec and time for parallel
execution = 23.16 seconds. That is, the updates executed almost 6 seconds
faster in parallel.
Therefore, Speedup = 29.52 / 23.16 = 1.274 seconds
d. Efficiency
The SQL Monitoring report states that the servers allocated for the
execution of the Update using parallel execution is 8.
Therefore, Efficiency = 1.274 / 8 = 0.159.
That is we have attained an efficiency of nearly 16 % using the Parallel
DML option.
43
Chapter 7
PERFORMANCE OF PARALLEL SQL RUN CONCURRENTLY
7.1 Purpose
The purpose of this experiment is to determine the performance of parallel SQL
statements run together, so as to explore issues pertaining to concurrency.
7.2 Serial Update and Serial Select Statement Executed Concurrently
For this experiment, we shall consider serial execution of an Update query shown
in Figure 22 below and the Select statement shown in Figure 23. We start execution of
these statements as close to each other as possible.
Figure 22: Serial Update
Figure 23: Select Statement Without Parallel
44
The wall clock elapsed times for the execution of the above two queries are shown in
Figures 24 and 25 respectively.
Figure 24: Elapsed Time for Serial Update
Figure 25 : Elapsed time for Serial Select statement
45
7.3 Parallel Update and Parallel Select statement Executed Concurrently
We then repeated the same experiment, but this time both queries were parallelized and
were run almost concurrently. The queries are shown in Figures 26 and 27.
Figure 26 : Parallel Update
Figure 27: Select Statement With Parallel Clause
The respective elapsed times are shown in Figure 28 and 29.
46
Figure 28 : Execution Time of Parallel Update
Figure 29 : Elapsed Time for Parallel Select
7.4 Results
The TKProf outputs for the above queries can be found in Appendix-E of this
project. Comparing the elapsed times for the two implementations as described in
sections 7.2 and 7.3 above, we can see that
47
1. Execution time for the SELECT statement which executed in serial (Figure 25) is
less that the execution of the same statement in parallel (Figure 29). This is due to
the concurrency overhead. Where the SELECT statement spends time waiting for
the UPDATE Statement to finish processing the records.
2. Execution time for the UPDATE statement which executed in serial (Figure 24) is
more that the execution of the same statement in parallel (Figure 28) which was as
expected and also proves the results for chapter 6.
48
Chapter 8
SUMMARY AND FUTURE WORK
Parallel Execution is an efficient way to manage system resources as well as gaining
performance improvement. Using Oracle’s parallel execution features, we could cut
down on execution times as well as effectively use the system resources by allowing the
multiple processors to execution small tasks in parallel.
As we have seen in our project, with 4 CPU’s and 8GB of memory and a limited number
of concurrent users, the elapsed times for SQL statements using parallel execution was
less than the elapsed times for the same statements run without parallel execution. And,
from the SQL monitoring reports we saw how Oracle assigns a Query Coordinator and a
set of parallel slave to perform the execution of the SQL statement in Parallel.
Although Oracle’s Parallel Execution has a lot to offer, at certain situations it may cause
drastic system failures. It requires monitoring and adjusting database parameter such as
the parallel_adaptive_multi_user in order to avoid such disasters. Processing tracing files
would be a tedious task and may require the use of the trcsess utility to analyze the
performance of parallel execution. Also, it requires a vast amount of system testing and
load testing before we apply parallel executions to user-end application.
Future works based on this project may include an analysis of Oracle’s Parallel Execution
features in situations that there is a front-end application that accesses the database and
observe the performance of the hints to determine the performance of these applications.
49
APPENDIX A
Oracle Initialization Parameters
Table 4: Oracle 11g Initialization Parameters
Basic
Name
Value
Type
Modified
Dynamic
O7_DICTIONARY_ACCESSIBILITY
active_instance_count
aq_tm_processes
archive_lag_target
asm_diskgroups
asm_diskstring
asm_power_limit
asm_preferred_read_failure_group
audit_file_dest
audit_sys_operations
audit_trail
background_core_dump
background_dump_dest
backup_tape_io_slaves
bitmap_merge_area_size
blank_trimming
buffer_pool_keep
buffer_pool_recycle
cell_offload_compaction
cell_offload_decryption
cell_offload_parameters
cell_offload_plan_display
cell_offload_processing
cell_partition_large_extents
circuits
client_result_cache_lag
client_result_cache_size
cluster_database
cluster_database_instances
cluster_interconnects
commit_logging
commit_point_strength
commit_wait
commit_write
compatible
control_file_record_keep_time
control_files
control_management_pack_access
FALSE
Boolean
Integer
0
0
Integer
Integer
String
String
1
Integer
String
C:\APP\PRAMUKH\ADMIN\
MPROJECT\ADUMP
FALSE
DB
partial
c:\app\pramukh\diag\rdbms
\mproject\mproject\trace
FALSE
1048576
FALSE
String
Boolean
String
String
String
Boolean
Integer
Boolean
String
String
ADAPTIVE
TRUE
String
Boolean
String
AUTO
TRUE
DEFAULT
String
Boolean
String
Integer
3000
0
FALSE
1
Big Integer
Big Integer
Boolean
Integer
String
String
1
Integer
String
String
11.2.0.0.0
7
C:\APP\PRAMUKH\ORADAT
A\MPROJECT\CONTROL01.CT
L,
C:\APP\PRAMUKH\FLASH_RE
COVERY_AREA\MPROJECT\C
DIAGNOSTIC+TUNING
String
Integer
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
YES
YES
YES
YES
YES
YES
NO
YES
NO
YES
NO
NO
NO
NO
YES
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
NO
NO
NO
NO
NO
NO
YES
NO
YES
YES
YES
YES
NO
NO
NO
NO
NO
NO
YES
NO
YES
YES
NO
NO
YES
YES
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
NO
YES
NO
YES
YES
NO
YES
NO
YES
NO
NO
NO
YES
String
String
50
Table 5: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
core_dump_dest
cpu_count
create_bitmap_area_size
create_stored_outlines
cursor_sharing
cursor_space_for_time
db_16k_cache_size
db_2k_cache_size
db_32k_cache_size
db_4k_cache_size
db_8k_cache_size
db_block_buffers
db_block_checking
db_block_checksum
db_block_size
db_cache_advice
db_cache_size
db_create_file_dest
db_create_online_log_dest_1
db_create_online_log_dest_2
db_create_online_log_dest_3
db_create_online_log_dest_4
db_create_online_log_dest_5
db_domain
db_file_multiblock_read_count
db_file_name_convert
db_files
db_flash_cache_file
db_flash_cache_size
db_flashback_retention_target
db_keep_cache_size
db_lost_write_protect
db_name
db_recovery_file_dest
db_recovery_file_dest_size
db_recycle_cache_size
db_securefile
db_ultra_safe
db_unique_name
db_writer_processes
dbwr_io_slaves
ddl_lock_timeout
c:\app\pramukh\diag\rdbms
String
\mproject\mproject\cdump
Integer
4
Integer
8388608
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
YES
YES
NO
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
NO
YES
YES
NO
NO
NO
NO
NO
NO
NO
YES
YES
NO
YES
YES
NO
YES
YES
YES
YES
YES
NO
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
NO
NO
NO
YES
YES
YES
YES
NO
NO
NO
Big Integer YES
String
YES
String
YES
String
YES
Integer
YES
Integer
YES
Integer
YES
NO
NO
NO
YES
NO
NO
NO
NO
YES
YES
YES
YES
YES
NO
NO
NO
NO
YES
String
EXACT
FALSE
0
0
0
0
0
0
FALSE
TYPICAL
8192
ON
0
String
Boolean
Big Integer
Big Integer
Big Integer
Big Integer
Big Integer
Integer
Boolean
String
Integer
String
Big Integer
String
String
String
String
String
String
String
128
Integer
String
200
Integer
String
0
1440
0
NONE
mProject
C:\app\pramukh\flash_reco
very_area
4102029312
0
PERMITTED
OFF
mProject
1
0
0
Big Integer
Integer
Big Integer
String
String
String
Big Integer
51
Table 6: Oracle 11g Initialization Parameters (Cont’d)
Basic
Name
Value
Type
Modified
Dynamic
deferred_segment_creation
dg_broker_config_file1
dg_broker_config_file2
dg_broker_start
diagnostic_dest
disk_asynch_io
dispatchers
distributed_lock_timeout
dml_locks
dst_upgrade_insert_conv
enable_ddl_logging
event
fal_client
fal_server
fast_start_io_target
fast_start_mttr_target
fast_start_parallel_rollback
file_mapping
fileio_network_adapters
filesystemio_options
fixed_date
gcs_server_processes
global_context_pool_size
global_names
global_txn_processes
hash_area_size
hi_shared_memory_address
hs_autoregister
ifile
instance_groups
instance_name
instance_number
instance_type
java_jit_enabled
java_max_sessionspace_size
java_pool_size
java_soft_sessionspace_limit
job_queue_processes
TRUE
C:\APP\PRAMUKH\PRODUCT
\11.2.0\MASTERSPROJECT\D
ATABASE\DR1MPROJECT.DA
C:\APP\PRAMUKH\PRODUCT
\11.2.0\MASTERSPROJECT\D
ATABASE\DR2MPROJECT.DA
T
FALSE
C:\APP\PRAMUKH
TRUE
(PROTOCOL=TCP)
(SERVICE=mProjectXDB)
60
1088
TRUE
FALSE
Boolean
Boolean
String
Boolean
String
Integer
Integer
Boolean
Boolean
String
Integer
Integer
String
Boolean
String
String
String
Integer
String
FALSE
1
131072
0
TRUE
Boolean
Integer
Integer
Integer
Boolean
Filename
String
mproject
0
RDBMS
TRUE
0
0
0
1000
YES
NO
YES
YES
YES
NO
YES
NO
NO
NO
NO
YES
YES
YES
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
YES
YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
YES
NO
YES
NO
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
YES
NO
NO
YES
YES
NO
YES
YES
YES
YES
YES
YES
NO
NO
YES
NO
NO
YES
YES
NO
NO
YES
NO
NO
NO
NO
NO
YES
NO
YES
NO
YES
String
String
0
YES YES
String
String
0
0
LOW
FALSE
YES
String
Integer
String
Boolean
Integer
Big Integer
Integer
Integer
52
Table 7: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
large_pool_size
ldap_directory_access
ldap_directory_sysauth
license_max_sessions
license_max_users
license_sessions_warning
listener_networks
local_listener
lock_name_space
lock_sga
log_archive_config
log_archive_dest
log_archive_dest_1
log_archive_dest_10
log_archive_dest_11
log_archive_dest_12
log_archive_dest_13
log_archive_dest_14
log_archive_dest_15
log_archive_dest_16
log_archive_dest_17
log_archive_dest_18
log_archive_dest_19
log_archive_dest_2
log_archive_dest_20
log_archive_dest_21
log_archive_dest_22
log_archive_dest_23
log_archive_dest_24
log_archive_dest_25
log_archive_dest_26
log_archive_dest_27
log_archive_dest_28
log_archive_dest_29
log_archive_dest_3
log_archive_dest_30
log_archive_dest_31
log_archive_dest_4
log_archive_dest_5
log_archive_dest_6
log_archive_dest_7
log_archive_dest_8
log_archive_dest_9
log_archive_dest_state_1
0
NONE
no
0
0
0
Big Integer
String
String
Integer
Integer
Integer
String
LISTENER_MPROJECT
String
String
FALSE
Boolean
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
enable
String
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
YES
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
53
Table 8: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
log_archive_dest_state_10
log_archive_dest_state_11
log_archive_dest_state_12
log_archive_dest_state_13
log_archive_dest_state_14
log_archive_dest_state_15
log_archive_dest_state_16
log_archive_dest_state_17
log_archive_dest_state_18
log_archive_dest_state_19
log_archive_dest_state_2
log_archive_dest_state_20
log_archive_dest_state_21
log_archive_dest_state_22
log_archive_dest_state_23
log_archive_dest_state_24
log_archive_dest_state_25
log_archive_dest_state_26
log_archive_dest_state_27
log_archive_dest_state_28
log_archive_dest_state_29
log_archive_dest_state_3
log_archive_dest_state_30
log_archive_dest_state_31
log_archive_dest_state_4
log_archive_dest_state_5
log_archive_dest_state_6
log_archive_dest_state_7
log_archive_dest_state_8
log_archive_dest_state_9
log_archive_duplex_dest
log_archive_format
log_archive_local_first
log_archive_max_processes
log_archive_min_succeed_dest
log_archive_start
log_archive_trace
log_buffer
log_checkpoint_interval
log_checkpoint_timeout
log_checkpoints_to_alert
log_file_name_convert
max_dispatchers
max_dump_file_size
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
enable
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
ARC%S_%R.%T
TRUE
4
1
FALSE
0
10248192
0
1800
FALSE
String
Boolean
Integer
Integer
Boolean
Integer
Integer
Integer
Integer
Boolean
String
Integer
unlimited
String
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
NO
YES
NO
YES
YES
YES
NO
YES
YES
54
Table 9: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
max_enabled_roles
max_shared_servers
memory_max_target
memory_target
object_cache_max_size_percent
object_cache_optimal_size
olap_page_pool_size
open_cursors
open_links
open_links_per_instance
optimizer_capture_sql_plan_baseli
nes
optimizer_dynamic_sampling
optimizer_features_enable
optimizer_index_caching
optimizer_index_cost_adj
optimizer_mode
optimizer_secure_view_merging
optimizer_use_invisible_indexes
optimizer_use_pending_statistics
optimizer_use_sql_plan_baselines
os_authent_prefix
os_roles
parallel_adaptive_multi_user
parallel_automatic_tuning
parallel_degree_limit
parallel_degree_policy
parallel_execution_message_size
parallel_force_local
parallel_instance_group
parallel_io_cap_enabled
parallel_max_servers
parallel_min_percent
parallel_min_servers
parallel_min_time_threshold
parallel_server
parallel_server_instances
parallel_servers_target
parallel_threads_per_cpu
permit_92_wrap_format
pga_aggregate_target
plscope_settings
plsql_ccflags
plsql_code_type
150
8388608000
4798283776
10
102400
0
300
4
4
FALSE
2
11.2.0.1
0
100
ALL_ROWS
TRUE
FALSE
FALSE
TRUE
OPS$
FALSE
TRUE
FALSE
CPU
MANUAL
16384
FALSE
FALSE
40
0
0
AUTO
FALSE
1
16
2
TRUE
0
IDENTIFIERS:NONE
INTERPRETED
YES
Integer
YES
Big Integer NO
Big Integer NO
Integer
YES
Big Integer YES
Integer
YES
Integer
NO
Integer
YES
Integer
YES
Integer
Boolean
YES
YES
String
YES
Integer
YES
Integer
YES
String
YES
Boolean
YES
Boolean
YES
Boolean
YES
Boolean
YES
String
YES
Boolean
YES
Boolean
YES
Boolean
YES
String
YES
String
YES
Big Integer YES
Boolean
YES
Integer
YES
Boolean
YES
Integer
YES
Integer
YES
Integer
YES
String
YES
Boolean
YES
Integer
YES
Integer
YES
Integer
YES
Boolean
YES
Integer
YES
String
YES
String
YES
String
YES
Integer
NO
NO
NO
NO
YES
YES
YES
NO
NO
NO
NO
YES
NO
YES
YES
YES
YES
YES
NO
NO
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
NO
NO
NO
NO
YES
YES
NO
YES
YES
YES
NO
YES
NO
YES
NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
NO
YES
NO
YES
YES
NO
YES
YES
YES
YES
NO
YES
YES
NO
NO
YES
YES
NO
YES
YES
YES
YES
55
Table 10: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
plsql_debug
plsql_optimize_level
plsql_v2_compatibility
plsql_warnings
pre_page_sga
processes
query_rewrite_enabled
query_rewrite_integrity
rdbms_server_dn
read_only_open_delayed
recovery_parallelism
recyclebin
redo_transport_user
remote_dependencies_mode
remote_listener
remote_login_passwordfile
remote_os_authent
remote_os_roles
replication_dependency_tracking
resource_limit
resource_manager_cpu_allocation
resource_manager_plan
result_cache_max_result
result_cache_max_size
result_cache_mode
result_cache_remote_expiration
resumable_timeout
rollback_segments
sec_case_sensitive_logon
sec_max_failed_login_attempts
sec_protocol_error_further_action
sec_protocol_error_trace_action
sec_return_server_release_banner
serial_reuse
service_names
session_cached_cursors
session_max_open_files
sessions
sga_max_size
sga_target
shadow_core_dump
shared_memory_address
shared_pool_reserved_size
shared_pool_size
FALSE
2
FALSE
DISABLE:ALL
FALSE
150
TRUE
enforced
FALSE
0
on
TIMESTAMP
EXCLUSIVE
FALSE
FALSE
TRUE
FALSE
4
5
12025856
MANUAL
0
0
TRUE
10
CONTINUE
TRACE
FALSE
disable
mProject
50
10
248
8388608000
0
none
0
38587596
0
YES
Integer
YES
Boolean
YES
String
YES
Boolean
YES
Integer
NO
Boolean
YES
String
YES
Boolean
YES
Boolean
YES
Integer
YES
String
YES
Boolean
YES
String
YES
String
YES
String
NO
Boolean
YES
Boolean
YES
Boolean
YES
Boolean
YES
Integer
YES
String
YES
Integer
YES
Integer
YES
String
YES
Integer
YES
Integer
YES
String
YES
Boolean
YES
Integer
YES
String
YES
String
YES
Boolean
YES
String
YES
String
YES
Integer
YES
Integer
YES
Integer
YES
Big Integer YES
Integer
YES
String
YES
Integer
YES
Integer
YES
Integer
YES
Boolean
YES
YES
YES
YES
NO
NO
YES
YES
NO
NO
NO
YES
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
YES
NO
NO
NO
YES
YES
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
NO
NO
YES
YES
NO
NO
NO
YES
YES
YES
YES
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
NO
YES
YES
NO
NO
YES
NO
NO
NO
NO
YES
NO
NO
NO
YES
56
Table 11: Oracle 11g Initialization Parameters (Cont'd)
Basic
Name
Value
Type
Modified
Dynamic
shared_server_sessions
shared_servers
skip_unusable_indexes
smtp_out_server
sort_area_retained_size
sort_area_size
spfile
sql92_security
sql_trace
sqltune_category
standby_archive_dest
standby_file_management
star_transformation_enabled
statistics_level
streams_pool_size
tape_asynch_io
thread
timed_os_statistics
timed_statistics
trace_enabled
tracefile_identifier
transactions
transactions_per_rollback_segment
undo_management
undo_retention
undo_tablespace
use_indirect_data_buffers
user_dump_dest
utl_file_dir
workarea_size_policy
xml_db_events
Integer
1
TRUE
Integer
Boolean
String
0
65536
C:\APP\PRAMUKH\PRODUCT
\11.2.0\MASTERSPROJECT\D
ATABASE\SPFILEMPROJECT.
FALSE
FALSE
DEFAULT
%ORACLE_HOME%\RDBMS
MANUAL
TRUE
TYPICAL
0
TRUE
0
0
TRUE
TRUE
Integer
Integer
Boolean
Boolean
String
String
String
Boolean
String
Integer
Boolean
Integer
Integer
Boolean
Boolean
Integer
Integer
String
Integer
String
Boolean
String
String
AUTO
enable
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
NO
NO
YES
YES
NO
NO
YES
YES
NO
NO
NO
YES
YES
NO
YES
NO
NO
NO
NO
NO
NO
YES
NO
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
YES
YES
NO
NO
NO
NO
YES
YES
NO
YES
YES
YES
YES
NO
NO
YES
YES
YES
NO
YES
YES
String
String
272
5
AUTO
900
UNDOTBS1
FALSE
c:\app\pramukh\diag\rdbms
\mproject\mproject\trace
YES
YES
YES
YES
YES
YES
String
String
57
APPENDIX B
Execution Statistics for Select & Project Query
TKProf Serial Output
TKProf: Release 11.2.0.1.0 - Development on Thu Feb 24 17:48:52 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: orclproject_s002_6512.trc
Sort options: default
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
SQL ID: 1hgzr5xxpmt7h
Plan Hash: 0
alter session set sql_trace = true
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------0
0.00
0.00
0
2
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------2
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 91
************************************************************************
58
SQL ID: 8qm74a8f09ggp
Plan Hash: 0
declare cursor NlsParamsCursor is SELECT * FROM
nls_session_parameters;begin SELECT Nvl(Lengthb(Chr(65536)),
Nvl(Lengthb(Chr(256)), 1)) INTO :CharLength FROM dual; for NlsRecord in
NlsParamsCursor loop if NlsRecord.parameter = 'NLS_DATE_LANGUAGE' then
:NlsDateLanguage := NlsRecord.value; elsif NlsRecord.parameter =
'NLS_DATE_FORMAT' then
:NlsDateFormat := NlsRecord.value; elsif
NlsRecord.parameter = 'NLS_NUMERIC_CHARACTERS' then
:NlsNumericCharacters := NlsRecord.value; elsif NlsRecord.parameter =
'NLS_TIMESTAMP_FORMAT' then
:NlsTimeStampFormat := NlsRecord.value;
elsif NlsRecord.parameter = 'NLS_TIMESTAMP_TZ_FORMAT' then
:NlsTimeStampTZFormat := NlsRecord.value; end if; end loop;end;
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------4
0.00
0.00
0
4
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------8
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
4
0
--------4
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 91
************************************************************************
SQL ID: 1zhvjzz2pz8c2
Plan Hash: 1388734953
SELECT NVL(LENGTHB(CHR(65536)), NVL(LENGTHB(CHR(256)), 1))
FROM
DUAL
call
count
cpu
elapsed
disk
query
current
---------- ------------ ----------- ------------- ----------- ----------- --------Parse
4
0.00
0.00
0
0
0
Execute
4
0.00
0.00
0
0
0
Fetch
4
0.00
0.00
0
0
0
---------- ------------ ----------- ------------- ----------- ----------- --------total
12
0.00
0.00
0
0
0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 91 (recursive depth: 1)
rows
--------0
0
4
--------4
59
Rows Row Source Operation
------- --------------------------------------------------1 FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
************************************************************************
SQL ID: 0nt1u6rszy5g3
Plan Hash: 1805486652
SELECT *
FROM
NLS_SESSION_PARAMETERS
call
---------Parse
Execute
Fetch
---------total
Count
cpu
elapsed
disk
------------ ----------- ------------- ----------4
0.00
0.00
0
4
0.00
0.00
0
4
0.00
0.00
0
------------ ----------- ------------- ----------12
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
68
--------68
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 91 (recursive depth: 1)
************************************************************************
SQL ID: aqshqh3qk0rzu
Plan Hash: 1805486652
select PARAMETER,VALUE
from
nls_session_parameters where PARAMETER in('NLS_NUMERIC_CHARACTERS',
'NLS_DATE_FORMAT','NLS_CURRENCY')
call
---------Parse
Execute
Fetch
---------total
Count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.00
0
1
0.00
0.00
0
1
0.00
0.00
0
------------ ----------- ------------- ----------3
0.00
0.00
0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
3
--------3
60
Parsing user id: 91
************************************************************************
SQL ID: 729h3vvsq0raq
Plan Hash: 1388734953
select to_char(9,'9C')
from
dual
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.00
0
1
0.00
0.00
0
1
0.00
0.00
0
------------ ----------- ------------- ----------3
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
1
--------1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 91
************************************************************************
SELECT
MAX(salary), AVG(salary)
FROM employee, department
WHERE employee.dno = department.deptno
GROUP BY employee.dno
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.01
0
1
0.00
0.00
0
1
0.01
0.00
0
------------ ----------- ------------- ----------3
0.01
0.01
0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 91
query
----------0
0
16
----------16
current
--------0
0
0
--------0
rows
--------0
0
5
--------5
61
Rows Row Source Operation
------- --------------------------------------------------5 HASH GROUP BY (cr=16 pr=0 pw=0 time=12 us cost=6 size=40 card=5)
509 TABLE ACCESS FULL EMPLOYEE (cr=16 pr=0 pw=0 time=127 us cost=5
size=4072 card=509)
************************************************************************
SQL ID: 988n7wn97ptgf
Plan Hash: 0
alter session set sql_trace = false
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.00
0
1
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------2
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 91
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------8
0.00
0.01
0
10
0.00
0.00
0
3
0.01
0.00
0
------------ ----------- ------------- ----------21
0.01
0.01
0
Misses in library cache during parse: 2
Misses in library cache during execute: 2
query
----------0
0
16
----------16
current
--------0
0
0
--------0
rows
--------0
4
9
--------13
62
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------8
0.00
0.00
0
8
0.00
0.00
0
8
0.00
0.00
0
------------ ----------- ------------- ----------24
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
72
--------72
Misses in library cache during parse: 0
18 user SQL statements in session.
0 internal SQL statements in session.
18 SQL statements in session.
************************************************************************
Trace file: orclproject_s002_6512.trc
Trace file compatibility: 11.1.0.7
Sort options: default
4 sessions in tracefile.
19 user SQL statements in trace file.
0 internal SQL statements in trace file.
18 SQL statements in trace file.
8 unique SQL statements in trace file.
261 lines in trace file.
113 elapsed seconds in trace file.
63
TKProf Parallel Output
TKProf: Release 11.2.0.1.0 - Development on Thu Feb 24 18:46:09 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: orclproject_p000_2696.trc
Sort options: default
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
SELECT /*+ PARALLEL(employee) PARALLEL(department) USE_HASH(employee)
ORDERED */
MAX(salary), AVG(salary)
FROM employee, department
WHERE employee.dno = department.deptno
GROUP BY employee.dno
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.00
0
1
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------2
0.00
0.00
0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 91 (recursive depth: 1)
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
64
Rows Row Source Operation
------- --------------------------------------------------0 PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40
card=5)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=5)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=5)
0
PX SEND HASH :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=5)
0
HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=5)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=2 size=4072
card=509)
0
TABLE ACCESS FULL EMPLOYEE (cr=0 pr=0 pw=0 time=0 us cost=2
size=4072 card=509)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------0
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- ----------1
0.00
0.00
0
1
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- ----------2
0.00
0.00
0
query
----------0
0
0
----------0
65
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
************************************************************************
Trace file: orclproject_p000_2696.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
40 lines in trace file.
elapsed seconds in trace file.
66
APPENDIX C
Execution Statistics for Join Operation
TKProf Serial Output
TKPROF: Release 11.2.0.1.0 - Development on Wed Mar 23 23:26:00 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_8420.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
SELECT /*+ NOParallel(C) NOParallel(S) NOCACHE*/
C.CUST_ID, C.CUST_FIRST_NAME, C.CUST_LAST_NAME
FROM PJADHAV.CUSTOMERS C, PJADHAV.SALES S
WHERE S.CUST_ID = C.CUST_ID
AND S.AMOUNT_SOLD > 50
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.00
0.00
0
1
0.00
0.00
0
18803
0.85
1.04
0
------------ ----------- ------------- --------18805
0.85
1.04
0
query
----------0
0
24610
----------24610
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
67
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 94 (PJADHAV)
Rows Row Source Operation
------- --------------------------------------------------282022 HASH JOIN (cr=24610 pr=0 pw=0 time=756835 us cost=1628 size=26888730
card=896291)
55500 TABLE ACCESS FULL CUSTOMERS (cr=1457 pr=0 pw=0 time=10613 us
cost=396 size=1110000 card=55500)
282022 TABLE ACCESS FULL SALES (cr=23153 pr=0 pw=0 time=298151 us
cost=1224 size=8962910 card=896291)
Rows Execution Plan
------- --------------------------------------------------0
SELECT STATEMENT MODE: ALL_ROWS
282022 HASH JOIN
55500 TABLE ACCESS MODE: ANALYZED (FULL) OF 'CUSTOMERS'
(TABLE)
282022 TABLE ACCESS MODE: ANALYZED (FULL) OF 'SALES' (TABLE)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
------------ ----------- ------------2
0.00
0.00
3
0.00
0.00
18803
0.85
1.04
------------ ----------- ------------18808
0.85
1.04
disk
-------0
0
0
-------0
query
----------0
0
24610
----------24610
Misses in library cache during parse: 2
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
68
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------0
0
0
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
1 statement EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_8420.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
1 SQL statements EXPLAINed using schema:
PJADHAV.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
19117 lines in trace file.
133 elapsed seconds in trace file.
69
TKProf Parallel Output
TKPROF: Release 11.2.0.1.0 - Development on Sat Apr 9 11:48:51 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_6112.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
SELECT /*+ MONITOR Parallel(C) Parallel(S) NOCACHE*/
C.CUST_ID, C.CUST_FIRST_NAME, C.CUST_LAST_NAME
FROM PJADHAV.CUSTOMERS C, PJADHAV.SALES S
WHERE S.CUST_ID = C.CUST_ID
AND S.AMOUNT_SOLD > 50
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.00
0.06
0
1
0.00
0.24
0
18803
0.34
0.65
0
------------ ----------- ------------- --------18805
0.34
0.96
0
query
----------0
10
0
----------10
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
70
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Rows Row Source Operation
------- --------------------------------------------------282022 PX COORDINATOR (cr=10 pr=0 pw=0 time=225181 us)
0
PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=226
size=26888730 card=896291)
0
HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=226 size=26888730
card=896291)
0
PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=55 size=1110000 card=55500)
0
PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=55
size=1110000 card=55500)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=55 size=1110000
card=55500)
0
TABLE ACCESS FULL CUSTOMERS (cr=0 pr=0 pw=0 time=0 us cost=55
size=1110000 card=55500)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=170 size=8962910
card=896291)
0
TABLE ACCESS FULL SALES (cr=0 pr=0 pw=0 time=0 us cost=170
size=8962910 card=896291)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------2
0.00
0.06
0
3
0.00
0.24
0
18803
0.34
0.65
0
------------ ----------- ------------- --------18805
0.34
0.96
0
Misses in library cache during parse: 2
Misses in library cache during execute: 1
query
----------0
10
0
----------10
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
71
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------0
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_6112.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
19113 lines in trace file.
128 elapsed seconds in trace file.
72
SQL Monitoring Report for Parallel Execution
73
APPENDIX D
Execution Statistics for Parallel DML – UNION Operation
TKProf Serial Output
TKPROF: Release 11.2.0.1.0 - Development on Sat Apr 9 13:00:15 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_7936.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
********
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
********
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
********
Update /*+ monitor noparallel(S1) nocache*/ SH.SALES_temp s1
Set S1.QUANTITY_SOLD = 2
where S1.CUST_ID in (select /*+ noparallel(C) nocache*/ c.Cust_id from SH.customers
C)
call
---------Parse
count
cpu
elapsed
------------ ----------- ------------1
0.00
0.00
disk
-------0
query
----------1
current
--------0
rows
--------0
74
Execute
Fetch
---------total
1
7.09
28.98
4149
0
0.00
0.00
0
------------ ----------- ------------- --------2
7.09
28.98
4149
4573
0
----------4574
9358516
0
--------9358516
918844
0
--------918844
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Rows Row Source Operation
------- --------------------------------------------------0
UPDATE SALES_TEMP (cr=4613 pr=4149 pw=0 time=0 us)
918844 HASH JOIN (cr=4563 pr=4149 pw=0 time=3398912 us cost=1283
size=29437507 card=949597)
55500 INDEX FAST FULL SCAN CUSTOMERS_PK (cr=123 pr=0 pw=0
time=7800 us cost=34 size=277500 card=55500)(object id 74152)
918844 TABLE ACCESS FULL SALES_TEMP (cr=4440 pr=4149 pw=0
time=2427932 us cost=1242 size=24689522 card=949597)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------3
0.00
0.00
0
4
7.09
28.98
4149
0
0.00
0.00
0
------------ ----------- ------------- --------7
7.09
28.98
4149
query
----------1
4573
0
----------4574
current
--------0
9358517
0
--------9358517
rows
--------0
918844
0
--------918844
current
--------0
rows
--------0
Misses in library cache during parse: 2
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
count
cpu
elapsed
------------ ----------- ------------13
0.00
0.00
disk
-------0
query
----------0
75
Execute
Fetch
---------total
15
0.00
0.00
0
25
0.01
0.52
283
------------ ----------- ------------- --------53
7.09
0.52
283
0
123
----------123
0
0
--------0
0
11
--------11
Misses in library cache during parse: 1
Misses in library cache during execute: 1
5 user SQL statements in session.
14 internal SQL statements in session.
19 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_7936.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
5 user SQL statements in trace file.
14 internal SQL statements in trace file.
19 SQL statements in trace file.
8 unique SQL statements in trace file.
221 lines in trace file.
29 elapsed seconds in trace file.
76
TKProf Parallel Output
TKPROF: Release 11.2.0.1.0 - Development on Sat Apr 9 12:59:11 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_6760.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
Update /*+ monitor parallel(S1) nocache*/ SH.SALES_temp s1
Set S1.QUANTITY_SOLD = 1
where S1.CUST_ID in (select /*+ parallel(C) nocache*/ c.Cust_id from SH.customers
C)
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.01
0.00
0
1
8.36
23.14
0
0
0.00
0.00
0
------------ ----------- ------------- --------2
8.37
23.14
4149
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
query
----------1
23
0
----------24
current
--------0
955840
0
--------955840
rows
--------0
918844
0
--------918844
77
Rows Row Source Operation
------- --------------------------------------------------0
UPDATE SALES_TEMP (cr=70 pr=0 pw=0 time=0 us)
1871990 PX COORDINATOR (cr=10 pr=0 pw=0 time=1435185 us)
0
PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=190
size=29437507 card=949597)
0
NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=190 size=29437507
card=949597)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us)
0
TABLE ACCESS FULL SALES_TEMP (cr=0 pr=0 pw=0 time=0 us cost=172
size=24689522 card=949597)
0
INDEX UNIQUE SCAN CUSTOMERS_PK (cr=0 pr=0 pw=0 time=0 us
cost=0 size=5 card=1)(object id 74152)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------3
0.01
0.00
0
4
8.36
23.15
0
0
0.00
0.00
0
------------ ----------- ------------- --------7
8.37
23.15
0
query
----------1
23
0
----------24
current
--------0
955841
0
--------955841
rows
--------0
918844
0
--------918844
current
--------0
0
0
--------0
rows
--------0
0
14
--------14
Misses in library cache during parse: 2
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------14
0.00
0.00
0
14
0.00
0.00
0
27
0.00
0.00
0
------------ ----------- ------------- --------55
0.00
0.00
0
query
----------0
0
124
----------124
78
Misses in library cache during parse: 0
5 user SQL statements in session.
13 internal SQL statements in session.
18 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_6760.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
5 user SQL statements in trace file.
13 internal SQL statements in trace file.
18 SQL statements in trace file.
6 unique SQL statements in trace file.
208 lines in trace file.
23 elapsed seconds in trace file.
79
SQL Monitoring Report for Parallel Execution of Update Statement
80
APPENDIX E
Execution Statistics Concurrent Executions
TKProf Serial Update Statement Output
TKPROF: Release 11.2.0.1.0 - Development on Mon Apr 4 22:58:26 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_8788.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
Update /*+ monitor noparallel(S1) nocache*/ SH.SALES_temp s1
Set S1.QUANTITY_SOLD = 1
where S1.CUST_ID in (select /*+ noparallel(C) nocache*/ c.Cust_id from SH.customers
C)
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.00
0.00
0
1
7.37
22.63
0
0
0.00
0.00
0
------------ ----------- ------------- --------2
7.37
22.63
0
query
----------0
4626
0
----------4626
current
--------0
939140
0
--------939140
rows
--------0
918844
0
--------918844
81
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 94
Rows Row Source Operation
------- --------------------------------------------------0
UPDATE SALES_TEMP (cr=4874 pr=0 pw=0 time=0 us)
918844 HASH JOIN (cr=4564 pr=0 pw=0 time=1499023 us cost=1284
size=11944972 card=918844)
55500 INDEX FAST FULL SCAN CUSTOMERS_PK (cr=123 pr=0 pw=0
time=7289 us cost=34 size=277500 card=55500)(object id 74152)
918844 TABLE ACCESS FULL SALES_TEMP (cr=4441 pr=0 pw=0 time=500128 us
cost=1242 size=7350752 card=918844)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------3
0.00
0.00
0
4
7.37
22.63
0
0
0.00
0.00
0
------------ ----------- ------------- --------7
7.37
22.63
0
query
----------0
4626
0
----------4626
current
--------0
939141
0
--------939141
rows
--------0
918844
0
--------918844
current
--------0
0
0
--------0
rows
--------0
0
62
--------62
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------62
0.00
0.00
0
62
0.00
0.00
0
124
0.00
0.00
0
------------ ----------- ------------- --------248
0.00
0.00
0
query
----------0
0
248
----------248
82
Misses in library cache during parse: 0
4 user SQL statements in session.
62 internal SQL statements in session.
66 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_8788.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
4 user SQL statements in trace file.
62 internal SQL statements in trace file.
66 SQL statements in trace file.
5 unique SQL statements in trace file.
638 lines in trace file.
22 elapsed seconds in trace file.
83
TKProf Serial Select Statement Output
TKPROF: Release 11.2.0.1.0 - Development on Mon Apr 4 22:56:43 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_3772.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
SELECT /*+ MONITOR NOPARALLEL(C) NOPARALLEL(S) NOCACHE*/
C.CUST_ID, C.CUST_FIRST_NAME, C.CUST_LAST_NAME
FROM SH.CUSTOMERS C, SH.SALES_temp S
WHERE S.CUST_ID = C.CUST_ID
AND S.AMOUNT_SOLD > 50
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.00
0.00
0
1
0.00
0.00
0
18803
0.98
9.72
0
------------ ----------- ------------- --------18805
0.98
9.72
0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 94
query
----------0
0
108375
----------108375
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
84
Rows Row Source Operation
------- --------------------------------------------------282022 HASH JOIN (cr=108375 pr=0 pw=0 time=729567 us cost=1660
size=26888730 card=896291)
55500 TABLE ACCESS FULL CUSTOMERS (cr=1459 pr=0 pw=0 time=10997 us
cost=405 size=1110000 card=55500)
282022 TABLE ACCESS FULL SALES_TEMP (cr=106916 pr=0 pw=0 time=312232
us cost=1247 size=8962910 card=896291)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------2
0.00
0.00
0
3
0.00
0.00
0
18803
0.98
9.72
0
------------ ----------- ------------- --------18808
0.98
9.73
0
query
----------0
0
108375
----------108375
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------0
0.00
0.00
0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
query
----------0
0
0
----------0
85
3 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_3772.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
19071 lines in trace file.
115 elapsed seconds in trace file.
86
TKProf Parallel UPDATE statement Output
TKPROF: Release 11.2.0.1.0 - Development on Mon Apr 4 23:11:53 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_p000_6600.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
Update /*+ monitor parallel(S1) nocache*/ SH.SALES_temp s1
Set S1.QUANTITY_SOLD = 1
where S1.CUST_ID in (select /*+ parallel(C) nocache*/ c.Cust_id from SH.customers
C)
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------2
0.00
0.01
0
3
0.88
18.94
0
0
0.00
9.72
0
------------ ----------- ------------- --------5
0.88
18.95
0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 94 (recursive depth: 1)
query
----------0
351901
0
----------351901
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
87
Rows Row Source Operation
------- --------------------------------------------------0
UPDATE SALES_TEMP (cr=0 pr=0 pw=0 time=0 us)
0
PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0
PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=189
size=11944972 card=918844)
2055 NESTED LOOPS (cr=2081 pr=0 pw=0 time=6290 us cost=189
size=11944972 card=918844)
2055 PX BLOCK ITERATOR (cr=13 pr=0 pw=0 time=1415085 us)
2055 TABLE ACCESS FULL SALES_TEMP (cr=13 pr=0 pw=0 time=1414481 us
cost=172 size=7350752 card=918844)
2055 INDEX UNIQUE SCAN CUSTOMERS_PK (cr=2068 pr=0 pw=0 time=0 us
cost=0 size=5 card=1)(object id 74152)
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------0
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------2
0.00
0.01
0
3
0.88
18.94
0
0
0.00
9.72
0
------------ ----------- ------------- --------5
0.88
18.95
0
query
----------0
351901
0
----------351901
88
Misses in library cache during parse: 0
2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_p000_6600.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
2 sessions in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
1 unique SQL statements in trace file.
61 lines in trace file.
18 elapsed seconds in trace file.
89
TKProf Parallel Select Statement Output
TKPROF: Release 11.2.0.1.0 - Development on Mon Apr 4 23:09:27 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_5632.trc
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
************************************************************************
count = number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
************************************************************************
error connecting to database using: /@
EXPLAIN PLAN option disabled.
************************************************************************
SELECT /*+ MONITOR PARALLEL(C) PARALLEL(S) NOCACHE*/
C.CUST_ID, C.CUST_FIRST_NAME, C.CUST_LAST_NAME
FROM SH.CUSTOMERS C, SH.SALES_temp S
WHERE S.CUST_ID = C.CUST_ID
AND S.AMOUNT_SOLD > 50
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.01
0.08
0
1
0.00
0.09
0
18803
0.34
0.61
0
------------ ----------- ------------- --------18805
0.35
0.79
0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 94
query
----------0
10
0
----------10
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
90
Rows Row Source Operation
------- --------------------------------------------------282022 PX COORDINATOR (cr=10 pr=0 pw=0 time=228125 us)
0
PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=230
size=26888730 card=896291)
0
HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=230 size=26888730
card=896291)
0
PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=56 size=1110000 card=55500)
0
PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=56
size=1110000 card=55500)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=56 size=1110000
card=55500)
0
TABLE ACCESS FULL CUSTOMERS (cr=0 pr=0 pw=0 time=0 us cost=56
size=1110000 card=55500)
0
PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=173 size=8962910
card=896291)
0
TABLE ACCESS FULL SALES_TEMP (cr=0 pr=0 pw=0 time=0 us cost=173
size=8962910 card=896291)
************************************************************************
SQL ID: aam2chsgpj7mb
Plan Hash: 0
alter session set sql_trace=false
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------1
0.00
0.00
0
1
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------2
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 94
************************************************************************
SQL ID: 1hgzr5xxpmt7h
Plan Hash: 0
alter session set sql_trace = true
91
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
1
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------1
0.00
0.00
0
query
----------0
0
0
----------0
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 94
************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------2
0.01
0.08
0
3
0.00
0.09
0
18803
0.34
0.61
0
------------ ----------- ------------- --------18808
0.35
0.79
0
query
----------0
10
0
----------10
current
--------0
0
0
--------0
rows
--------0
0
282022
--------282022
current
--------0
0
0
--------0
rows
--------0
0
0
--------0
Misses in library cache during parse: 2
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call
---------Parse
Execute
Fetch
---------total
count
cpu
elapsed
disk
------------ ----------- ------------- -------0
0.00
0.00
0
0
0.00
0.00
0
0
0.00
0.00
0
------------ ----------- ------------- --------0
0.00
0.00
0
Misses in library cache during parse: 0
query
----------0
0
0
----------0
92
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
0 statements EXPLAINed in this session.
************************************************************************
Trace file: C:\app\pramukh\diag\rdbms\mproject\mproject\trace\mproject_ora_5632.trc
Trace file compatibility: 11.1.0.7
Sort options: prscnt prscpu prsela prsdsk prsqry prscu prsmis
execnt execpu exeela exedsk exeqry execu exerow
exemis fchcnt fchcpu fchela fchdsk fchqry fchcu
fchrow
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
19127 lines in trace file.
135 elapsed seconds in trace file.
93
BIBLIOGRAPHY
[1] Oracle 9i Database Concepts Release 2(9.2). Part Number A96524-01. [Online].
Available:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/c20paral.htm
[2] Oracle Database Concepts 10g Release 2(10.2). Part Number B14223-02. [Online].
Available:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/parpart.htm
[3] Using Oracle’s Parallel Execution Features, Acadia Publications. [Online]. Available:
http://www.akadia.com/services/ora_parallel_processing.html
[4] Oracle8(TM) Server Tuning Release 8.0. Part Number A54638-01. [Online].
Available:
http://www.cs.umbc.edu/portal/help/oracle8.bak/server803/A54638_01/parlexec.htm
[5] Oracle Database Data Warehousing Guide 11g Release 1(11.1). Part Number
B28313-02. Available:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28313/usingpe.htm
[6] Oracle Database Performance Tuning Guide 10g Release 1 (10.1). Part Number
B10752-01. Available:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/optimops.htm
[7] Oracle8i Designing and Tuning for Performance Release 2(8.1.6). Part Number
A76992-01. Available:
http://download.oracle.com/docs/cd/A84870_01/doc/server.816/a76992/optimops.htm
94
[8] Oracle9i Database Performance Tuning Guide and Reference Release 2(9.2). Part
Number A96533-02. [Online]. Available:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96533/ex_plan.htm
[9] Oracle8 Tuning Release 8.0. Part Number A58246-01. [Online]. Available:
http://download.oracle.com/docs/cd/A58617_01/server.804/a58246/pexdiag.htm
[10] Oracle9i Database Performance Tuning Guide and Reference Release 2(9.2). Part
Number A96533-02. [Online]. Available:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96533/sqltrace.htm#BEGIN
[11] Use EXPLAIN PLAN and TKPROF To Tune Your Applications, by Roger Schrag,
Database Specialists, Inc. [Online]. Avaliable:
http://www.dbspecialists.com/files/presentations/use_explain.html
[12] Amdahl’s Law for Speedup and Eficiency. [Online]. Avaliable:
http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl.html
[13] Optimizer Modes – Oracle Tips by Burleson Consulting. [Online]. Available:
http://www.remote-dba.net/t_op_sql_optimizer_mode.htm
[14] Oracle Database Reference 11g Release 1(11.1) – Plan Table. [Online]. Available:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/statviews_5127.htm