PL/SQL New Features and Enhancements in Oracle Database 11g Release 1

Oracle 11g includes a substantial number of PL/SQL new features and enhancements. In order to prevent this article becoming too large some of these features have been split off into separate articles, but the following sections represent an explanation of the all the new features listed in the What's New in PL/SQL? section of the PL/SQL Language Reference manual. Topics covered in this article:

Enhancements to Regular Expression Built-in SQL Functions SIMPLE_INTEGER Datatype CONTINUE Statement Sequences in PL/SQL Expressions Dynamic SQL Enhancements Generalized Invocation Named and Mixed Notation in PL/SQL Subprogram Invocations Automatic Subprogram Inlining PL/Scope PL/SQL Native Compiler Generates Native Code Directly New PL/SQL Compiler Warning PLS-00436 Restriction in FORALL Statements Removed

Topics covered in separate articles on this site:

Cross-Session PL/SQL Function Result Cache Trigger Enhancements in Oracle Database 11g Release 1 PL/SQL Hierarchical Profiler Native Oracle XML DB Web Services Database Resident Connection Pool

Enhancements to Regular Expression Built-in SQL Functions

The REGEXP_INSTR and REGEXP_SUBSTR functions include a new SUBEXPR parameter that limits the pattern match to a specific subexpression in the search pattern.
SQL> SELECT REGEXP_INSTR('1234567890', '(123)(4(56)(78))', 1, 1, 0, 'i', 1) FROM dual; REGEXP_INSTR('1234567890','(123)(4(56)(78))',1,1,0,'I',1) --------------------------------------------------------1 1 row selected.

SQL> SELECT REGEXP_INSTR('1234567890', '(123)(4(56)(78))', 1, 1, 0, 'i', 3) FROM dual; REGEXP_INSTR('1234567890','(123)(4(56)(78))',1,1,0,'I',3) --------------------------------------------------------5 1 row selected. SQL> SELECT REGEXP_SUBSTR('1234567890', '(123)(4(56)(78))', 1, 1, 'i', 0) FROM dual; REGEXP_S -------12345678 1 row selected. SQL> SELECT REGEXP_SUBSTR('1234567890', '(123)(4(56)(78))', 1, 1, 'i', 1) FROM dual; REG --123 1 row selected. SQL> SELECT REGEXP_SUBSTR('1234567890', '(123)(4(56)(78))', 1, 1, 'i', 3) FROM dual; RE -56 1 row selected. SQL>

The new REGEXP_COUNT function returns the number of times the search pattern appears in source string.
SQL> SELECT REGEXP_COUNT('123 123 123 123', '123', 1, 'i') FROM dual; REGEXP_COUNT('123123123123','123',1,'I') ---------------------------------------4 1 row selected. SQL> SELECT REGEXP_COUNT('123 123 123 123', '123', 9, 'i') FROM dual; REGEXP_COUNT('123123123123','123',9,'I') ---------------------------------------2 1 row selected. SQL>

SIMPLE_INTEGER Datatype
The SIMPLE_INTEGER datatype is a subtype of the PLS_INTEGER datatype and can dramatically increase the speed of integer arithmetic in natively compiled code, but only shows marginal performance improvements in interpreted code. The following procedure compares the performance of the SIMPLE_INTEGER and PLS_INTEGER datatypes.
CREATE OR REPLACE PROCEDURE simple_integer_test_proc AS l_start NUMBER; l_loops NUMBER := 10000000; l_pls_integer PLS_INTEGER := 0; l_pls_integer_incr PLS_INTEGER := 1; l_simple_integer SIMPLE_INTEGER := 0; l_simple_integer_incr SIMPLE_INTEGER := 1; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP l_pls_integer := l_pls_integer + l_pls_integer_incr; END LOOP; DBMS_OUTPUT.put_line('PLS_INTEGER: ' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP l_simple_integer := l_simple_integer + l_simple_integer_incr; END LOOP; DBMS_OUTPUT.put_line('SIMPLE_INTEGER: ' || (DBMS_UTILITY.get_time l_start) || ' hsecs'); END simple_integer_test_proc; /

When run in the default interpreted mode the performance improvement of the SIMPLE_INTEGER datatype is not spectacular.
SQL> SET SERVEROUTPUT ON SQL> EXEC simple_integer_test_proc; PLS_INTEGER: 47 hsecs SIMPLE_INTEGER: 44 hsecs PL/SQL procedure successfully completed. SQL>

We natively compile the procedure by altering the PLSQL_CODE_TYPE value for the session and recompiling the procedure.
ALTER SESSION SET PLSQL_CODE_TYPE=NATIVE; ALTER PROCEDURE simple_integer_test_proc COMPILE;

Natively compiling the procedure produces dramatic speed improvements for both datatypes, but more so for the SIMPLE_INTEGER datatype.
SQL> SET SERVEROUTPUT ON

SQL> EXEC simple_integer_test_proc; PLS_INTEGER: 10 hsecs SIMPLE_INTEGER: 2 hsecs PL/SQL procedure successfully completed. SQL>

The speed improvements are a result of two fundamental differences between the two datatypes. First, SIMPLE_INTEGER and PLS_INTEGER have the same range (-2,147,483,648 through 2,147,483,647), but SIMPLE_INTEGER wraps round when it exceeds its bounds, rather than throwing an error like PLS_INTEGER.
SET SERVEROUTPUT ON DECLARE l_simple_integer SIMPLE_INTEGER := 2147483645; BEGIN FOR i IN 1 .. 4 LOOP l_simple_integer := l_simple_integer + 1; DBMS_OUTPUT.PUT_LINE(TO_CHAR(l_simple_integer, 'S9999999999')); END LOOP; FOR i IN 1 .. 4 LOOP l_simple_integer := l_simple_integer - 1; DBMS_OUTPUT.PUT_LINE(TO_CHAR(l_simple_integer, 'S9999999999')); END LOOP; END; / +2147483646 +2147483647 -2147483648 -2147483647 -2147483648 +2147483647 +2147483646 +2147483645 PL/SQL procedure successfully completed. SQL>

Second, SIMPLE_INTEGER can never have a NULL value, either when it is declared, or by assignment.
DECLARE l_simple_integer SIMPLE_INTEGER; BEGIN NULL; END; / * ERROR at line 2: ORA-06550: line 2, column 20: PLS-00218: a variable declared NOT NULL must have an initialization assignment SQL> DECLARE

l_simple_integer SIMPLE_INTEGER := 0; BEGIN l_simple_integer := NULL; END; / * ERROR at line 4: ORA-06550: line 4, column 23: PLS-00382: expression is of wrong type ORA-06550: line 4, column 3: PL/SQL: Statement ignored SQL>

The removal of overflow and NULL checking result in a significant reduction in overhead compared to PLS_INTEGER.

CONTINUE Statement
The CONTINUE statement jumps out of the current loop interation and starts the next one. It can be used on its own, or as part of a CONTINUE WHEN statement, as shown below.
SET SERVEROUTPUT ON DECLARE l_number NUMBER := 0; BEGIN FOR i IN 1 .. 100 LOOP CONTINUE WHEN MOD(i,2) = 0; -- Do something here! l_number := l_number + 1; END LOOP; DBMS_OUTPUT.put_line('CONTINUE WHEN : ' || l_number); l_number := 0; FOR i IN 1 .. 100 LOOP IF MOD(i,2) = 0 THEN CONTINUE; END IF; -- Do something here! l_number := l_number + 1; END LOOP; DBMS_OUTPUT.put_line('IF .. CONTINUE: ' || l_number); END; / CONTINUE WHEN : 50 IF .. CONTINUE: 50 PL/SQL procedure successfully completed. SQL>

This type of processing has always been possible using IF statements either on their own or with exceptions or GOTO statements, but the CONTINUE statement is neater and brings PL/SQL in line with other langauges. The following examples show the type of code necessary to perform the same task before the CONTINUE statement was added to PL/SQL.
SET SERVEROUTPUT ON DECLARE ex_continue EXCEPTION; l_number NUMBER := 0; BEGIN FOR i IN 1 .. 100 LOOP BEGIN IF MOD(i,2) != 0 THEN RAISE ex_continue; END IF; -- Do something here! l_number := l_number + 1; EXCEPTION WHEN ex_continue THEN NULL; END; END LOOP; DBMS_OUTPUT.put_line('EXCEPTION: ' || l_number); l_number := 0; FOR i IN 1 .. 100 LOOP IF MOD(i,2) != 0 THEN -- Do something here! l_number := l_number + 1; END IF; END LOOP; DBMS_OUTPUT.put_line('IF l_number := 0; FOR i IN 1 .. 100 LOOP IF MOD(i,2) = 0 THEN GOTO label_continue; END IF; -- Do something here! l_number := l_number + 1; << label_continue >> NULL; END LOOP; DBMS_OUTPUT.put_line('GOTO END; / EXCEPTION: 50 : ' || l_number); : ' || l_number);

IF GOTO

: 50 : 50

PL/SQL procedure successfully completed. SQL>

Sequences in PL/SQL Expressions

The NEXTVAL and CURRVAL sequence pseudocolumns can now be accessed in PL/SQL expressions as well as queries. This makes the code look simpler, and the documentation suggests it improves performance. The following example compares the speed of the original and new methods of accessing these sequence values.
CREATE SEQUENCE test1_seq START WITH 1000000; SET SERVEROUTPUT ON DECLARE l_start NUMBER; l_loops NUMBER := 100000; l_value NUMBER; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT test1_seq.NEXTVAL INTO l_value FROM dual; END LOOP; DBMS_OUTPUT.put_line('NEXTVAL SELECT=' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP l_value := test1_seq.NEXTVAL; END LOOP; DBMS_OUTPUT.put_line('NEXTVAL Expression=' || (DBMS_UTILITY.get_time l_start) || ' hsecs'); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT test1_seq.CURRVAL INTO l_value FROM dual; END LOOP; DBMS_OUTPUT.put_line('CURRVAL SELECT=' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); l_start := DBMS_UTILITY.get_time;

FOR i IN 1 .. l_loops LOOP l_value := test1_seq.CURRVAL; END LOOP; DBMS_OUTPUT.put_line('CURRVAL Expression=' || (DBMS_UTILITY.get_time l_start) || ' hsecs'); END; / NEXTVAL NEXTVAL CURRVAL CURRVAL

SELECT=2196 hsecs Expression=2203 hsecs SELECT=1007 hsecs Expression=1003 hsecs

PL/SQL procedure successfully completed. SQL>

You can see that as far as elapsed time is concerned, there is little difference between the two methods.

Dynamic SQL Enhancements

Native dynamic SQL and the DBMS_SQL package now support dynamic SQL statements larger than 32 KB. The EXECUTE IMMEDIATE statement, OPEN-FOR statement and DBMS_SQL.PARSE procedure all accept SQL statements in the form of CLOBs. The DBMS_SQL.TO_REFCURSOR function converts a DBMS_SQL cursor ID into a REF CURSOR.
SET SERVEROUTPUT ON DECLARE l_cursor NUMBER; l_return NUMBER; l_ref_cursor SYS_REFCURSOR; TYPE t_emp_tab IS TABLE OF emp%ROWTYPE; l_emp_tab t_emp_tab; BEGIN l_cursor := DBMS_SQL.open_cursor; DBMS_SQL.parse(l_cursor, 'SELECT * FROM emp', DBMS_SQL.NATIVE); l_return := DBMS_SQL.EXECUTE(l_cursor); -- Connvert from DBMS_SQL to a REF CURSOR. l_ref_cursor := DBMS_SQL.to_refcursor(l_cursor); FETCH l_ref_cursor BULK COLLECT INTO l_emp_tab; DBMS_OUTPUT.put_line('Employee Count: ' || l_emp_tab.count); CLOSE l_ref_cursor; END;

/ Employee Count: 14 PL/SQL procedure successfully completed. SQL>

The DBMS_SQL.TO_CURSOR_NUMBER function converts a REF CURSOR into a DBMS_SQL cursor ID.
SET SERVEROUTPUT ON DECLARE l_ref_cursor SYS_REFCURSOR; l_cursor NUMBER; l_count NUMBER := 0; BEGIN OPEN l_ref_cursor FOR 'SELECT * FROM emp'; l_cursor := DBMS_SQL.to_cursor_number(l_ref_cursor); WHILE DBMS_SQL.fetch_rows(l_cursor) > 0 LOOP l_count := l_count + 1; END LOOP; DBMS_OUTPUT.put_line('Employee Count: ' || l_count); DBMS_SQL.close_cursor(l_cursor); END; / Employee Count: 14 PL/SQL procedure successfully completed. SQL>

In addition, the DBMS_SQL package now supports all datatypes supported by native dynamic SQL.

Generalized Invocation
Generalized invocation allows a subtype to invoke a method of a parent type (supertype) using the following syntax.
(SELF AS supertype_name).method_name

The following example shows this in action. First, we create a type with some attributes and a member function.
CREATE OR REPLACE TYPE my_type AS OBJECT ( id NUMBER, description VARCHAR2(50), MEMBER FUNCTION show_attributes RETURN VARCHAR2) NOT FINAL; / CREATE OR REPLACE TYPE BODY my_type AS

MEMBER FUNCTION show_attributes RETURN VARCHAR2 IS BEGIN RETURN 'id=' || id || ' description=' || description; END; END; /

Next, we create a subtype of this object, which adds a new attribute and method as well as overriding the show_attributes member function.
CREATE OR REPLACE TYPE my_subtype UNDER my_type ( short_desc VARCHAR2(10), OVERRIDING MEMBER FUNCTION show_attributes RETURN VARCHAR2, MEMBER FUNCTION show_parent_attributes RETURN VARCHAR2); / CREATE OR REPLACE TYPE BODY my_subtype AS OVERRIDING MEMBER FUNCTION show_attributes RETURN VARCHAR2 IS BEGIN RETURN (self AS my_type).show_attributes || ' short_desc=' || short_desc; END; MEMBER FUNCTION show_parent_attributes RETURN VARCHAR2 IS BEGIN RETURN (self AS my_type).show_attributes; END; END; /

Notice the method of the parent type is accessed using the generalized invocation syntax. The code below creates a subtype and invokes its member functions.
SET SERVEROUTPUT ON DECLARE l_subtype my_subtype := my_subtype(1, 'Long description for 1', 'S Desc 1'); BEGIN DBMS_OUTPUT.put_line('show_attributes=' || l_subtype.show_attributes); DBMS_OUTPUT.put_line('show_parent_attributes=' || l_subtype.show_parent_attributes); END; / show_attributes=id=1 description=Long description for 1 short_desc=S Desc 1 show_parent_attributes=id=1 description=Long description for 1 PL/SQL procedure successfully completed. SQL>

A type can invoke the member functions of any parent type in this way, regardless of the depth of the inheritance.

Named and Mixed Notation in PL/SQL Subprogram Invocations

Prior to 11g, PL/SQL invoked from SQL had to have its parameters passed using positional notation, making it difficult to determine the meaning of parameters. Oracle 11g allows positional, named and mixed notation to be used when calling PL/SQL from SQL, as shown below.
-- Build a test function with multiple parameters. CREATE OR REPLACE FUNCTION test_func(p_value_1 IN p_value_2 IN RETURN NUMBER AS BEGIN RETURN p_value_1 + p_value_2; END test_func; / Function created. SQL> -- Positional Notation. SQL> SELECT test_func(10, 20) FROM dual; TEST_FUNC(10,20) ---------------30 1 row selected. SQL> -- Mixed Notation. SQL> SELECT test_func(10, p_value_2 => 20) FROM dual; TEST_FUNC(10,P_VALUE_2=>20) --------------------------30 1 row selected. SQL> -- Named Notation. SQL> SELECT test_func(p_value_1 => 10, p_value_2 => 20) FROM dual; TEST_FUNC(P_VALUE_1=>10,P_VALUE_2=>20) -------------------------------------30 1 row selected. SQL> NUMBER DEFAULT 0, NUMBER DEFAULT 0)

Automatic Subprogram Inlining

Every call to a procedure or function causes a slight, but measurable, performance overhead, which is especially noticeable when the subprogram is called within a loop. Avoiding procedures and functions is not an option, as it goes against the concept of modular programming, making

programs bulky and difficult to manage. Automatic subprogram inlining can reduce the overheads associated with calling subprograms, whilst leaving your original source code in its normal modular state. This is done by replacing the subprogram calls with a copy of the code in the subprogram at compile time. The process of subprogram inlining is controlled by the PLSQL_OPTIMIZE_LEVEL parameter and the INLINE pragma. When PLSQL_OPTIMIZE_LEVEL=2 (the default), the INLINE pragma determines whether the following statement or declaration should be inlined or not. When PLSQL_OPTIMIZE_LEVEL=3, the optimizer may inline code automatically. In this case the INLINE pragma can turn it off inlining for a statement, or increase the likelihood that the optimizer will choose to inline a statement. The relationship is easier to understand when you see the following example. These tests use an anonymous block with a function defined in the declaration block. The function is then called repeatedly in a loop. The settings for PLSQL_OPTIMIZE_LEVEL and the INLINE pragma are altered to switch subprogram inlining on and off. First, we make sure PLSQL_OPTIMIZE_LEVEL=2 and run the code with no INLINE pragma set. With these settings we would not expect to see subprogram inlining taking place.
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=2; SET SERVEROUTPUT ON DECLARE l_loops NUMBER := 10000000; l_start NUMBER; l_return NUMBER; FUNCTION add_numbers (p_1 IN NUMBER, p_2 IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_1 + p_2; END add_numbers; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP --PRAGMA INLINE (add_numbers, 'YES'); l_return := add_numbers(1, i); END LOOP; DBMS_OUTPUT.put_line('Elapsed Time: ' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); END; / Elapsed Time: 509 hsecs PL/SQL procedure successfully completed. SQL>

This results in an elapsed time of 509 hsecs.

Next, we keep the same optimization setting, but include the INLINE pragma with a setting of "YES" for the calls to the ADD_NUMBERS function. We would now expect subprogram inlining to take place.
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=2; SET SERVEROUTPUT ON DECLARE l_loops NUMBER := 10000000; l_start NUMBER; l_return NUMBER; FUNCTION add_numbers (p_1 IN NUMBER, p_2 IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_1 + p_2; END add_numbers; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP PRAGMA INLINE (add_numbers, 'YES'); l_return := add_numbers(1, i); END LOOP; DBMS_OUTPUT.put_line('Elapsed Time: ' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); END; / Elapsed Time: 245 hsecs PL/SQL procedure successfully completed. SQL>

This gives an elapsed time of 245 hsec, which is approximately half that of the previous test, implying that subprogram inlining is taking place. Next, we make sure PLSQL_OPTIMIZE_LEVEL=3 and run the code with no INLINE pragma set. We would now expect the optimizer to implicitly choose to inline the ADD_NUMBERS call.
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=3; SET SERVEROUTPUT ON DECLARE l_loops NUMBER := 10000000; l_start NUMBER; l_return NUMBER; FUNCTION add_numbers (p_1 IN NUMBER, p_2 IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_1 + p_2; END add_numbers;

BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP --PRAGMA INLINE (add_numbers, 'YES'); l_return := add_numbers(1, i); END LOOP; DBMS_OUTPUT.put_line('Elapsed Time: ' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); END; / Elapsed Time: 245 hsecs PL/SQL procedure successfully completed. SQL>

This gives an elapsed time of 245 hsec, which implies that subprogram inlining is still taking place. Finally, we make sure PLSQL_OPTIMIZE_LEVEL=3 and run the code with an INLINE pragma set to "NO". We would expect there to be no inlining of the ADD_NUMBERS call now.
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=3; SET SERVEROUTPUT ON DECLARE l_loops NUMBER := 10000000; l_start NUMBER; l_return NUMBER; FUNCTION add_numbers (p_1 IN NUMBER, p_2 IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_1 + p_2; END add_numbers; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP PRAGMA INLINE (add_numbers, 'NO'); l_return := add_numbers(1, i); END LOOP; DBMS_OUTPUT.put_line('Elapsed Time: ' || (DBMS_UTILITY.get_time - l_start) || ' hsecs'); END; / Elapsed Time: 500 hsecs PL/SQL procedure successfully completed. SQL>

This gives an elapsed time of 500 hsecs, which implies that inlining did not take place as we expected. The INLINE pragma only affects the following types of statements.

Assignment Call Conditional

CASE CONTINUE-WHEN EXECUTE IMMEDIATE EXIT-WHEN LOOP RETURN

In each case, it affects every call to specified subprogram from the statement. The optimizer can choose to ignore an INLINE pragma setting of "YES" if it believes inlining is undesirable, but a setting of "NO" will always prevent inlining. The compiler inlines subprograms early in the optimization process, which may preventing later, more powerful optimizations taking place. As a result, performance almost always improves with inlining, but in some cases it may not be effective.

PL/Scope
PL/Scope is a tool that gathers information about user defined identifiers at compile time. Collection of PL/Scope data is controlled by the PLSCOPE_SETTINGS parameter, which has a default setting of "IDENTIFIERS:NONE". Switch this value to "IDENTIFIERS:ALL" to enable collection.
SQL> ALTER SESSION SET PLSCOPE_SETTINGS='IDENTIFIERS:ALL'; Session altered. SQL>

Data collection is performed for all objects compiled after the flag is set, so we must now create an object to gather some data.
CREATE OR REPLACE PROCEDURE test_plscope (p_in l_var NUMBER; BEGIN l_var := p_in; l_var := l_var + 1; END; / IN NUMBER) AS

The data is stored in the SYSAUX tablespace, so the current space used for PL/Scope data can be displayed with the following query.
SELECT space_usage_kbytes

FROM WHERE

v$sysaux_occupants occupant_name = 'PL/SCOPE';

SPACE_USAGE_KBYTES -----------------384 1 row selected. SQL>

The PL/Scope data is available from the %_IDENTIFIERS views. The following query displays data gathered during the compilation of the test_plscope procedure.
COLUMN name FORMAT A30 SELECT LPAD(' ', level*2, ' ') || name AS name, type, usage, usage_id, line, col FROM user_identifiers START WITH usage_context_id = 0 CONNECT BY PRIOR usage_id = usage_context_id; NAME LINE COL ----------------------------------- ---------TEST_PLSCOPE 1 11 TEST_PLSCOPE 1 11 P_IN 1 25 L_VAR 2 3 L_VAR 4 3 P_IN 4 12 L_VAR 6 3 L_VAR 6 12 8 rows selected. SQL> TYPE USAGE USAGE_ID

------------------ ----------- ---------- ---PROCEDURE PROCEDURE FORMAL IN VARIABLE VARIABLE FORMAL IN VARIABLE VARIABLE DECLARATION DEFINITION DECLARATION DECLARATION ASSIGNMENT REFERENCE ASSIGNMENT REFERENCE 1 2 3 4 5 6 7 8

The likelihood is that most users will view the PL/Scope data via a PL/SQL IDE, such as SQL Developer. The documentation states that some identifiers will not listed unless the STANDARD package is recompiled after the PLSCOPE_SETTINGS parameter is set as follows. This results in over 7,000 invalid objects, most of which will not recompile even when using the urlrp.sql script. I don't recommend this approach if you want a working instance.

PL/SQL Native Compiler Generates Native Code Directly

Native compilation of PL/SQL code as been possible since Oracle 9i. See:

PL/SQL Native Compilation (9i) PL/SQL Native Compilation Enhancements (10g)

In these versions of the database, the PL/SQL code was converted to C code, compiled and run as external procedures. Using natively compiled PL/SQL needed a C compiler on the server and intervention from the DBA. In addition, using natively compiled PL/SQL in a RAC environment could prove problematic. In Oracle 11g, PL/SQL native compilation requires no C compiler, no DBA intervention and is fully supported in a RAC environment. By setting the PLSQL_CODE_TYPE to a value of NATIVE, rather than the default value of INTERPRETED, code is compiled directly to machine code and stored in the SYSTEM tablespace. When the code is called, it is loaded into shared memory, making it accessible for all sessions in that instance. The %_PLSQL_OBJECT_SETTINGS views include the current PLSQL_CODE_TYPE setting for each PL/SQL object. Remember, native compilation will improve the speed of procedure code, but has no effect on the performance of SQL. When code performs lots of mathematical operations, like the SIMPLE_INTEGER example, native compilation can produce considerable performance improvements. If code is predominantly performing SQL, little improvement will be noticed. As with previous database versions, it is possible to natively compile all PL/SQL code in the database, provided you follow the supported procedure.

New PL/SQL Compiler Warning

A new PL/SQL compiler warning has been added to identify WHEN OTHERS exception handlers that do no re-raise errors using RAISE or RAISE_APPLICATION_ERROR. Such exception handlers can often hide code failures that result in hard to identify bugs. The example below shows the expected compiler warning when the PLSQL_WARNINGS flag is set.
SQL> ALTER SESSION SET plsql_warnings = 'enable:all'; Session altered. SQL> 2 3 4 5 6 7 8 CREATE OR REPLACE PROCEDURE others_test AS BEGIN RAISE_APPLICATION_ERROR(-20000, 'Force and exception'); EXCEPTION WHEN OTHERS THEN NULL; END; /

SP2-0804: Procedure created with compilation warnings SQL> SHOW ERRORS Errors for PROCEDURE OTHERS_TEST:

LINE/COL ERROR -------- ----------------------------------------------------------------5/8 PLW-06009: procedure "OTHERS_TEST" OTHERS handler does not end in RAISE or RAISE_APPLICATION_ERROR SQL>

This is only a warning message, so it only identifies possible problem code, it doesn't prevent it.

PLS-00436 Restriction in FORALL Statements Removed

The PLS-00436 restriction has been removed, which means you can now reference the individual elements of a collection within the SET and WHERE clauses of a DML statement in a FORALL construct. To see this in action, create and populates a test table using the following code.
CREATE TABLE forall_test ( id NUMBER, description VARCHAR2(50) ); INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO COMMIT; forall_test forall_test forall_test forall_test forall_test VALUES VALUES VALUES VALUES VALUES (1, (2, (3, (4, (5, 'ONE'); 'TWO'); 'THREE'); 'FOUR'); 'FIVE');

The PL/SQL block below populates a collection with the existing data, amends the data in the collection, then updates the table with the amended data. The final query displays the changed data in the table.
DECLARE TYPE t_forall_test_tab IS TABLE OF forall_test%ROWTYPE; l_tab t_forall_test_tab; BEGIN -- Retrieve the existing data into a collection. SELECT * BULK COLLECT INTO l_tab FROM forall_test; -- Alter the data in the collection. FOR i IN l_tab.first .. l_tab.last LOOP l_tab(i).description := 'Description for ' || i; END LOOP; -- Update the table using the collection. FORALL i IN l_tab.first .. l_tab.last UPDATE forall_test SET description = l_tab(i).description WHERE id = l_tab(i).id; COMMIT; END; / SELECT * FROM forall_test;

ID ---------1 2 3 4 5

DESCRIPTION --------------------------Description for 1 Description for 2 Description for 3 Description for 4 Description for 5

5 rows selected. SQL>

Notice both the SET and WHERE clauses contain references to individual columns in the collection. This makes using bulk-binds for DML even easier as we no longer need to maintain multiple collections if we need to reference columns in the WHERE clause. It can also improve performance of updates, as previous versions required updates of the whole row using the ROW keyword, which included potentially unnecessary updates of primary key and foreign key columns. For more information see:

What's New in PL/SQL? - Oracle Database PL/SQL Language Reference 11g Release 1 (11.1) Oracle Database PL/SQL Packages and Types Reference 11g Release 1 (11.1)