high performance plsql
DESCRIPTION
High Performance PLSQL - presentation given at Oracle Open World 2009TRANSCRIPT
© 2009 Quest Software, Inc. ALL RIGHTS RESERVED
High Performance PL/SQL
Guy Harrison
Director of Development, Melbourne
www.guyharrison.net
2
Introductions
Buy Guy’s BookBuy Quest Products
3
http://www.motivatedphotos.com/?id=17760
4
Blue
Yellow
Red
0 10 20 30 40 50 60 70 80
Star trek shirt fatality analysis
Pct
5
Measuring PL/SQL performance• DBMS_PROFILER is the best way to find PL/SQL “hot
spots”:
6Scripts at www.guyharrison.net
7
Toad Profiler support
8
SQL*Navigator profiler support
9
11g Hierarchical profiler
$ plshprof -output hprof demo1.trc
10
Plshprof output
12
When is PL/SQL faster?
• PL/SQL routines most massively outperform other languages when network round trips are significant.
13
Network traffic• Routines that process large numbers of rows and return simple
aggregates are also candidates for a stored procedure approach
14
Stored procedure alternative
15
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)
16
Aspects of PL/SQL performance
Compilation and datatype Tweaks
PL/SQL code structure
PL/SQL Data handling
SQL Code
17
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)
18
Compilation and datatype Tweaks
PL/SQL code structure
PL/SQL Data handling
SQL Code
19
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
21
22
Compilation and datatype Tweaks
PL/SQL code structure
PL/SQL Data handling
SQL Code
23
Three ways of processing rows C
PU
& lo
gica
l rea
ds
•One at a time
•In Batches
•All at once .
Mem
ory Requirem
entsFour
24
One at a time
25
All at once
26
In batches
27
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)
28
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
29
BULK COLLECT worst case scenario
30
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:
31
Using bind variables
32
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)
33
NOCOPY• The NOCOPY clause causes a parameter to be passed
“by reference” rather than “by value”
34
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)
35
Associative arrays • Traditionally, sequential scans of PLSQL tables are used for caching
database table data:
36
Associative arrays• Associative arrays allow for faster and simpler lookups:
37
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)
38
Compilation and datatype Tweaks
PL/SQL code structure
PL/SQL Data handling
SQL Code
39
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)
40
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
41
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)
42
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”
*
43
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
)
44
Compilation and datatype Tweaks
PL/SQL code structure
PL/SQL Data handling
SQL Code
45
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)
46
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.74
14.48
47.22
Elapsed time (s)
47
11g Function cache• Suits deterministic but expensive functions• Expensive table lookups on non-volatile tables
48
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)
49
In-lining
Manual in-liningModular design
50
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)
51
Ran out of time for...
• Array insert using FORALL• Explicit vs. implicit cursors • RETURNING clause • Pipelined functions• Optimizing triggers• Short circuit evaluations• IF and CASE comparison ordering
52
Thank You – Q&A