ORACLE ARCHITECTURE

OPTIMIZATION

Optimizer is the heart of the SQL processing

engine. The Optimizer decides the most
efficient way to execute a SQL statement.
The Oracle server provides two methods of
optimizations. Cost-based(CBO) and Rule-
based (RBO).

Page 1
 Execution Plan
To execute a DML statement, Oracle may
need to perform many steps. The combination
of the steps Oracle uses to execute a statement
is called an execution plan. An execution plan
includes an access method for each table that
the statement accesses and an ordering of the
tables.

Page 2
Steps of Execution Plan

Each step of the execution plan returns a set of

rows that either are used by the next step or, in
the last step, are returned to the user or
application issuing the SQL statement. A set of
rows returned by a step is called a row source.

page 3
 RBO VS CBO

The rule-based optimizer looks only at the

syntax of your SQL statements and checks
whether fields are indexed or not. Whereas the
CBO compares the amount of disk I/O and
CPU resources required for different execution
plans.

Page 4
 Choosing the default Optimizer
An Optimizer for a database can be choose by changing
the OPTIMIZER_MODE in the database parameter file.
The following are the parameters for CBO :
CHOOSE: Enable cost based optimizer.
ALL_ROWS: Optimizes with a goal of minimum
resource use to complete the entire statement.
FIRST_ROWS: Optimizes with a goal of best response
time i.e. Minimum resource use to return the first few
rows of the result sets.
RULE: This restricts Oracle to use a Rule-based approach.
Page 5
 Explain Plain
The EXPLAIN PLAN statement displays execution plans
chosen by the Oracle optimizer for any DML statements. A
statement’s execution plan is the sequence of operations
Oracle performs to execute the statement. The components of
execution plan include:
1.An ordering of the tables referenced by the statement.
2.An access method for each table mentioned in the statement.
3.A join method of tables affected by the join operations in the
statement.
Page 6
 Using the EXPLAIN PLAN
Creating The Output Table:
Before issuing an EXPLAIN PLAN statement, create a table to
hold its output. Run the SQL script UTLXPLAN.SQL to create a
sample output table called PLAN_TABLE.
Run utlbstat.sql and then given the command ‘ANALYZE
TABLE EMP COMPUTE STATISTICS’ to compute the
statistics.
Displaying PLAN_TABLE output:
Display the most recent plan table output using the following
scripts:
UTLXPLS.SQL: Shows plan table output for serial processing.
UTLSPLP.SQL: Shows plan table output with parallel execution
columns and also indentify the number of rows processed by each
step in the plan, which helps to identify inefficiencies in the
After creating a explain table, we can explain the execution plan
of a query.
E.g. Explain plan set statement_id=‘a1’ for select * from emp;

page 8
 USING HINTS
Hints are used to speed up the DML statements we run on our database.
Oracle makes it possible to speed performance of insert statements using
some technique to set a direct path to disk for your inserted data. A direct
path is a method for loading data in Oracle that bypass certain aspects of
the Oracle in order to improve the performance of the data. To make it
possible we have to pass some hints to the Oracle optimizer.
Let us consider the following example:
insert into balraj.emp (select * from scott.emp);
The above statement takes time to be executed as it follows the default
Oracle optimizer rule. TO speed it up we can follow the following
process:
Insert /* append */ into balraj.emp nologging (select * from scott.emp);
Page 9
 The AUTOTRACE utility
This utility can be used to trace the queries automatically.
SQL*PLUS will execute the query and display the execution plan
following the results.
Consider the following example:
SET AUTOTRACE ON explain
SELECT * FROM SCOTT.EMP ORDER BY ENAME;
OR
SET AUTOTRACE TRACEONLY EXPLAIN
select * from scott.emp order by ename;
Using this we don’t need to query the plan table.
After using AUTOTRACE, we can turn it off by issuing SET
AUTOTRACE OFF.
SQL trace and TKPROF
The SQL trace facility and TKPROF let us accurately access the
efficiency of the SQL statements. When this facility is enabled,
performance statistics for all SQL statements executed in a user
session are placed into trace files. We can run the TKPROF
program to format the contents of the trace file and place the
output into a readable output file.The following steps are to be
followed to deal with the this.

Page 11
Using SQL trace and TKPROF
The following steps can be followed for using this utility.
1. Set initialization parameters for trace file management.
TIMED_STATISTICS:-Controls whether Oracle tracks CPU
and elapsed time for each statement. This should be TRUE.
MAX_DUMP_FILE_SIZE:-Control the maximum size of the
trace file generated by the SQL Trace facility.
USER_DUMP_DEST:- Points to the directory where trace files
are created.
We can find our trace file by issuing the following command:
SELECT VALUE FROM V$PARAMETER WHERE
NAME=‘USER_DUMP_DEST
 2.Enabling the SQL trace
feature

The SQL Trace feature can be used in three ways:

1. Issue an ALTER SESSION command.
(To trace the current session)
2. Make a call to
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION.
(We can trace another session)
3.Set SQL_TRACE=TRUE in the database parameter file.
(To enable this facility for our instance i.e. all the sessions in our
instance.)
Page 13
3. Using TKPROF

TKPROF accepts as input a trace file produced by the SQL trace

facility, and it produces a formatted output file. It is also used to
generate execution plans. It is a command line utility. The
following is an example of using the utility of TKPROF:
1.select username, sid ,serial# form v$session;
2.execute
dbms_system.set_sql_trace_in_session(<sid>,<serial#>,TRUE)
3.tkprof c:\oracle\admin\orcl\udump\<tracefile name>
c:\oracle\admin\orcl\udump\<new file name> sort execpu
explain=scott/tiger
Page 14