oracledatabaseperformancetuning-111220233535-phpapp01

7/24/2019 oracledatabaseperformancetuning-111220233535-phpapp01

1/42

Presented By-

Rahul Gaikwad

Oracle Database PerformanceTuning


2/42

What is Database Tuning?

Database tuning is a group of activitiesused to optimie the performance of adatabase!

Goal Of Database Tuning"To ma#imie use of system resourcesTo perform task as e$cientlyTo work rapidly as possible

www!yogi%icreations!com


3/42

Why and when should onetune?

&low Physical '(O-caused by poorly-con)gured disks

-caused by unnecessary physical '(O

-caused by poorly-tuned &*+!

,#cessive P. usage-'t means that there is little idle P. on the system

-caused by an inade/uately-sied system0

-caused by untuned &*+statements

-caused ine$cient application programs!

+atch ontentionRarely is latch contention tunable by recon)guring theinstance! Rather0 latch contention usually is resolvedthrough application changes!



4/42

Causes for low Performance

Bad onnection 1anagementBad .se of ursors and the &hared Pool

Bad &*+

.se of 2onstandard 'nitialiationParameters

Getting Database '(O 3rong

Redo +og &etup Problems

+ong 4ull Table &cans5igh 6mounts of Recursive 7&8&9 &*+



5/42

Where should we do the tuning?Database DesignPoor system performance usually results from apoor database design!One should generally normalize to the 3NF.&elective denormaliation can provide valuable performanceimprovements!!

Application Tuning:6ppro#imately :;< of all Oracle system performance problems areresolved by coding optimal SQL.

Memory Tuning:By Properly size your database bu=ers 7shared pool0 bu=er cache0 logbu=er0 etc9

By looking at your wait events, buer hit ratios, system swapping andpaging0 etc!

Disk !" Tuning:Database )les needs to beproperly sized.6lso look for fre/uent dis! sorts, "ull table scans, data "ragmentation0 etc!

#liminate Database Contention:Study database loc!s, latches and wait eventscarefully and eliminatewhere possible!

Tune the "perating $ystem:#onitor and tune o eratin s stem P.0 '(O and memor utiliation!



6/42

Ob%ect &tatistics

ardinality,stimates

'O and P.,stimates

DB parameters6nd con)g

ost estimate&ystem &tatistics

Table and inde#&tructure

"ptimi%ing the optimi%erOptimier inputs



7/42

Database $tatistics

Database statistics provideinformation on the type of load onthe database0 as well as the internal

and e&ternal resources used by thedatabase!


8/42

$tatistics

Stats

Wait

SQL

Sessions

Metrics

Time Model


9/42

Wait #'ents 3ait events are statistics that indicate that it

ha'e to wait for an event to completebeforebeing able to continue the processing!

common e#amples of the waits- Application:locks waits caused by row level

locking Commit:waits for redo log write con)rmation

after a commit dle: signify the session is inactive (etwork:waits for data to be sent over the

network )ser !": wait for blocks to be read o= a disk


10/42

Time Model $tatistics

The *+$#$$,TM#,M"D#-and *+$.$,TM#,M"D#-

views provide time model statisticsThe most important of the time model statistics is DB time!

This statistics represents the total time spent indatabase calls and is a indicator of the total instanceworkload!

't is calculated by aggregating the CPU and wait timesof all sessions

DB time is measured cumulativelyfrom the time that theinstance was started!

4or e#ample0 a instance that has been running for >;minutes could have four active user sessions whosecumulative DB time is appro#imately ?@; minutes!


11/42

Acti'e $ession /istory 0A$/1

The *+ACT*#,$#$$"(,/$T"2.viewprovides sampled session activity in theinstance!

6ctive sessions are sampled every second andare stored in a circular bufer in SGA!

6ctive &ession includes any session that wason the P. at the time of sampling!


12/42

$ystem and $ession $tatistics

6 large number of cumulative database statistics areavailable on a system and session level through the

*+$.$$TATand *+$#$$TATviews! "perating $ystem $tatistics

Operating system statistics provide information on the usageand performance of the main hardware components ofthe system0 as well as the performance of the operating

system itself! 't is always best to consider operating system statistics as a

diagnostic tool0 similar to the way many doctors use bodytemperature0 pulse rate0 and patient pain when making adiagnosis!!

Operating system statistics include the followingA P. &tatistics irtual 1emory &tatistics Disk &tatistics

2etwork &tatistics


13/42

Automatic Workload 2epository

The 6utomatic 3orkload Repository 763R9 collects0 processes0 andmaintains performance statistics for problem detection and self-tuning

purposes!

This data is stored both in memory and in the database!

63R includeA

Time model statistics i!e! *+$.$,TM#,M"D#-and*+$#$$,TM#,M"D#- views

&ome of the system and session statistics collected in the *+$.$$TATand*+$#$$TATviews

Acti'e $ession /istory 0A$/1statistics0 representing the history of recentsessions activity

63R automatically generates snapshots of the performance dataonce every hour

and collects the statistics in the workload repository!


14/42

Metric 6 metric is de)ned as the rate o change in

some cumulative statistic3

That rate can be measured against time0transactions0 or database calls!

4or e#ample0 the number database calls persecond is a metric!

6 history of recent metric values is availablethrough $% views!


15/42

Tools or )tilities for PT

C&*+P+62

4ind &*+s with high resource costs

,EP+6'2 P+62 F DB1&&T6T

Determine the e#ecution plan

&*+ Trace(Tkprof Best drilldown at the session level


16/42

*+$4-,P-A(

.sed to display the e#ecution plan of a &*+statementA

6fter the statement has e#ecuted0 you can

display the plan by /uerying theC&*+P+62 view!

The C&*+P+62&T6T'&T'& view providesthe actual e&ecution statistics for everyoperation in the plan0 such as the numberof output rows and elapsed time!



17/42

#5P-A( P-A(

The ,EP+6'2 P+62 statement displays e#ecution plans for&,+,T0 .PD6T,0 '2&,RT0 and D,+,T, statements!

6 statements e#ecution plan is the se&uence o" operationsOracle performs to run the statement!

The row source tree is the core of the e#ecution plan! 't shows A ordering of the tables

access method for each table

%oin method for tables

Data operations like )lter0 sort0 or aggregation

The plan table 6lso contains information A Optimiation0 such as the cost and cardinality of each operation

Partitioning0 such as the set of accessed partitions

Parallel e#ecution0 such as the distribution method of %oin inputs



18/42

P-A(,TA6-# "utput Table

The P+62T6B+, is automatically created to

hold the output of an ,EP+6'2 P+62statement for all users!

P+62T6B+, is the default sample output

table into which the ,EP+6'2 P+62statement inserts rows describing e#ecutionplans!

3hile a P+62T6B+, table is automaticallyset up for each user0 you can use the &*+script utl#plan!s/l to manually create a localP+62T6B+, in your schema!



19/42

uses ,EP+6'2 P+62

To e#amine a &*+ statement that&electemployee,id7 8ob,title7 salary7 anddepartment,name for the employees

whose Ds are less than 9;!Example Using EP!A"# P!A#

SELECT e.employee_id, j.job_title, e.salary,d.department_name

FROM employees e, jobs j, departments d

WHERE e.employee_id < !"

#$% e.job_id & j.job_id

#$% e.department_id & d.department_id'



20/42

#5P-A( P-A( "utput


21/42

$teps of #&ecution Plan&tep > reads all rowsof the employees table!&tep H looks up each 'ob(id in )*+(-(P inde/ and 0nds the

rowids of the associated rows in the %obs table!&tep I retrieves the rows with rowids that were returned by &tepH from the %obs table!

&tep J looks up each department(id in -1P2(-(P inde/ and)nds the rowids of the associated rows in the departments table!

&tep K retrieves the rows with rowids that were returned by &tepJ from the departments table!

The following steps in ,#ample operate on rows returned by theprevious row sourceA

&tep @ performs the nested loop operation on 'ob(id in the 'obs

and employees tables0 accepting row sources from &teps > and I0%oining each row from &tep > source to its corresponding row in&tep I0 and returning the resulting rows to &tep @!

&tep ? performs the nested loop operation, accepting rowsources from &tep@ and &tepK0 %oining each row from &tep @source to its corresponding row in &tep K0 and returning the

resulting rows to &tep ?!www!yogi%icreations!com


22/42



23/42

Full Table $cans

This type of scan reads all rows "rom a table

and 0lters outthose that do not meet theselection criteria!

During a full table scan0 all blocks in the tablethat are under the high water mark are

scanned!The high water mark indicates the amount of

used space0 or space that had been formattedto receive data!

,ach row is e#amined to determine whether itsatis)es the statements 35,R, clause!



24/42

2owid $cans

The rowid of a row speci)es the data 0les and

data bloc! containing the row and the locationo" the row in that block!

+ocating a row by specifying its rowid is the"astest way to retrieve a single row0 because

the e#act location of the row in the database isspeci)ed!

To access a table by rowid0 Oracle 0rst obtainsthe rowidsof the selected rows0 either from the

statements 35,R, clause or through an inde#scan of one or more of the tables inde#es!

Oracle then locates each selected row in thetable based on its rowid!



25/42

nde& $cans'n this method0 a row is retrieved by tra$ersing the index0 using the

inde/ed column values speci)ed by the statement!

6n inde# scan retrieves data rom an index based on the value of one ormore columns in the inde#!

To perform an inde# scan0 "racle searches the index "or the inde/edcolumn values accessed by the statement!

'f the statement accesses only columns of the inde#0 then Oracle reads theinde#ed column values directly from the inde&0 rather than from thetable!

The inde# contains not only the inde#ed value0 but also the rowids of rowsin the table having that value!

Therefore0 if the statement accesses other columns in addition to theinde#ed columns0 then Oracle can )nd the rows in the table by using eithera table access by rowid or a cluster scan!

An index scan typesA

Assessing !" for 6locks7 not 2ows

nde& )niNue $cans

nde& 2ange $cans

nde& 2ange $cans Descending

nde& $kip $cans

Full $cans

Fast Full nde& $cansnde& Hoins



26/42

SINGLE TABLE LOOKUP

Index or table scan?

Avoid accidental table scans

Optimize indexes

best combination of concatenated indexes

Optimize necessary table scansVertical/Horizontal partitioning

1000


27/42

0 10 20 30 40 50 60 70 80 90 100

1

10

100

1000

Full Scan no caching

Index sorted data, no caching

Index unsorted, cached data

Full Table scan, cached data

Pct of table accessed

Elasped Time (s)

Break even point s for index vs table scan

C t tdId Eff ti


28/42

None

last name

last+first name

last,first,BirthYear

last,first,birthyear,id

0 200 400 600 800 1000 1200 1400 1600

1459

63

6

4

3

Logical IO

SELECT cust_id

FROM sh.customers c

WHERE cust_first_name = 'Connor'

A! cust_"ast_name = '#isho$'

A! cust_%ear_of_&irth = ()*+

Concatenated Index Effectiveness


29/42

BITMAP INDEXES


30/42

BITMAP INDEXES

1 10 100 1000 10000 100000 1000000

0.01

0.1

1

10

100

Bitmap index B*-Tree index Full table scan

Distinct values in table

Elapsed Time (s)


31/42

VERTICAL PARTITIONING


32/42

OPTIMIZING JOINS

Best join orderEliminate rows as early as possible

Join Type:

Nested loopsOptimize the join index

Sort merge

Avoid, esp. if memory scarce

Hash joinAvoid multi-pass executions

Joins


33/42

NESTED LOOPS JOIN

No Index

prod_id

prod_id,channel_id

time_id

prod_id,channel_id,cust_id,time_id,promo_id

0 100 200 300 400 500 600

546.55

48.36

23.43

3.14

2.2

Elapsed time (s)

Indexing


34/42

SORT-MERGE AND HASH JOIN

1 10 100 1000

0

50

100

150

200

250

Hash Join Sort Merge Join

Workarea Memory (MB)

Elapsed Time (s)

In Memory

In Memory

Single pass disk sortMlti pass disk sort

!isk Sort


35/42

BITMAP JOIN INDEX


36/42

BITMAP JOIN PERFORMANCE

SELECT S,M -amount_so"d

FROM customers /O0 sa"es s ,S01 -cust_id WHERE

cust_emai"='f"int.2effre%s3com$an%4.com'+

"itmap Join inde#

"itmap inde#

$ll ta%le scan

0 2000 &000 '000 (000 10000 12000 1&000

'(

1)52&

1*)&(0

o!i"al IO

A""ess Pa#$


37/42

%ORTIN& ' WAT WE EXPECT

Ta%le+Inde# I, -./ Time Temp Segment I,

P&A Memory aaila*le (MB)

ime

Memory Sort

Single .ass

!isk Sort

Mltipass

!isk Sort


38/42

DM T+NIN& , INDEXE%

1 . only3

2

*

&

5

'

4

0 2)000 &)000 ')000 ()000 10)000 12)000 1&)000 1')000 1()000

1)11

')'41

()'1

10)41

12)424

1&)2(5

1')*1'

o!i"al reads re-.ired

N.m*er o/ i0de1es

DM


39/42

T6o Inserts

Mltita%le insert

0 1 2 * & 5 ' 4 ( 10

Insert %oth

Insert 7M78

Insert /S

Elapsed #ime (s)

M+TI,TABE IN%ERT


40/42

I9S7:T ; /.!8T7

M7:


41/42

Top 9 "racle $4- tuning tips

?! Design and develop with performance in mind

@! ,stablish a tuning environment

>! 'nde# wisely

I! Reduce parsing

H! Take advantage of ost Based Optimier

K! 6void accidental table scans

J! Optimie necessary table scans

:! Optimie %oinsL! .se array processing

?;! onsider P+(&*+ for MtrickyN &*+



42/42

T/A(I .")O3

oracledatabaseperformancetuning-111220233535-phpapp01

Documents

Transcript of oracledatabaseperformancetuning-111220233535-phpapp01