Create attachments and attach them to Sales Order Header or Order Lines

Bulk Collect & For All vs Cursor & For-Loop

After more and more reads about BULK COLLECT and FORALL and their performance improvements      I decided to have a closer look on it by myself to see how powerful they really are. So I built a little test-case which inserts all entries from the all_object view into another table. The inserts happens on three different ways:
First way is a simple cursor over the view and a insert in a loop with FETCH into local variables. This way also shows how slow the opening of the cursor itself is.
The second way is a simple FOR – IN LOOP with the insert of the cursor variables.
And, of course, the third way is the way with bulking the rows and inserting them with FORALL so lets see.

So the other table looks like this (three columns are enough for this tests)

SQL> create table temp (owner varchar2(30), name varchar2(30), type varchar2(19));

Table created.

And the three diffrent procedures looks like this

CREATE OR REPLACE PROCEDURE CURSOR_FOR_OPEN_QUERY
IS
l_sOwner VARCHAR2(30);
l_sName VARCHAR2(30);
l_sType VARCHAR2(19);
CURSOR cur IS SELECT owner, object_name name, object_type type FROM all_objects;
BEGIN
dbms_output.put_line(‘Before CURSOR OPEN: ‘ || systimestamp);
OPEN cur;
dbms_output.put_line(‘Before LOOP: ‘ || systimestamp);
LOOP
FETCH cur INTO l_sOwner, l_sName, l_sType;
IF cur%NOTFOUND THEN
EXIT;
END IF;
INSERT INTO temp values (l_sOwner, l_sName, l_sType);
END LOOP;
CLOSE cur;
dbms_output.put_line(‘After CURSOR CLOSE: ‘ || systimestamp);
COMMIT;
END;
/

CREATE OR REPLACE PROCEDURE CURSOR_FOR_QUERY
IS
BEGIN
dbms_output.put_line(‘Before CURSOR: ‘ || systimestamp);
FOR cur IN (SELECT owner, object_name name, object_type type FROM all_objects) LOOP
INSERT INTO temp values (cur.owner, cur.name, cur.type);
END LOOP;
dbms_output.put_line(‘After CURSOR: ‘ || systimestamp);
COMMIT;
END;
/

CREATE OR REPLACE PROCEDURE BULK_COLLECT_QUERY
IS
TYPE sOwner IS TABLE OF VARCHAR2(30);
TYPE sName IS TABLE OF VARCHAR2(30);
TYPE sType IS TABLE OF VARCHAR2(19);
l_sOwner sOwner;
l_sName sName;
l_sType sType;
BEGIN
dbms_output.put_line(‘Before Bulk Collect: ‘ || systimestamp);
SELECT owner, object_name, object_type
BULK COLLECT INTO l_sOwner, l_sName, l_sType
FROM all_objects;
dbms_output.put_line(‘After Bulk Collect: ‘ || systimestamp);
–
FORALL indx IN l_sName.FIRST..l_sName.LAST
INSERT INTO temp values (l_sOwner(indx), l_sName(indx), l_sType(indx));
–
dbms_output.put_line(‘After FORALL: ‘ || systimestamp);
COMMIT;
END;
/
Ok, then I bounced the database to get no buffers, caching, etc. on it.

So the first execute

SQL> exec cursor_for_open_query
Before CURSOR OPEN: 27-SEP-07 10.56.30.699401000 AM +02:00
Before LOOP: 27-SEP-07 10.56.30.922366000 AM +02:00
After CURSOR CLOSE: 27-SEP-07 10.57.07.699791000 AM +02:00

Only look at the seconds it took 37 seconds and nearly nothing for opening the cursor! But how much rows were inserted?

SQL> select count(*) from temp;

COUNT(*)
———-
49424

Truncate the table (truncate to free the extends!) and bounce the database again and now the second run

SQL> exec cursor_for_query
Before CURSOR: 27-SEP-07 10.59.47.848249000 AM +02:00
After CURSOR: 27-SEP-07 11.00.09.072525000 AM +02:00

The whole loop took 22 seconds, well this looks already better. Well, also all rows inserted?

SQL> select count(*) from temp;

COUNT(*)
———-
49424

But now (after truncate and bouncing) the bulk collect run

SQL> exec bulk_collect_query
Before Bulk Collect: 27-SEP-07 11.01.33.553224000 AM +02:00
After Bulk Collect: 27-SEP-07 11.01.41.874054000 AM +02:00
After FORALL: 27-SEP-07 11.01.42.065753000 AM +02:00

Look at this, for bulking all the lines into the collection took just 8 seconds (for 49 424 rows) and the inserts just 1 second! Unbelievable, together we did everything in 9 seconds where the other ways took over 20 seconds!

Well now lets try to first execute the bulk load then truncate the table again but not bouncing the database so that the buffers and caches a still filled

SQL> exec bulk_collect_query
Before Bulk Collect: 27-SEP-07 11.02.31.257498000 AM +02:00
After Bulk Collect: 27-SEP-07 11.02.41.614205000 AM +02:00
After FORALL: 27-SEP-07 11.02.41.818092000 AM +02:00

PL/SQL procedure successfully completed.

SQL> select count(*) from temp;

COUNT(*)
———-
49423

SQL> truncate table temp;

Table truncated.

SQL> exec cursor_for_query
Before CURSOR: 27-SEP-07 11.04.04.960254000 AM +02:00
After CURSOR: 27-SEP-07 11.04.25.749038000 AM +02:00

Ok so now we need 10 seconds for the run with the bulk but we sill need 21 seconds for the cursor! So not really a improvement with the cache and so on. Ok final test on a big system with over 268 thousand rows

Before Bulk Collect: 27-SEP-07 11.24.17.034732000 AM +02:00
After Bulk Collect: 27-SEP-07 11.24.25.111020000 AM +02:00
After FORALL: 27-SEP-07 11.24.26.129826000 AM +02:00
PL/SQL procedure successfully completed.

COUNT(*)
———-
267985

Table truncated.

Before CURSOR: 27-SEP-07 11.24.29.629354000 AM +02:00
After CURSOR: 27-SEP-07 11.25.02.244549000 AM +02:00
PL/SQL procedure successfully completed.

COUNT(*)
———-
268056
And again, bulking took 8 seconds and the inserts just 1 second! But the run with the cursor took 33 seconds!

So this was just a short test but it definitely shows that BULK COLLECT and FORALL are much faster than cursors within the FOR loop! Only disadvantage of FORALL as you maybe already guess if you looked at the code: You can just perform one DML statement, there is no “FORALL END” clause! But anyway also bulking is a very high-performance functionality of Oracle! So if you have to run throw data collections then use BULK COLLECT!

-- Venzi

http://venzi.wordpress.com/2007/09/27/bulk-collect-forall-vs-cursor-for-loop/