.

Oracle Performance Tuning

 Oracle components

Data

Actual data

Redo

Changes made to the database-Used for recovery

Undo

Consistency
 How oracle engine works

Oracle physical components

Oracle memory structures and
Background processes
 Data Storage---Physical structures

Data files

Log files

Control files

Archive files

Init file
 Data Storage---Logical Structures

Table space

Segments

Extents

Blocks
Oracle Memory components
Oracle RDBMS Architecture

Background Processes

SGA
Oracle
Server Processes

Client Processes
 Oracle Architecture
System Global Area
SMON Instance Lock Area Large Pool Redo Log Buffer Pnnnn

UGA I/O Buffer

Area
PMON Shared Pool RECO
Database Buffer Cache
Library Data
Cache Dictionary
Snnnn SNPnn
Cache

Shared SQL Area

Dnnnn LCKn

INSTANCE DBWR CKPT LGWR ARCH

DATABASE
SERVER
DATA Archived
Redo Redo Logs
PGA USER
Logs Logs
INDEX
TEMP Group 1 Group 2 Alert
Datafiles ROLLBACK File
Parameter Password
SYSTEM Control
USER File File
Files
INIT.ORA orapwSID Trace
Files
 Oracle memory structures

SGA --Shared global area

PGA --Program global area

Large pool area

Java pool area

 System Global Area
Database Buffers Redo Buffer Redo Buffer
Dictionary Buffers

Shared Pool

Database buffer cache Holds data

Log buffer Holds changes
Shared pool area Holds Parsing information
 Shared pool area

Library Cache Data dictionary cache

Shared sql area Private Sql area

Persistentarea Runtime area

Shared Pool Tuning
 Background Processes

Smon
Pmon
Dbwr
Lgwr
Arch
SNPn
LCKnn
Pnn
Snn
Dnn
How Oracle engine works
 What happens when you press “Enter”?

 SQL Statement Processing

 Parse
 Define
 Bind
 Execute
 Fetch (For SELECT only)
 SQL Statement Processing - Parse

 Steps in Parsing
 Syntax Check
 Object Resolution
 Security Check
 Build Parse Tree & Execution Plan
 Store Parse Tree & Execution Plan in the
 Shared SQL Area (Lib. Cache)
 In 9i and up, bind variable value peeking is performed
 Hard vs. Soft Parse
 SQL Statement Processing - Define

 Resolve and map data types on the client and the server
 SQL*Net is involved
 ARRAYSIZE negotiated
 SQL Statement Processing - Bind

 All bind variables(:v_id, :v_name etc.) are bound with their current
values
 SQL is not hard-parsed for varying values
 Facilitates re-use of SQL
 SQL Statement Processing - Execute

 Execution Plan is applied on the SGA

 Data is read or written to
 If SQL is DML then
Redo & Rollback is generated;
Transactional operations are performed;
End If;
 SQL Statement Processing -
Fetch

 Data is fetched for SELECTs only

 Number of fetches is subject to ARRAYSIZE
 ARRAYSIZE has a direct impact on the amount of logical I/O in
your database
 Perform array fetches and PL/SQL array processing when

possible
 SQL*Plus - SET ARRAYSIZE n
 Forms - Set the Records Fetched Block Property Sheet
Parsing
 Selecting a record

Segment header Root block

Branch Branch

Leaf Leaf

Branch
 Updating a record

Records the data change in log buffer

Reserve space from rollback segment (Transaction table)

Writes a plan to know how to get the old value if the user gives rollback

Updates the record

Tuning
 Application Tuning

 Access paths

 Sql tools and utilities

 Indexes

 Optimizer

 Joins

 Sorting

 Hints

 Parallel

 Trouble-shooting - are there any quick fixes

 
 Access paths

Full table scan

sample scans
rowid scans
index unique scan
 index range scan
index fast full scans
 index full scans
 index joins
 bitmap joins
 cluster scans
hash scans
 Access Paths

Full table scan

Index scan

Rowid scan

Index fast full scan Count (*)

 So what’s a full-table
scan?

 A full-table scan is the process of reading all blocks of a

database table sequentially

 When a full-table scan occurs, indexes on the scanned

table are not used

 Because of the volume of data processed, they can

consume large amounts of I/O bandwidth

• More often than not, full-table scans were the cause of bad
query performance
 FTS effects on buffer cache

Buffer Cache LRU List

Most Recently Used (MRU) Least Recently Used (LRU)

Block aging

Blocks accessed by index Blocks accessed by

start here default FTS start here
Blocks accessed by FTS start
here if CACHEd
 Full table scan

 Disk subsystems have improved dramatically to

increase I/O bandwidth, relative to overall database
size and number of users

 Significant performance gains can now be achieved

by properly using full-table scans
 Full table scan

The usual reasons why full-tables scans



Missing indexes on large tables



A poor indexing strategy on large tables



Missing table or index statistics


 Full-table scan performance

Must have correct indexes on large tables to avoid

inappropriate full-tables scans

Drop indexes on small tables unless they support

primary or unique key constraints

•db_file_multi_block_read_count

Maximum number of blocks read for each physical I/O

operation during a full-table scan
–OS dependent
–Typically 8 to 64 (Default=8 on Solaris)
Diagnostic and Tuning Tools
 Diagnostic and Tuning Tools

“If you can’t measure it, you can’t manage it.” —Peter Drucker

• Software performance is measured by its speed

• Speed = Result ÷ Time

• If you can’t measure the time it takes for an application to produce

a result,then you can’t manage its performance.
Explain plan

Tkprof

V$scripts

Statspack

Oracle enterprise manager

 Explain Plan

An explain plan is a representation of the access path that is taken when

a query is executed within Oracle

Create plan_table
@$ORACLE_HOME/rdbms/admin/utlxplan.sql

Explain plan for

Select * from emp where dno=10 order by ename

Query

@$ORACLE_HOME/rdbms/admin/utlxpls.sql
@$ORACLE_HOME/rdbms/admin/utlxplp.sql
 Explain plan

Output
Reading the Execution Plan
Query Plan
--------------------------------------------------------------------------------
1.0 SELECT STATEMENT Statement1 Cost = 36 (For analyzed only)
2.1 SORT ORDER BY (7th)
3.1 FILTER (6th)
4.1 NESTED LOOPS OUTER (5th)
5.1 TABLE ACCESS BY ROWID BK (2nd)
6.1 INDEX RANGE SCAN I_BK_06 NON-UNIQUE (1st)
5.2 TABLE ACCESS BY ROWID EE (4th)
6.1 INDEX UNIQUE SCAN I_EE_01 UNIQUE (3rd)
 Operations

TABLE ACCESS FULL

TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN
INDEX RANGE SCAN
NESTED LOOPS
HASH JOIN
MERGE JOIN
REMOTE
SORT ORDER BY
SORT GROUP BY
SORT JOIN
 Explain plan

TABLE ACCESS FULL

Perform a full table scan of the indicated table
SORT ORDER BY
Sort the input rows for the purpose of satisfying an ORDER BY clause. Input: the rows
to be sorted. Output: the rows in sorted order.

INDEX UNIQUE SCAN

Look up a complete key in a unique index. Output: Zero or one ROWIDs from the
index.
INDEX RANGE SCAN
Look up a key in a non-unique index, Output: Zero or more ROWIDs from the index.
Single Table, no Index (1.5)
SELECT * >.SELECT STATEMENT
>...TABLE ACCESS by rowid emp
FROM emp
WHERE rowid=
‘00004F2A.00A2.000C’

 Table access by rowid

 Single row lookup
 Goes straight to the block, and filters the row
 Fastest way to retreive one row
 If you know its rowid
Single Table, Index (2.1)
SELECT * >.SELECT STATEMENT
>...TABLE ACCESS by rowid emp
FROM emp >.....INDEX unique scan i_emp_pk
WHERE empno=174;

Unique emp(empno)

 Index Unique Scan

 Traverses the node blocks to locate correct leaf block
 Searches value in leaf block (if not found => done)
 Returns rowid to parent row-source
 Parent: accesses the file+block and returns the row
Single Table, Index (2.2)
SELECT * >.SELECT STATEMENT
>...TABLE ACCESS by rowid emp
FROM emp >.....INDEX range scan i_emp_pk
WHERE empno>100;

Unique emp(empno)

 Unique Index Range Scan

 Traverses the node blocks to locate most left leaf block with start
value
 Searches 1st occurrence of value-range in leaf block
 Returns rowid to parent row-source
 Parent: accesses the file+block and returns the row
 Continues on to next valid occurrence in leaf block
 Until no more occurences / no longer in value-range
Single Table, Index (2.3)
SELECT * >.SELECT STATEMENT
>...TABLE ACCESS by rowid emp
FROM emp >.....INDEX range scan i_emp_j_h
WHERE job=‘manager’
AND hiredate=’01-01-2001’;

Emp(job,hiredate)

 Full Concatenated Index

 Use job-value to navigate to sub-Btree
 Then search all applicable hiredates
Single Table, Index (2.6)
SELECT * >.SELECT STATEMENT
>...TABLE ACCESS by rowid emp
FROM emp >.....INDEX range scan i_emp_j_h
WHERE hiredate=’01-01-2001’;

Emp(job,hiredate)

 Index Skip Scan (prior versions did FTS)

 “To use indexes where they’ve never been used before”
 Predicate on leading column(s) no longer needed
 Views Btree as collection of smaller sub-Btrees
 Works best with low-cardinality leading column(s)
 Tkprof

Setting Autotrace (SQL*Plus 3.3) and Timing On

 TKPROF

Alter session set sql_trace=true

Alter session set tracefile_identifier=‘sense’

Run your application / execute sql statements.

user_dump_dest.
 TKPROF performance

database server

“raw” SQL trace file TKPROF report file

TKPROF program

Use TKPROF to convert the trace file into a readable format.

 TKPROF <trace filename> <output filename>
 TKPROF

Set auto trace on

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 3117 0.83 0.92 0 0 0 3113
Fetch 3117 7.03 9.88 40 55902 0 3105
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 6235 7.86 10.80 40 55902 0 6218
 TKPROF output

*******************************************************************************
*
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

*******************************************************************************
*
 Autotrace Output
Set autotrace on

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'EMP7_I1' (NON-UNIQUE)
 Autotrace Output
Statistics
0 recursive calls
0 db block gets
1 consistent gets
1 physical reads
0 redo size
223 bytes sent via SQL*Net to client
274 bytes recd via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
 Setting Timing On

SQLPLUS> SET TIMING ON

SQLPLUS> select count(name) from emp7
Where name = 'branches';

COUNT(NAME)
--------------
100
Elapsed: 00:00:00.84
 V$scripts

V$session

V$sql

V$process

V$sysstat

V$library cache

V$rollstat

V$sqlarea
 Statspack

SQL> connect / as sysdba\

SQL> @$ORACLE_HOME/rdbms/admin/spcreate

Tables ---Begins with STAT$

 DBMS PROFILER

@$ORACLE_HOME/rdbms/admin/profload.sql
@$ORACLE_HOME/rdbms/admin/proftab.sql

PLSQL_PROFILER_RUNS
PLSQL_PROFILER_UNITS
PLSQL_PROFILER_DATA
Questions?
Indexes—Walk Through
 The Concept of an Index

 An index contains a pointer for each table row (rowid)

 We want a cross-reference of the table to enable us to access the data rows

quickly

 When an index block cannot store pointers to all data, a second index block is
created and a pointer is placed in the root block to the newly created index
block
 Index

•Index read I/O is sequential in nature

–Oracle wait-event for single-block I/O requests used
during indexed access
–“db file sequential read”
–Used with RANGE, UNIQUE, and FULL scans
–FAST FULL index-scans are an exception
–Uses sequential multiblock I/O similar to FULL
table-scans
 Index Types

Type Introduced
Bitmap Indexes 7.3.2
Index Organised Table 8.0
Partitioned Indexes 8.0
Reverse Key 8.0
LOB Index 8.0
Compressed 8.1.5
Function-Based Indexes 8.1.5
Descending 8.1.5
Virtual Indexes 8.1.5
Bitmap Join Indexes 9.0.1
 INDEXES

Create Index (example)

 Create Index scott.empno_idx1 on scott.emp(Empno)

 Create Index scott.empno_idx1 on scott.emp(Empno,ename,sal)

 INDEXES

B*tree
 Insertion

Inserting 'ENG','SCO' and 'USA'

Before After
ENG
SCO
USA

Index initially has single empty leaf block at root. Rows are
inserted into leaf block
 Insertion

Inserting 'BEL'
Before After
ENG U
SCO
USA

BEL USA
ENG
SCO

Root node is now a branch block. Two new leaf nodes created.
Leaf rows split between the two new blocks
 Insertion

Inserting 'SPA'
Before After
U S U

BEL USA BEL SCO USA

ENG ENG SPA
SCO

New leaf node created. Leaf rows split between the two leaf
nodes. New leaf block pointer added to branch block
 When Are Bitmap Indexes Not Useful?

When row level locking is required - locking on the bitmap index is done
at the bitmap category level.

High volume OLTP systems

A full table scan is often more efficient if only a single bitmap value is
filtered

Bitmaps would kill concurrency

 BITMAP INDEX

Restrictions

Bitmap indexes are not supported for Trusted Oracle.

Not used by the rule-based optimizer.

Cannot be used on a partitioned table as a global index.

No online build/rebuild support for bitmap indexes

Bitmap indexes cannot be used for referential integrity checking


A bitmap index cannot be declared as UNIQUE.

Until 9i, you cannot specify BITMAP when creating an index-organized

table.

You cannot specify BITMAP for a domain index.

 Initialization Parameters for Bitmap Indexing

CREATE_BITMAP_AREA_SIZE
Determines the amount of memory allocated for bitmap creation.
Default is 8MB. If cardinality is small, this value can be reduced
significantly.

BITMAP_MERGE_AREA_SIZE
Amount of memory to use for merging bitmap strings. Default value
is 1MB. Larger value can improve performance since the bitmap segments
must be pre-sorted before being merged into a single bitmap.
 Function based index:

 
 
Function-based indexes introduced in Oracle release 8.1 provides an efficient
mechanism to evaluate predicates involving functions

Init.ora to set:
optimizer_goal=choose|first_rows|all_rows

query_rewrite_enable = true
query_rewrite_integrity = trusted

Create index emp_idx on emp (UPPER(ename));

 Function based index:
The main features of Function-based Indexes are
 

Used by cost-based optimizer.

Can be created either as B*Tree or bitmap index.

Index can be build on an arithmetic expression or expression containing

PL/SQL, package functions, C callout or SQL built-in functions.

Improves query performance.

Indexes can be created on object columns and REF columns by using

methods defined for the object.

Function based indexing is only available in the Enterprise Edition and is not
available in the Standard Edition.
 Function based index:
Restrictions

 
1.Function-based indexes cannot be created on

a) LOB columns,

b) Nested table column

c) Aggregate functions are not allowed in the expressions of the index.

Example: SUM, AVG, etc.

d) It can only be used with Cost Based optimizer. The rule based optimizer will
never use function-based indexes.

e) Since function cannot return NULL you cannot store null values
 Indexing ---Case when

Selective Uniqueness
You have a table with versioned information in it
A project table with status "ACTIVE" and "INACTIVE"
When status is "ACTIVE", some set of columns must be unique
When status is "INACTIVE", those columns may contain any values -- any
number of duplicates
How can you do it?
 Indexing—Case when

create table project

(project_ID number primary key,
teamid number, job varchar2(100),
status varchar2(20) check (status in ('ACTIVE', 'INACTIVE')) );
 
create UNIQUE index
job_unique_in_teamid on project
( case when status = 'ACTIVE' then teamid else null end,
case when status = 'ACTIVE' then job else null end )
 REVERSE Key Indexes

 REVERSE indexes
 causes monotonically-ascending data values to become more random
by simply reversing data
 “123456” becomes “654321”
 “123457” becomes “754321”, etc...
 data is transparently converted and unconverted upon insert and
retrieval
 data is re-fitted to fit Oracle’s original design decision
 Impact:
 only equivalence operations will use the index
 “=“, “!=“, “<>”, “IN”, and “NOT IN”
 range-scans will not use the index
 “>”, “>=“, “<“, “<=“, “LIKE”, “BETWEEN”
 What Columns to Index

 Columns that are often found in the WHERE clause

 Columns that are used to join tables.

 When the query will return less then 15% of the rows in a
large table.
 Columns not to Index

 Columns that are constantly updated.

 Columns that contain a lot of null values.

 Columns that have a poor distribution of data

 Finding index usage

Index Monitoring (9i)

Index1 Index2
Index3 Index4
Index5 Index6

Oracle9i

Monitor which index

is not used

select index_name,monitoring,used,start_monitoring,
end_monitoring from v$object_usage;
 Finding index usage

 
Monitor Index Usage (9i)
Start/Reset: ALTER INDEX <index> MONITORING USAGE.
Stop: ALTER INDEX <index> NOMONITORING

Views
 
User_indexes
User_ind_columns
V$object_usage (9i)
Index_stats
 Oracle9i Key Index Features

• Skip Scan Index

 Allows the use of the 2nd part of an index

 Can also be a source of problems if not careful

• Bitmap Join Index

 Allows a single index to span two tables

 Requires the use of a unique constraint
 Can give substantial performance gains
 Oracle9i Skip/Scan Index

The Skip/Scan Index:

 Allows you to scan the index instead of the table
 Saves you from doing a full table scan
 Create index year_state_idx on test2(year, state);

First Part
Of Index
(YEARS)

Second Part Second Part

Of Index Of Index
A-M N-Z
 Oracle9i Skip/Scan Index

 Skips the first part of the index (YEAR)

 Scans the second part of the index (STATE)
 SELECT COUNT(*)FROM TEST2 WHERE STATE=‘AL’

First Part Skip this level

Of Index
2001
Second Part Second Part Scan this level
Of Index Of Index
AL AZ
 Bitmap Join Index:

Allows a single index to span two tables

Requires the use of a unique constraint
• CREATE TABLE EMP1 AS SELECT * FROM SCOTT.EMP;

• CREATE TABLE DEPT1 AS SELECT * FROM SCOTT.DEPT;

• ALTER TABLE DEPT1

ADD CONSTRAINT DEPT_CONSTR1 UNIQUE (DEPTNO);

CREATE BITMAP INDEX EMPDEPT_IDX

ON EMP1(DEPT1.DEPTNO) FROM EMP1, DEPT1
WHERE EMP1.DEPTNO = DEPT1.DEPTNO
 Usage---Bitmap Join Index:

SELECT /*+ INDEX(EMP1 EMPDEPT_IDX) */ COUNT(*)

FROM EMP1, DEPT1
WHERE EMP1.DEPTNO = DEPT1.DEPTNO;
 Advanced tips for index monitoring

Binary height-----User_indexes

This should be low

CLUSTERING FACTOR
SELECTIVITY TAKE EG FROM CBO

The Skewness Problem

Index parameters—opt_ind_cost_adj
Questions?
OPTIMIZER
 Optimizer

The Optimizer_Mode Parameter - Values

Rule
Choose
cost
Optimizer_Goal - Values
Rule
All_Rows - Get all rows fastest (Reports)
First_Row - Get the first row fast (Forms)
Choose (Fix problem areas)
Alter Session set Optimizer_Goal = <mode>;
 How to set which one?

 Instance level: Optimizer_Mode parameter

 Rule
 Choose
 if statistics then CBO (all_rows), else RBO
 First_rows, First_rows_n (1, 10, 100, 1000)
 All_rows
 Session level:
 Alter session set optimizer_mode=<mode>;
 Statement level:
 Hints inside SQL text specify mode to be used
 Optimizer

FIRST_ROWS_1
FIRST_ROWS_10
FIRST_ROWS_100
FIRST_ROWS_1000
alter system set optimizer_mode = first_rows_100;
alter session set optimizer_mode = first_rows_100;
select /*+ first_rows(100) */ from student;
 Oracle and the Optimizers

 Rule based (RBO)

– Set OPTIMIZER_MODE to RULE or use RULE hint
– Doesn't use statistics
– No new development

 Cost Based (CBO)

– Set OPTIMIZER_MODE to CHOOSE, FIRST_ROWS, ALL_ROWS
or use Hints
– Must have statistics
 RBO--Mechanisms

RBO makes linear, step-by-step decisions. It makes a decision,and

then uses that decision as the basis for considering the next decision.
As it progresses from each step to another, it considers an
ever-narrowing set of possibilities, dependent on earlier decisions.
 RBO--Mechanisms

The text of the SQL statement itself

Basic information about the Tables, clusters, and views in the FROM clause

The data type of the columns referenced in the other clauses

The data type of the columns referenced in the other clauses

Data dictionary information is only available for the local database.

 Ranks for RBO
Rank Path Description
1 Single Row by Rowid
2 Single Row by Cluster Join
3 Single Row by Hash Cluster Key with Unique or Primary Key
4 Single Row by Unique or Primary Key
5 Clustered Join
6 Hash Cluster Key
7 Indexed Cluster Key
8 Composite Index
9 Single-Column Indexes
10 Bounded Range Search on Indexed Columns
11 Unbounded Range Search on Indexed Columns
12 Sort Merge Join
13 MAX or MIN of Indexed Column
14 ORDER BY on Indexed Column
15 Full Table Scan
 RBO disadvantages …..

Does NOT support the new features of versions 8, 8i and 9i such

as:
Bitmap Indexes
Partitioned Tables and indexes
Reverse Indexes
Parallel Queries
Hash Joins
Star Queries
All new indexes
COST BASED OPTIMIZER
 CBO

–“physical-IO + CPU/1000 + 1.5 NetIO”

 CBO—Mechanisms--Grandmaster

Consider the viability of playing a game of chess in this manner.

As a matter of fact, this is how I play chess – like the RBO.
I am only capable of considering the very next move, and am incapable of
visualizing two, or three, or ten moves into the future for one possible
permutation, let alone multiple permutations. I don’t win very often.

Unlike the RBO, the CBO determines the cost of all possible
execution plans. It tries all possible permutations of
execution plan, up to the limit imposed by the initialization parameter,
OPTIMIZER_MAX_PERMUTATIONS, which defaults to a value of 80,000.

Grandmaster capable of considering all potential moves, along with subsequent

moves, deciding on the next move with the greatest number possible advantage
 The Cost Based Optimizer

Available only in versions 7 and above

Needs statistics
Analyze table emp compute statistics
Analyze index emp_idx1 compute statistics
Analyze table emp estimate statistics
Analyze index emp_idx1 estimate statistics
 What can go wrong?
--CBO

At least two things can go wrong with a mathematical processor:

It could receive bad data as input (the old garbage-in, garbage-out problem)

one or more formulas may fail to include important factors or

otherwise be in error
Questions?
SORTING
 Sorting

TheInit.ora parameter SORT_AREA_SIZE will allocate

memory for sorting
Determines the PER USER space allocated in main memory
for each process to sort.
Try to sort in Memory instead of in Temporary Segments

If not enough, temporary segments are used.

Increasing sort_area_size to reduce disk I/O


Causes swapping if to little memory is left
 Sorting
Statements generating Temporary
Segments:
Create Index
Select .... Order By
Select .... Distinct
Select .... Group By
Select .... Union
Select .... Intersect
Select .... Minus
Questions?
HINTS
 Hints

The Syntax must be correct or the Hint will be ignored, and no error
message is issued.

Hints only apply to the statement they are in. Nested statements are
treated as totally different statements, requiring their own Hints.

There is a 255 character limit to Hints.

When using an alias for a table in the statement, the alias needs to be in
the Hint.
 Key” Hints for Optimization

FULL - Do a Full Table Scan

SELECT /*+ FULL(table_name) */ column1, column2 ...

INDEX - Force an Indexed Search

SELECT /*+ INDEX(table_name index_name1
index_name2...) */

ORDERED - Force the driving table

SELECT /*+ ORDERED */ column1, column2..
FROM table1, table2
 Key” Hints for Optimization

ALL_ROWS - Explicitly chooses the cost-based approach with a goal of

best throughput.
Select /*+ ALL_ROWS */ ...................

The ALL_ROWS hint usually suppresses an index

FIRST_ROWS - Chooses the cost-based approach with a goal of best

response time.
Select /*+ FIRST_ROWS */ ...................
The FIRST_ROWS hint usually forces an index
 Key” Hints for Optimization

Using hash_join and parallel

select /*+ use_hash(e,b) parallel(e, 4) parallel(b, 4) */

e.ename,
hiredate,
   b.comm
from
   emp e,
bonus b
where
   e.ename = b.ename
 Hints for Joins

Nested loop Use_nl

Sort merge Use_merge

Hash Use_hash
Questions?
Parallel Query Option
The Parallel Query Option

Used on CPU intensive jobs.

Allows the query to be spread across multiple CPU’s

Short jobs will usually suffer from this option because of the time
required to divide and reassemble the query.

Available only when a Full table scan or a Sort operation is being

performed.
 The Parallel Query Option

Multiple Server Processes can work together simultaneously to

process a single SQL statement.

Improves data-intensive operations.

Takes advantage of the hardware - effectiveness scales with

added resources.

Cost-based Optimization
 Benefits of Parallel Execution

CPU CPU
scan scan

CPU CPU
idle scan

CPU CPU
idle scan

CPU CPU
idle scan

Server without Parallelism Server with

Parallelism
 Parallel Query Process

User Query

Query Coordinator

Query Query Query Query

Server Server Server Server

System Global Area

 Degree of Parallelism

An example of a sort with the degree of

Sort
parallelism set to 4 Operation

Query
A-G Server

Query
Query H- M Server

Coordinator
Query
N-T Server

Query
U-Z Server
 Parallel Query Operations

 The various query types that can be parallelized are:

 Access methods:
 Table Scans, Index Full Scans
 Partitioned Index Range Scans
 Various SQL operations:
 GROUP BY, ORDER BY, NOT IN, EXISTS, IN,
SELECT DISTINCT, UNION, UNION ALL, MINUS,
INTERSECT, CUBE, ROLLUP, Aggregates
 Join methods:
 Nested Loop, Sort Merge
 Hash, Star Transformation, partition-wise join
 Parallel DDL Operations

 The parallel DDL statements for non-partitioned tables

and indexes are:
 CREATE INDEX
 CREATE TABLE ... AS SELECT
 ALTER INDEX ... REBUILD
 The parallel DDL statements for partitioned tables and
indexes are:
 CREATE INDEX
 CREATE TABLE ... AS SELECT
 ALTER TABLE ... MOVE PARTITION
 ALTER TABLE ... SPLIT PARTITION
 ALTER TABLE ... COALESCE PARTITION
 ALTER INDEX ... REBUILD PARTITION
 ALTER INDEX ... SPLIT PARTITION
 Parallel Query Use

With Hints
Select /*+ Full(table) Parallel(table [degree]) */

Creating tables to use the Parallel Option

Create Table table
(table_id Number, col1 Varchar2(10))
Parallel (Degree 2) | Parallel 2
 Parallel DML - V8

Example (Parallel in subquery):

insert /*+ PARALLEL (time_history_summary,2) */

into time_history_summary (rank, grpcode, fees)

(select /*+ PARALLEL (time_history, 6) */

rank, grpcode, sum(fees)

from time_history

group by rank, grpcode);

 Parallel Process Tuning

• Key INIT.ORA Parameters

PARALLEL_AUTOMATIC_TUNING (8i)----False

PARALLEL_THREADS_PER_CPU (8i)---Default = 2 (port

specific)

LARGE_POOL_SIZE (8i)
 Tuning Parallel Execution

PARALLEL_AUTOMATIC_TUNING
Default = FALSE

If = TRUE, Automatically Sets:

parallel execution buffers and they are allocated from the
LARGE_POOL, not the SHARED_POOL.
 Monitoring

V$ views:
v$pq_sysstat
v$pq_sesstat
v$pq_tqstat
v$pq_slave

Explain Plan

utlxplp.sql - Parallel Explain Plan Display

Questions?
Joins
 Join Algorithms ...

Nested loop Sort merge

Hash join
 Join costs

Nested loop join

Cost of accessing outer table+ (cardinality of outer table*cost of accessing inner table)

Sort merge join

(Cost of accessing outer table+outer sort cost)+(Cost of accessing Inner table+Inner sort cost)

Hash join

(Cost of accessing outer table)+(Cost of building hash table)+ (Cost of accessing Inner table)
 Understanding Driving Tables

• What is a Driving Table?

 Oracle refers to the driving table as the outer table in a join

 This is the table that dictates how the data is retrieved from the database

 Oracle parses queries from right to left through the FROM clause

Select T1.A, T1.B, T2.X, T2.Y from T1, T2 Where T1.A = 10 and T1.B = T2.X;

T1-----Driving or Outer table

T2-----Driven or Inner table
 Understanding Driving Tables

• Which Table Should be the Driving Table?

 The table that returns the fewest number of rows the fastest

 If there are three or more tables, the driving table should be

the intersection table
 Nested loop join

Oracle compares each row of an inner set with Each row of the outer set
and returns those rows That satisfy the condition

Under CBO ,the smallest table becomes driving table

 Nested loop join

Select custid,phone,plan from cust c ,plan p Where c.custid=p.custid

and c.custname=‘SENTHIL’
1.Oracle finds all rows that match the where clause (here in the case
custname)
2.Using the result set from driving table ,Oracle uses index on the driven
table to find entries that match the value of join field conditions
(custid=custid)

3.Using rowids in the index ,oracle gets the data

 Nested loop join

1.Find rows from that matches condition (Small)

Emp—100m rows--.001% 2.Join with the large table
3.Here oracle has to needlessly process more.
4.Instead take the large as driving table

Dept—100 rows---50%
 Nested Loop Join ...

 Has an outer table (driving table) and an inner table.

 Each row from the outer table that satisfies its local predicates is
joined with rows from the inner table.

 This process is repeated for every qualifying row of the outer table.

 If there is no available index on the inner table, multiple scans of the

inner table are necessary.
 Nested Loop Join … Diagram

Outer Inner Composite

Table (T1) Table (T2) Table
A B X Y A B X Y
10 3 5 A 10 3 3 B
10 1 3 B 10 1 1 D
10 2 2 C 10 2 2 C
10 6 1 D 10 2 2 E
10 1 2 E 10 1 1D
9 F
7G

Select T1.A, T1.B, T2.X, T2.Y from T1, T2

Where T1.A = 10 and T1.B = T2.X;
 Nested Loop Join … Tips

 Use when Driving Table results are small.

 High Index selectivity

 Index, preferably a unique index exists on the join column of the inner table.

 More Cpu required

 Can also be used for non-equi join

 Does not require sorting

 Returns first rows faster –Better response time

 Hash Join ... Algorithms ...

 The two tables are read and split into partitions.

 A hash table is built for each partition that fits into memory.

 Partitions that don’t fit into memory are placed onto disk.

 The join is performed by taking a partition from the second

table and probing the hash table.
 Hash Join … Tips

 Safe to use with Oracle8 and greater..

 Cannot be used with RBO.

 HASH_JOIN_ENABLED parameter must be set TRUE.
 HASH_AREA_SIZE parameter controls the amount of memory used
for hash joins.

 Increase SORT_AREA_SIZE ,HASH_AREA_SIZE parameter if Hash

joins are used.
 Requires More Cpu
 Sort / Merge Algorithms ...

select count(t1.v1) ct_v1,

count(t2.v2) ct_v2
from big1 t1, big2 t2
where t2.n2 = t1.n1;

Oracle reads, filters, and usually sorts, the qualifying rows in each of the
tables independently.

The two intermediate result tables are sorted in the same sequence based
on the join predicate column(s).

The cost of a sort-merge equi-join is typically the cost of acquiring each of

the two data sets, plus the cost of making sure the two data sets are sorted.
 Sort merge Join … Tips

For Larger tables that don’t generate small result sets.

When indexes don’t exist on the join predicates.

Large portion of the rows are being joined

Requires more Sort area size and Temp segments

Require more Memory and Disk I/O

 Index Joins - 8i

Oracle generates a subset each index containing the columns referenced from
that index which meet the WHERE conditions by performing a Range Scan or a
Full Scan on each index

Oracle performs a Hash Join to combine the subsets

Oracle satisfies the query with the Joined Indexes

 What you Need for it to Work
Index Joins - 8i
OPTIMIZER_GOAL= CHOOSE|FIRST_ROWS|ALL_ROWS
HASH_AREA_SIZE sufficiently large
A set of indexes that contain (cover) all of the columns referenced in the
query
Optionally use the INDEX_JOIN hint
Works with both B*-TREE and BITMAP indexes

Benefit
A Full Table Scan can be avoided without creating an additional index
I hear and I forget

I see and I remember

I do and I understand
Questions?
Feel Free to Contact Me

98840----70711

110038