Tuning Presentation July 18

8/9/2019 Tuning Presentation July 18

1/145

Oracle Performance Tuning

.


2/145

Data

Actual data

Redo

Changes made to the database-Used for recovery

Undo

Consistency

Oracle components


3/145

How oracle engine works

Oracle physical components

Oracle memory structures and

Background processes


4/145

Data Storage---Physical structures

Data files

Log files

Control files

Archive files

Init file


5/145

Table space

Segments

Extents

Blocks

Data Storage---Logical Structures


6/145


7/145

Oracle RDBMS Architecture

Background ProcessesBackground Processes

Client ProcessesClient Processes

SGASGA

Server ProcessesServer Processes

OracleOracle


8/145

Oracle Architecture

System Global Area

Shared Pool

Redo Log Buffer

LGWR ARCH

ArchivedLogs

DBWR CKPT

RedoLogs

SYSTEM

ROLLBACK

TEMP

INDEX

USER

DATA

Control

Files

PMON

SMON

RedoLogs

INIT.ORA

USER

SERVER

RECO

Snnnn

Dnnnn

Pnnnn

LCKn

SNPnn

PGA

INSTANCE

DATABASE

Shared SQL Area

DataDictionary

Cache

LibraryCache

Datafiles

Group 1 Group 2AlertFile

TraceFiles

orapwSID

PasswordFile

ParameterFile

Instance Lock Area Large Pool

I/O BufferArea

UGA

Database Buffer Cache


9/145

SGA --Shared global area

PGA --Program global area

Large pool area

Java pool area

Oracle memory structures


10/145

Database buffer cache Holds data

Log buffer Holds changes

Shared pool area Holds Parsing information

Database Buffers Redo Buffer Redo Buffer

Shared Pool

System Global AreaDictionary Buffers


11/145

Library Cache

Shared sql area Private Sql area

Persistentarea Runtime area

Data dictionary cache

Shared pool area


12/145

Shared Pool Tuning


13/145

Smon

Pmon

Dbwr

Lgwr

Arch

SNPn

LCKnn

Pnn

Snn

Dnn

Background Processes


14/145

How Oracle engine works


15/145

What happens when you press Enter?

SQL Statement Processing

Parse

Define

Bind

Execute

Fetch (For SELECT

only)


16/145

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


17/145

SQL Statement Processing - Define

Resolve and map data types on the client and the server

SQL*Net is involved ARRAYSIZE negotiated


18/145

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


19/145

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;


20/145

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 - SETARRAYSIZE n Forms - Set the Records Fetched Block Property Sheet


21/145

Parsing


22/145

Segmentheader Root block

Branch Branch

Leaf Leaf

Branch

Selectingarecord


23/145

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

Updating a record


24/145

Tuning


25/145

Application Tuning

Access paths

Sql tools and utilities

Indexes

Optimizer

Joins

Sorting

Hints

Parallel

Trouble-shooting - are there any quick fixes


26/145

Full table scan

sample scans

rowid scansindex unique scan

index range scan

index fast full scans

index full scans

index joins

bitmap joins

cluster scans

hash scans

Access paths


27/145

Access Paths

Full table scan

Index scan

Rowid scan

Index fast full scan Count (*)


28/145

So whatsa full-table scan?

A full-table scan is the process of reading all blocks of adatabase table sequentially

When a full-table scan occurs, indexes on the scannedtable are not used

Because of the volume of data processed, they canconsume large amounts of I/O bandwidth

More often than not, full-table scans were the cause of badquery performance


29/145

FTS effects onbuffercache

Buffer Cache LRU List

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

Block aging

Blocks accessed by indexstart here

Blocks accessed bydefault FTS start here

Blocks accessed by FTS start

here if CACHEd


30/145

Fulltable scan

Disk subsystems have improved dramatically toincrease I/O bandwidth, relative to overall databasesize and number of users

Significant performance gains can now be achieved

by properly using full-table scans


31/145

The usual reasons why full-tables scans

Missing indexes on large tables

A poor indexing strategy on large tables

Missing table or index statistics

Fulltable scan


32/145


33/145

Diagnosticand TuningTools


34/145

If you cant measure it, you cant manage it. Peter Drucker

Software performance is measured by its speed

Speed = Result Time

If you cant measure the time it takes for an application toproduce a result,then you cant manage its performance.

Diagnosticand TuningTools


35/145

Explain plan

Tkprof

V$scripts

Statspack

Oracle enterprise manager


36/145

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


37/145

Explain plan

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)

OutputOutput


38/145

TABLE ACCESS FULL

TABLE ACCESS BY INDEX ROWID

IND

EX UNIQUE SCANINDEX RANGE SCAN

NESTED LOOPS

HASH JOIN

MERGE JOIN

REMOTE

SORT ORDER BY

SORT GROUP BY

SORT JOIN

Operations


39/145


40/145

Single Table, no Index (1.5)

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

>.SELECT STATEMENT

>...TABLE ACCESS byrowidempSELECT *

FROM emp

WHERE rowid=

00004F2A.00A2.000C


41/145

Single Table, Index (2.1)

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

>.SELECT STATEMENT

>...TABLE ACCESS byrowidemp

>.....INDEX unique scani_emp_pk

SELECT *

FROM emp

WHERE empno=174;

Unique emp(empno)


42/145


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

>.SELECT STATEMENT


>.....INDEX range scani_emp_pk

SELECT *

FROM emp

WHERE empno>100;

Unique emp(empno)


43/145


Full Concatenated Index

Use job-value to navigate to sub-Btree

Then search all applicable hiredates

>.SELECT STATEMENT


>.....INDEX range scani_emp_j_h

SELECT *

FROM emp

WHERE job=manager

AND hiredate=01-01-2001;

Emp(job,hiredate)


44/145


Index Skip Scan (prior versions did FTS)

To use indexes where theyve 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)

>.SELECT STATEMENT


>.....INDEX range scani_emp_j_h

SELECT *

FROM emp

WHERE hiredate=01-01-2001;

Emp(job,hiredate)


45/145

Tkprof

Setting Autotrace (SQL*Plus 3.3) and Timing OnSetting Autotrace (SQL*Plus 3.3) and Timing On


46/145

TKPROF

Alter session set sql_trace=true

Alter session set tracefile_identifier=sense

Run your application / execute sql statements.

user_dump_dest.


47/145

TKPROF performance

raw SQL trace file TKPROF report file

TKPROF program

database server

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

TKPROF


48/145

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


49/145

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

********************************************************************************


50/145

Autotrace OutputAutotrace Output

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 SORT (AGGREGATE)

2 1 INDEX (RANGE SCAN) OF 'EMP7_I1' (NON-UNIQUE)

Set autotrace on


51/145


52/145

Setting Timing OnSetting Timing On

SQLPLUS> SETTIMING ON

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

COUNT(NAME)

--------------

100Elapsed: 00:00:00.84


53/145

V$scripts

V$session

V$sql

V$process

V$sysstat

V$library cache

V$rollstat

V$sqlarea


54/145

SQL> connect / as sysdba\

SQL> @$ORACLE_HOME/rdbms/admin/spcreate

Tables ---Begins with STAT$

Statspack


55/145

DBMS PROFILER

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

PLSQL_PROFILER_RUNS

PLSQL_PROFILER_UNITS

PLSQL_PROFILER_DATA


56/145

Questions?


57/145

IndexesWalkThrough


58/145

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 rowsquickly

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


59/145

Index read I/O is sequential in nature

Oracle wait-event for single-block I/O requests usedduring 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


60/145

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

S


61/145

Create Index (example)

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

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

INDEXES


62/145

B*tree

INDEXES


63/145

Insertion

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

BeforeAfter

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

inserted into leaf block

ENG

SCO

USA


64/145

Insertion

Inserting 'BEL'Before After

ENG

SCO

USA

Root node is now a branch block. Two new leaf nodes created.

Leaf rows split between the two new blocks

USABEL

ENG

SCO

U


65/145

Insertion

Inserting 'SPA'Before After

USABEL

ENG

SCO

U

SCO

SPA

USABEL

ENG

S U

New leaf node created. Leaf rows split between the two leaf

nodes. New leaf block pointer added to branch block


66/145

When row level locking is required - locking on the bitmap index is doneat the bitmap category level.

High volume OLTP systems

A full table scan is often more efficient if only a singlebitmap value isfiltered

Bitmaps would kill concurrency

When Are Bitmap Indexes Not Useful?


67/145

Bitmap indexes are not supported forTrusted 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.

BITMAP INDEX

Restrictions


68/145

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 valueis 1MB. Larger value can improve performance since the bitmap segments

must be pre-sorted before being merged into a single bitmap.

Initialization Parameters for Bitmap Indexing


69/145

Function-based indexes introduced in Oracle release 8.1 provides an efficient

mechanism to evaluate predicates involving functions

Function based index:

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));

i b d i d


70/145


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 usingmethods defined for the object.

Function based indexing is only available in the Enterprise Edition and is not

available in the Standard Edition.

F i b d i d


71/145

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

Restrictions



72/145

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?


73/145

IndexingCase when

create table project

(project_ID number primary key,

teamid number, job varchar2(100),

status varchar2(20) check (status in ('ACTIVE', 'INACTIVE')) );

create UNIQUEindex

job_unique_in_teamid on project( case whenstatus = 'ACTIVE'thenteamidelsenullend,

case whenstatus = 'ACTIVE'then job elsenullend )


74/145

REVERSE Key Indexes

REVERSE indexes

causes monotonically-ascendingdata values to become more randomby simply reversing data

123456 becomes 654321123457 becomes 754321, etc...

data is transparently converted and unconverted upon insert andretrieval

data is re-fitted to fit Oracles original design decision

Impact: only equivalence operations will use the index

=, !=, , IN, and NOT IN

range-scans will not use the index

>, >=,


75/145

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.


76/145

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


77/145

Oracle9i

Monitor whichindexisnotused

Index1 Index2

Index3 Index4

Index5 Index6

Finding index usage

Index Monitoring (9i)

select index_name,monitoring,used,start_monitoring,

end_monitoring from v$object_usage;

Finding index usage


78/145

Views

User_indexesUser_ind_columns

V$object_usage (9i)

Index_stats

Finding index usage

Monitor Index Usage (9i)

Start/Reset: ALTER INDEX MONITORING USAGE.

Stop: ALTER INDEX NOMONITORING


79/145

Oracle9i Key Index Features

Skip Scan Index

Allows the use of the 2ndpart 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


80/145

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 PartFirst Part

OfIndexOfIndex

(YEARS)(YEARS)

Second PartSecond Part

OfIndexOfIndex

NN--ZZ


OfIndexOfIndex

AA--MM


81/145

Oracle9i Skip/Scan Index

Skips the first part of the index (YEAR)

Scans the second part of the index (STATE)

S ELECT COUNT(*)FROM TEST2 WHERESTATE=AL

First PartFirst Part

OfIndex

OfIndex20012001


OfIndexOfIndex

AZAZ


OfIndexOfIndex

ALAL

Skip this level

Scan this level

Bit J i I d


82/145

Bitmap Join Index:

CREAT

ET

ABLE EMP1 AS SELECT

* FROM SCOTT.

EMP;

CREATE TABLE DEPT1 AS SELECT * FROM SCOTT.DEPT;

ALTERTABLE DEPT1

ADD CONSTRAINTDEPT_CONSTR1 UNIQUE (DEPTNO);

CREATE BITMAP INDEX EMPDEPT_IDX

ON EMP1(DEPT1.DEPTNO) FROM EMP1,DEPT1

WHERE EMP1.DEPTNO = DEPT1.DEPTNO

Allows a single index to span two tables

Requires the use of a unique constraint


83/145

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

FROM EMP1, DEPT1WHERE EMP1.DEPTNO = DEPT1.DEPTNO;

Usage---Bitmap Join Index:


84/145

Advanced tips for index monitoring

Binary height-----User_indexes

This should be low

CLUSTERING FACTOR

SELECTIVITY TAKE EG FROM CBO

The Skewness Problem

Index parametersopt_ind_cost_adj


85/145

Questions?


86/145

OPTIMIZER


87/145

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)

AlterSessionsetOptimizer_Goal= ;


88/145

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=;

Statement level: Hints inside SQL text specify mode to be used


89/145

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;

Optimizer


90/145

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_ROWSor use Hints

Must have statistics


91/145

RBO makes linear, step-by-step decisions. It makes a decision,andthen 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


92/145

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.

RBO--Mechanisms

Ranks for RBO


93/145

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

Ranks for RBO

RBO disadvantages ..


94/145

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

RBO disadvantages ..


95/145

COST BASED OPTIMIZER


96/145

physical-IO + CPU/1000 + 1.5 NetIO

CBO


97/145

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 possiblepermutation, let alone multiple permutations. I dont win very often.

Unlike the RBO, the CBO determines the cost of allpossible

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

CBOMechanisms--Grandmaster

The Cost Based OptimizerThe Cost Based Optimizer


98/145

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

The Cost Based OptimizerThe Cost Based Optimizer


99/145

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


100/145

Questions?


101/145

SORTING

Sorting


102/145

Sorting

The Init.ora parameter SORT _AREA_SIZE will allocate

memory for sorting

Determines the PER USER space allocated in main memoryfor 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


103/145

Create Index

Select .... Order By

Select ....Distinct

Select .... Group By

Select .... Union

Select .... Intersect

Select .... Minus

Statements generating Temporary Segments:Statements generating Temporary Segments:

g


104/145

Questions?


105/145

HINTS

Hints


106/145

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 OptimizationKey Hints for Optimization


107/145

FULL - Do a Full Table Scan

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

INDEX - Force an Indexed Search

SELECT /*+ INDEX(table_nameindex_name1index_name2...)

*/

ORDERED- Force the driving table

SELECT /*+ ORDERED */ column1, column2..

FROM table1, table2

y py p



108/145

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 bestresponse time.

Select/*+ FIRST_ROWS*/ ...................

The FIRST_ROWS hint usually forces an index


i f i i ii f i i i


109/145

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

e.ename,

hiredate,

b.comm

from

emp e,

bonus b

wheree.ename = b.ename


Using hash_join and parallel

Hints for JoinsHints for Joins


110/145

Hints for JoinsHints for Joins

Nested loop Use_nl

Sort merge Use_merge

Hash Use_hash


111/145

Questions?


112/145

Parallel Query OptionParallel Query Option

Th P ll l Q O tiTh P ll l Q O ti


113/145

The Parallel Query OptionThe Parallel Query Option

Used on CPU intensive jobs.

Allows the query to be spread across multiple CPUs

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.

Th P ll l Q O iTh P ll l Q O i


114/145

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

The Parallel Query OptionThe Parallel Query Option


115/145

Benefits of Parallel Execution

CPU

idle

CPU

idle

CPU

idle

CPU

scan

Server without Parallelism Server with

Parallelism

CPU

scan

CPU

scan

CPU

scan

CPU

scan

ll l Q


116/145

Parallel Query Process

System Global Area

User Query

Query Coordinator

QueryServer

QueryServer

QueryServer

QueryServer


117/145

Degree of Parallelism

An example of a sort with the degree of

parallelism set to 4

A - G

H - M

N - T

U - Z

QueryCoordinator

QueryServer

QueryServer

QueryServer

QueryServer

SortOperation

Parallel Query Operations


118/145

Parallel Query Operations

The various query types that can be parallelized are:

Access methods:

Table Scans, Index Full ScansPartitioned 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


119/145

Parallel DDL Operations

The parallel DDL statements for non-partitioned tablesand indexes are:CREATE INDEX

CREATE TABLE ... AS SELECTALTER INDEX ... REBUILD

The parallel DDL statements for partitioned tables andindexes are:CREATE INDEX

CREATE TABLE ... AS SELECT

ALTER TABLE ... MOVE PARTITIONALTER TABLE ... SPLIT PARTITIONALTER TABLE ... COALESCE PARTITIONALTER INDEX ... REBUILD PARTITIONALTER INDEX ... SPLIT PARTITION

Parallel Query UseParallel Query Use


120/145

Parallel Query UseParallel 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 DMLParallel DML V8V8


121/145

Parallel DMLParallel DML -- V8V8

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);


122/145

Parallel Process Tuning

Key INIT.ORA Parameters

PARALLEL_AUTOMATIC_TUNING (8i)----False

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

LARGE_POOL_SIZE (8i)


123/145

PARALLEL_AUTOMATIC_TUNING

Default = FALSE

If = TRUE, Automatically Sets:parallelexecution buffers andthey are allocatedfrom the

LARGE_POOL,nottheSHARED_POOL.

Tuning Parallel Execution

Monitoring


124/145

V$ views:

v$pq_sysstat

v$pq_sesstatv$pq_tqstat

v$pq_slave

Explain Plan

utlxplp.sql - Parallel Explain PlanDisplay

g

Questions?


125/145

Questions?


126/145

Joins

Join Algorithms ...


127/145

g

Nested loop Sort merge

Hash join

Join costs


128/145

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)

Join costs

Understanding Driving Tables


129/145

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

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

T1-----Driving or Outer table

T2-----Driven or Inner table

Understanding Driving Tables


130/145

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


131/145

Nested loop join

Oracle compares each row of an inner set withEach row of the outer setand returns those rows That satisfy the condition

Under CBO,the smallest table becomes driving table

N t d l j i


132/145

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

Nested loop join


133/145

Emp100m rows--.001%

Dept100 rows---50%

1.Find rows from that matches condition (Small)

2.Join with the large table

3.Here oracle has to needlessly process more

.

4.Instead take the large as driving table

Nested Loop Join ...


134/145

Has an outer table (drivingtable) 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 theinner table are necessary.

p

Nested Loop Join Diagram


135/145

Outer

Table (T1)

Inner

Table (T2)

Composite

Table

10 3

10 1

10 2

10 6

10 1

5 A

3 B

2 C

1 D

2 E

9 F7 G

10 3 3 B10 1 1 D

10 2 2 C

10 2 2 E

10 1 1 D

A B X Y A B X Y

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

Where T1.A = 10and T1.B = T2.X;

Nested Loop Join Tips


136/145

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


137/145

The two tables are read and split into partitions.

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

Partitions that dont 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


138/145

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


139/145

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


140/145

For Larger tables that dontgenerate small result sets.

When indexes dont 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 JoinsIndex Joins -- 8i8i


141/145

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 WorkWhat you Need for it to Work


142/145

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 thequery

Optionally use the INDEX_JOIN hint

Works with both B*-TREE and BITMAP indexes

yy

Index JoinsIndex Joins -- 8i8i

A Full Table Scan can be avoided without creating an additional index

BenefitBenefit


143/145

Questions?


144/145

Questions?

Feel Free to Contact Me


145/145

98840----70711

110038

Date post:	29-May-2018
Category:	Documents
Upload:	manipfizer
View:	216 times
Download:	0 times

Tuning Presentation July 18

Documents