Which Code Runs Slower

Test Your PL/SQL Knowledge

This puzzler has come from Steven Feuerstein for the month of February 2008. So I thought to reproduce the puzzler with its answer:

The employees table in the production Oracle Database 10g Release 2 instance of the MassiveGlobalCorp company contains 2.5 million rows.
 

Below are three different blocks of code, each of which fetch all rows from this table and then "do stuff" with each fetched record. Which will run much slower than the other two, and why?

 

a.
DECLARE
  CURSOR employees_cur IS SELECT * FROM employees;
BEGIN
  FOR employee_rec IN employees_cur LOOP
      do_stuff (employee_rec);
   END LOOP;
END;
 
b.
DECLARE
  CURSOR employees_cur IS SELECT * FROM employees;
  l_employee   employees%ROWTYPE;
BEGIN
   OPEN employees_cur;
   LOOP
      FETCH employees_cur INTO l_employee;
      EXIT WHEN employees_cur%NOTFOUND;
      do_stuff (l_employee);
   END LOOP;
   CLOSE employees_cur;
END;
 
c.
DECLARE
   CURSOR employees_cur IS SELECT * FROM employees;
   TYPE employees_aat IS TABLE OF employees%ROWTYPE INDEX BY PLS_INTEGER; 
   l_employees   employees_aat;
BEGIN
   OPEN employees_cur;
   LOOP
     FETCH employees_cur
      BULK COLLECT INTO l_employees LIMIT 100; 
      EXIT WHEN l_employees.COUNT () = 0; 
      FOR indx IN 1 .. l_employees.COUNT
      LOOP
         do_stuff (l_employees (indx));
      END LOOP;
   END LOOP;
   CLOSE employees_cur;
END;

Scroll below to see the answer:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

(b) Is the slowest. That's because on Oracle 10g and higher, the PL/SQL optimizer will automatically rewrite cursor FOR loops so that they are executed in the same way as the BULK COLLECT query.

Sounds Interesting???

Steven Feuerstein is considered one of the world's leading experts on the Oracle PL/SQL language, having written ten books on PL/SQL all published by O'Reilly Media, including Oracle PL/SQL Programming and Oracle PL/SQL Best Practices (all from O'Reilly Media).

Steven has been developing software since 1980, spent five years with Oracle (1987-1992), and serves as a PL/SQL Evangelist to Quest Software.  

He publishes puzzlers every month and here is where you can see all of them.

Proxy user connect for SQL *Plus


Oracle Tips by Burleson Consulting
Today, systems with thousands of individual Oracle user ID's are not very common.  Almost all enterprise applications (ERP packages like SAP, Oracle Financials) use pre-spawned Oracle connections that are created by a single Oracle user ID with names like AR or SAPR3.

The application server manages the connections to Oracle for us.
This is called a "proxy", the term proxy meaning an act where a 3rd party does something on our behalf.   Unfortunately, when our end-users connect anonymously through a proxy, we do not have any end-user level security through traditional security tools like granting privileges or using roles and the only Oracle security is that is granted the ERP "master" user ID.

Who goes there?
From a DBA perspective, all database activity is being done by this single user and a query of the v$session view for an ERP does not identify any specific user, because they are connected to Oracle via the proxy on the application server.

This is a special nightmare for Oracle auditing, and all database auditing must now be done within the application server because is not aware of the "real" end-user, behind the proxy connection.
For complete information on Oracle auditing for ERP's see my notes in my bestselling security book "Oracle Privacy Security Auditing" with Arup Nanda.

The answer is to create a method whereby the ERP can maintain it's pre-spawned connection to Oracle while giving Oracle the ability to impose traditional security management (via roles, privileges, VPD's, etc.).

Oracle proxy connect authentication in 10gr2
To address this issue of unknown specific users within pre-spawned Oracle connections, Oracle has introduced a new proxy connection authentication in Oracle 10g release 2.
Under this new architecture, the ERP user ID is given limited privileges (create session only), and individual Oracle user ID's are created for each ERP user, using the traditional "create user" syntax.

Traditionally, you always connected to Oracle by only specifying your user ID and password:
connect scott/tiger

New with 10r2 proxy identification in SQL*Plus, the "connect" command has been enhanced to allow for a "proxy":

connect sapr3[scott]/tiger

You can also use this syntax to connect to SQL*Plus directly from the OS prompt:

root> sqlplus sapr3[scott]/tiger@mydb

As we see, we have a second, "proxy" user ID in the connect request (scott, in this case).  When Oracle establishes the database connection, he will first connect as SAPR3 (who only has connect and resource privileges) and then open a proxy connection as scott.

Now, we have complete Oracle privileges and access control, just as if the scott user was connected, but in reality we have connected with the SAPR3 user, keeping our pre-spawned connection pool happy.
Note:  To see the "proxy owner" of any Oracle session, you can see a proxy connection by using the sys_context package:

-- Here we see that Oracle has scott as the user ID
select user from dual;

USER
---------------------------------------
SCOTT

-- Here we call sys_context to reveal the proxy user:
select sys_context('USERENV','PROXY_USER') from dual;
SYS_CONTEXT('USERENV','PROXY_USER')
---------------------------------------
SAPR3

Article Courtesy:
http://www.dba-oracle.com/t_proxy_connect_authentication.htm