alter system set resource_manager_plan=''; 

SQL> show parameter resource_manager_plan

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
resource_manager_plan                string      SCHEDULER[0x3003]:DEFAULT_MAIN
                                                 TENANCE_PLAN

"What is the maximum size of a PL/SQL procedure?"

That wouldn't surprise me, greatly, though one might consider it a bit odd because the invoker rights feature of PL/SQL was added in Oracle8i - many years ago!

So I will first offer a brief overview of invoker rights, why you'd use it, how you use it. Then I will introduce one of the major challenges with invoker rights. Finally, I offer a utility that can help you overcome that challenge.

When you create a PL/SQL program unit, you can include an optional AUTHID clause. There are two forms of this clause:

AUTHID DEFINER
AUTHID CURRENT_USER

AUTHID DEFINER is the default. So these two procedures specify "definer rights"

PROCEDURE show_emp_count AUTHID DEFINER
PROCEDURE show_emp_count

And this version specifies "invoker rights":

PROCEDURE show_emp_count AUTHID CURRENT_USER

So that's the syntax. What does it do for you?

In many application environments, the code is owned by one schema (let's call it CODE_SCHEMA), and then privileges are granted to execute that code to other schemas (USER_SCHEMA).

When a program unit is created in CODE_SCHEMA with definer rights, then when a user connected to USER_SCHEMA runs that program, it runs under the privileges of CODE_SCHEMA.

When a program unit is created in CODE_SCHEMA with invoker rights, then when a user connected to USER_SCHEMA runs that program, it runs under the privileges of USER_SCHEMA. And all such privileges must be directly granted (no role-based privileges).

In other words, at the time an invoker rights program is executed, Oracle resolves all references to SQL-related database objects (tables and views, for the most part) according to the current user's privileges, and not the privileges of the owner of the program. And role-based privileges are used by Oracle with invoker rights programs.

I will step through a simple demonstration below. You are, however, probably wondering what invoker rights is good for. Invoker rights comes in very handy whenever you have a program that needs to work differently (with different tables) depending on who is running the code.

Consider Quest Code Tester for Oracle. This automated testing tool for PL/SQL is built around a test repository: 30+ tables and associated code. Usually, this repository is installed in a central schema, and then access to the repository is allowed through synonyms.

As a use of Quest Code Tester, I connect to my own development schema, and then call Code Tester programs to define and run my tests.

If Quest Code Tester relied on definer rights, then the test repository schema would need to have the authority to execute code in all the development schemas, and probably have directly granted privileges on underlying tables as well. That is a very risky test repository and most DBAs will not create such a powerful schema.

Instead, many of the packages in Quest Code Tester are defined as invoker rights. So when the developer asks Code Tester to run a test of the program in her schema, no special privileges are needed in the test repository schema. And Code Tester is not able to do anything to application data that the developer's code does not specifically allow.
In essence, with invoker rights, Oracle "reflects" back into the invoking schema to resolve references as you see below:

 
Now let's walk through a simple demonstration. I will first create a table in SCOTT with two rows:

CONNECT scott/tiger

CREATE TABLE authid_demo (n NUMBER)
/

BEGIN
   INSERT INTO authid_demo
   VALUES (1);

   INSERT INTO authid_demo
   VALUES (2);

   COMMIT;
END;
/

I will create the "same" table in HR, but with no rows:

CONNECT hr/hr

CREATE TABLE authid_demo (n NUMBER)
/

Then in SCOTT, I create three procedures, each of which do mostly the same thing: show the number of rows in the authid_demo table.

CREATE OR REPLACE PROCEDURE proc1 AUTHID CURRENT_USER
IS
   num   PLS_INTEGER;
BEGIN
   SELECT COUNT (*) INTO num FROM authid_demo;
   DBMS_OUTPUT.put_line ('proc 1 invoker authid_demo count = ' || num);
END;
/

CREATE OR REPLACE PROCEDURE proc2 AUTHID DEFINER
IS
   num   PLS_INTEGER;
BEGIN
   SELECT COUNT (*) INTO num FROM authid_demo;
   DBMS_OUTPUT.put_line ('proc 2 definer authid_demo count = ' || num);
   proc1;
END;
/

CREATE OR REPLACE PROCEDURE proc3 AUTHID CURRENT_USER
IS
   num   PLS_INTEGER;
BEGIN
   SELECT COUNT (*) INTO num FROM authid_demo;
   DBMS_OUTPUT.put_line ('proc 3 invoker authid_demo count = ' || num);
   proc1;
   proc2;
END;
/

Note that we have these two sequence of calls:

PROC3 -> PROC1
PROC3 -> PROC2 -> PROC1

and that PROC3 and PROC1 are invoker rights, while PROC2 is definer rights.

I then allow HR to run all this code and access the underlying table in SCOTT:

GRANT EXECUTE ON proc1 TO hr
/

GRANT EXECUTE ON proc2 TO hr
/

GRANT EXECUTE ON proc3 TO hr
/

GRANT SELECT ON scott.authid_demo TO hr
/

Finally, I run PROC3 - from HR:

BEGIN
   scott.proc3;
END;
/

Here's the output I see:

Line 1: proc 3 invoker authid_demo count = 0
Line 2: proc 1 invoker authid_demo count = 0
Line 3: proc 2 definer authid_demo count = 2
Line 4: proc 1 invoker authid_demo count = 2

Lines 1 and 2 demonstrate invoker rights at work: even though HR called SCOTT's PROC3 and PROC1 programs, the count of rows in authid_demo is retuned as 0, not 2.

Line 3 demonstrates definer rights: it shows the number of rows in SCOTT's authid_demo table, even though the program was called by HR.

But line 4 - now that is puzzling, isn't it? Notice that I got an answer of 2, not 0, for the count in the authid_demo table. Yet I called the same program (PROC1) that two lines earlier showed 2.

So: same code executes, but returns different answer. Very troubling, wouldn't you say?

Here's the problem: if at any point along the execution call stack (in this case, PROC3 -> PROC2 -> PROC1), a definer rights program is executed, then from that point on down the stack the "current user" is resolved by Oracle to be the owner of that definer rights program and not the currently connected user.

When PROC3 called PROC1, that was invoker rights calling invoker rights, and so the current user was HR and the procedure showed 0 rows.

When PROC3 called PROC2, Oracle reset "current user" to SCOTT. Then when PROC2 called PROC1, Oracle resolved the reference to the authid_demo table using SCOTT, and theprocedure therefore showed 2 rows.

This change in expected behavior can cause many problems in your application, ranging from raising "table or view does not exist" and "insufficient privileges" errors to returning or changing the wrong rows of data.

Assuming this is not the behavior you want, you need to make sure that all the program units executed in your call stack are all definer rights or all invoker rights, or at least that once you call a definer rights program, you only call other definer rights programs from that point on.

Fine advice (at least I think so), but how do you apply it? Call stacks in real applications can be very deep, easily a dozen or more entries. Plus, how can you even get hold of the call stack to analyze it?

First, you can call the DBMS_UTILITY.FORMAT_CALL_STACK at any point in your code, and Oracle will return a string that contains the call stack. Here's an example of the formatted call stack Oracle returns, taken from the Quest Code Tester log:

 

----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
3B6C8C64         1  anonymous block
3FA473E8      1012  package body QCTO183.QU_RUNTIME
3FA473E8      1042  package body QCTO183.QU_RUNTIME
3FA32EF8      3120  package body QCTO183.QU_ALL_OBJECTS
3FA32EF8      3138  package body QCTO183.QU_ALL_OBJECTS
3FA12F2C      2613  package body QCTO183.QU_GENERATE
3FA12F2C      3269  package body QCTO183.QU_GENERATE
3FA12F2C      3341  package body QCTO183.QU_GENERATE
3FA12F2C      3601  package body QCTO183.QU_GENERATE
3FA12F2C      6192  package body QCTO183.QU_GENERATE
3FA12F2C      8835  package body QCTO183.QU_GENERATE
3FA12F2C      9138  package body QCTO183.QU_GENERATE
3FA12F2C      9196  package body QCTO183.QU_GENERATE
3FA12F2C      9487  package body QCTO183.QU_GENERATE
4DA12F23      9737  package body QCTO183.QU_HARNESS
3BC12F2C      9800  package body QCTO183.QU_TEST
3BC12F2C     10130  package body QCTO183.QU_TEST
3B6F83F8         4  anonymous block

 

So to follow my own advice, I would now have to open each of these package specifications and check the AUTHID setting. That's rather tedious.

Perhaps there is another way. Consider the ALL_PROCEDURES data dictionary view:

 
Notice the AUTHID column. You can look up the AUTHID setting for your program unit from this view. So it seems as though you could write a program to parse the call stack and then look up the AUTHID setting for each program unit in the stack, and make sure there are no problems with  a switch from invoker rights to definer rights, and back, in that stack.

Yes, you could do that. But likely you want, because you have a real job and a real life and very little time to write such programs.

Fortunately, I don't have a "real job" (well, believe you me, they keep me very busy here at Quest, but they also more or less let me do what I want. J ) and I sure don't have a real life. My office is at home, so the boundaries between work (PL/SQL) and non-work crumbled years ago.

Well, enough about me and my life. The bottom line is that I have created a package, called authid_analysis, available in authid_analysis.pkg file of my demo.zip, that will perform precisely this analysis on your behalf.

Here's the header of the package:

CREATE OR REPLACE PACKAGE authid_analysis
IS
   FUNCTION authid_setting (program_owner_in IN VARCHAR2
                          , program_name_in  IN VARCHAR2
                           )
      RETURN VARCHAR2;

   FUNCTION is_current_user (program_owner_in IN VARCHAR2
                           , program_name_in  IN VARCHAR2
                            )
      RETURN BOOLEAN;

   FUNCTION is_definer (program_owner_in IN VARCHAR2
                      , program_name_in  IN VARCHAR2
                       )
      RETURN BOOLEAN;

   PROCEDURE analyze_callstack (callstack_in IN VARCHAR2 DEFAULT NULL);
END authid_analysis;

You can retrieve the AUTHID setting of a program from ALL_PROCEDURES and find out if a program is invoker rights (is_current_user) or definer rights (is_definer).

Finally, call the analyze_callstack procedure to identify possible problems, as described above. If you do not pass the call stack, analyze_callstack will call the FORMAT_CALL_STACK function for you.

You can easily integrate this package into your error logging and tracing routine, making it easy to identify possible program areas in your code. I plan to add this to Quest Error Manager as soon as I have a moment.

The authid_analysis.tst scritp will allow you run a quick test of this utility. Here's what I see:

CREATE OR REPLACE PROCEDURE proc1
   AUTHID CURRENT_USER
IS
BEGIN
   authid_analysis.analyze_callstack;
END;
/

CREATE OR REPLACE PROCEDURE proc2
IS
BEGIN
   proc1;
END;
/

CREATE OR REPLACE PROCEDURE proc3
   AUTHID CURRENT_USER
IS
BEGIN
   proc2;
END;
/

BEGIN
   proc3;
END;
/
> DEFINER      package body HR.AUTHID_ANALYSIS called by...
> CURRENT_USER procedure HR.PROC1 called by...
> DEFINER      procedure HR.PROC2 called by...
> CURRENT_USER procedure HR.PROC3 called by...
>              anonymous block

As you can see, I have a switch from invoker rights to definer rights in the call to PROC2 and that will likely cause problems.

I hope you find this utility useful.

As I understand it, there are basically three ways to do this:

1. Invoke a Java method from within a PL/SQL wrapper
    
2. Call a C program as an external procedure from within PL/SQL.
    
3. Use the new DBMS_SCHEDULER package.

I will soon publish a DBMS_SCHEDULER solution (written by Bryn Llewellyn, PL/SQL Product Manager) on my OTN Best Practices column. In the meantime, you will find below a quick review of the steps needed to do this in Java and C.

Executing Host Command with Java

With the Java approach, you will take these steps:

1. Find the Java class that implements host command execution.
    
2. Build a class that invokes that host command method. Let's call it HostCommand.
    
3. Build a PL/SQL program that calls a method in HostCommand to run your command.
    
4. Acquire the privileges needed to execute host commands via Java in the database.

Let's go through each of these steps.

1. Find the Java class that implements host command execution.

Objects of the java.lang.Runtime class include an exec method that will execute a host command.

2. Build a class that invokes that host command method.

Let's call it HostCommand.

Here's code to create a new Java class in the database to invoke this command for the Windows XP operating system:

CREATE OR REPLACE AND RESOLVE JAVA SOURCE NAMED "UTLcmd"
AS import java.lang.Runtime;
public class execHostCommand
{ 
  public static void execute (String command) 
    throws java.io.IOException
  {
   String osName = System.getProperty("os.name");
   if(osName.equals("Windows XP"))
       command = "cmd /c " + command;
   Runtime rt = java.lang.Runtime.getRuntime();
   rt.exec(command);
  }
}
/

You can easily modify the execute method to support other operating systems based on the value of osName.

3. Build a PL/SQL program that calls a method in HostCommand to run your command.

CREATE OR REPLACE PACKAGE host_command IS
  PROCEDURE execute (cmd IN VARCHAR2) AS LANGUAGE JAVA NAME
           'execHostCommand.execute(java.lang.String)';
END;
/

Notice that I "map" the VARCHAR2 datatype to the java.lang.String class in my call to the new Java method.

4. Acquire the privileges needed to execute host commands via Java in the database.

You need special privileges to execute host commands from within the database through Java. Otherwise when you try to execute your command you will see an error like this (the error message will vary depending on what you are trying to do):

One way to obtain these privileges is to have the JAVASYSPRIV role granted to your schema. This role contains all the privileges you need (and more).

For a more nuanced approach to granting the required privileges, you can also use the Java security API available in the Oracle database. For example, if I want to delete a file using a host command (perhaps it is not accessible through UTL_FILE), I will need to grant the following privileges to the schema in which the command is executed, such as HR:

BEGIN
   DBMS_JAVA.grant_permission ('HR'
                             , 'SYS:java.io.FilePermission'
                             , '<>'
                             , 'execute'
                              );
   DBMS_JAVA.grant_permission ('HR'
                             , 'SYS:java.lang.RuntimePermission'
                             , 'writeFileDescriptor'
                             , ''
                              );
   DBMS_JAVA.grant_permission ('HR'
                             , 'SYS:java.lang.RuntimePermission'
                             , 'readFileDescriptor'
                             , ''
                              );
END;
/

Executing Host Command with C

To use C, you must define an external procedure and then invoke it within your PL/SQL block. It is not possible within this article to cover completely all the steps and issues involved in setting up such an external procedure. I will, instead, cover the highlights. For the full details, read Chapter 27 of Oracle PL/SQL Programming, 4th edition, in which my co-author Bill Pribyl thoroughly explains external procedures.

As with Java, you will need help from your database administrator to supply the privileges needed to execute your host command in C.

Here are the steps to follow with C:

1. Find (or build) the C program that implements host command execution.
    
2. Save the C source to a file and generate a shared library for it.
    
3. Save the library file where Oracle can find it.
    
4. Define a library inside Oracle that is associated with the shared library on disk.
    
5. Create a PL/SQL wrapper for the C function.

Let's go through each of these steps.

1. Find (or build) the C program that implements host command execution.

The C system function executes an operating system command. So I build a simple C function, extprocsh(), that accepts a string and passes it to the system function for execution:

int extprocsh(char *cmd)
{
   return system(cmd);
}

The function returns the result code as provided by system, a function normally found in the C runtime library (libc) on Unix, or in msvcrt.dll on Microsoft platforms.

2. Save the C source to a file and generate a shared library for it.

I save the source code in a file named extprocsh.c. I then use the GNU C compiler to generate a shared library. On a 64-bit Solaris machine running GCC 3.4.2 and Oracle Database 10g Release 2, the following compiler command worked to create a shared library:

gcc -m64 extprocsh.c -fPIC -G -o extprocsh.so

Similarly, on Microsoft Windows XP Pro running GCC 3.2.3 from Minimal GNU for Windows (MinGW), also with Oracle Database 10g Release 2, this works:

c:\MinGW\bin\gcc extprocsh.c -shared -o extprocsh.dll

3. Save the library file where Oracle can find it.

These commands generate a shared library file, extprocsh.so or extprocsh.dll. Now I need to put the library file somewhere that Oracle can find it. The default locations for Windows and Unix respectively are:

$ORACLE_HOME/bin
$ORACLE_HOME/lib

If you want to use a non-default location, you will need to edit the listener configuration file and supply path value(s) for the ENVS="EXTPROC_DLLS...".

4. Define a library inside Oracle that is associated with the shared library on disk.

After copying the file and/or making adjustments to the listener, you will then define a "library" inside Oracle to point to the DLL. For example:

CREATE OR REPLACE LIBRARY extprocshell_lib 
   AS '/u01/app/oracle/local/lib/extprocsh.so';   -- Unix
     
CREATE OR REPLACE LIBRARY extprocshell_lib
   AS 'c:\oracle\local\lib\extprocsh.dll';      -- Microsoft

Note: performing this step requires Oracle's CREATE LIBRARY privilege.

5. Create a PL/SQL wrapper for the C function.

Now I can create a PL/SQL call specification which uses the newly created library:

CREATE OR REPLACE FUNCTION exec_host_command (cmd IN VARCHAR2)
   RETURN PLS_INTEGER
AS
   LANGUAGE C
   LIBRARY extprocshell_lib
   NAME "extprocsh"
   PARAMETERS (cmd STRING, RETURN INT);

Then, assuming that your DBA has set up the system environment to support external procedures, the exec_host_command function can now be called anywhere you can invoke a PL/SQL function.

Note that these operating system commands will execute with the same privileges as the Oracle Net listener that spawns the extproc process.

• You will have lots of (dozens, perhaps hundreds) of separate test cases to run; if each test takes five minutes due to data volume, the test cycle will take an enormous amount of time.
   
• Ideally, you run your tests after each change you make to your program. That way, you can immediately determine if you have introduced any bugs. But if running those tests takes an hour, you will test less frequently and you will get less "return" on your investment of creating your tests.