Achieving PL/SQL Excellence

Oracle PLSQL Best Practices

and Tuning

Steven Feuerstein
[email protected]
[email protected]
www.quest.com
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 1
 Software Used in Training
ƒ PL/Vision: a library of packages installed on top of PL/SQL
– PL/Vision Lite - use it, copy, change it for free -- unless you build
software to be sold commercially
– Advanced PL/SQL Knowledge Base: contains PL/Vision Professional,
the fully supported and enhanced version
ƒ Demonstration scripts executed in the training can be found on
the RevealNet PL/SQL Pipeline:
– www.revealnet.com/Pipelines/PLSQL/index.htm plsql_ides.txt

– Archives, Miscellaneous, PL/SQL Seminar Files

– See filedesc.doc for a description of many of the files
ƒ A PL/SQL IDE (Integrated Development Environment)
– You no longer have to use SQL*Plus and a crude editor! Choose from
among the many listed in plsql_ides.txt
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 2
 Training Objectives

ƒ Learn how to build code that:

– Is readable, both by the author and others
– Is more easily and quickly maintained
– Works more efficiently
– You are proud of

ƒ Improve your ability to review code: yours and others'

– To do that, you have to know how to recognize what is
wrong with a program
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 3
 Training Outline
ƒ Setting the stage
ƒ Writing SQL in PL/SQL
ƒ Package Construction
ƒ Modularizing and Encapsulating Logic
ƒ Deploy an Exception Handling Architecture
ƒ Unit Test within a Framework
ƒ Optimize Algorithms
ƒ Use Data Structures Efficiently
ƒ Manage Code in the Database and SGA
ƒ Create Readable and Maintainable Code

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 4

PL/SQL Tuning & Best Practices
Setting the Stage

ƒ What's wrong with this code?

ƒ Setting expectations re: tuning
ƒ Implementation strategies for best practices
ƒ Analyzing performance
ƒ Understanding the PL/SQL Architecture

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 5

"What is Wrong with this Code?"
ƒ Code repetition!
– More to fix, more to maintain

ƒ Exposed implementation!
– show me how it is getting the job done

ƒ Hard-coding
– assumes that something will never change
-- and that is never going to not happen
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 6
 Hard-Coding in PL/SQL
ƒ Literal values IF num_requests > 100 THEN
ƒ Date format in a call to TO_DATE 'MM/DD/YY'
ƒ Language specificities '09-SEP-2001'
ƒ Constrained declarations NUMBER(10,4)
ƒ Variables declared using base datatypes my_name VARCHAR2(20)
ƒ Every SQL statement you write, especially implicit cursors
ƒ COMMIT and ROLLBACK statements
ƒ Fetching into a list of individual variables
ƒ Embedded (unencapsulated) business rules
Scary,
isn't it?
When you are done with this seminar, you will know
how to get rid of all these kinds of hard-coding.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 7

 Scope of Tuning Training
ƒ Focus is on PL/SQL
-- not SQL PL/SQL Engine

ƒ In other words: tune

your SQL first! PL/SQL
Code
PL/SQL
Statement
Block Executor
ƒ Limited treatment of
SQL tuning, SGA SQL Data
sizing and analysis, SQL Engine

SQL-specific new SQL Statement

features in Oracle,
Executor

etc.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 8
 Expectations for a Training on
Tuning
Improve the
performance of your
application 1000
fold for only $19.95
a month!*

*Plus shipping and handling and technical support. All

performance degradation the responsibility
9/16/2006 Copyright of the user.
2001 Steven Feuerstein, PL/SQL Best Practices - page 9
 Resources for PL/SQL Tuning
ƒ Interested in "Oracle tuning"? The world is your oyster:
– Oracle documentation
– Numerous tuning books and Web sites
– Many, many tools
ƒ But PL/SQL tuning? Slim pickings...
– PL/SQL books and general Oracle tuning books offer some
coverage, but it is minimal and piecemeal
– Code Complete by Steve McConnell (Microsoft Press)
• Many tuning tips are not language-specific. This book offers an
excellent treatment of tuning philosophies and issues you have to
address in any programming language
ƒ PL/SQL tuning is tough, compared to SQL tuning
– You have to analyze and tune algorithms
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 10
 Tuning Myths
ƒ “A fast program is as important as a correct one”
– Squeezing out microsecond performance improvements is much less
important than meeting user requirements
ƒ "Fewer lines of code improves speed"
– There is no predictable relationship between lines of code and
resulting performance. Think recursion...
– But increasing code density definitely reduces readability
ƒ “Certain operations are probably faster than others”
– There is no room for “probably” in tuning. Either an operation is faster
or it is not -- and that fact can change as you change versions and
environments
ƒ "Optimize as you write your code"
– Don't knowingly write inefficient code, but don't agonize over code that
may never contribute to a performance bottleneck. These are often
only apparent when you run a completed application
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 11
PL/SQL Tuning & Best Practices

Strategies for Implementing

Best Practices

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 12

 Words Are Not Enough!
You have a long list of best practices and
standards that you plan to deploy in your
organization.
How can you get developers to "follow the
rules"? Send out a memo? Hold a
meeting?
ƒ Need to develop a "culture of quality", so that all developers
consciously seek to write higher quality code.
ƒ Then move beyond words to software components and utilities that:
– Implement the standards for developers, and simply present them as
infrastructure components
– Generate standards-based code
– Analyze code for compliance with standards
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 13
 Generator and Analyzer Utilities
ƒ You have a number of options to generate code:
– Build your own. It's not too hard to do something "quick and dirty" --
and very focused on your needs
– Use the PL/Vision PLVgen package to create standard "code starters"
– Many IDEs have templates and mini code libraries
– Full-blown generation tools like Oracle Designer and PL/Generator
ƒ You can also use SQL and the data dictionary to analyze your
code
– It's one of the big advantages of stored code
showchar.sql
showei.sql
SELECT DISTINCT name showsrc.sql
FROM USER_SOURCE valstd.pkg
WHERE INSTR (UPPER (text), ' CHAR') > 0;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 14

 Strategies for Implementation
Summary
ƒ Involve the entire dev team in creating and adopting
best practices.
– Anything imposed risks backlash
ƒ Provide tools that implement standards "automatically"
– Developers won't even realize they're conforming
ƒ Analyze stored code for compliance with standards
– Use the power of SQL to manage your code, as well as
your users' data

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 15

PL/SQL Tuning & Best Practices
Analyzing Performance

ƒ Utilize Existing Tools

ƒ The PL/SQL Code Profiler (Oracle8i)
ƒ The DBMS_APPLICATION_INFO package
ƒ Homegrown Timer Utility
ƒ Compare Implementations
ƒ Calculate Overhead of Various Operations

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 16

 Measure Before You Tune
ƒ Oracle PL/SQL is a different sort of animal from standard
programming languages
– It not only is designed to manipulate Oracle RDBMS information,
but the code is stored in and executed from that database!
– Accessing that code competes with other DB operations.
ƒ Tuning PL/SQL code involves three main areas of tuning:
– SQL statements
And
– PL/SQL code (algorithms) upgrading!
– Memory utilization and management of code
ƒ Critical to tune for concurrent users, not just single user.
But before you can tune, you must know what is
running slowly. You must measure.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 17
 Utilize Existing Tools
ƒ Oracle and other software vendors now provide a number of
performance analysis tools
– Unfortunately, almost all focus almost exclusively on SQL
ƒ TKPROF
– Lots of output, lots of work to analyze that output
ƒ Later-generation tools embed and offer expertise
– Sure, you should know the basics of SQL tuning, but it is
increasingly possible to rely on SW-based knowledge to do the
hard work for you
– Oracle Performance Pack
– Quest SQLab
– Computer Associates SQL Station Plan Analyzer
– Others, I am sure...
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 18
 The PL/SQL Code Profiler
ƒ In Oracle8i, the DBMS_PROFILER package offers an API to
facilitate performance and code coverage analysis
ƒ Easy to gather statistics:
– Install the package and BEGIN
DBMS_OUTPUT.PUT_LINE (
supporting elements DBMS_PROFILER.START_PROFILER (
'showemps ' ||
– Start the profiler TO_CHAR (SYSDATE, 'YYYYMMDD HH24:MI:SS')
)
– Run your code );
showemps;
– Stop the profiler DBMS_OUTPUT.PUT_LINE (
DBMS_PROFILER.STOP_PROFILER);
ƒ Bigger challenge: END;

Analyzing the results...

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 19

 Installing the Code Profiler
ƒ You will probably have to install the code yourself (in the SYS schema)
Check the package specification file for documentation and guidelines
– Specification: dbmspbp.sql Body: prvtpbp.plb
– Files are located in Rdbms\Admin unless otherwise noted
ƒ You must install the profile tables by running the proftab.sql script. Can
define them in a shared schema or in separate schemas
ƒ Creates three tables:
– PLSQL_PROFILER_RUNS: parent table of runs
– PLSQL_PROFILER_UNITS: program units executed in run
– PLSQL_PROFILER_DATA: profiling data for each line in a program unit
ƒ These tables, particularly *_DATA, can end up with lots of rows in them

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 20

 Interpreting Code Profiler Results
ƒ To make it easier to analyze the data produced by the profiler,
Oracle offers the following files in the Ora81\plsql\demo
directory:
– profrep.sql: Creates a number of views and a package named prof_report_utilities
to help extract data from profiling tables
– profsum.sql: series of canned queries and programs using prof_report_utilities
Don't run them all; pick the ones that look most useful

EXECUTE prof_report_utilities.rollup_all_runs;

/* Total time */
SELECT TO_CHAR (grand_total / 1000000000, '999999.99') AS grand_total
FROM plsql_profiler_grand_total;

/* Total time spent on each run */

SELECT runid, SUBSTR (run_comment, 1, 30) AS run_comment,
slowest.sql
run_total_time / 1000000000 AS seconds slowest.txt
FROM plsql_profiler_runs
WHERE run_total_time > 0
ORDER BY runid asc;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 21
 Homegrown Timer Utility
ƒ PL/SQL developers often need a very granular timing
mechanism: What is the elapsed time for this one function?
ƒ Oracle offers several mechanisms to get this information
– DBMS_UTILITY.GET_TIME function
– V$TIMER table and other V$ data sources
– SQL*Plus SET TIMING ON
ƒ In most cases, you will be best off building an encapsulation
around the lower-level functionality
Package Implementation Object Implementation
BEGIN DECLARE
PLVtmr.capture; se_tmr tmr_t :=
showemps; tmr_t.make ('Showemps');
PLVtmr.show_elapsed BEGIN
plvtmr.pkg
('Showemps'); se_tmr.go; tmr81.ot
END; showemps; vsesstat.pkg
se_tmr.stop;
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 22
 Compare Implementations
ƒ You write a program
DECLARE
v_user VARCHAR2(30);
once_tmr tmr_t :=
and it just doesn't seem &1);
tmr_t.make ('Packaged',

fast enough every_tmr tmr_t :=

tmr_t.make ('USER', &1);
BEGIN
ƒ Time to try a different once_tmr.go;
FOR indx IN 1 .. &1

approach -- and then LOOP

v_user := thisuser.name;

you need to compare

END LOOP;
once_tmr.stop;

them every_tmr.go;
FOR indx IN 1 .. &1

– The timer utility offers an LOOP

v_user := USER;

easy way to do this END LOOP;

every_tmr.stop;
END;

thisuser.*
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 23
 Calculate Overhead
ƒ We often wonder how
DECLARE
otmr tmr_t :=
tmr_t.make ('OPEN?');
expensive is a particular ftmr tmr_t :=
tmr_t.make ('FETCH?');

operation, or when Oracle CURSOR lots_stuff IS

actually performs a
SELECT *
from plsql_profiler_data
Order BY total_time DESC;
requested task lots_rec lots_stuff%ROWTYPE;

ƒ Common questions:
BEGIN
otmr.go;
OPEN lots_stuff;
– Does Oracle identify the otmr.stop;

result of a query with the ftmr.go;

FETCH lots_stuff INTO lots_rec;
OPEN or the first FETCH? ftmr.stop;
END;

– What is the overhead of a SQL> @open_fetch

procedure or function call?

Elapsed for "OPEN" = 0 seconds.
open_fetch.sql
Elapsed for "FETCH?" = 1490.1
curperf*.sql
ovrhead.sql seconds.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 24
PL/SQL Tuning & Best Practices

Understanding PL/SQL
Architecture

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 25

 PL/SQL in Shared Memory
System Global Area (SGA) of RDBMS Instance
Shared Pool Library cache
Shared SQL
Select * Update emp
Reserved Pool
Pre-parsed from emp Set sal=...

Large Pool calc_totals show_emps upd_salaries

emp_rec emp%rowtype; emp_rec emp%rowtype;

tot_tab tottabtype; tot_tab tottabtype;

Session 1 memory Session 2 memory User 2

(PGA/UGA) (PGA/UGA)

User 1 9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 26
 Code in Shared Memory
ƒ PL/SQL is an interpretative language. The source code is
“partially compiled” into an intermediate form (“p-code”).
– The p-code is loaded into the shared pool when any element of
that code (package or stand-alone program) is referenced.
ƒ The partially-compiled code is shared among all users who
have EXECUTE authority on the program/package.
– Prior to Oracle7.3, contiguous memory was required for program
units. That is now relaxed, but still preferable.
ƒ Each user (Oracle session) has its own copy of any data
structures defined within the program/package.
– Separate sets of in-memory data (not shared among different
users) are stored in the PGA.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 27
 PL/SQL Tuning and Best
Practices
Writing SQL in PL/SQL

ƒ What's the Big Deal?

ƒ Some Rules to Follow
ƒ Synchronize Code with Data Structures
ƒ Avoid Repetition of SQL
ƒ Optimize the way we write SQL in PL/SQL

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 28

 Why We Write PL/SQL Code
ƒ The predominant reason you write PL/SQL programs is to
interact with the database, which:
– Is the repository of information that shapes your business
– Is always changing
ƒ The layer of PL/SQL code should support the data model
– It should not disrupt your ability to maintain and work with that model
– But common coding practices tend to do just that: make it extremely
difficult to modify and enhance your code as the data structures
change
ƒ The difficulties surface in two different areas:
– Transaction integrity
– Poor coding practices
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 29
 Transaction Integrity
the Hard Way

Typical Data Access Method

Each program must
maintain transaction
Order Entry integrity.
Application software Program
access data structures
directly.

Order Item
Table Table

ƒ When a transaction consists of three updates, two inserts,

a delete and six queries, how do you guarantee that each
developer is going to get it right?
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 30
 The Dangers of Poor
Coding Practices
ƒ If you are not very careful, it is very easy to write your code
in ways that cause your code to break whenever a change
occurs in the underlying structures
Data Structures

Dept Code
PROCEDURE calc_totals
IS
v_dname VARCHAR2(20);
v_ename CHAR(30);
BEGIN
SELECT dname, ename
Emp INTO v_dname, v_ename
This program is a
ticking time bomb
FROM emp, dept
in my
WHERE ...;
application...
...
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 31
 The View from 30,000 Feet
High-Level Best Practices

ƒ Never repeat an SQL statement in application code

ƒ Encapsulate all SQL statements behind a procedural interface,

usually a package

ƒ Write your code assuming that the underlying data structures

will change

ƒ Take advantage of PL/SQL-specific enhancements for SQL

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 32
 Never Repeat SQL
ƒ Take the "acid test" of SQL in PL/SQL: Can you say "sure"
to the following question?
Do you know all the places in your code where an INSERT (or
DELETE or UPDATE) occurs for your table(s)?

– If the answer is "not really", then you have essentially lost control
of your application code base
ƒ It is crucial that you avoid repetition of the same logical
SQL statement...
– With repetition, comes variation, and with it excessive parsing
– Potentially significant impact on performance and maintainability

And sometimes you have to worry about

more than logical variations!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 33
 Give W/One Hand,Take W/the Other
ƒ Oracle sometimes improves things in ways that make it very
difficult for us to take advantage of them
ƒ When are two SQL statements the same and yet different?
twoblocks.sql
Column A Column B
SELECT COUNT(*) select count(*)
FROM after_deforestation; = from after_deforestation; ?
BEGIN BEGIN
UPDATE favorites update favorites
SET flavor = 'CHOCOLATE' set flavor = 'CHOCOLATE' ?
WHERE name = 'STEVEN'; = where name = 'STEVEN';
END; END;
BEGIN BEGIN
UPDATE ceo_compensation update ceo_compensation
SET stock_options = 1000000, set stock_options = 1000000,
salary = salary * 2.0 = salary = salary * 2 ?
WHERE layoffs > 10000; where layoffs > 10000;
END; END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 34

 Crossing the Physical-Logical Divide
ƒ When you write SQL, you must be aware of the physical
representation of your code
– Pre-parsed cursors are only used for byte-wise equal statements
(analyzed using a hash of the SQL string)
– White space (blanks, tabs, line breaks) make a difference – except for
SQL inside PL/SQL blocks
– PL/SQL reformats SQL to avoid nuisance redundancy
ƒ Not much can be done, however, about these kinds of logical
duplications: BEGIN
update ceo_compensation
BEGIN set salary = salary * 2,
UPDATE ceo_compensation stock_options = 1000000
SET stock_options = 1000000, where layoffs > 10000;
salary = salary * 2
WHERE layoffs > 10000;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 35
 How to Avoid SQL Repetition
ƒ You should, as a rule, not even write
SQL in your PL/SQL programs
– You can't repeat it if you don't write it

ƒ Instead, rely on pre-built, pre-tested,

write-once, use-often PL/SQL
programs.
SQL
– "Hide" both individual SQL statements
and entire transactions.

Guaranteed transaction integrity!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 36

 Transaction Integrity with
PL/SQL
A Method That Guarantees Integrity
The application calls
Order Entry a packaged program
Program to execute the logical
transaction.

All business rules

are embedded and
maintained in the
package The packaged code
communicates with
the tables.

Order Item
Table Table

ƒ This is why Oracle originally developed the PL/SQL language!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 37
 Hide all SQL Behind Interface

ƒ A team lead can't watch over everybody's shoulders to

"police" the construction of every SQL statement
– Instead, a group needs to set policies and provide code so that
everyone can follow the rules – and write better code

ƒ Here are some recommendations:

– Build and use table encapsulation packages
– Hide all single row queries behind function interfaces
– In particular, don't expose the dual table
– Move multi-row cursors into packages

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 38

 The Beauty of Table Encapsulation
Insert
Update
Application
Employee Delete Code
GetRow

ƒ Move all SQL inside packages: one per table or "business object"
– All DML statements written by an expert, behind a procedural interface,
with standardized exception handling
– Commonly-needed cursors and functions to return variety of data (by
primary key, foreign key, etc.)
– If the encapsulation package doesn't have what you need, add the new
element, so that everyone can take advantage of it
– Separate packages for query-only and change-related functionality (for
added security) te_employee.*
givebonus*.sp
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 39
 Allow No Exceptions!
ƒ Instead of this:
INSERT INTO employee
(employee_id, department_id, salary, hire_date) TRUE STORY!
VALUES "I forced all programmers to
(1005, 10, 10000, SYSDATE); use the encapsulated
INSERT, instead of writing
ƒ Do this: their own. Using SQLab, we
determined that this one
te_employee.insert ( insert statement was parsed
employee_id_in => 1005, department_id_in => 10, 1 time and executed over a
salary_in => 10000, hire_date_in => SYSDATE); million times! It has been in
the SGA for over 2 weeks,
ƒ Check dependency information to identify never aging out because it is
called so frequently."
programs that rely directly on tables
SELECT owner || '.' || name refs_table,
REFERENCED_owner || '.' || REFERENCED_name table_referenced
FROM ALL_DEPENDENCIES
WHERE type IN ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'FUNCTION')
AND REFERENCED_type IN ('TABLE', 'VIEW');

reftabs.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 40
 Minimal Encapsulation a Must!
ƒ At an absolute minimum, hide every single row query behind the
header of a function
– If you hide the query, you can choose (and change) the implementation
for optimal performance

ƒ No need to argue about implicit vs explicit; the main thing is to

encapsulate

ƒ Best approach: put the function in a package, so you can take

advantage of package-level data
– Very useful for data caching mechanisms; by hiding the way you retrieve
the data, you allow yourself the freedom to change the retrieval
implementation without affecting any usages

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 41

 Get Me the Name for an ID...
Don't "expose" any SQL... Instead, hide the query
DECLARE CREATE OR REPLACE PACKAGE te_employee
l_name VARCHAR2(100); AS
BEGIN SUBTYPE fullname_t IS VARCHAR2
SELECT last_name || ',' || (200);
first_name
INTO l_name FUNCTION fullname (
FROM employee l employee.last_name%TYPE,
WHERE employee_id = f employee.first_name%TYPE
employee_id_in; )
... RETURN fullname_t;
END;
FUNCTION name (
And call the function... employee_id_in IN
employee.employee_id%TYPE
DECLARE )
l_name te_employee.fullname_t; RETURN fullname_t;
BEGIN END;
l_name := /
te_employee.name (
employee_id_in);
...
explimpl.pkg
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 42

 And Never, Ever Expose the
Dual Table
ƒ The dual table is 100% kluge. It is astonishing that Oracle
still relies on it within the STANDARD PL/SQL package

ƒ Always hide queries against the dual table inside a function

– We need to be optimistic: perhaps in Oracle12i the dual table will
no longer be necessary

Instead of this... Write this:

BEGIN BEGIN
SELECT employee_id_seq.NEXTVAL l_employee_id :=
INTO l_employee_id te_employee.next_pkey;
FROM dual;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 43

 Encapsulation Creation Options
ƒ You can pursue one of the following four models:
Focused
Template-Based Quick and Dirty Feature of
Generator
Development Homemade Model Broader Product
Product

Oracle Designer PL/Generator

tmplgen.sql pkggen.sql
SQL-Station from RevealNet

Increasing degrees of flexibility and automation

ƒ Many challenges to successful encapsulation, including:

– Write large volumes of high quality code.
– Train developers to understand and use the API.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 44
 Write Code Assuming Change
Dependent
Existing
Data structure programs Re-compile
code base
changes marked invalid code
valid
invalid

ƒ Use anchoring to tightly link code to underlying data

structures
ƒ Rely on bind variables inside SQL statements
ƒ Fetch into cursor records
ƒ Qualify all references to PL/SQL variables inside SQL
statements

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 45

 Anchor Declarations of
Variables
ƒ You have two choices Hard-Coded Declarations
when you declare a ename VARCHAR2(30);

variable:
totsales NUMBER (10,2);

– Hard-coding the datatype

– Anchoring the datatype to
another structure Anchored Declarations
Whenever possible, use anchored v_ename emp.ename%TYPE;
totsales pkg.sales_amt%TYPE;
declarations rather than explicit
datatype references emp_rec emp%ROWTYPE;
tot_rec tot_cur%ROWTYPE;
%TYPE for scalar structures
%ROWTYPE for composite
structures
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 46
 Examples of Anchoring
DECLARE The emp table
v_ename emp.ename%TYPE;
v_totsal config.dollar_amt%TYPE;
ename VARCHAR2(60)
newid config.primary_key; empno NUMBER
BEGIN hiredate DATE
. . .
sal NUMBER
END;

ƒ Use %TYPE and %ROWTYPE

PACKAGE config when anchoring to database
IS
dollar_amt NUMBER (10, 2); elements
pkey_var NUMBER(6); ƒ Use SUBTYPEs for
programmatically-defined types
SUBTYPE primary_key
IS ƒ SUBTYPEs can also be used to
pkey_var%TYPE; mask dependencies that are
END config; revealed by
PLV.sps
%TYPE/%ROWTYPE
aq.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 47
 Benefits of Anchoring
ƒ Synchronize PL/SQL variables with database columns and rows
– If a variable or parameter does represent database information in your
program, always use %TYPE or %ROWTYPE
– Keeps your programs in synch with database structures without having
to make code changes
ƒ Normalize/consolidate declarations of derived variables
throughout your programs
– Make sure that all declarations of dollar amounts or entity names are
consistent
– Change one declaration and upgrade all others with recompilation

Remember: Never Repeat Code!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 48
 Quiz: Where's the Hard Coding?
1 name VARCHAR2 (30);
2 minbal NUMBER(10,2);
3 BEGIN
4 OPEN company_pkg.allrows (1507);

5 FETCH company_pkg.allrows INTO name, minbal;

6 IF name = ‘ACME’ THEN ...

ƒ Better question for this code: which of these six lines

of code do not contain an example of hard-coding?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 49

Always Fetch into Cursor Records
name VARCHAR2 (30); Fetching into individual
w minbal NUMBER(10,2); variables hard-codes
BEGIN number of items in select
r OPEN company_pkg.allrows; list.
o FETCH company_pkg.allrows
INTO name, minbal;
n
g IF name = ‘ACME’ THEN ...

CLOSE company_pkg.allrows;
Fetching into a record
means writing
rec company_pkg.allrows%ROWTYPE; less code.
r BEGIN
I OPEN company_pkg.allrows;
FETCH company_pkg.allrows INTO rec;
g If the cursor select list
changes, it doesn't
h IF rec.name = ‘ACME’ THEN ...
necessarily affect your
t CLOSE company_pkg.allrows;
code.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 50

 Avoid Hard Coding inside SQL
ƒ Don't bury hard-coded values in your SQL statements
– Instead, move your cursors to a shared area and then rely on that
version in all instances
ƒ Here is some inefficient, hard to maintain code:
DECLARE DECLARE
CURSOR r_and_d_cur IS CURSOR marketing_cur IS
SELECT last_name FROM employee SELECT last_name FROM employee
WHERE department_id = 10; WHERE department_id = 20;
BEGIN
ƒ And what it should be: OPEN marketing_cur;

CREATE OR REPLACE PACKAGE bydept

IS
CURSOR name_cur (dept IN INTEGER) IS
SELECT last_name FROM employee
WHERE department_id = dept;
BEGIN
Local variables OPEN bydept.name_cur (20);
also avoid multiple parses. bindvar.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 51

 Avoiding SQL-PL/SQL
Naming Conflicts
ƒ One rule: make sure that you never define variables with same name as
database elements
– OK, you can be sure today, but what about tomorrow?
– Naming conventions simply cannot offer any guarantee
ƒ Better approach: always qualify references to PL/SQL variables inside
SQL statements
– Remember: you can use labels to give names to anonymous blocks

PROCEDURE del_scenario
IS
reg_cd VARCHAR2(100) := :GLOBAL.reg_cd; No problem!
BEGIN
DELETE FROM scenarios
WHERE reg_cd = del_scenario.reg_cd
AND scenario_id = :scenario.scenario_id;
END; delscen.sql
delscen1.sql
delscen2.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 52
 Write SQL Efficiently in PL/SQL

ƒ It's one thing to tune your SQL statements; it is quite

another to write your SQL inside PL/SQL so that it
executes as efficiently as possible

ƒ Use native SQL whenever possible

ƒ Use PL/SQL to replace IO-intensive SQL
ƒ Use the RETURNING Clause
ƒ Use WHERE CURRENT OF
ƒ BULK BIND and COLLECT (Oracle8i)
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 53
 Use Native SQL Whenever
Appropriate

ƒ If you can replace a PL/SQL loop that executes a SQL

statement repetitively with a "pure" SQL statement, you are
likely to get improved performance
ƒ Instead of this:
FOR rec IN (SELECT ename, sal FROM emp)
LOOP
UPDATE emp SET sal = rec.sal * 1.01
WHERE ename = rec.ename;
END LOOP;

ƒ Do this:
UPDATE emp SET sal = sal * 1.01; allsql.tst
allsql2.tst

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 54

 Use PL/SQL to Avoid
IO-Intensive SQL
ƒ 100% Pure SQL -- it's almost always the right way to
go, but sometimes it results in excessive processing
– Correlated sub-queries compute same values repeatedly
– Multiple joins require lots of SORT/MERGE operations
SELECT 'Top employee in ' || department_id || ' is ' || Instead of one
E.last_name || ', ' || E.first_name str big query...
FROM employee E
WHERE E.salary = (SELECT MAX (salary) FROM employee E2
WHERE E2.department_id = E.department_id)
Break it up and
CURSOR dept_cur IS run within
SELECT department_id, MAX (salary) max_salary
PL/SQL loops...
FROM employee E GROUP BY department_id;

CURSOR emp_cur (dept IN PLS_INTEGER,maxsal IN NUMBER) IS

SELECT last_name || ', ' || first_name emp_name
useplsql.tst
FROM employee
WHERE department_id = dept AND salary = maxsal;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 55
 Use the RETURNING Clause
ƒ Oracle8 offers a new clause FOR INSERT and UPDATE
statements: the RETURNING clause.
– Retrieve information from DML statement w/o a separate query.
ƒ Instead of this:
BEGIN
INSERT INTO UnionBuster VALUES (ub_seq.NEXTVAL, 'Prison', 5);
SELECT ub_id, hourly_wage INTO v_latest_bustID, v_hard_to_beat
FROM UnionBuster
WHERE labor_type = 'Prison';
END;

ƒ Do this:
BEGIN
INSERT INTO UnionBuster VALUES (ub_seq.NEXTVAL, 'Prison', 5)
RETURNING ub_id, hourly_wage
INTO v_latest_bustID, v_hard_to_beat;
END;

returning.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 56
 Use WHERE CURRENT OF
ƒ When using SELECT FOR UPDATE, use the WHERE
CURRENT OF clause in UPDATE and DELETE to avoid
coding a possibly complex and slower WHERE clause.
ƒ Instead of this:
LOOP
FETCH cur INTO rec;
EXIT WHEN cur%NOTFOUND;

UPDATE employee SET last_name = UPPER (last_name)

WHERE employee_id = rec.employee_id;
END LOOP;

ƒ Do This:
LOOP
FETCH cur INTO rec;
EXIT WHEN cur%NOTFOUND;

UPDATE employee SET last_name = UPPER (last_name)

wco.sql
WHERE CURRENT OF cur;
END LOOP;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 57
 Use Bulk Binding and COLLECT
ƒ Oracle8i offers new syntax to improve the performance of
both DML and queries. In Oracle8, updating from a collection
(or, in general, performing multi-row DML) meant writing
code like this:
CREATE TYPE dlist_t AS TABLE OF INTEGER;
/

PROCEDURE whack_emps_by_dept (deptlist dlist_t)

IS
BEGIN
FOR aDept IN deptlist.FIRST..deptlist.LAST
LOOP
DELETE emp WHERE deptno = deptlist(aDept);
END LOOP;
END;

“Conventional bind” (and lots of them!)

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 58
 Conventional Bind
Oracle server

PL/SQL Runtime Engine SQL Engine

PL/SQL block
Procedural
statement
FOR aDept IN deptlist.FIRST.. executor
deptlist.LAST SQL
LOOP
DELETE emp statement
WHERE deptno = deptlist(aDept);
END LOOP; executor

Performance penalty
for many “context
switches”

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 59

 Enter the “Bulk Bind”
Oracle server

PL/SQL Runtime Engine SQL Engine

PL/SQL block
Procedural
statement
FORALL aDept IN deptlist.FIRST.. executor
deptlist.LAST SQL
DELETE emp
WHERE deptno = deptlist(aDept); statement
executor

Much less overhead for

context switching

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 60

 Use the FORALL Bulk Bind
Statement
ƒ Instead of the individual DML operations, you can do this:

PROCEDURE whack_emps_by_dept (deptlist dlist_t)

IS
BEGIN
FORALL aDept IN deptlist.FIRST..deptlist.LAST
DELETE FROM emp WHERE deptno = deptlist(aDept);
END;

ƒ Some restrictions:
– Only the single DML statement is allowed. If you want to INSERT
and then UPDATE, two different FORALL statements
– Cannot put an exception handler on the DML statement

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 61

 Use BULK COLLECT for Queries
CREATE OR REPLACE FUNCTION get_a_mess_o_emps
ƒ BULK COLLECT (deptno_in IN dept.depno%TYPE)
RETURN emplist_t

performs bulk bind IS

emplist emplist_t := emplist_t();

of results from SQL

TYPE numTab IS TABLE OF NUMBER;
TYPE charTab IS TABLE OF VARCHAR2(12);
TYPE dateTab IS TABLE OF DATE;
select statement enos numTab;
names charTab;

– Returns each
hdates dateTab;
BEGIN

selected expression
SELECT empno, ename, hiredate
BULK COLLECT INTO enos, names, hdates

in a table of scalars
FROM emp
WHERE deptno = deptno_in;
emplist.EXTEND(enos.COUNT);
FOR i IN enos.FIRST..enos.LAST
LOOP
emplist(i) := emp_t(enos(i),
names(i), hiredates(i));
END LOOP;
RETURN emplist;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 62

 Combining FORALL & BULK
COLLECT
ƒ Use the RETURNING clause to obtain information about
each of the DML statements executed in the FORALL
– Since you are executing multiple DML statements, you need
to BULK COLLECT the RETURNING results into one or more
collections
FUNCTION whack_emps_by_dept (deptlist dlist_t)
RETURN enolist_t
IS
enolist enolist_t;
BEGIN
FORALL aDept IN deptlist.FIRST..deptlist.LAST bulkcoll.sql
DELETE FROM emp WHERE deptno IN deptlist(aDept) bulktiming.sql.
RETURNING empno BULK COLLECT INTO enolist; bulkcollect91.sql

RETURN enolist;
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 63
 Tips and Fine Points
ƒ Use bulk binds if you write code with these characteristics:
– Recurring SQL statement in PL/SQL loop
– Use of a collection as the bind variable, or code that could be
transformed to use a collection containing the bind variable
information
ƒ Bulk bind rules:
– Can be used with any kind of collection
– Collection subscripts cannot be expressions
– The collections must be densely filled
– If error occurs, prior successful DML statements are NOT ROLLED
BACK
ƒ Bulk collects:
– Can be used with implicit and explicit cursors
– Collection is filled starting at row 1
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 64
 Optimizing DBMS_SQL Usage
ƒ DBMS_SQL implements dynamic SQL in PL/SQL
– It is a very complex and difficult to use package

ƒ Keep in mind the following tips when working with

DBMS_SQL:
– Re-parse only when absolutely necessary
– Allocate new cursors only when necessary
– Close dynamic SQL cursors when done, and also in
exception sections
– Always choose binding over concatenation
effdsql.tst
– Use bulk processing features of Oracle8
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 65
 Manage Dynamic SQL Cursors

ƒ If you have already allocated memory for a cursor and

assigned the value to a PL/SQL variable, you can parse
multiple statements against that same cursor
– Don’t open and close cursors unnecessarily
ƒ Make sure you close DBMS_SQL cursors when done and also
in exception sections
– They are not closed automatically when the block terminates
– You will often want to close cursors on exceptions in the parse phase
ƒ Best solution: encapsulate calls to
DBMS_SQL.OPEN_CURSOR and also DBMS_SQL.PARSE
openprse.pkg

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 66

 Choose Binding over
Concatenation
ƒ You can concatenate rather than bind, but binding is almost
always preferable. Two key reasons:
– Simpler code to build and maintain
– Improved application performance
ƒ Simpler code to build and maintain
– Concatenation results in much more complicated and error-prone code
unless you are doing a very simple operation effdsql.tst
updnval2.sp
ƒ Improved application performance updnval3.sp

– Concatenates requires an additional call to DBMS_SQL.PARSE and

also increases the likelihood that the SQL statement will be physically
different, requiring an actual re-parsing and unnecessary SGA
utilization
ƒ Note: you cannot bind schema elements, like table names
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 67
 Use Bulk Processing Features
ƒ Similar to the FORALL and COLLECT features of Oracle8i,
DBMS_SQL as of Oracle8 allows you to specify the use of
"arrays", i.e., index tables, when you perform updates, inserts,
deletes and fetches
ƒ Instead of providing a scalar value for an operation, you specify
an index table. DBMS_SQL then repeats your action for every
row in the table
ƒ It really isn't "array processing"
– In actuality, DBMS_SQL is executing the specified SQL statement N
times, where N is the number of rows in the table
ƒ This technique still, however, can offer a significant
performance boost over Oracle7 dynamic SQL
– And in some cases give you better performance than static SQL
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 68
 Array-Oriented Actions
ƒ You will take these steps when working with arrays or
collections in DBMS_SQL:
– Bind arrays of values with DBMS_SQL.BIND_ARRAY
– Define a column as an array with DBMS_SQL.DEFINE_COLUMN
– Fetch multiple rows with one call with DBMS_SQL.FETCH_ROWS
– Retrieve multiple column values with DBMS_SQL.COLUMN_VALUE
and DBMS_SQL.VARIABLE_VALUE
ƒ We will look at performing updates, inserts and deletes, then
finish up with queries
ƒ These examples are explained and explored thoroughly in
chapter 3 of Oracle Built-in Packages (O’Reilly & Associates)

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 69

 An Example with Bulk Deletes
ƒ When you delete using arrays, you will specify the values in the
WHERE clause for all rows to be deleted
CREATE OR REPLACE PROCEDURE delemps
(enametab IN DBMS_SQL.VARCHAR2_TABLE)
IS
cur PLS_INTEGER := PLVdyn.open_and_parse (
'DELETE FROM emp WHERE ename LIKE UPPER (:ename)');

fdbk PLS_INTEGER;
BEGIN
DBMS_SQL.BIND_ARRAY (cur, 'ename', enametab);

fdbk := DBMS_SQL.EXECUTE (cur);

p.l ('Rows deleted', fdbk);

DBMS_SQL.CLOSE_CURSOR (cur);
END;

dyndel.sp
dyndel.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 70
 Returning Values After Execution
ƒ With Oracle8, you can include a RETURNING clause
– Obtain info about rows just modified without issuing extra query
CREATE OR REPLACE PROCEDURE delemps (
enametab IN DBMS_SQL.VARCHAR2_TABLE)
IS
cur PLS_INTEGER := PLVdyn.open_and_parse (
'DELETE FROM emp WHERE ename LIKE UPPER (:ename) ' ||
' RETURNING empno INTO :empnos');
empnotab DBMS_SQL.NUMBER_TABLE; Notice use of
VARIABLE_VALUE
fdbk PLS_INTEGER;
BEGIN
DBMS_SQL.BIND_ARRAY (cur, 'ename', enametab);
DBMS_SQL.BIND_ARRAY (cur, 'empnos', empnotab);
fdbk := DBMS_SQL.EXECUTE (cur);
DBMS_SQL.VARIABLE_VALUE (cur, 'empnos', empnotab);

FOR indx IN empnotab.FIRST .. empnotab.LAST LOOP

p.l (empnotab(indx)); dyndel2.sp
dyndel2.tst
END LOOP;
DBMS_SQL.CLOSE_CURSOR (cur);
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 71
 Example of Bulk Fetch -- One Pass

ƒ I know the table is small, so I grab all the rows at once

CREATE OR REPLACE PROCEDURE showall IS
cur PLS_INTEGER;
fdbk PLS_ INTEGER;
empno_tab DBMS_SQL.NUMBER_TABLE;
hiredate_tab DBMS_SQL.DATE_TABLE;
BEGIN
cur := PLVdyn.oap ('SELECT empno, hiredate FROM emp');

DBMS_SQL.DEFINE_ARRAY (cur, 1, empno_tab, 100, 1);

DBMS_SQL.DEFINE_ARRAY (cur, 2, hiredate_tab, 100, 1);

fdbk := DBMS_SQL.EXECUTE_AND_FETCH (cur);

DBMS_SQL.COLUMN_VALUE (cur, 1, empno_tab);

DBMS_SQL.COLUMN_VALUE (cur, 2, hiredate_tab);

FOR rowind IN empno_tab.FIRST .. empno_tab.LAST arrayemp.sp

LOOP
p.l (empno_tab(rowind)); p.l (hiredate_tab(rowind));
END LOOP;
DBMS_SQL.CLOSE_CURSOR (cur);
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 72

 Fetching N Records at a Time
DBMS_SQL.DEFINE_ARRAY (cur, 1, empno_tab, numrows, 1);
DBMS_SQL.DEFINE_ARRAY (cur, 2, hiredate_tab, numrows, 1);

fdbk := DBMS_SQL.EXECUTE (cur);

LOOP
fdbk := DBMS_SQL.FETCH_ROWS (cur);

DBMS_SQL.COLUMN_VALUE (cur, 1, empno_tab);

DBMS_SQL.COLUMN_VALUE (cur, 2, hiredate_tab);
arrayempN.sp
EXIT WHEN fdbk < numrows;
END LOOP;

ƒ What if you do not know how many rows will be fetched?

– In this case, you fetch N rows at a time inside a loop and then exit
when there are no more to fetch. The above example shows the
kind of loop you would write
ƒ Note: rows are appended to the index tables. You must
DELETE in between fetches to clear them out (unless you
want to fill the table and process the data later)
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 73
 Update Rows En Masse From File
ƒ This examples shows how to do a bulk load of data from a file
into SQL
– Data file contains key (employee number) and new salary
– Use UTL_FILE to read the contents of the file and load it into arrays
– Use Oracle8 DBMS_SQL to update in a single pass

CREATE OR REPLACE PROCEDURE upd_from_file

(loc IN VARCHAR2, file IN VARCHAR2)
IS
cur PLS_INTEGER := DBMS_SQL.OPEN_CURSOR;
fdbk PLS_INTEGER;
Declare DBM_SQL
empnos DBMS_SQL.NUMBER_TABLE;
arrays and UTL_FILE
sals DBMS_SQL.NUMBER_TABLE;
pointer.
fid UTL_FILE.FILE_TYPE;
v_line VARCHAR2(2000); fileupd.sp
v_space PLS_INTEGER; fileupd.dat
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 74
 Quiz!
ƒ Some people get rich by laying off other people
– Write code to show the CEO(s) who laid off the most people, and
the CEO(s) who laid off the second-highest number of people
– You could do it all in pure SQL...but would you want to?

SELECT name || ' of ' || company Slasher1

FROM ceo_compensation
WHERE layoffs =
(SELECT MAX (layoffs)
FROM ceo_compensation);

SELECT name || ' of ' || company Slasher2

FROM ceo_compensation
WHERE layoffs =
(SELECT MAX (layoffs)
FROM ceo_compensation slowsql_q1.sql
WHERE layoffs != slowsql_a1.sql
(SELECT MAX (layoffs) slowsql_a1.tst
FROM ceo_compensation));0
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 75
 Quiz!
ƒ This program is running slowly. How can I improve it?
– This is a test of analyzing algorithms for unnecessary and/or slow
program performance, and tuning of DBMS_SQL code
CREATE OR REPLACE PROCEDURE insert_many_emps
IS
cur INTEGER := DBMS_SQL.open_cursor;
rows_inserted INTEGER;

BEGIN
DBMS_SQL.parse (cur,
'INSERT INTO emp (empno, deptno, ename)
VALUES (:empno, :deptno, :ename)',
DBMS_SQL.native);

FOR rowind IN 1 .. 1000

LOOP
DBMS_SQL.bind_variable (cur, 'empno', rowind);
DBMS_SQL.bind_variable (cur, 'deptno', rowind * deptno);
DBMS_SQL.bind_variable (cur, 'ename', 'Steven' || rowind);
rows_inserted := DBMS_SQL.execute (cur);
END LOOP; loadlots*.*

DBMS_SQL.close_cursor (cur);
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 76
 Writing SQL in PL/SQL
Summary

ƒ Never Repeat SQL

– Maximize performance, minimize impact of change
ƒ Anchor Variables Whenever Possible
– You're almost never doing something for the first time
– If you are, let that be the prototype for all others
ƒ Take a Serious Look at Table Encapsulation
– It's a worthwhile investment for the future of your
applications
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 77
PL/SQL Tuning & Best Practices

Package Construction

ƒ Hide package-level data inside the package body

ƒ Build toggles and windows to increase usability and

flexibility of your packages

ƒ Tips for managing large packages

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 78

 Hide Package Data!

ƒ Never put your variables and other data structures in the

package specification
– Always put it in the body. Then build publicly-available "get and set"
programs to change values in the data structures and retrieve the
current values
Set Procedure External
Data Program
Get Function

ƒ The benefits include:

– Tighter control over data structures. If your data is public, it can be
changed by any program with EXECUTE authority
– Flexibility to change implementation of data structure
– Ability to track access to the data
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 79
 Public vs. Private Data
PACKAGE P_and_L Public data, declared in
IS package specification,
last_stmt_dt DATE; directly accessible.
END P_and_L;

PACKAGE BODY P_and_L Tip: Use PLVgen.gas to

IS generate code like this.
Now in the body, last_stmt_dt DATE;
with get-and-set
routines. FUNCTION last_date RETURN DATE IS
BEGIN
RETURN last_stmt_dt;
END;

PROCEDURE set_last_date (date_in IN DATE)

And a business IS
rule: date cannot BEGIN
be in the future. last_stmt_dt := LEAST (date_in, SYSDATE);
END;
END P_and_L;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 80

 Different Access Paths to Data
The public approach exposes fully the variable and allows for violation of
the business rule. Below I move the last statement date into the future.
IF P_and_L.last_stmt_dt <
ADD_MONTHS (SYSDATE, -3)
THEN
P_and_L.last_stmt_dt := SYSDATE + 12;
END IF;

And a business rule is violated!

The private version of the same code hides the variable completely and
protects against violations of the rules.
IF P_and_L.last_date <
ADD_MONTHS (SYSDATE, -3)
THEN
P_and_L.set_last_date (SYSDATE + 12);
END IF;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 81

 Tracking Variable Reads and Writes
ƒ When you use get-and-sets to control access to your data, good
things just naturally start coming your way
– For example, you can easily add a trace to your code to show when, where
and how a specific variable’s value is read and/or changed. Wow!
– If you have exposed the variable in the specification of the package, it would
be very difficult to perform this kind of trace
– A PL/SQL debugger might someday do this
– Or maybe you could examine the source code stored in the USER_SOURCE
view. A fairly tedious process
ƒ But with get-and-sets, you have given yourself a “hook” on
which to hang your trace
– Since the variable can only be accessed through these modules, you can
place your trace inside the procedure and function
– The package structure then guarantees that you will have caught every
access
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 82
 Tracking Changes to P&L Date
PACKAGE BODY P_and_L
ƒ With just a few, quick IS
changes, the p_and_l last_stmt_dt DATE;

package now uses FUNCTION last_date RETURN DATE IS

PLVxmn to show any BEGIN
PLVxmn.trace
attempts to access the ('last_date', 1, last_stmt_dt);
variable RETURN last_stmt_dt;
ƒ In this case, the PLVxmn END;

package itself offers the PROCEDURE set_last_date (date_in IN DATE)

ability to display the IS

BEGIN
module which called the PLVxmn.trace

package
('set_last_date', 2, date_in);

ƒ We will learn how to build

last_stmt_dt :=
LEAST (date_in, SYSDATE);
a trace package in the END;
END P_and_L;
next section
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 83
 Build Toggles and Windows
ƒ You will greatly increase the usability and flexibility of your
packages if you build toggles and windows into the package
interface (specification)

Data Window
External
Switch On
Switch Program
Flag
Switch Off

ƒ Toggles are...
– On/off switches that allow you to modify the behavior of the package
without changing its code
ƒ Windows offer...
– Read-only access to the inner workings of a package
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 84
 A Window Offers Safe Viewing
External
Data Window Program

ƒ Normally, the contents of the package body (private data,

implementation of code) are completely hidden from a user of the
package
– This "black box" protects the integrity of the data and encourages top-
down design and problem-solving, but it can leave you in the dark when
you run and test your code
ƒ Maintain package integrity and shed light on internal package
functioning by providing read-only glimpses off package activity
– Developers open and close the window, but they can't "break and enter"
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 85
 A Toggle Offers Flexibility
ƒ A toggle is an on-off switch that allows a user to modifies
the behavior of programs inside the package
– Without making any code changes to that package

yes
Application Is feature Take requested
requests action turned on? action

no Continue normal
execution

ƒ Toggles are often used in conjunction with Windows, as the

next example will demonstrate

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 86

 Toggle & Window Example:
Variable Trace
ƒ A variable trace offers a fine example of a toggle and a window
BEGIN
P_and_L.set_stmt_date (SYSDATE + 12); A dozen
programs touch
IF P_and_L.stmt_date > SYSDATE - 4 your data. Which
THEN one is causing
P_and_L.set_stmt_date (SYSDATE - 1); the problem?
END IF;
END;

ƒ I want to be able to watch both reads from and writes to a

variable, and see:
– The current value of the variable
– The new value of the variable if it is being changed
– What program is touching the variable
ƒ What are my options?
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 87
 Adding Trace Before Each Touch
BEGIN
DBMS_OUTPUT.PUT_LINE (SYSDATE + 12);
P_and_L.set_stmt_date (SYSDATE + 12);

DBMS_OUTPUT.PUT_LINE (P_and_L.stmt_date);
IF P_and_L.stmt_date > SYSDATE - 4
THEN
DBMS_OUTPUT.PUT_LINE (SYSDATE - 1);
P_and_L.set_stmt_date (SYSDATE - 1);
END IF;
END;

ƒ This approach is full of drawbacks, including:

– Reduces productivity and code quality. You must write the same code
repeatedly (and remember to do it). You must then take out those
calls when done testing, etc.
– DBMS_OUTPUT.PUT_LINE is, in and of itself, problematic. For
example, what if the SQL string contains more than 255 characters?
What if you want to write to a pipe?
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 88
 A Better Idea: Put Trace
Inside "Touch"
ƒ Bundle the trace into each program that reads from or writes to
the variable
– Requires no additional coding for users, except to turn on the
trace when needed
ƒ Combine the window with a toggle to turn it on and off
– After all, you don't always want to see this information
CREATE OR REPLACE PACKAGE p_and_l Get and Set programs
IS for hidden date variable.
PROCEDURE set_stmt_date (date_in IN DATE);
FUNCTION stmt_date RETURN DATE;
Turn trace on or off,
PROCEDURE trc; return current setting.
PROCEDURE notrc;
FUNCTION tracing RETURN BOOLEAN;
END; p_and_l.pkg
watch.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 89
 Trace Window & Toggle
Implementation
CREATE OR REPLACE PACKAGE BODY p_and_l
IS
g_trace BOOLEAN := FALSE;
Global Boolean Flag
PROCEDURE trc IS
BEGIN
g_trace := TRUE;
END;

PROCEDURE notrc IS
Procedures set the
BEGIN flag's value, while the
g_trace := FALSE;
END;
function returns
the current value.
FUNCTION tracing RETURN BOOLEAN IS
BEGIN
RETURN g_trace;
END;
/* MORE ON NEXT PAGE
*/
END dynsql;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 90
 Trace Window & Toggle
Implementation
CREATE OR REPLACE PACKAGE BODY p_and_l
IS
PROCEDURE set_stmt_date (date_in IN DATE)
IS
BEGIN
IF tracing
THEN
Check status watch.action ('set_stmt_date', date_in);
of toggle. END IF;

g_stmt_date := date_in; Rely on separate

END; watch package.
END p_and_l;

ƒ By creating a separate package to do the watching, you have

a reusable utility that also hides the implementational details,
giving you lots of flexibility
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 91
 The Watch Package
Specification
CREATE OR REPLACE PACKAGE watch
IS Select the
PROCEDURE toscreen; output type.
PROCEDURE topipe;

PROCEDURE action (prog IN VARCHAR2, val IN BOOLEAN);

PROCEDURE action (prog IN VARCHAR2, val IN DATE);
PROCEDURE action (prog IN VARCHAR2, val IN NUMBER);
PROCEDURE action (prog IN VARCHAR2, val IN VARCHAR2);

PROCEDURE show; Overloaded

END; watch programs.

ƒ You have to know when to draw the line

– Watch does not try to determine automatically the program which asked
for the watch (check out PLVcs for a package that can do this)
– Instead, it will just call DBMS_UTILITY.FORMAT_CALL_STACK
watch.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 92
 The Watch Package Body
CREATE OR REPLACE PACKAGE BODY watch
IS
c_pipe_name CONSTANT VARCHAR2(3) := 'watch$trc';

c_screen CONSTANT INTEGER := 0;

Data to manage
c_pipe CONSTANT INTEGER := 1;
output type.
g_target INTEGER := 0;

PROCEDURE toscreen
IS Request a
BEGIN write to screen.
g_target := c_screen;
END;

PROCEDURE topipe
IS Request a
BEGIN write to pipe.
g_target := c_pipe;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 93

 The Watch Package Body
PROCEDURE action (prog IN VARCHAR2, val IN VARCHAR2)
IS
stat INTEGER; Put together
msg PLV.dbmaxvc2; the watch string.
BEGIN
msg := ' Time: ' || PLV.now || ' Context: ' || prog ||
' Message: ' || val ||
' Callstack ' || DBMS_UTILITY.FORMAT_CALL_STACK;

IF g_target = c_screen
THEN Write to screen.
p.l (msg);

ELSIF g_target = c_pipe

THEN
Write to pipe.
DBMS_PIPE.RESET_BUFFER;
DBMS_PIPE.PACK_MESSAGE (msg);
stat := DBMS_PIPE.SEND_MESSAGE (c_pipe_name, timeout => 0);
END IF;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 94

 Managing Package Code

ƒ Modularize and re-use internal package elements to

reduce code volume and improve maintainability

ƒ Split up large packages into separate, smaller packages

-- and hide the split

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 95

 Modularize Within Your Package

ƒ Modularizing your code is always important, but inside

package bodies modularization is more crucial than
ever before
– And it is also often neglected
– Ugly package bodies can be hidden behind pretty (well-
designed) interfaces
– That works (if you're lucky) for the first production roll-out.
Maintenance is, on the other hand, an unqualified nightmare

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 96

 Modularize Within Your
Package (Cont.)
ƒ Package bodies can be very hard to control and maintain,
particularly because of the primitive nature of PL/SQL
editors
– Overloading, in particular, carries the potential for greatly
increased code volume and lots of code redundancy
– As you deepen your PL/SQL skills and take on more complex
application development challenges, you must also deepen
your commitment to properly modularizing your code
– Perhaps you should remember that "diamonds are forever"...

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 97

 The Overloading Diamond
Top point of diamond:
"single" program

User View
Display Data

Package Spec
Display Date Display Number Display String
Diamond facets
are the programs
in the Package Body
specification
Display Formatted Text

Your challenge: to pull all the facets back to a point, a Bottom point of
single implementation. diamond: the
implementation
p.spb

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 98

 Avoiding Redundancy In the Package
ƒ Sometimes the need to modularize is obvious
– Large-scale overloading literally begs for a consolidated implementation
– In other situations the pattern and need is less clear, but the long-term
implications if you do not bother to modularize can be severe
ƒ You should be an unabashed fanatic when it comes to avoiding
redundant code in your package body
– It might seem like extra work at first, but as scope creeps and
enhancement requests arrive, you will find yourself very thankful for the
initial effort.
– Follow that deceptively simple rule: never repeat a line of code. Instead,
build a private (body-only) function or procedure to encapsulate the
logic
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 99
 Code Reuse in the PLVdyn
Package
dropobj truncate

dml_update (3) multiobj compile

parse_update ddl

open_and_parse

display_data DBMS_SQL.
DBMS_SQL.PARSE
OPEN_CURSOR

PLVprs.display_wrap

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 100
 Splitting up Large Packages
ƒ It is certainly possible to create stored code -- especially
packages -- which become too large
– Too large to compile
– Too large to maintain effectively
– Too large to enhance in a reasonable span of time
ƒ What can you do when you have created "monsters"?
– Modularize ruthlessly, avoiding any kind of code repetition by using
nested modules or private programs in the body
– You can also split up large packages into separate program units to
make sure that you can compile -- and incrementally compile --
without lengthy delays

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 101
 Lots of Code, Lots of Headaches
ƒ The problem is with the body (all that code), not the
specification
"Deep" (large)
programs

Before...

Global, private
data Data

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 102
 After: Break Up that Big Body
ƒ Keep the public specification intact so existing
code is not affected by the change Shallow
public
package
Create a
"virtual
package"
through
privileges.

Data

Move global
data into
"hidden"
pkg spec.

splitpkg.pkg

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 103
 Package Construction
Summary

ƒ Hide the Data

– Build get-and-set routines (or generate them) and keep
control of your data

ƒ Make Your Packages Flexible and Accessible

– Toggles and windows are easy enough to add after the fact
– Help users do things the right way

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 104
PL/SQL Tuning & Best Practices
Modularization & Encapsulating Logic

ƒ Modularizing fundamentals
ƒ Encapsulation scenarios
ƒ The dangers of over-abstraction

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 105
 Back to Modularizing
Fundamentals
ƒ Modularize to reduce complexity, make your tasks
manageable, and make your resulting code maintainable
ƒ Tried-and-tested guidelines for 3GLs hold true for PL/SQL
– Code Complete by Steve McConnell is chock-full of
recommendations
ƒ Two to keep in mind:
– Modularize with top-down design; keep executable sections
small and easy to read
– Avoid multiple RETURN statements in executable section
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 106
 Keeping Executable Code Tight
ƒ Most of the time when we write programs, we end up with big blobs
of code spaghetti

ƒ Executable sections that are hundreds, if not thousands of lines long

ƒ If someone -- anyone -- is going to be able to maintain and enhance

your code, you need to:
– Keep your executable sections small and self-documenting
– Avoid fanatically any code redundancies

An objective worth aiming for:

Thou Shalt Keep Thy Executable Sections
Down to a Single Page or Screen
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 107
 Local Modules Improve Readability
ƒ Move blocks of PROCEDURE assign_workload (department_in IN NUMBER)
IS
complex code into CURSOR emp_cur

the declaration
IS
SELECT * FROM emp WHERE deptno = department_in;

section PROCEDURE assign_next_open_case

(emp_id_in IN NUMBER, case_out OUT NUMBER) IS BEGIN … END;
ƒ Replace them FUNCTION next_appointment (case_id_in IN NUMBER) IS BEGIN … END;
with descriptive PROCEDURE schedule_case
names (case_in IN NUMBER, date_in IN DATE) IS BEGIN … END;

BEGIN /* main */
ƒ The code is now FOR emp_rec IN emp_cur
easier to read and LOOP
IF analysis.caseload (emp_rec.emp_id) <
maintain analysis.avg_cases (department_in);
THEN
ƒ You can more assign_next_open_case (emp_rec.emp_id, case#);
schedule_case
easily identify (case#, next_appointment (case#));
areas for END IF;
END LOOP
locmod.sp
utgen.pkb
improvement END assign_workload;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 108
Local Modules Avoids Redundancy
ƒ Even if local modules don't have a dramatic impact on code
volume, the extra effort to avoid redundancy today is a valuable
insurance policy against maintenance costs in the future
PROCEDURE calc_percentages (total_in IN NUMBER)
IS

FUNCTION formatted_pct (val_in IN NUMBER)

RETURN VARCHAR2 IS
BEGIN
RETURN TO_CHAR ((val_in/total_in) * 100, '$999,999');
END;

BEGIN
food_sales_stg := formatted_pct (sales.food_sales);
service_sales_stg := formatted_pct (sales.service_sales);
toy_sales_stg := formatted_pct (sales.toy_sales);
END;

locmod.sp
hashdemo.sp 9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 109
 Avoid Multiple RETURNS in Functions
ƒ Try to follow the general rule: one way in, one way out
– Multiple RETURNs in the executable section make it error-
prone and difficult to maintain
FUNCTION status_desc ( FUNCTION status_desc (
cd_in IN VARCHAR2) cd_in IN VARCHAR2)
RETURN VARCHAR2 RETURN VARCHAR2 Now it always
IS IS RETURNs
BEGIN retval VARCHAR2(20); something.
IF cd_in = 'C' BEGIN
THEN RETURN 'CLOSED'; IF cd_in = 'C'
THEN retval := 'CLOSED';
ELSIF cd_in = 'O' ELSIF cd_in = 'O'
THEN RETURN 'OPEN'; THEN retval := 'OPEN';
ELSIF cd_in = 'I'
ELSIF cd_in = 'I' THEN retval := 'INACTIVE';
THEN RETURN 'INACTIVE'; END IF;
END IF; RETURN retval;
END; END;

ƒ You should, however, include RETURNs in exception

multret.sf
explimpl.pkg

handlers unless the error is "catastrophic"

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 110
 Encapsulating for Protection and
Flexibility
ƒ When you encapsulate, you wrap something inside a layer of
code
ƒ Here are some scenarios crying out for encapsulation:
Application Application Application

Enhancement Implementation Interception

Encapsulation Encapsulation Layer
Current Current Native PL/SQL
Weak Approach Data Structure Functionality

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 111
 Developing the Encapsulation
Reflex
ƒ We'll explore several examples of encapsulation
(a.k.a., abstraction):
– Implementing transaction flexibility
– Working around the limitations of DBMS_OUTPUT
– Storing knowledge so that it won't be forgotten
– Using assertion routines

ƒ But first...you have to give yourself (or request)

the time to be creative, to visualize a higher level
of abstraction

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 112
 Make the Extra Effort!
ƒ The path of "minimal implementation" taken (often) by Oracle:
PACKAGE DBMS_UTILITY
IS
PROCEDURE comma_to_table( All lists manipulated by PL/SQL
list IN VARCHAR2, developers are delimited by
tablen OUT BINARY_INTEGER, commas, right?
tab OUT uncl_array);

ƒ With a user community in the millions, you should aim higher

PACKAGE DBMS_UTILITY
IS
My Dream Implementation...
PROCEDURE string_to_table (
list IN VARCHAR2,
Allow user definition of the
tab OUT uncl_array,
delimiter, overload for more
delim IN VARCHAR2 := ','
flexible usage.
);

FUNCTION string_to_table
(list_in VARCHAR2, delim IN VARCHAR2 := ',')
RETURN uncl_array;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 113
 It's Hard to Achieve
Effective Reuse
We need all of the following...
ƒ Quality code that is worth reusing
ƒ Central repository for code
ƒ Means of locating the right piece of code
ƒ Good documentation of code in the repository
ƒ Management commitment to supporting reuse

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 114
 Transaction Management
Flexibility
A simple enough recommendation:
Never call COMMIT; in your PL/SQL code

ƒ When you do that you hard-code your

transaction boundaries into your code
– After all, there's no reversing a COMMIT

What? You think that's silly?

Sure, we all need to commit now and then.

The question: what is the best way to do that in your code?
Developers often need more flexibility and features than the
COMMIT built-in can provide.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 115
 Guys Don't Wanna COMMIT -
Reason 1
ƒ During test phase, they want to easily reset their test data back
to its original form
– Sure, you could build a script to drop all the objects and recreate
them with the proper data, but that can be time-consuming
ƒ Instead, why not just comment out the COMMIT?
– When I'm done testing, I will "un-comment" as needed
PROCEDURE my_monster_application
IS
BEGIN
Insert_a_bunch_of_rows;
It's a classic mistake.
You finish debugging your
Change_lots_more_data;
application -- and then you
change it to make it
-- COMMIT;
"production ready".
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 116
 Guys Don't Wanna COMMIT -
Reason 2
ƒ They need to update 1M rows and find themselves running out
of rollback segments or getting "snapshot too old" errors
– So you have to commit "every N records"

commit_counter := 0
FOR original_rec IN original_cur
LOOP
translate_data (original_rec);
Surely you have
IF commit_counter >= 10000 better things to
THEN do with your time
COMMIT; than write code
commit_counter := 0; like this!
ELSE
commit_counter := commit_counter + 1;
END IF;
END LOOP;
COMMIT;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 117
 Guys Don't Wanna COMMIT -
Reason 3
ƒ They use a non-default rollback segment, and that darn
COMMIT resets the active RB segment to the default
– The "fix" is easy: you just have to remember to call
DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT every time you
execute a COMMIT
– And you have to remember the name of that obscure program!
BEGIN
Here's
COMMIT;
one!
DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT ('big_one');

FOR I IN 1 .. max_years
Uh oh! do_stuff;
There's COMMIT;
another one! DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT ('bigone');
END LOOP;

Whoops! Typo!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 118
 Who Needs Those
Complications?

ƒ You've got enough to worry about, without having to

deal with all of that stuff!
ƒ Make your coding life simpler by hiding all those
details, all those complications, behind a packaged
interface
– Use toggles and windows in the package to change the
commit behavior of your application…without changing
your application!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 119
 Intercepting and Modifying a
Commit
ƒ Use toggles to override and even turn off default processing

Application By calling
requests commit PLVcmt.perform_commit

Is trace
no
Finally, the real
turned on?
thing!

yes
yes
Display or log Is commit COMMIT;
information turned on?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 120
 Using the COMMIT Alternative
ƒ The following program uses the PL/Vision alternative
to COMMIT
CREATE OR REPLACE PROCEDURE myapp (counter IN INTEGER)
IS
BEGIN
/* Define the current rollback segment. */ Set the non-default
PLVcmt.set_rbseg ('bigseg'); rollback segment.

FOR cmtind IN 1 .. counter

LOOP
DELETE FROM emp2 WHERE ROWNUM < 2;

PLVcmt.perform_commit (
'DELETED ' || SQL%ROWCOUNT ||
' on iteration ' || cmtind); While committing,
END LOOP; also pass trace
END; information.
cmt.tst
plvcmt.sps
plvcmt.spb
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 121
Simplify Incremental Commit Logic
ƒ The following program commits every N record
– But the N is not fixed in the code
– Much less code needs to be written
PROCEDURE update_seven_million_rows (every_n IN INTEGER)
IS
BEGIN Set the increment and
PLVcmt.commit_after (every_n); initialize the counter.

PLVcmt.init_counter;

FOR original_rec IN original_cur

Set the increment and
LOOP
initialize the counter.
translate_data (original_rec);
PLVcmt.increment_and_commit;
END LOOP;

PLVcmt.perform_commit; Save any "leftovers".

END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 122
 The Added Value Adds Up

ƒ Some people right now are This instructor must be

surely thinking to nuts. You actually
expect us to build a
themselves: package that contains
18 programs, instead of
just COMMIT?"

Well, it would be nuts to build something that

already exists. So use PLVcmt (Lite or otherwise) if
this technique looks handy.
Otherwise, the next time you find yourself writing
incremental commit logic or wishing you could see
when/if you committed, remember PLVcmt!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 123
 Storing Acquired Knowledge
ƒ We learn new techniques after significant investment of research
time, and then we lose access to that new knowledge
– The result is lowered productivity and redundant code
February 1998 April 1998 February 1999

Program 1 Program 2 Program 3

Queries and Code Queries and Code Queries and Code

to Manipulate to Manipulate to Manipulate
Primary Keys Primary Keys Primary Keys

After three hours, Where did I put that Primary keys, wait a
I figured it all out -- and stuff on primary keys? minute, there's a note
I buried it in my current Aw heck, I'll just write it on my terminal: see
program. again. checktab.sql.

ƒ Give yourself a break and encapsulate as you learn

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 124
 Encapsulating Data Dictionary Info
ƒ How many times have you ventured deep into the reference
manuals to figure out how to extract information from the data
dictionary on a given topic?
– It's a jungle in there!
– A package is a perfect place to store the knowledge and make it easily
accessible

PLVpky PLVfkys PLVcols

PLVinds PLVcons

pky.tst
tabhaslong.sf
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 125
 Let's Talk About DBMS_OUTPUT
ƒ PL/SQL 1 had ZERO tracing/output capability, causing an
uproar from the developer community
ƒ So Oracle Corporation gave us DBMS_OUTPUT, and it:
– Requires the typing of 20 letters just to call the darned thing
– Knows nothing about the Boolean datatype
– Ignores my requests to display blank lines and trims leading blanks
– Raises VALUE_ERROR if the string has more than 255 bytes
– Refuses to display anything until the block finished executing?

How did they manage to make

something this straightforward
so painful to use?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 126
 Saving Yourself From
DBMS_OUTPUT
ƒ Just say to yourself: "I will never call that thing in my
application, instead I will call my own, better alternative"

DBMS_OUTPUT

Application
Software

Overlay
Package
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 127
Constructing a Useful Substitute
PROCEDURE p.l (line_in IN VARCHAR2) IS Don’t ignore leading
BEGIN blanks or blank lines.
IF RTRIM (line_in) IS NULL
THEN
DBMS_OUTPUT.PUT_LINE (g_prefix);

ELSIF LENGTH (line_in) > p.linelen Wrap (instead of

THEN blowing up on) long
PLVprs.display_wrap (line_in, linelen); strings.

ELSE
DBMS_OUTPUT.PUT_LINE (g_prefix || line_in);
END IF;

EXCEPTION
Anticipate and attempt
WHEN OTHERS
to correct common
THEN
problems.
DBMS_OUTPUT.ENABLE (1000000);
DBMS_OUTPUT.PUT_LINE (g_prefix || line_in);
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 128
 Validation of Assumptions
ƒ Every module has its assumptions
– A certain set of key data is available, or dates must be
within a specific range
– If you don't validate those assumptions, your programs
will break in unpredictable, ugly ways
ƒ Code defensively
– Assume that developers will not use your programs
properly

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 129
 Traditional Approach to Validation
ƒ Use conditional logic to perform the checks
If department pointer is
PROCEDURE calc_totals (
NULL, display message &
dept_in IN INTEGER, date_in IN DATE) IS
raise error.
BEGIN
IF dept_in IS NULL
THEN
p.l ('Provide a non-NULL department ID.');
RAISE VALUE_ERROR;
END IF;

IF TRUNC (date_in) NOT BETWEEN

TRUNC (ADD_MONTHS (SYSDATE, -60)) AND TRUNC (SYSDATE)
THEN
p.l ('Date is out of range.');
RAISE VALUE_ERROR;
If date is out of range,
END IF;
display message & raise
error.
/* Ok, now perform the calculation. */

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 130
The Problems with Business-as-Usual

ƒ First, notice the repetition in this approach

– Two IF statements (issues of excessive code volume)
– Two different calls to a display mechanism
– Two different RAISEs
ƒ Second, I have exposed or hard-coded the way I check for and
deal with assumption violations
– If I ever decide to change the way I handle violations of assumptions,
I have to go to each IF statement and make the fix
ƒ You can avoid all of these problems and end up with a much
more powerful and flexible way of validating assumptions by
using assertion routines
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 131
 Taking the Assertion Approach
PROCEDURE calc_totals
(dept_in IN INTEGER, date_in IN DATE) IS
BEGIN Ease of use improves
assert (dept_in IS NOT NULL, chances of checking all
'Provide a non-NULL department ID.'); conditions.

assert (TRUNC (date_in) BETWEEN

TRUNC (ADD_MONTHS (SYSDATE, -60)) AND TRUNC (SYSDATE),
'Date is out of range.');

/* Ok, now perform the calculation. */

. . .
END;

ƒ Call a program instead of writing the code repeatedly

– A generic condition tester, consolidating all logic in one place
– Work in positive terms, asserting that your assumption holds
– Segregate validation logic from "approved" executable logic
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 132
 Building a Generic Assertion Program
Let's start with simplest, most naive implementation —
PROCEDURE assert (condition_in IN BOOLEAN)
IS
BEGIN
IF NOT condition_in
Stops the calling program
THEN
if the condition is FALSE.
RAISE VALUE_ERROR;
END IF;
END;

ƒ Puts a thin layer of code I need to display a message!

between the application and

I need to raise a different exception!
the asserting logic
– This gives you flexibility...
– And the ability to recover from
And what about Nulls?
oversights and near misses
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 133
 Enhancing the Assertion Program
PROCEDURE assert (
condition_in IN BOOLEAN, Ah, what a relief! Now I
msg_in IN VARCHAR2 := NULL) know for certain that all
IS NULLs are trapped.
BEGIN
IF NOT condition_in OR condition_in IS NULL
THEN
IF msg_in IS NOT NULL
Display a message if it is
THEN
provided.
DBMS_OUTPUT.PUT_LINE (msg_in);
END IF;
RAISE errpkg.assertion_failure;
END IF;
END; Special exception just for
assertions.

ƒ Make any needed corrections in one place only in your entire

application
– Correct mistakes with a minimum of embarrassment!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 134
 Offer Specialized Assertions
PACKAGE PLV
ƒ You will find yourself IS
PROCEDURE assert
writing the same Boolean (bool_in IN BOOLEAN,

expressions repeatedly
stg_in IN VARCHAR2 := NULL);

PROCEDURE assert_notnull
– Bury the repetition in a (val_in IN BOOLEAN|DATE|NUMBER|VARCHAR2,
variety of assertion stg_in IN VARCHAR2 := NULL);

programs PROCEDURE assert_inrange

(val_in IN DATE,
ƒ The result is that you write start_in IN DATE := SYSDATE,
end_in IN DATE := SYSDATE+1,
less code, get more stg_in IN VARCHAR2 := NULL,

consistent behavior, and

truncate_in IN BOOLEAN := TRUE);

are more likely to actually PROCEDURE assert_inrange

(val_in IN NUMBER,
test for these conditions start_in IN NUMBER, end_in IN NUMBER,
stg_in IN VARCHAR2 := NULL);

. . .

plv.sps

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 135
 Using Specialized Assertions
ƒ Let's take a final look at the calc_totals procedure, this
time using assertion programs designed to check for
specific types of conditions
PROCEDURE calc_totals
(dept_in IN INTEGER, date_in IN DATE)
IS
BEGIN
PLV.assert_notnull (dept_in,
'Provide a non-NULL department ID.');

PLV.assert_inrange (date_in,
ADD_MONTHS (SYSDATE, -60), SYSDATE,
'Date is out of range.');

/* Ok, now perform the calculation. */

. . .
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 136
 The Dangers of Excessive
Encapsulation
ƒ Suppose that I am building an application that needs to make
extensive use of UTL_FILE to write the contents of a variety of
tables to files

ƒ Two possible implementations:

– Create a single, generic program that can write the contents of any
table to any file…HARD!
– Write a new “dump” procedure for each table…TEDIOUS!

ƒ I decided to tackle the hard challenge, but do so in a way that

would offer a powerful “repository management” utility to any
use of PL/Vision: PLVrep
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 137
 Design Objective of PLVrep
ƒ Single language or API that can be used to manipulate the
various kinds of data repositories known to PL/SQL
– Database table
– Collection (index-by table)
– Database pipe
– Operating system file
– String
– Screen

ƒ With PLVrep, you (theoretically) don't need to know about

UTL_FILE, SQL, DBMS_SQL, DBMS_PIPE,
DBMS_OUTPUT, etc. Excellent!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 138
 Layers of Abstraction with PLVrep
Data Merge Application
Case Converter
Process Server

PLVrep, a Generic Repository Manager

Repository- PL/Vision Dataset

Specific Layers
PLVdata Manager
PLVfile PLVpipe PLVdyn

PLVdate PLVtab

PLVbool PLVofst
UTL_FILE DBMS_PIPE DBMS_SQL

PLVstr PLVseg
Generic PL/SQL Repository Functions

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 139
Flow of Generic Repository Mgt.
Allocates memory to keep track of
Define information about the repository.

Opens a dynamic cursor,

Open opens a file, etc. Makes repository
available for read/write operations.

Read from repository.

Manipulate
Write to repository.
Contents
Analyze status of repository.

Closes a file, closes a cursor, etc.

Close Makes repository unavailable
for read/write operations

Deallocates memory from the repository.

Destroy Pointer becomes invalid.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 140
 PLVrep Tackles "Table to File"
CREATE OR REPLACE PROCEDURE tab2file (
tab IN VARCHAR2, file IN VARCHAR2 := NULL,
delim IN VARCHAR2 := ',')
IS
tid PLS_INTEGER := PLVrep.dbtabid (tab);
fid PLS_INTEGER :=
PLVrep.fileid (NVL (file, tab || '.dat'),
fixedlen=>PLV.ifelse (delim IS NULL, TRUE, FALSE));
BEGIN
PLVrep.tabsegs (tid, tab); -- Make the repositories look like
PLVrep.tabsegs (fid, tab); -- the table.
PLVrep.copy (tid, fid, segdelim => delim);
END;

Write any table to any file.

Five lines of executable code.
Wow!

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 141
 Problems with PLVrep
ƒ Too complicated
– 143 procedures and functions
– A robust new vocabulary for PL/SQL developers ?!?!

ƒ Too generic
– It tries to achieve (and largely accomplishes) too much.
– Feature set overwhelms potential advantage of a “single language”

ƒ Too slow
– The tradeoff for being so generic, for hiding so much complexity, is
that PLVrep has to do lots of work on your behalf

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 142
 What is High Quality Software?
ƒ Is it a "perfectly" designed and
implemented system, built upon
many layers of abstracted,
theoretically reusable code?
– Is such a thing (a) truly desirable
or (b) even possible? or…

ƒ Should I try to build a beautiful

monument to myself or should I
create a living, breathing home that
others can inhabit -- and modify -- as
needed?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 143
 Let's Talk About Habitability
"Habitability is the characteristic of a piece of source code that
enables programmers, coders, bug-fixers, and people coming to
the code later in its life to understand its construction and
intentions, and to change it comfortably and confidently.“

… Richard Gabriel, Patterns of Software

ƒ Why would habitability be important?

– Software is written by people; what makes us human must be
taken into account in the software development process
– Software must constantly be changed. It can never possibly be
perfect, because it is supposed to reflect the real world

ƒ A closely-related concept: piecemeal growth

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 144
 Piecemeal Growth of Software
"Piecemeal growth is the process of design and implementation in
which software is embellished, modified, reduced, enlarged and
improved through a process of repair rather than of replacement."

… Richard Gabriel, Patterns of Software

ƒ Gee, it's like someone gave a name to what we are already

and always doing

ƒ Let's stop beating ourselves up with a bunch of shoulds:

should have encapsulated, should have reused, should
have abstracted…
– Instead, we should accept it as reality and change our
environment and our processes to support it
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 145
 Habitable “Table to File” Program
CREATE OR REPLACE PROCEDURE DEPARTMENT2file (
loc IN VARCHAR2,
file IN VARCHAR2 := 'DEPARTMENT.dat',
delim IN VARCHAR2 := '|'
)
IS
fid UTL_FILE.FILE_TYPE;
line VARCHAR2(32767);
BEGIN
fid := UTL_FILE.FOPEN (loc, file, 'W');
FOR rec IN (SELECT * FROM DEPARTMENT)
LOOP
/* Construct the single line of text.*/
line :=
TO_CHAR (rec.DEPARTMENT_ID) || delim ||
rec.NAME || delim ||
TO_CHAR (rec.LOC_ID);
Easy to understand, but I
UTL_FILE.PUT_LINE (fid, line);
END LOOP; have to write a new
procedure for each table.
UTL_FILE.FCLOSE (fid);
END;

tab2file.txt
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 146
 Resolving the Dilemma w/Code
Generation
ƒ So we have a bind:
– Write (and learn how to use)
Quality
highly abstracted, complex
code, or… Artistry

– Write (and maintain) lots of

code, and make it
decent quality, maintainable Productivity Application
Specificity
stuff
ƒ Perhaps there is a "third
way": context-aware code
generation

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 147
 Generate "Habitable" Code?
[STOREIN][objname]2file.sp
CREATE OR REPLACE PROCEDURE [objname]2file (
loc IN VARCHAR2,
file IN VARCHAR2 := '[objname].dat',
delim IN VARCHAR2 := '|'
) Template captures pattern.
IS
fid UTL_FILE.FILE_TYPE;
[IF]oraversion[IN]8.0,8.1 Utility generates code from
line VARCHAR2(32767); template for a specific object.
[ELSE]
line VARCHAR2(1023);
[ENDIF] Resulting code is readily
BEGIN understandable and easily
fid := maintained.
UTL_FILE.FOPEN (loc, file, 'W');
FOR rec IN (SELECT * FROM [objname])
LOOP
line :=
[FOREACH]col
[IF][coldatatype][eq]VARCHAR2
...

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 148
 Encapsulation Recommendations
ƒ Build small encapsulations/abstractions
– If I need to take a week-long class to learn how to use the
abstraction/library, I will never really (re)use that code
ƒ Keep hierarchies shallow as long as possible
– If you make a mistake along the way, you can fix it with a minimum of
impact
ƒ Build incrementally
– Avoid “master plans”; build in direct response to programmer needs
ƒ Don't accept performance trade-offs for abstraction
– It is very rarely justified in a production environment
ƒ Find or build tools/utilities to leverage abstractions
– The toughest challenge of all!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 149
PL/SQL Best Practices

Developing an
Exception Handling
Architecture

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 150
 Exception Handling in PL/SQL
Execute Application Code

Handle Exceptions

ƒ The PL/SQL language provides a powerful, flexible "event-

driven" architecture to handle errors which arise in your programs
– No matter how an error occurs, it will be trapped by the corresponding
handler
ƒ Is this good? Yes and no
– You have many choices in building exception handlers
– There is no one right answer for all situations, all applications
– This usually leads to an inconsistent, incomplete solution

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 151
 You Need Strategy &
Architecture
ƒ To build a robust PL/SQL application, you need to decide on
your strategy for exception handling, and then build a code-
based architecture for implementing that strategy
ƒ In this section, we will:
– Explore the features of PL/SQL error handling to make sure we have
common base of knowledge
– Examine the common problems developers encounter with exception
handling
– Construct a prototype for an infrastructure component that enforces a
standard, best practice-based approach to trapping, handling and
reporting errors The PL/Vision PLVexc
package is a more complete
implementation.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 152
 Flow of Exception Handling
PROCEDURE financial_review
IS
BEGIN PROCEDURE calc_profits
calc_profits (1996); IS BEGIN
numeric_var := 'ABC';
calc_expenses (1996);
EXCEPTION
DECLARE WHEN VALUE_ERROR THEN
v_str VARCHAR2(1); log_error;
PROCEDURE calc_expenses BEGIN RAISE;
IS BEGIN v_str := 'abc'; END;
... EXCEPTION
EXCEPTION WHEN VALUE_ERROR THEN
WHEN NO_DATA_FOUND . . .
THEN END;
log_error; EXCEPTION
END; WHEN OTHERS
THEN
...
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 153
 Scope and Propagation
Reminders
ƒ You can never go home
– Once an exception is raised in a block, that block's executable section
closes. But you get to decide what constitutes a block
ƒ Once an exception is handled, there is no longer an exception
(unless another exception is raised)
– The next line in the enclosing block (or the first statement following the
return point) will then execute
ƒ If an exception propagates out of the outermost block, then that
exception goes unhandled
– In most environments, the host application stops
– In SQL*Plus and most other PL/SQL environments, an automatic
ROLLBACK occurs
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 154
 What the Exception Section Covers
ƒ The exception section only handles exceptions raised in the
executable section of a block
– For a package, this means that the exception section only handles
errors raised in the initialization section
DECLARE
Declarations
BEGIN
Executable
Statements
EXCEPTION
Exception
Handlers
END
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 155
 Continuing Past an Exception
ƒ Emulate such behavior by enclosing code within its own block
PROCEDURE cleanup_details (id_in IN NUMBER) IS
BEGIN
DELETE FROM details1 WHERE pky = id_in;
All or DELETE FROM details2 WHERE pky = id_in;
Nothing END;

PROCEDURE cleanup_details (id_in IN NUMBER) IS

BEGIN
BEGIN
The DELETE FROM details1 WHERE pky = id_in;
"I Don't Care" EXCEPTION WHEN OTHERS THEN NULL;
Exception END;
Handler BEGIN
DELETE FROM details2 WHERE pky = id_in;
EXCEPTION WHEN OTHERS THEN NULL;
END;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 156
 Exceptions and DML
ƒ DML statements are not rolled back by an exception unless it
goes unhandled
– This gives you more control over your transaction, but it also can
lead to complications
– What if you are logging errors to a database table? That log is then
a part of your transaction
ƒ You may generally want to avoid "unqualified" ROLLBACKs
and instead always specify a savepoint
EXCEPTION
WHEN NO_DATA_FOUND THEN
ROLLBACK TO last_log_entry;
INSERT INTO log VALUES (...);
SAVEPOINT last_log_entry;
But it can get
END;
complicated!
lostlog*.sql
rb.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 157
 Application-Specific Exceptions
ƒ Raising and handling an exception specific to the application requires
special treatment
– This is particularly true in a client-server environment with Oracle
Developer

Client Side Server Side

Update, Delete, Insert
Oracle Forms
Application
Emp DB Trigger
Table

Send Error Info Back

Stored
Program

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 158
 Communicating an Application Error
ƒ Use the RAISE_APPLICATION_ERROR built-in procedure to
communicate an error number and message across the client-server
divide
– Oracle sets aside the error codes between -20000 and -20999 for your
application to use. RAISE_APPLICATION_ERROR can only be used those
error numbers
RAISE_APPLICATION_ERROR
(num binary_integer,
msg varchar2,
keeperrorstack boolean default FALSE);

The following code from a database triggers shows a typical usage of

RAISE_APPLICATION_ERROR
IF :NEW.birthdate > ADD_MONTHS (SYSDATE, -1 * 18 * 12)
THEN
RAISE_APPLICATION_ERROR
(-20070, ‘Employee must be 18.’);
END IF;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 159
 Handling App. Specific Exceptions
– Handle in OTHERS with check against SQLCODE...
BEGIN
INSERT INTO emp (empno, deptno, birthdate)
VALUES (100, 200, SYSDATE);
Server-side
EXCEPTION
WHEN OTHERS THEN
Database
IF SQLCODE = -20070 ...
END;

Or handle with named exception, declared on client side ...

DECLARE
emp_too_young EXCEPTION;
PRAGMA EXCEPTION_INIT (emp_too_young, -20070);
BEGIN
INSERT INTO emp (empno, deptno, birthdate)
VALUES (100, 200, SYSDATE); Server-side
EXCEPTION Database
WHEN emp_too_young THEN ...
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 160
 The Ideal But Unavailable
Solution
-- Declare the exception in one place (server) and reference it (the error number or
name) throughout your application.
Server side pkg
CREATE OR REPLACE PACKAGE emp_rules IS
defines exception.
emp_too_young EXCEPTION;
END;

IF birthdate > ADD_MONTHS (SYSDATE, -216) THEN

Database trigger
RAISE emp_rules.emp_too_young;
raises exception.
END IF;

BEGIN
INSERT INTO emp VALUES (100, 200, SYSDATE);
EXCEPTION Client side block
WHEN emp_rules.emp_too_young THEN ... handles exception.
END;

But this won't work with Oracle Developer! If it's got a dot and is defined
on the server, it can only be a function or procedure, not an exception or
constant or variable...
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 161
 Blocks within Blocks I
– What information is displayed on your screen when you
execute this block?
DECLARE
aname VARCHAR2(5);
BEGIN
BEGIN
aname := 'Justice';
DBMS_OUTPUT.PUT_LINE (aname);
EXCEPTION
WHEN VALUE_ERROR
THEN
DBMS_OUTPUT.PUT_LINE ('Inner block');
END;
DBMS_OUTPUT.PUT_LINE ('What error?');
EXCEPTION
WHEN VALUE_ERROR
THEN excquiz1.sql
DBMS_OUTPUT.PUT_LINE ('Outer block');
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 162
 Blocks within Blocks II
– What information is displayed on your screen when you
execute this block?
DECLARE
aname VARCHAR2(5);
BEGIN
DECLARE
aname VARCHAR2(5) := 'Justice';
BEGIN
DBMS_OUTPUT.PUT_LINE (aname);

EXCEPTION
WHEN VALUE_ERROR THEN
DBMS_OUTPUT.PUT_LINE ('Inner block');
END;
DBMS_OUTPUT.PUT_LINE ('What error?');
EXCEPTION
WHEN VALUE_ERROR THEN excquiz2.sql
DBMS_OUTPUT.PUT_LINE ('Outer block'); excquiz2a.sql
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 163
 Blocks within Blocks III
ƒ What do you see when you execute this block?
DECLARE
aname VARCHAR2(5);
BEGIN
<<inner>>
BEGIN
aname := 'Justice';
EXCEPTION
WHEN VALUE_ERROR THEN
RAISE NO_DATA_FOUND;

WHEN NO_DATA_FOUND THEN

DBMS_OUTPUT.PUT_LINE ('Inner block');
END inner;

EXCEPTION excquiz3.sql
WHEN NO_DATA_FOUND THEN excquiz6.sql
excquiz6a.sql
DBMS_OUTPUT.PUT_LINE ('Outer block');
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 164
 Blocks within Blocks IV
ƒ What do you see when you execute this block?
– Assume that there are no rows in emp where deptno equals -15
DECLARE
v_totsal NUMBER;
v_ename emp.ename%TYPE;
BEGIN
SELECT SUM (sal) INTO v_totsal FROM emp WHERE deptno = -15;

p.l ('Total salary', v_totsal);

SELECT ename INTO v_ename

FROM emp
WHERE sal =
(SELECT MAX (sal) FROM emp WHERE deptno = -15);

p.l ('The winner is', v_ename);

EXCEPTION
WHEN NO_DATA_FOUND THEN
p.l ('Outer block'); excquiz4.sql
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 165
 Taking Exception to My Exceptions
ƒ What do you see when you execute this block?
DECLARE
d VARCHAR2(1);
no_data_found EXCEPTION;
BEGIN
SELECT dummy INTO d
FROM dual
WHERE 1=2;

IF d IS NULL
THEN
RAISE no_data_found;
END IF;

EXCEPTION
WHEN no_data_found excquiz5.sql

THEN
DBMS_OUTPUT.PUT_LINE ('No dummy!');
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 166
 Where Did the Error Occur?
ƒ When an error occurs inside your code, the most
critical piece of information is the line number of the
program in which the error was raised
ƒ How can you obtain this information?
A. DBMS_UTILITY.FORMAT_ERROR_STACK
B. Unhandled exception
C. DBMS_UTILITY.FORMAT_CALL_STACK
D. Write error information to log file or table
disperr*.tst

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 167
 What, No GOTO?
ƒ It gets the job done…but does the end justify the means?
FUNCTION totalsales (year IN INTEGER) RETURN NUMBER
IS
return_nothing EXCEPTION;
return_the_value EXCEPTION;
retval NUMBER;
BEGIN
retval := calc_totals (year);

IF retval = 0 THEN
RAISE return_nothing;
ELSE
RAISE return_the_value;
END IF;

EXCEPTION
WHEN return_the_value THEN RETURN retval; isvalinlis.sql
WHEN return_nothing THEN RETURN 0;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 168
 An Exceptional Package
PACKAGE BODY valerr
PACKAGE valerr IS
IS v VARCHAR2(1) := ‘abc’;
FUNCTION FUNCTION get RETURN VARCHAR2 IS
get RETURN VARCHAR2; BEGIN
END valerr; RETURN v;
END;
BEGIN
p.l ('Before I show you v...');
EXCEPTION
WHEN OTHERS THEN
p.l (‘Trapped the error!’);
END valerr;

ƒ So I create the valerr package and then execute the following

command. What is displayed on the screen?
SQL> EXECUTE p.l (valerr.get);

valerr.pkg
valerr2.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 169
Desperately Seeking Clarity
ƒ Hopefully everyone now feels more confident in their
understanding of how exception handling in PL/SQL
works

ƒ Let's move on to an examination of the challenges you

face as you build an application and seek to build into
it consistent error handling

ƒ After that, we take a look at how you might build a

generic, reusable infrastructure component to handle
the complexities of exception handling
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 170
All-Too-Common Handler Code
EXCEPTION
WHEN NO_DATA_FOUND THEN
v_msg := 'No company for id ' || TO_CHAR (v_id);
v_err := SQLCODE;
v_prog := 'fixdebt'; I am showing
INSERT INTO errlog VALUES everyone how the
(v_err, v_msg, v_prog, SYSDATE, USER); log is kept.
WHEN OTHERS THEN
v_err := SQLCODE;
v_msg := SQLERRM;
Lots of
v_prog := 'fixdebt';
redundant code.
INSERT INTO errlog VALUES
(v_err, v_msg, v_prog, SYSDATE, USER);
RAISE;

ƒ If every developer writes exception handler code on their own, you end up
with an unmanageable situation
– Different logging mechanisms, no standards for error message text,
inconsistent handling of the same errors, etc.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 171
 Some Dos and Don'ts
ƒ Make decisions about exception handling before starting your
application development. Here are my recommendations:

DISCOURAGE individual developer usage of

RAISE_APPLICATION_ERROR, PRAGMA
EXCEPTION_INIT, explicit (hard-coded) -
20,NNN error numbers, hard-coded error
messages, exposed exception handling logic.

ENCOURAGE use of standardized components,

including programs to raise application-specific
exception, handle (log, re-raise, etc.) errors, and
rely on pre-defined error numbers and messages.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 172
 Checking Standards Compliance
ƒ Whenever possible, try to move beyond document-based
standards
– Instead, build code to both help people deploy standards and
create tools to help verify that they have complied with standards
CREATE OR REPLACE PROCEDURE progwith (str IN VARCHAR2)
IS
CURSOR objwith_cur (str IN VARCHAR2)
IS
SELECT DISTINCT name
FROM USER_SOURCE
WHERE UPPER (text) LIKE '%' || UPPER (str) || '%';

BEGIN
FOR prog_rec IN objwith_cur (str)
LOOP
p.l (prog_rec.name); valstd.pkg
END LOOP;
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 173
 Pre-Defined -20,NNN Errors
PACKAGE errnums
IS
Assign Error
en_general_error CONSTANT NUMBER := -20000;
Number
exc_general_error EXCEPTION;
PRAGMA EXCEPTION_INIT
(exc_general_error, -20000);

en_must_be_18 CONSTANT NUMBER := -20001;

exc_must_be_18 EXCEPTION; Declare Named
PRAGMA EXCEPTION_INIT Exception
(exc_must_be_18, -20001);

en_sal_too_low CONSTANT NUMBER := -20002;

exc_sal_too_low EXCEPTION;
PRAGMA EXCEPTION_INIT Associate
(exc_sal_too_low , -20002); Number w/Name

max_error_used CONSTANT NUMBER := -20002;

END errnums;

But don't write this code manually! msginfo.pkg

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 174
 Reusable Exception Handler
Package
PACKAGE errpkg Generic Raise
IS
PROCEDURE raise (err_in IN INTEGER);

PROCEDURE recNstop (err_in IN INTEGER := SQLCODE, Record

msg_in IN VARCHAR2 := NULL); and Stop

PROCEDURE recNgo (err_in IN INTEGER := SQLCODE,

msg_in IN VARCHAR2 := NULL); Record
and Continue

FUNCTION errtext (err_in IN INTEGER := SQLCODE)

RETURN VARCHAR2;

END errpkg;
Message Text
Consolidator errpkg.pkg

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 175
 Implementing a Generic RAISE
ƒ Hides as much as possible the decision of whether to do a normal
RAISE or call RAISE_APPLICATION_ERROR
– Also forces developers to rely on predefined message text
PROCEDURE raise (err_in IN INTEGER) IS
BEGIN
IF err_in BETWEEN -20999 AND -20000
THEN
RAISE_APPLICATION_ERROR (err_in, errtext (err_in));
ELSIF err_in IN (100, -1403)
Enforce use
THEN
RAISE NO_DATA_FOUND;
of standard
ELSE message
PLVdyn.plsql (
'DECLARE myexc EXCEPTION; ' ||
' PRAGMA EXCEPTION_INIT (myexc, ' ||
TO_CHAR (err_in) || ');' || Re-raise almost
'BEGIN RAISE myexc; END;'); any exception using
END IF; Dynamic PL/SQL!
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 176
 Raising Application Specific Errors
ƒ With the generic raise procedure and the pre-defined error numbers,
you can write high-level, readable, maintainable code
– The individual developers make fewer decisions, write less code, and
rely on pre-built standard elements
ƒ Let's revisit that trigger logic using the infrastructure elements...
PROCEDURE validate_emp (birthdate_in IN DATE) IS
BEGIN
IF ADD_MONTHS (SYSDATE, 18 * 12 * -1) < birthdate_in
THEN
errpkg.raise (errnums.en_must_be_18);
END IF;
END;

No more hard-coded
strings or numbers.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 177
 Deploying Standard Handlers
ƒ The rule: developers should only call a pre-defined handler inside
an exception section
– Make it impossible for developers to not build in a consistent, high-quality
way
– They don't have to make decisions about the form of the log and how the
process should be stopped
EXCEPTION
WHEN NO_DATA_FOUND
THEN
errpkg.recNgo (
SQLCODE,
' No company for id ' || TO_CHAR (v_id));

WHEN OTHERS
THEN The developer simply
errpkg.recNstop; describes
END; the desired action.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 178
 Implementing a Generic Handler
ƒ Hides all details of writing to the log, executing the handle action
requested, etc.
PACKAGE BODY errpkg
IS
PROCEDURE recNgo (err_in IN INTEGER := SQLCODE,
msg_in IN VARCHAR2 := NULL)
IS
BEGIN
log.put (err_in, NVL (msg_in, errtext (err_in)));
END;

PROCEDURE recNstop (err_in IN INTEGER := SQLCODE,

msg_in IN VARCHAR2 := NULL)
IS
BEGIN
recNgo (err_in, msg_in);
errpkg.raise (err_in); Pre-existing package
END; elements are re-used.

END errpkg;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 179
 Retrieving Consolidated
Message Text
FUNCTION errtext (err_in IN INTEGER := SQLCODE) RETURN VARCHAR2 IS
CURSOR txt_cur IS
SELECT text FROM message_text
WHERE texttype = 'EXCEPTION' AND code = err_in;
txt_rec txt_cur%ROWTYPE;
BEGIN
OPEN txt_cur;
FETCH txt_cur INTO txt_rec;
IF txt_cur%NOTFOUND THEN
txt_rec.text := SQLERRM (err_in);
END IF;
You can selectively
RETURN txt_rec.text;
override default,
END;
cryptic Oracle messages.

ƒ Or, as shown in the errpkg.pkg file, you can call the underlying
msginfo packaged function to retrieve the text from that standardized
component
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 180
 Added Value of a Handler
Package
ƒ Once you have all of your developers using the handler
package, you can add value in a number of directions:
– Store templates and perform runtime substitutions
– Offer the ability to "bail out" of a program, no matter how many
layers of nesting lie between it and the host application

exc.tst
exc2.tst
exc3.tst

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 181
 An Exception Handling Architecture
Summary

ƒ Make Sure You Understand How it All Works

– Exception handling is tricky stuff
ƒ Set Standards Before You Start Coding
– It's not the kind of thing you can easily add in later
ƒ Use Standard Infrastructure Components
– Everyone and all programs need to handle errors the
same way

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 182
PL/SQL Tuning & Best Practices

Control Contention
in
Multi-User Systems

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 183
 Sharing Resources
ƒ Anyone writing single-user applications can skip
this topic.
– Any takers?
ƒ Contention for shared resources can skewer
performance of the most perfectly written pl/sql
programs.
ƒ Many contention issues have their origin in
application design and implementation.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 184
 Types of Contention
ƒ Lock contention: waiting to access shared data
ƒ Latch contention: waiting to access Oracle internal
resources
– Can be difficult to diagnose properly, but there are classic
cases to avoid
ƒ I/O contention: waiting to read/write to disk
– Usually a DBA datafile / tablespace distribution issue
ƒ When user processes WAIT, algorithm efficiency
doesn’t matter at all!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 185
 SQL Locking Only one user can modify any
row in table

LOCK TABLE emp in EXCLUSIVE

MODE; Row-share lock for
all rows selected
SELECT * FROM emp FOR UPDATE;

UPDATE emp SET sal = sal*1.1 Row-exclusive lock

WHERE dept = 10; for all rows updated
SELECT * FROM dept;
No data locks taken

ƒ Locks released at transaction commit (rollback)

ƒ Lock only what you need and release as soon as
possible to avoid contention
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 186
 Controlled lock waiting
resource_busy EXCEPTION;
PRAGMA EXCEPTION_INIT(resource_busy,-54);
tries INTEGER := 1;
LOOP
EXIT WHEN locked OR tries = 3; Oracle also exposes
BEGIN lock mgmt services to
SELECT * FROM emp WHERE dept = 10
FOR UPDATE NOWAIT; PL/SQL
locked := TRUE;
EXCEPTION
WHEN resource_busy
THEN tries := tries + 1; DBMS_LOCK.SLEEP(.5);
END;
END LOOP;

ƒ NOWAIT raises ORA-54 when row(s) cannot be locked

ƒ Instead of waiting forever, catch exception and try again ½
second later (up to 3 times)
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 187
 Deadlock (name says it)
Lock requested
Resource A
Lock requested
User 1
Lock held
User 2

Lock held Resource B

ƒ Each session needs A and B to complete transaction

– And each holds what the other needs
ƒ One session’s transaction will be rolled back, which?
ƒ Avoid deadlock by locking resources in consistent order
– Lock A first, then B and deadlock will not occur
– Another good reason to encapsulate transactions
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 188
 Latching
ƒ Latches are like very short duration locks
ƒ Latches protect Oracle internal (SGA) data structures
– Your application cannot ask for a latch explicitly
ƒ All SQL activity involves numerous latches
– Latching is not a problem in itself
– Contention arises when too many processes ask for
latches too fast that are being held too long
ƒ Latch contention manifests as excess CPU
consumption and session waiting
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 189
 SQL processing latches
library cache: lookup cached SQL object
cache buffers chains: lookup data blocks in
buffer cache
You can’t prevent latching
cache buffers lru chain: add new blocks to buffer but you can avoid many
cache LRU lists latching problems.

library cache: lookup SELECT * FROM EMP;

cached SQL
shared pool: allocate
space for new SQL UPDATE EMP SET name = ‘JB’
WHERE id = ‘123’;

redo allocation: get space COMMIT;

in redo buffer
redo copy: copy changes to
buffer
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 190
 Controllable latch contention

ƒ Library cache and shared pool latches

– Too much hard parsing => not enough SQL sharing
– Use bind variables, not literal concatenation
– Avoid object invalidation/recompilation

ƒ Redo allocation and redo copy latches

– May be caused by very high commit frequency
– Another good reason to use a commit encapsulation
package

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 191
 ORA-1555: Snapshot too old
ƒ Common cause:
– Batch update driven by cursor on large result set
– Other processes updating cursor table(s)
– Concurrency problem, not rollback segment sizing
ƒ False cure: commit more frequently
– Problem is NOT rollback for updates, but rollback for read-
consistent image of cursor (unaffected by commit)
ƒ True cure: close and re-open the driving cursor
– Process the large result set in a sequence of read-
consistent images

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 192
 ORA-1555 Candidate
CURSOR big_result_cur IS
SELECT * FROM big_table;

FOR result_rec IN big_result_cur

LOOP
/* do some DML based on result_rec */
END LOOP;

ƒ Oracle tries to keep read-consistent image of

big_result_cur (as/of loop start time) until loop
finishes
ƒ If big_table rows modified by other processes this
can become difficult (or impossible = ORA-1555)
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 193
 Avoiding ORA-1555
last_id_processed INTEGER := 0; Parameterized cursor
Batch_size INTEGER := 1000;
pushes through successive
CURSOR result_set_cur(Lid integer) IS result sets
SELECT * FROM big_table BT
WHERE BT.id > Lid
ORDER BY BT.id ASC; Assumes results can
be ordered by id and
result_set_rec result_set_cur%ROWTYPE;
all ids > 0
OPEN result_set_cur(last_id_processed);
LOOP
FETCH result_set_cur INTO result_set_rec; Release read-consistent
EXIT WHEN result_set_cur%NOTFOUND;
image of result_set_cur
/* process result_set_rec */ and open new one, this
last_id_processed := result_set_rec.id; avoids the ORA-1555
IF MOD(result_set_cur%ROWCOUNT,batch_size=0)
THEN CLOSE result_set_cur; COMMIT;
OPEN result_set_cur(last_id_updated);
END IF;
END LOOP; COMMIT;9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 194
 Dangers of Dynamic SQL

ƒ Common tradeoff: flexibility vs. performance

ƒ Runtime compilation is always slower than pre-
compilation
– Extra parsing/optimization (CPU) and memory allocation
ƒ May only be problematic when volume is large
– So don’t be dogmatic about it!
ƒ Dynamic DDL can really be a killer
– Library cache object invalidation/recompilation

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 195
 Synonyms add overhead

ƒ Public and private synonyms both add additional

overhead vs. schema.objname references
– Both incremental CPU and shared pool memory overhead

ƒ When many database objects are referenced by

many users on high-throughput systems...
– It may pay to use fully qualified object references
– BUT this is a form of hard-coding that can have
maintenance implications

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 196
PL/SQL Tuning & Best Practices

Optimize Algorithms

ƒ Avoid Unnecessary Code Execution

ƒ Answer the Question Being Asked
ƒ Do Lots of Stuff At the Same Time
ƒ Avoid the Heavy Lifting

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 197
 Avoid Unnecessary Code
Execution

ƒ Avoid repetitive code execution

ƒ Optimal collection scanning code
ƒ Minimize database trigger firing

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 198
 Avoid Repetitive Code Execution
A classic problem area:
PROCEDURE process_data (nm_in IN VARCHAR2) IS
BEGIN
FOR rec IN pkgd.cur
LOOP
process_rec (UPPER (nm_in), rec.total_production);
END LOOP;
END;

Easy solution:
PROCEDURE process_data (nm_in IN VARCHAR2) IS
v_nm some_table.some_column%TYPE := UPPER (nm_in);
BEGIN
FOR rec IN pkgd.cur
LOOP
process_rec (v_nm, rec.total_production);
END LOOP;
END;
effdsql.tst
loadlots*.*
Sometimes the problem is less obvious...
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 199
Optimal Collection Scanning Code

ƒ Oracle offers three types of collections (index-by

tables, nested tables and variable arrays) and a
set of methods to modify/access those collections
ƒ A common requirement is to scan the contents of
these collections. What is the best way to do that?
ƒ Considerations as you think about writing such code:
– Index-by tables are not necessarily sequentially filled
– References to undefined rows raise the
NO_DATA_FOUND exception
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 200
 Using the FOR Loop
ƒ Methods used: COUNT, FIRST and LAST
– The COUNT method is used to make sure there is something in
the table
– If not, FIRST and LAST return NULL and a numeric FOR loop
from NULL to NULL raises VALUE_ERROR
BEGIN
IF birthdays.COUNT > 0
THEN
FOR rowind IN birthdays.FIRST .. birthdays.LAST
LOOP
DBMS_OUTPUT.PUT_LINE (birthdays(rowind).best_present);
END LOOP;
END IF;
END;

But I am still making a dangerous assumption about the contents of

this PL/SQL table!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 201
 Protection in the FOR Loop
ƒ If I want to make sure that my PL/SQL table references
never raise NO_DATA_FOUND, I should use the EXISTS
operator
BEGIN
IF birthdays.COUNT > 0
THEN
FOR rowind IN birthdays.FIRST .. birthdays.LAST
LOOP
IF birthdays.EXISTS (rowind)
THEN
DBMS_OUTPUT.PUT_LINE
(birthdays(rowind).best_present);
END IF;
END LOOP;
END IF;
END;

Still, this is far less than ideal as far as algorithms go. Why?
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 202
 Optimal Table Scanning Code
ƒ Using the FIRST and NEXT methods, I don't have to worry
about table sparseness and I don't have to use EXISTS to
check my next row for existence
– NEXT returns NULL when you are at the highest row
– To scan in reverse, start with LAST and use PRIOR
rowind PLS_INTEGER := birthdays.FIRST;
BEGIN
LOOP
EXIT WHEN rowind IS NULL;
DBMS_OUTPUT.PUT_LINE plsqlloops.sp
(birthdays(rowind).best_present);
rowind := birthdays.NEXT (rowind);
END LOOP;
END;

ƒ Note: you can also take advantage of various sorting algorithms,

depending on how the data is stored in a densely-filled collection
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 203
 Quiz!

ƒ How can I optimize this code?

PROCEDURE exec_line_proc (line IN INTEGER)
IS
BEGIN
IF line = 1 THEN exec_line1; END IF;
IF line = 2 THEN exec_line2; END IF;
IF line = 3 THEN exec_line3; END IF;
...
IF line = 2045 THEN exec_line2045; END IF;
END;

slowalg_q2.sql
slowalg_a2.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 204
 Minimize Firing of Database Triggers
CREATE OR REPLACE TRIGGER check_raise
AFTER UPDATE OF salary, commission
ON employee FOR EACH ROW
WHEN (NVL (OLD.salary, -1) != NVL (NEW.salary, -1) OR
NVL (OLD.commission, -1) != NVL (NEW.commission, -1))
BEGIN
...

ƒ Use the WHEN and UPDATE OF clauses

– Trigger will not fire unless the NEW salary is different from the OLD
-- and both are NOT NULL
– Trigger will not fire unless salary or commission are referenced in
the UPDATE statement
ƒ Disable trigger execution when you are certain of the data.
– Commonly applicable to batch processes
– The settrig.sp file contains a generalized mechanism to do this
settrig.sp
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 205
 Answer the Question
Being Asked
ƒ Are you a good listener?
Listening to what other people
say is an excellent skill to have
and develop -- and it applies to
programming as well
ƒ All too often, we don't listen or
read carefully enough to the
requirement -- and we answer
the wrong question

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 206
Do We Have Any Rows?
CREATE OR REPLACE PROCEDURE drop_dept
(deptno_in IN NUMBER, reassign_deptno_in IN NUMBER)
IS
temp_emp_count NUMBER;
BEGIN
-- Do we have any employees in this department to transfer?
SELECT COUNT(*)
INTO temp_emp_count
FROM emp WHERE deptno = deptno_in;
-- Reassign any employees
IF temp_emp_count >0
THEN
UPDATE emp
SET deptno = reassign_deptno_in
WHERE deptno = deptno_in;
END IF;
DELETE FROM dept WHERE deptno = deptno_in;
COMMIT;
END drop_dept;

ƒ How much is wrong with this code?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 207
 The Minimalist Approach
ƒ At least one row?
BEGIN
OPEN cur; Use an explicit cursor,
FETCH cur INTO rec; fetch once and then
IF cur%FOUND check the status.
THEN
...

ƒ More than one row?

BEGIN
OPEN cur;
FETCH cur INTO rec;
IF cur%FOUND Use an explicit cursor,
THEN fetch once and then fetch
FETCH cur INTO rec; again. "Two times" is the
IF cur%FOUND charm.
THEN
...

atleastone.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 208
 Do Lots of Stuff At the Same Time

ƒ Big computers, powerful software...we should do all

we can to take full advantage of those resources
ƒ PL/SQL does not offer support for multi-threading,
but you do have some options for simultaneous
execution of multiple programs in your application:
– Run programs in parallel with DBMS_PIPE
– Schedule asynchronous execution with DBMS_JOB

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 209
 Parallelize Your Code with Pipes
ƒ Oracle uses DBMS_PIPE to improve RDBMS performance
– Parallel updates of indexes, partitioned queries, etc.
ƒ You can do the same for your application if:
– You have multiple CPUs available
– You have processes which can run in parallel; they mustn't be inter-
dependent
Start

Process A Process B Process C

parallel.sql

Synchronize
&
Continue
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 210
 Schedule Asynchronous Execution
ƒ You can also use DBMS_JOB to execute programs in another
Oracle session
– The job can be run immediately, or at a specific time (and at a specific
interval. You will probably need to COMMIT to get the job going
– DBMS_JOB does not offer any inter-job relationships, so you have to
built in a pause for confirmation and so on
DECLARE
job# PLS_INTEGER;
PROCEDURE doit (job IN VARCHAR2) IS BEGIN
DBMS_JOB.SUBMIT (
job#, 'calc_comp (''' || job || ''')', SYSDATE, NULL);
COMMIT;
END;
BEGIN
doit ('CLERK');
doit ('VP');
doit ('PROGRAMMER');
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 211
 Avoid the Heavy Lifting
ƒ For reasons of both efficiency and productivity, you should
always check to see if a solution is already available before
you build it yourself
– If Oracle wrote it, it is probably implemented in C, increasing the
likelihood that it will run faster than what you produce
ƒ Familiarize yourself with the built-in functionality, from
STANDARD-based functions to the built-in packages
ƒ Consider the following requirements:
– Return TRUE if a string is a valid number, false otherwise
– Search for the Nth occurrence of a substring within a string, and
return the rest of the string from that point isnum*.*
fromnth.*

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 212
 Quiz!
ƒ Assuming that process_employee_history has been
optimized (a big assumption!), how else can we improve the
performance of this code?

DECLARE
CURSOR emp_cur
IS
SELECT last_name, TO_CHAR (SYSDATE, 'MM/DD/YYYY') today
FROM employee;
BEGIN
FOR rec IN emp_cur
LOOP
IF LENGTH (rec.last_name) > 20
THEN
rec.last_name := SUBSTR (rec.last_name, 1, 20);
END IF;
process_employee_history (rec.last_name, rec.today); slowalg_q1.sql
END LOOP; slowalg_a1.sql
END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 213
 Quiz!
ƒ Construct a schedule of lease payments for a store and save
them in a PL/ SQL table
– For each of 20 years, the lease amount is calculated as the sum of
lease amounts for the remaining years
– The total lease for year 10, in other words, would consist of the
lease amounts (fixed and variable) for years 10 through 20
ƒ Functions returning the lease amounts are provided
(dummies): pv_of_fixed, pv_of_variable
ƒ How best can we implement this requirement?
presvalue.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 214
 Quiz!
SQL> BEGIN
2 p.l (ltrim ('abcabcbadef', 'abc'));
3 p.l (lstrip ('abcabcbadef', 'abc', 2));
4 END;
5 /
def
badef

ƒ LTRIM and RTRIM trim specified characters, but do

not recognize patterns
ƒ Challenge: build a function that combines trim
capabilities with REPLACE, which replaces patterns
instead of individual characters lstrip*.sf
lstrip.tst

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 215
 PL/SQL Tuning and Best
Practices

Use Data Structures Efficiently

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 216
Use Data Structures Efficiently

ƒ When VARCHAR2 is not really VARCHAR2...

ƒ Rely on PLS_INTEGER
ƒ Avoid Implicit Conversions
ƒ Minimizing Transfer of Large Structures
ƒ Don't Use NOT NULL Constraints
ƒ Defer CPU and Memory Utilization Until Needed
ƒ Cache Data with Packages
ƒ Leverage Oracle Hashing

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 217
 When VARCHAR2 is not really
VARCHAR2
ƒ Before Oracle8, variables declared as VARCHAR2 were
treated computationally as variable length, but memory was
allocated as fixed-length. Beware!
ƒ On Oracle 7.3, you can use the following script to soak up all
the real memory available in your system:
DECLARE
TYPE big_type IS TABLE OF VARCHAR2(32767)
INDEX BY BINARY_INTEGER;
big big_type;
BEGIN
DBMS_OUTPUT.enable;
FOR i IN 1 .. 32767
LOOP
big (i) := NULL;
END LOOP;
END;

Note: memory is released when you end the session

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 218
 Rely on PLS_INTEGER

ƒ PLS_INTEGER operations use machine arithmetic, making it

the most efficient datatype for integer manipulation
– It has the same range as BINARY_INTEGER (-2147483647 ..
2147483647)
– Performance gains will vary greatly depending on the integer
computations

ƒ Prior to Oracle8, watch out for differences in behavior between

BINARY_INTEGER and PLS_INTEGER
– Use of PLS_INTEGER might raise an overflow exception, while use of
BINARY_INTEGER does not
– In Oracle8 and above, use of either raises consistent ORA-01426
errors (NUMERIC_OVERFLOW) plsint*.sql
overflow.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 219
 Avoid Implicit Conversions
ƒ If you are not careful, you can easily rely on the PL/SQL
engine to perform implicit (and perhaps unnecessary)
datatype conversions
– The result is minor performance degradation
Instead of this... Do this...
DECLARE DECLARE
num NUMBER; num NUMBER;
BEGIN BEGIN
num := num + 1; num := num + 1.0;

DECLARE DECLARE
str VARCHAR2(100); str VARCHAR2(100);
int PLS_INTEGER; int PLS_INTEGER;
BEGIN BEGIN
str := str || int; str := str || TO_CHAR (int);

implconv.tst

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 220
 Minimize Transfer of Large
Structures
ƒ Default parameter passing in PL/SQL is by value, not reference
– This means that IN OUT parameters are copied into local data
structures, upon which changes are made. The local contents are then
copied back to the parameter upon successful completion
ƒ Large IN OUT parameters (records and collections, primarily)
can cause performance degradation
ƒ Two solutions to this problem:
– Move data structure out of parameter list and into a package
Specification (making it a "global")
– Use the NOCOPY feature of Oracle8i
ƒ You can also use the Oracle8i UTL_COLL to tune access to
nested tables
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 221
 Move Structure to Package Spec.
ƒ You can avoid passing a large structure by defining it in the
specification of a package, making it globally accessible
– You can then remove it from the parameter list of your program and
reference it directly within the program
– SAFEST way to do this is to put the collection or record itself in the
package body and provide programs to access that structure
– Note: performance gains will vary greatly depending on what kind of
operations you perform on the structure
ƒ When you do this, you lose some flexibility
– Only once instance of the global can be manipulated within your
session
– This is quite different from passing any number of different structures
as parameters
pkgvar.pkg
pkgvar.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 222
 Use the NOCOPY Feature of Oracle8i
PROCEDURE nocopydemo (
some_collection IN OUT NOCOPY some_collection_tabtype,
some_object OUT NOCOPY some_object_type);

ƒ Most useful for collections, records and objects, but remember:

– When you specify NOCOPY, you are only making a request of or
suggestion to the compiler
ƒ Your request to use NOCOPY will be ignored when:
– Program is called via RPC (remote procedure call)
– You pass in just an element of a coll3ection
– Collection elements have a constraint (e.g., NOT NULL)
– Parameters are records with anchored declarations nocopy*.tst

– Implicit datatype conversions are required

– And more...see the documentation
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 223
 Nasty Tradeoff with By Reference
Passing
ƒ With conventional call by value:
– Parameter value changes are “rolled back” on an exception in called
routine
– May be preferred for data integrity -- behavior is in accord with
Oracle's read consistent principles
ƒ With call by reference (NOCOPY and using globals):
– Changes made to to a by-ref parameter take effect immediately and
are not rolled back when an exception occurs in your program. The
result may be a data structure with partial changes
ƒ Watch out for parameter aliasing problems (an issue for by-
value parameter passing as well)
– Issue arises when you pass a global structure as a parameter and
directly reference/change that global inside the program
parmalias.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 224
 Tune Access to Nested Tables
ƒ UTL_COLL is a new
CREATE OR REPLACE FUNCTION getpets_like
(petlist IN Pettab_t, like_str IN VARCHAR2)

Oracle8i package that

RETURN pettab_t
IS

allows you to take list_to_return Pettab_t := Pettab_t();

onepet Pet_t;

advantage of stored counter PLS_INTEGER := 1;

BEGIN

nested table “locators” IF UTL_COLL.IS_LOCATOR(petlist)

THEN
FOR theRec IN
ƒ You can avoid (SELECT VALUE(l) apet

materializing a large
FROM TABLE(CAST(petlist AS Pettab_t)) l
WHERE l.name LIKE like_str)

collection into memory by

LOOP
list_to_return.EXTEND;

instead accessing it via

list_to_return(counter) := theRec.apet;
counter := counter + 1;

locator
END LOOP;
ELSE
FOR i IN 1..petlist.COUNT
– Handy when you only LOOP
IF petlist(i).name LIKE like_str
want to access a portion THEN

of the collection's
list_to_return.EXTEND;
list_to_return(i) := petlist(i);
attributes END IF;
END LOOP;
END IF;
utlcoll*.sql RETURN list_to_return;
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 225
 Avoid NOT NULL Constraint
ƒ Oracle recommends that you avoid applying the NOT NULL constraint
to a declaration, and instead check for a NULL value yourself
ƒ Instead of this:
DECLARE
my_value INTEGER NOT NULL := 0;
BEGIN
IF my_value > 0 THEN ...
END;

ƒ Do this:
DECLARE
my_value INTEGER := 0;
BEGIN
IF my_value IS NULL THEN /* ERROR! */
ELSIF my_value > 0 THEN ...
END;

notnull.tst

ƒ Note: my tests indicate that the savings are nominal

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 226
 Defer Memory and CPU Allocation
ƒ Use nested, anonymous blocks to defer allocation of memory
and even CPU utilization
Before After
PROCEDURE always_do_everything PROCEDURE only_as_needed (...) IS
(...) BEGIN
IS IF <condition>
big_string VARCHAR2(32767) := THEN
ten_minute_lookup (...); DECLARE
big_list big_string VARCHAR2(32767) :=
list_types.big_strings_tt; ten_minute_lookup (...);
BEGIN big_list
IF <condition> list_types.big_strings_tt;
THEN BEGIN
use_big_string (big_string); use_big_string (big_string);
Process_big_list (big_list); Process_big_list (big_list);
ELSE END;
/* Nothing big ELSE
going on here */ /* Nothing big
... going on here */
END IF; ...
END; END IF;
defer.sql END;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 227
 Cache Data with Packages
ƒ General principle: if you need to access the same data and it
doesn't change, cache it in the most accessible location to
maximize lookup performance
ƒ Packages offer an ideal caching mechanism
– Any data structure defined at the package level (whether in
specification or body) serves as a persistent, global structure
– Remember: separate copy for each connection to Oracle
ƒ Let's explore further:
– Define, protect and access package data
– Use the initialization section

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 228
 Define, Access and Protect Pkg Data
ƒ Great example: the USER function
– The value returned by USER never changes in a session
– Each call to USER is in reality a SELECT FROM dual
– So why do it more than once?
CREATE OR REPLACE PACKAGE thisuser
IS
Hide package data!
FUNCTION name RETURN VARCHAR2; If exposed, you cannot
END;
guarantee integrity of data.
CREATE OR REPLACE PACKAGE BODY thisuser Build "get and set"
IS
/* Persistent "global" variable */ programs around it.
g_user VARCHAR2(30) := USER;

FUNCTION name RETURN VARCHAR2 IS

thisuser.pkg
BEGIN thisuser.tst
RETURN g_user;
END;
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 229
 Optimize Lookups with a Local Cache
ƒ Common application requirement: look up name or description
for foreign key in a table
– Common, but expensive operation in a client-server environment
ƒ Wouldn't it be nice to be able to have the application remember
that it just queried that value?
– In many cases, the value hasn't changed (how many "code" tables do
you have?)
ƒ While Oracle does optimize performance of repetitive access,
you still pay the price for going through the SQL layer
– Perhaps we can take advantage of a local cache (per user) to speed up
performance

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 230
 Data Caching with PL/SQL Tables
Data retrieved
First access Pass Data from cache Data returned
to Cache to application

Database Application
Function
Not in cache; PGA
Request data Application
from database Requests Data

Subsequent accesses Data retrieved Data returned

from cache to application

Data found in
cache. Database Application
Database is not needed.
Function
PGA
Application
Requests Data

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 231
 Code for a Caching Function
PACKAGE te_company Specification
IS
FUNCTION name$val (id_in IN company.company_id%TYPE)
RETURN company.name%TYPE;
END te_company;

ƒ You must place the retrieval function inside a package

– The package body provides persistence for PL/SQL table
– Note that the specification gives no indication of the technique used to
return the company name
PACKAGE BODY te_company Body...
IS
TYPE names_tabtype IS
TABLE OF company.name%TYPE INDEX BY BINARY_INTEGER;
names names_tabtype;

…continued on next slide

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 232
 Body of Self-Optimizing Function
FUNCTION name$val (id_in IN company.company_id%TYPE)
RETURN company.name%TYPE
IS
CURSOR comp_cur IS
SELECT name FROM company where company_id = id_in;
retval company.name%TYPE;
BEGIN
IF names.EXISTS (id_in) If the row is cached,
THEN retrieve from cache.
retval := names (id_in);
ELSE
OPEN comp_cur; FETCH comp_cur INTO retval;
CLOSE comp_cur;
If not in cache, use
IF retval IS NOT NULL standard database
THEN retrieval.
names (id_in) := retval;
END IF;
END IF;
RETURN retval; emplu.pkg
END name$val; If a match was found emplu.tst
END te_company; store it in the
cache for next time.
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 233
 Another Tool, To Be Applied
Selectively
ƒ Local caching isn't always appropriate
– The data should be static. If the table from which you cached data
changes, it is very difficult to update the cache
– Either for small tables or for large tables with "hot spots"

ƒ You can produce variations on this theme:

– Pre-load the entire table into memory. Might be handy for small tables
– Add a flag to your function to allow either database retrieval or cached
retrieval, modifiable at run-time
– Create a "system-wide" cache that is accessible to all sessions. This
can be done using database pipes and is explored in the Oracle Built-
in Packages seminar
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 234
 Leverage Oracle Hashing
ƒ Hashing algorithms transform strings to numbers
– Standard usage: generate unique values for distinct strings
FUNCTION DBMS_UTILITY.GET_HASH_VALUE
(name IN VARCHAR2,
base IN NUMBER,
hash_size IN NUMBER)
RETURN NUMBER;

ƒ Provide the string, the base or starting point, and the hash size (total
number of possible return values).
ƒ Tips for hashing:
– You must use the same base and hash size to obtain consistent hash
values
– Maximum hash size: upper limit of BINARY_INTEGER: 2**31-1
– No guarantee that two different strings will not hash to the same
number. Check for and resolve conflicts
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 235
 A Hash Encapsulator
ƒ Hide base and hash table values to ensure consistency
CREATE OR REPLACE PACKAGE hash
IS
FUNCTION val (str IN VARCHAR2) RETURN NUMBER;
END hash;
/
CREATE OR REPLACE PACKAGE BODY hash
IS
maxRange CONSTANT BINARY_INTEGER := POWER (2, 31) - 1;
strt CONSTANT BINARY_INTEGER := 2;

FUNCTION val (str IN VARCHAR2) RETURN NUMBER IS

retval NUMBER := 0;
BEGIN
RETURN
DBMS_UTILITY.GET_HASH_VALUE (str, strt, maxRange);
END val;
END hash;
/

hash.pkg
hashcomp.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 236
 Hashing for an Alternative Index
ƒ Index-by tables support only one index: the row number
– So to locate the row in which a particular string is located, you have
to do a "full table scan" -- or do you?
ƒ Use the hash function to build an alternative index to the
contents of the PL/SQL table
Hash Name to
Produce Alt Index Row # Alternate Index Collection
Cached Data Collection

Row # Full Set of Employee Data Row # Employee ID and Name

1055 SMITH, 12-JAN-99, ... 78955 1055 SMITH

3458 FELLON, 10-MAR-82, ... 203055 3458 FELLON
7988 DIONA, 22-JUL-90, ... 1109878 7988 DIONA

Row # is Complete the round trip to find the row for a name
employee ID
number. altind*.pkg
altind.tst
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 237
 Quiz! slowds*.sql

ƒ How can we
CREATE OR REPLACE PROCEDURE fix_me (
nmfilter IN VARCHAR2, comm_list IN OUT comm_pkg.reward_tt
)

tune up this IS
v_nmfilter VARCHAR2(2000) NOT NULL := nmfilter;

program?
v_info VARCHAR2(2000);
v_nth INTEGER;
v_sal NUMBER;

ƒ Remember: You
indx INTEGER
BEGIN
FOR indx IN comm_list.FIRST .. comm_list.LAST
will not usually LOOP
v_nth := v_nth + 1;

find big gains in

v_info :=
'Doubled ' || v_nth || 'th salary on ' ||
SYSDATE || ' to ' || comm_list(indx).sal * 2;
data structure IF UPPER (comm_list(indx).nm) LIKE

tuning, but the THEN

UPPER (v_nmfilter)

UPDATE employee
cumulative effect SET salary := comm_list(indx).sal * 2.0,
info := v_info,

can be commission := comm_list.comm

WHERE last_name = UPPER (comm_list(indx).nm);

impressive.
comm_list(indx).comm := 0;
END IF;
END LOOP;
END;
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 238
 PL/SQL Tuning and Best
Practices

Manage Code in the Database

and SGA

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 239
 Manage Code in the
Database/SGA
ƒ PL/SQL code is stored in the Oracle data dictionary
and executed from the SGA's shared pool area
– It is imperative that you understand the PL/SQL
architecture and then tune access to your code
ƒ PL/SQL Architecture in Shared Memory
ƒ Analyze Code Usage & Dependencies
ƒ Manage Memory Allocation and Usage

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 240
 Analyze Code Usage &
Dependencies

ƒ How big is my code?

ƒ What does my code need in order to run?
ƒ What is cached in the SGA?
ƒ The V$DB_OBJECT_CACHE view
ƒ The V$SQLAREA view

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 241
 How Big is My Code?
ƒ Oracle offers the *_OBJECT_SIZE views to give you information
about the size of your code. There are three different entries of
interest:
– Source size: the source code, used to recompile the program
– Parsed size: Code required to compile other programs that reference this
one. If you "keep" a program unit, this code is also loaded into the SGA
– Code size: partially-compiled code that is loaded into the SGA
ƒ Use the view to identify large programs and compare sizes of
different implementations
ƒ Large program units are generally good candidates for pinning into
the SGA (covered later)
pssize.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 242
 What Does My Code
Need to Run?
ƒ If program A calls program B, then both A and B need to be
present in the SGA for A to execute
ƒ Oracle maintains dependency information in a variety of
views (*_DEPENDENCIES and PUBLIC_DEPENDENCY)
ƒ Analyze complete memory requirements!
– Combine dependency information with USER_OBJECT_SIZE to
get a more complete picture
– Or take snapshots (before and after) of what is in the SGA (more
on this later)
ƒ Watch out! Accessing these DD views can be very time-
consuming (to learn and to execute). analyzedep.ins
analyzedep.sql
analyzedep.tst
utldtree.sql

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 243
 What is Cached in the SGA?
ƒ The best way to understand the requirements and activity of
the PL/SQL code in the SGA is to look at the SGA
ƒ Oracle offers a variety of data structures to get this
information:
– V$ROWCACHE: check for data dictionary cache hits/misses
– V$LIBRARYCACHE: check for object access hits/misses
– V$SQLAREA: statistics on shared SQL area, one row per SQL
string (cursor or PL/SQL block)
– V$DB_OBJECT_CACHE: displays info on database objects that
are cached in the library cache
ƒ And much more. We will just scratch the surface and pull out
those items most useful for PL/SQL tuning
grantv$.sql
insga.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 244
 Library Cache views
Shared Pool

Library Cache V$DB_OBJECT_CACHE

Cursor cache V$SQLAREA DB PIPES

SELECT BEGIN PLSQL PKG SPEC

-- plsql
INSERT END;
PLSQL PKG BODY
UPDATE DELETE
JAVA class

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 245
 The V$DB_OBJECT_CACHE View
ƒ The V$DB_OBJECT_CACHE view gives you this
information:
– LOADS: number of times element has been loaded to the SGA
– EXECUTIONS: number of times element has been executed. This
is not aggregated for the program name. Only for the code block.
– KEPT: YES if the element has been pinned
– TYPE: NOT LOADED if the element has been referenced but not
loaded
ƒ Excessive numbers of loads and/or high execution counts
indicate the need for adjusting the shared pool size and/or
pinning that program unit

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 246
 The V$SQLAREA View

ƒ This view gives you lots of information about the contents of

the shared pool and parsed SQL statements
ƒ Is a subset of V$DB_OBJECT_CACHE and does not have
separate aggregate entries for individual program units
ƒ You can analyze statements for memory and disk usage,
repetitive SQL, and so on
SQL> exec insga.show_similar
*** Possible Statement Redundancy:
begin fix_me (1); end;
begin fix_me(1); end;
*** Possible Statement Redundancy:
select * from EMP
select * from emp

insga.pkg
similar.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 247
 Tune Memory Allocation
and Usage
ƒ Set the SGA shared pool size
ƒ Manage session memory with DBMS_SESSION
ƒ Use the SERIALLY_REUSABLE Pragma
ƒ Minimize program inter-dependencies

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 248
 Size the Shared Pool
ƒ The shared pool must be large enough to cache your code
without excessive (or any) swapping
– Oracle uses the least-recently-used algorithm to make room for code
that needs to be executed
– Tune size of shared pool through analysis of contents of shared pool
when application is up and running
ƒ INIT.ORA parameters of interest:
– SHARED_POOL_SIZE: size in bytes of shared pool area
– SHARED_POOL_RESERVED_SIZE: size in bytes of portion of shared
pool area reserved for requests larger than
SHARED_POOL_MIN_ALLOCATION when the shared pool does not
have enough contiguous blocks for request.
SQL> exec insga.show_hitratio
ROW CACHE Hit ratio = 93.81%
Ratio is below 95%. Consider raising the SHARED_POOL_SIZE init.ora
parameter.
LIBRARY CACHE Hit
9/16/2006 ratio
Copyright = 99.61%
2001 Steven Feuerstein, PL/SQL Best Practices - page 249
 Manage Session Memory
ƒ DBMS_SESSION.RESET_PACKAGE
– Reinitializes all package states, your own and even the built-in
packages like DBMS_OUTPUT
– Never use in stored PL/SQL (embedded within an application);
package states will not be re-instantiated until outer-most PL/SQL
block within which RESET_PACKAGE was called completes
– RESET_PACKAGE does not release memory associated with cleared
package variables (see next program)
ƒ DBMS_SESSION.FREE_UNUSED_USER_MEMORY
– Returns memory back to OS or shared pool
– Call after compilation of large objects, when large PL/SQL tables are
no longer needed, or after large sort operations
ƒ Recommendation: clear out memory before you start a profiling
session to "make all things equal" reset.sql
resetmem.sql
mysess.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 250
 Freeing Unused User Memory
(FUUM)

One local table,

Two local
one "global"
tables
table

After procedure
execution and
FUUM, no
memory
allocated.

After procedure execution and FUUM, global

memory still allocated.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 251
 Pin Code in the SGA
ƒ "Pin" your code (including triggers and types) into shared
memory, and exempt it from the LRU algorithm
– When you pin using, your code remains in the SGA until the instance is
shutdown
ƒ Pinning is usually performed right after database startup. Prior to
Oracle 7.3, two separate steps were required
– 1. Register that program, package or cursor to be pinned by calling the
DBMS_SHARED_POOL.KEEP procedure
– 2. Reference the code element so that it will be loaded into memory.
– This second step is now performed with the call to KEEP
ƒ The DBMS_SHARED_POOL is not automatically
installed/available in all versions. See pool.ins.
pool.ins
plvpin.sp
keeper.sql
showkeep.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 252
 Use the SERIALLY_REUSABLE Pragma

ƒ By default, package-level data structures persist for the entire

session and are stored in the user memory area
– Problematic memory consumption with large numbers of users
ƒ Oracle8 offers a new pragma to instruct the runtime engine to
release memory after each package instruction
– And shift allocation of memory to the SGA, not PGA/UGA
ƒ Especially handy: serial.sql

– For closing package-level cursors automatically

– Releasing memory used for collections and large VARCHAR2s
CREATE OR REPLACE PACKAGE one_use_pkg
IS Designate in both
PRAGMA SERIALLY_REUSABLE; specification and
body.
CURSOR must_close_cur IS SELECT ...;
big_collection lotsa_strings_tabtype;
END one_use_pkg; 9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 253
 Minimize Inter-Program
Dependencies
ƒ As you write more and more PL/SQL code and seek to re-use
that code, you need to be careful about:
– The dependencies you establish between programs and packages
– What programs you put into which packages
ƒ You may sometimes need to re-architect packages as they
evolve over time
– It is important to keep intact the legacy specification Proc 2

Proc 1 Proc 2
Proc 1
Old

New
analyzedep.*
utldtree.sql
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 254
PL/SQL Tuning & Best Practices

Creating Readable &

Maintainable Code

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 255
Writing Code You Can Be Proud Of

ƒ And code you -- as well as others -- can maintain

with an absolute minimum of headaches
– Use the full range of constructs in the language
– Achieve a consistent, readable coding style
– Choose names carefully for program elements
– Document to add value
– Keep the execution section tight, and its meaning and purpose
transparent

Tips for organizing source code in files

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 256
 Use Everything the Language Offers
ƒ PL/SQL is based on Ada, and is a highly structured and
robust language. Use it, all of it! Some examples...
If a variable's value doesn't change, declare a constant.
This both protects the value and also documents for
others that it should not be changed.
Use labels for anonymous blocks and loops.
They're not just or GOTOs.
c_max_date CONSTANT DATE DEFAULT SYSDATE;

<<every_month>>
FOR month_ind IN 1 .. 12
LOOP
every_month.month_ind ...
END LOOP every_month;

Use the native BOOLEAN datatype

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 257
 The Boolean: A True Pleasure
ƒ The database doesn't support Boolean columns, but that's
no excuse to avoid PL/SQL's datatype
– A Boolean can have one of three values: TRUE, FALSE and NULL

IS
valid_company CHAR(1);
Nasty!
BEGIN
You don't have to use Y IF valid_company = 'Y'
or N, T or F, etc. to
represent these actual
values. IS Better...
valid_company BOOLEAN;
BEGIN
IF valid_company = TRUE

IS
valid_company BOOLEAN; Best.
BEGIN
IF valid_company

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 258
 Achieving a Consistent Coding Style

ƒ Programs are more readable and easier to maintain when a

consistent and effective coding style is applied
– Each developer should have a consistent style. Best of all? An entire
team shares a common style
ƒ There are two ways to achieve this objective:
– Make sure everyone writes code the same way
– Use a utility to format the code after or while it is written
ƒ Chapter 3 of Oracle PL/SQL Programming offers 34 pages on
the Feuerstein idea of style
ƒ PL/Formatter from RevealNet is the first commercial "pretty
printer" for PL/SQL code
– Check for others as well!
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 259
 Hard-to-Read SQL Statement
SELECT company_id, sales,
address1, company_type_ds description, min_balance
FROM
company A, sales_amount B, company_type C, company_config D,
region E, regional_status F
WHERE
A.company_id = B.company_id and
A.company_type_cd = C.company_type_cd
and C.company_type_cd = D.company_type_cd and A.region_cd =
E.region_cd and E.status = F.status;

ƒ No, none of us ever write anything like this, right?

ƒ The ABCs of table aliases are particularly informative: we
have consistency, but we don't have added value
– Rules for rules' sake are not necessarily an improvement
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 260
 A Non-Procedural Format for
SQL
Logical "middle" of
SQL statement
Application-
SELECT COM.company_id, specific
sales, elements
left-
address1,
justified
company_type_ds description,
min_balance

FROM company COM,

sales_amount SAL, Meaningful
Clause
Keywords
company_type TYP, table
of company_config CFG, aliases
Statement region REG,
right-justified regional_status RST

WHERE COM.company_id = SAL.company_id No vertical

AND COM.company_type_cd = TYP.company_type_cd alignment
AND TYP.company_type_cd = CFG.company_type_cd of
AND COM.region_cd = REG.region_cd elements
AND REG.status = RST.status;

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 261
 The Name is a Lot of the Game
ƒ Both the structure and content of the names you give to
program elements have a direct impact on the quality of your
code
ƒ Potential problems include:
– The name does not accurately describe what the code element does
or represents
– The same code element is represented by a bewildering array of
different names
– The structure of the name misrepresents the code; usually this occurs
when you give "procedure names" to functions
– Names of database objects, such as tables and columns, are used as
names of PL/SQL variables
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 262
 Recommendations for Naming
Elements
ƒ Use standard prefixes or Cursor company_cur
suffixes for code elements Record company_rec
Local variable l_ename
Most important aspect Global variable g_ename
of conventions: Constant c_lastdate
PL/SQL Table Type dates_tabtype
Consistent application!
PL/SQL Table dates_tab

ƒ The syntax of program names

is critical PROCEDURE calculate_totals
– Verb-noun for
procedures FUNCTION is_valid_type (...)
– Preposition for Boolean RETURN BOOLEAN

functions FUNCTION total_sales RETURN NUMBER

– Noun for other functions
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 263
 Comment to Add Value
ƒ Provide documentation in the following areas:
– Standard program header: who, what, when, why
– Modification histories
– Explanations of a workaround, patches, etc.
– A "translation" of a complex or dense section of code
• As we shall see, though, a better solution than a comment is to make
the code less complex and dense
ƒ Avoid fancy comment "boxes" and right margins
– Don't waste time maintaining the format of your comments
ƒ Keep comments down to an absolute minimum
– Remember: they are a form of code repetition
– Best of all is to avoid comments and allow your code to
"speak9/16/2006
for itself"
Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 264
 The Path to Righteous Code
/* If the first field of the properties record is N... */
IF properties_flag.field1 = 'N' THEN

A singularly non-informative comment

/* If the customer is not eligible for a discount... */

IF properties_flag.field1 = 'N' THEN

At least the comment adds some value now!

IF customer_flag.discount = constants.ineligible
THEN

Better names for variables, named constants got rid of the comment

IF NOT customer_rules.eligible_for_discount (customer_id)

THEN

Encapsulation with a function offers readability and easy enhancement

constants.sps
custrules.pkg
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 265
 OK, Use Some Words and Paper
ƒ Create checklists to serve as reminders before construction,
and guidelines for code review after completion
– The following items are offered simply to give you an idea of the
topics you might include

Check out
ƒ General coding guidelines Code Complete
by Steve McConnell
– All naming conventions are followed for many more
– No hard-coded values coding tips and
checklists.
– Repetitive code is modularized
– Functions always return values
– One way in, one way out: loops and programs
– Unused variables and code sections are removed
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 266
 Organizing Source Code in Files
ƒ Use standard file extensions for different kinds of source code:
pks for package specs, pkb for package bodies, etc.
ƒ Always separate the "CREATE OR REPLACE" for package
specifications and bodies into different files
– You only recompile your package specifications when needed
(minimizing the cascade of INVALID program units)
ƒ Create/compile all of your specifications before you compile
your bodies
– This defines all the headers or stubs for your application code to
compile
– You can then create packages with inter-dependencies and no
compilation problems
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 267
Creating Readable/Maintainable Code

Summary

ƒ Take Full Advantage of the Language

– And don't assume you know it all. Take time out regularly
for a little studying

ƒ Write Code You Can Be Proud Of

– From coding style to names to structure, your software is a
product of your mind. Why make a mess of it?

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 268
 You Can Write Blazing Fast
PL/SQL!
ƒ Tuning PL/SQL code is an iterative and incremental process
– You are unlikely to uncover a "silver bullet" that is not related to some
SQL statement. You can, however, have a substantial impact on the
performance of your and others' code
ƒ Write code with efficiency in mind, but save intensive tuning until
entire components are complete and you can perform
benchmarking
ƒ MOST IMPORTANT! Avoid repetition and dispersion of SQL
statements throughout your application
ƒ PL/SQL code is executed from shared memory. You must tune the
shared pool to avoid excessive swapping of code
9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 269
 Closing Comments

ƒ Write code with efficiency in mind, but save intensive tuning

until entire components are complete and you can perform
benchmarking
ƒ Concerning best practices, give yourself a fighting chance:
– Use code generators whenever possible; make it hard to not
employ best practices
– Write scripts to check source for compliance
– Share lessons learned and code built

Visit the PL/SQL Pipeline (www.revealnet.com/plsql-pipeline) to share

what you learn about tuning and best practices, and to get your
questions answered.

9/16/2006 Copyright 2001 Steven Feuerstein, PL/SQL Best Practices - page 270