© 2010 Quest Software, Inc. ALL RIGHTS RESERVED

High Performance PL/SQL

Guy Harrison

Director of Development, Melbourne

www.guyharrison.net

Guy.harrison@quest.com

www.twitter.com/guyharrison

2

Introductions

4

5

6

7

Agenda

• Measuring PL/SQL Performance

• PL/SQL Performance advantages

• SQL Code

• PL/SQL Data handling

• PL/SQL code structure

• Compilation and datatype Tweaks

8

Measuring PL/SQL performance• DBMS_PROFILER is the best way to find PL/SQL “hot spots”:

9Scripts at www.guyharrison.net

10

Toad Profiler support

11

SQL*Navigator profiler support

12

11g Hierarchical profiler

$ plshprof -output hprof demo1.trc

13

Plshprof output

14

DBMS_HPROF tables

Scripts at www.guyharrison.net

15

When is PL/SQL faster?

• PL/SQL routines most massively outperform other languages when network round trips are significant.

16

Network traffic• Routines that process large numbers of rows and return simple

aggregates are also candidates for a stored procedure approach

17

Stored procedure alternative

18

Network traffic example

Stored Procedure

Java client

0 200 400 600 800 1,000 1,200 1,400 1,600 1,800

344

1703

297

313

Local Host

Remote Host

Elapsed time (ms)

19

Aspects of PL/SQL performance

Compilation and datatype Tweaks

PL/SQL code structure

PL/SQL Data handling

SQL Code

20

PLSQL_OPTIMIZE_LEVEL

0: No optimization

1: Minor (eliminate but not

reorganize)

2: (default) Significantly

reorganize code (array

fetch, optimize loops)

3: 11g specific (in-lining,

etc)

21

Compilation and datatype Tweaks

PL/SQL code structure

PL/SQL Data handling

SQL Code

22

It’s usually the SQL • Most PL/SQL routines spend most of their time executing

SELECT statements and DML• SQL tuning is a big topic but:

– Measure SQL overhead of PL/SQL routines first– Ensure best possible optimizer statistics – Consider adequacy of indexing– Learn how to use DBMS_XPLAN, SQL Trace, etc – Exploit 10g/11g tuning facilities (if licensed)– Don’t issue SQL when you don’t need to

23

SQL or PL/SQL?

cachedPlsql.sql at guyharrison.net/opsg

24

25

Compilation and datatype Tweaks

PL/SQL code structure

PL/SQL Data handling

SQL Code

26

Three ways of retrieving rows C

PU

& lo

gica

l rea

ds

•On

e

at

a

tim

e

•In

Bat

ch

es

•All

at

on

ce

.

Mem

ory Requirem

ents

27

One at a time

28

All at once

29

In batches

30

Array processing

1 10 100 1000 10000 100000 10000000

20

40

60

80

100

120

140

160

180

200

Bulk Collect Size

Ela

ps

ed

Tim

e No bulk collect

Bulk collect without LIMIT

(Prior to 10g or PLSQL_OPTIMIZE_LEVEL <2)

31

Array processing

• PLSQL_OPTIMIZE_LEVEL>1 causes transparent BULK COLLECT LIMIT 100

1 10 100 1000 10000 100000 1000000 100000000

50

100

150

200

250

300

Array Size

Ela

sped

tim

e (s

)

10g or higher with PLSQL_OPTIMIZE_LEVEL >1

No bulk collect

Bulk collect without LIMIT

32

BULK COLLECT worst case scenario

33

Array Insert• No Array Insert

• Insert all in single array:

34

Array Insert Performance

FORALL

FOR loop

0 50 100 150 200 250 300 350

25.06

341.86

Elapsed (s)

35

Bind variables in Dynamic SQL • Using bind variables allows sharable SQL, reduces parse overhead and

minimizes latch contention • Unlike other languages, PL/SQL uses bind variables transparently

– EXCEPT when using Dynamic SQL:

36

Using bind variables

37

Bind variable performance • 10,000 calls

Bind variables

No Binds

0 1 2 3 4 5 6 7 8

3.42

7.84

Elasped Time (s)

38

NOCOPY• The NOCOPY clause causes a parameter to be passed “by

reference” rather than “by value”

39

NOCOPY performance gains• 4,000 row, 10 column “table”; 4000 lookups:

NOCOPY

NO NOCOPY

0 100 200 300 400 500 600 700 800 900

0.28

864.96

Elapsed time (s)

40

Associative arrays • Traditionally, sequential scans of PLSQL tables are used for caching

database table data:

41

Associative arrays• Associative arrays allow for faster and simpler lookups:

42

Associative array performance• 10,000 random customer lookups with 55,000 customers

Associative lookups

Sequential scan

0 5 10 15 20 25 30

0.04

29.79

Elapsed time (s)

43

Compilation and datatype Tweaks

PL/SQL code structure

PL/SQL Data handling

SQL Code

44

Reduce unnecessary Looping• Unnecessary loop iterations burn CPU

Well formed loop

Poorly formed loop

0 5 10 15 20 25 30 35

3.96

34.31

Elapsed time (s)

45

Remove loop Invariant terms• Any term in a loop that does not vary should be extracted from

the loop

PLSQL_OPTIMIZE_LEVEL>1 does this automatically

46

Loop invariant performance improvements

plsql_optimize_level=2

Optimized loop

Original loop

0 2 4 6 8 10 12

5.28

5.87

11.09

Elapsed time (s)

47

Recursion (see: recursion)• Recursive routines often offer elegant solutions*.• However, deep recursion is memory-intensive and usually

not scalable

* Known In Australia as “smart-ass solutions”

*

48

Recursion memory overhead

0 2000000 4000000 6000000 8000000 100000000

200

400

600

800

1000

1200

1400

Recursive

Non-recursive

Recursive Depth

PG

A m

emo

ry (

MB

)

49

Compilation and datatype Tweaks

PL/SQL code structure

PL/SQL Data handling

SQL Code

50

Number crunching (1)

SIMPLE_INTEGER

PLS_INTEGER

NUMBER

0 5 10 15 20 25

5.99

7.06

20.09

0.54

3.83

17.64

NATIVE

INTERPRETED

Elasped Time (s)

51

Number crunching (2)

Java stored procedure

PLSQL compiled, SIMPLE_INTEGER datatype

PLSQL interpreted, PLS_INTEGER data type

PLSQL interpreted, NUMBER data type

0 5 10 15 20 25 30 35 40 45 50

0.11

0.740000000000001

14.48

47.22

Elapsed time (s)

52

11g Function cache• Suits deterministic but expensive functions OR• Expensive table lookups on non-volatile tables

53

Function cache performance • 100 executions, random date ranges 1-30 days:

Function cache

No function cache

0 1 2 3 4 5 6

1.51

5.21

Elapsed time (s)

54

In-lining

Manual in-liningModular design

55

Automatic in-lining• PLSQL_OPTIMIZE_LEVEL = 3

• OR:

PRAGMA INLINE

Manual Inlining

No Inlining

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

2.54

2.56

4.95

Elapsed time (s)

56

Expression “Short circuit”• Put the least likely condition first in an AND expression. Oracle

doesn’t need to evaluate the second expression if the first is FALSE.

57

Expression “Short circuit”• Put the most likely expression first in an OR expression. Oracle

does not have to evaluate the second expression if the first is TRUE.

58

Expression short circuit

OR

AND

0 50 100 150 200 250 300 350

216

308

295

181

Least likely first

Most likely first

PLSQL Elapsed time (ms)

Typ

e o

f co

mp

aris

on

59

IF and CASE statement ordering

Most likely First

Least likely First

0 500 1000 1500 2000 2500 3000 3500 4000

781

3,657

PL/SQL execution time (ms)

IF C

lau

se o

rder

ing

© 2010 Quest Software, Inc. ALL RIGHTS RESERVED

너를 감사하십시요 Thank You Danke Schön

Gracias 有難う御座いました Merci

बहवः� धन्यवःदाः� Obrigado 谢谢