Date post: | 09-Jun-2015 |
Category: |
Technology |
Upload: | guy-harrison |
View: | 3,505 times |
Download: | 3 times |
© 2010 Quest Software, Inc. ALL RIGHTS RESERVED
High Performance PL/SQL
Guy Harrison
Director of Development, Melbourne
www.guyharrison.net
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”:
10
Toad Profiler support
11
SQL*Navigator profiler support
12
11g Hierarchical profiler
$ plshprof -output hprof demo1.trc
13
Plshprof output
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 谢谢