Oracle PL/SQL Practices

Critical elements of PL/SQL Best Practices Build your development toolbox Unit test PL/SQL programs Optimize SQL in PL/SQL programs Manage errors effectively and consistently Write readable, maintainable code

High Level, High Impact Important principles... Assume everything will change. Aim for a single point of definition (a SPOD). Top four tips.... Drink lots of water. Write tiny chunks of code. Stop writing so much SQL. Stop guessing and start testing.

Let's read some code! Move blocks of complex code into the declaration section Replace them with descriptive names The code is now easier to read and maintain You can more easily identify areas for improvement

Anchor Declarations of Variables

Always Fetch into Cursor Records

Input Parameters

Select-in multi-columns

Update-set multi-columns

Avoid SQL-PL/SQL Naming Conflicts

Row Count

Performance Discussion

dynamic sql without bind variable DECLARE cur SYS_REFCURSOR; tmp crm_partner%ROWTYPE; BEGIN FOR j IN LOOP OPEN cur FOR 'SELECT * FROM crm_partner p WHERE rownum <= '|| j; LOOP FETCH cur INTO tmp; EXIT WHEN cur%NOTFOUND; NULL; END LOOP; CLOSE cur; END LOOP; END; / PL/SQL procedure successfully completed Executed in seconds

dynamic sql with bind variable DECLARE cur SYS_REFCURSOR; tmp crm_partner%ROWTYPE; BEGIN FOR j IN LOOP OPEN cur FOR 'SELECT * FROM crm_partner p WHERE rownum <= :i' USING j; LOOP FETCH cur INTO tmp; EXIT WHEN cur%NOTFOUND; NULL; END LOOP; CLOSE cur; END LOOP; END; / PL/SQL procedure successfully completed Executed in seconds

dynamic sql fetch all one time DECLARE cur SYS_REFCURSOR; TYPE type_tab IS TABLE OF crm_partner%ROWTYPE; tmp type_tab; BEGIN FOR j IN LOOP OPEN cur FOR 'SELECT * FROM crm_partner p WHERE rownum <= :i' USING j; FETCH cur BULK COLLECT INTO tmp; FOR i IN 1.. tmp.count LOOP NULL; END LOOP; CLOSE cur; END LOOP; END; / PL/SQL procedure successfully completed Executed in seconds

static cursor DECLARE CURSOR get_data(p_row_no IN NUMBER) IS SELECT * FROM crm_partner p WHERE rownum <= p_row_no; BEGIN FOR j IN LOOP FOR i IN get_data(j)LOOP NULL; END LOOP; END; / PL/SQL procedure successfully completed Executed in 0.39 seconds

static cursor fetch all one time DECLARE CURSOR cur(p_row_no IN NUMBER) IS SELECT * FROM crm_partner p WHERE rownum <= p_row_no; TYPE type_tab IS TABLE OF crm_partner%ROWTYPE; tmp type_tab; BEGIN FOR j IN LOOP OPEN cur(j); FETCH cur BULK COLLECT INTO tmp; FOR i IN 1.. tmp.count LOOP NULL; END LOOP; CLOSE cur; END LOOP; END; / PL/SQL procedure successfully completed Executed in seconds

dml single insert/select or bulk collect/forall You should do it in a single SQL statement if at all possible. If you cannot do it in a single SQL Statement, then do it in PL/SQL. If you cannot do it in PL/SQL, try a Java Stored Procedure. If you cannot do it in Java, do it in a C external procedure. If you cannot do it in a C external routine, you might want to seriously

Bulk collect-For-Insert ops$tkyte%ORA11GR2> declare 2 type array is table of t1%rowtype index by binary_integer; 3 cursor test_curs is select * from t1; 4 l_data array; 5 begin 6 open test_curs; 7 loop 8 fetch test_curs bulk collect into l_data limit 2000; 9 for i in 1..l_data.COUNT 10 LOOP 11 insert into t2 values l_data(i); 12 END loop; 13 exit when test_curs%notfound; 14 END LOOP; 15 close test_curs; 16 end; 17 / PL/SQL procedure successfully completed.

Bulk collect-Forall-Insert ops$tkyte%ORA11GR2> declare 2 type array is table of t1%rowtype index by binary_integer; 3 cursor test_curs is select * from t1; 4 l_data array; 5 begin 6 open test_curs; 7 loop 8 fetch test_curs bulk collect into l_data limit 2000; 9 forall i in 1..l_data.COUNT 10 insert into t3 values l_data(i); 11 exit when test_curs%notfound; 12 END LOOP; 13 close test_curs; 14 end; 15 /

Insert-into-from insert into t4 select * from t1;

Switching between PL/SQL and SQL engines

Conventional Bind

Bulk Bind

Direct path inserts NOTE: a) it isn't necessarily faster in general. It does a direct path load to disk - bypassing the buffer cache. There are many cases - especially with smaller sets - where the direct path load to disk would be far slower than a conventional path load into the cache. b) a direct path load always loads above the high water mark, since it is formatting and writing blocks directly to disk - it cannot reuse any existing space. Think about this - if you direct pathed an insert of a 100 byte row that loaded say just two rows - and you did that 1,000 times, you would be using at least 1,000 blocks (never reuse any existing space) - each with two rows. Now, if you did that using a conventional path insert - you would get about 70/80 rows per block in an 8k block database. You would use about 15 blocks. Which would you prefer? c) you cannot query a table after direct pathing into it until you commit. (current session) d) how many people can direct path into a table at the same time? One - one and only one. It would cause all modifications to serialize. No one else could insert/update/delete or merge into this table until the transaction that direct paths commits. insert /*+ APPEND*/ into t4 select * from t1; Direct path inserts should be used with care, in the proper circumstances. A large load - direct path, but most of the time - conventional path.

direct path vs. conventional path

Thanks! Questions & Answers Shawn Huang （黄其晟） Data Architect Desk: Mobile: