13.2 Bulk dml with the forall Statement

Oracle introduced a significant enhancement to PL/SQL's DML capabilities for Oracle8i and above with the FORALL statement. FORALL tells the PL/SQL runtime engine to bulk bind into the SQL statement all of the elements of one or more collections before sending anything to the SQL engine. Why would this be useful? We all know that PL/SQL is tightly integrated with the underlying SQL engine in the Oracle database. PL/SQL is the database programming language of choice for Oracle—even though you can now (at least theoretically) use Java inside the database as well.

But this tight integration does not necessarily mean that no overhead is associated with running SQL from a PL/SQL program. When the PL/SQL runtime engine processes a block of code, it executes the procedural statements within its own engine but passes the SQL statements on to the SQL engine. The SQL layer executes the SQL statements and then returns information to the PL/SQL engine, if necessary.

This transfer of control (shown in Figure 13-1) between the PL/SQL and SQL engines is called a context switch. Each time a switch occurs, there is additional overhead. There are a number of scenarios in which many switches occur and performance degrades. In Oracle8i and above, Oracle now offers two enhancements to PL/SQL that allow you to bulk together multiple context switches into a single switch, thereby improving the performance of your applications. These enhancements are FORALL, which is explored in this chapter, and BULK COLLECT, which is explained in Chapter 14.

Figure 13-1. Context switching between pl/sql and sql

When the statement is bulk bound and passed to SQL, the SQL engine executes the statement once for each index number in the range. In other words, the same SQL statements are executed, but they are all run in the same round trip to the SQL layer, minimizing the context switches. This is shown in Figure 13-2.

Figure 13-2. One context switch with forall

13.2.1 The forall Statement

Although the FORALL statement contains an iteration scheme (i.e., it iterates through all the rows of a collection), it is not a FOR loop. Consequently, it has neither a LOOP nor an END LOOP statement. Its syntax is as follows:

FORALL index_row IN lower_bound ... upper_bound

sql_statement;

where:

index_row

Is the specified collection that the FORALL will iterate through

lower_bound

Is the starting index number (row or collection element) for the operation

upper_bound

Is the ending index number (row or collection element) for the operation

sql_statement

Is the SQL statement to be performed on each collection element

You must follow these rules when using FORALL:

• The body of the FORALL statement must be a single DML statement—an INSERT, UPDATE, or DELETE.

• The DML statement must reference collection elements, indexed by the index_row variable in the FORALL statement. The scope of the index_row variable is the FORALL statement only; you may not reference it outside of that statement. Note, though, that the upper and lower bounds of these collections do not have to span the entire contents of the collection(s).

• Do not declare a variable for index_row. It is declared implicitly as PLS_INTEGER by the PL/SQL engine.

• The lower and upper bounds must specify a valid range of consecutive index numbers for the collection(s) referenced in the SQL statement. Sparsely filled collections will raise the following error:

ORA-22160: element at index [3] does not exist

See the diffcount.sql file on O'Reilly site for an example of this scenario.

• The collection subscript referenced in the DML statement cannot be an expression. For example, the following script:

• DECLARE

• names name_varray := name_varray( );

• BEGIN

• FORALL indx IN names.FIRST .. names.LAST

• DELETE FROM emp WHERE ename = names(indx+10);

END;

will cause the following error:

PLS-00430: FORALL iteration variable INDX is not allowed in this context