Skip to Main Content
  • Questions
  • Determine when an ORA-4068 will happen

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Jeff.

Asked: March 13, 2001 - 9:32 am UTC

Last updated: July 25, 2003 - 3:43 am UTC

Version: 8.1.7.0.0

Viewed 1000+ times

You Asked

I know that package variables will cause ORA-4068 error messages when another user tries to re-compile the package body that is already in use. I know why I am getting these errors, I need to know how I can detect these errors before the user compiles a package body.
--
For example, a user creates a package:
session1 > l
1 create or replace package foo
2 is
3 function bar return varchar2;
4* end foo;
session1 > /

Package created.

Then, in the same session, the user creates the package body:
session1 > l
1 create or replace package body foo
2 is
3 v2 varchar2(80);
4 function bar return varchar2
5 is
6 ver varchar2(80);
7 begin
8 v2:='this is a package variable.';
9 ver := v2;
10 return ver;
11 end bar;
12* end foo;
session1 > /

Package body created.

Then the user executes the package:
session1 > set serveroutput on
session1 > exec dbms_output.put_line(foo.bar);
this is a package variable.

PL/SQL procedure successfully completed.

Now another sqlplus session is started in window#2 as the same user and he executes the package:
session2 > set serveroutput on
session2 > exec dbms_output.put_line(foo.bar);
this is a package variable.

PL/SQL procedure successfully completed.

Now, the user needs to recompile the body of foo. If he recompiles the package in session1, an ORA-4068 error will be generated in session2. Before the first session recompiles the package body, I want to be able to find out if he will generate an ORA-4068 error for any other users using that package.


and Tom said...

Run catblock.sql found in $ORACLE_HOME/rdbms/admin when logged in as SYS using svrmgrl (if you haven't already).

That'll give you a view DBA_DDL_LOCKS. Now you can:

scott@DEV816> select a.username, b.owner || '.' || b.name
2 from v$session a, dba_ddl_locks b
3 where a.sid = b.session_id
4 and b.type like '%/Procedure/%';

USERNAME B.OWNER||'.'||B.NAME
------------------------------ --------------------------------------------
SCOTT SYS.DBMS_APPLICATION_INFO
SCOTT SYS.DBMS_OUTPUT


Now, if scott starts using other stuff:

scott@DEV816> exec ops$tkyte.print_table( 'select * from dual' );
DUMMY : X
-----------------

PL/SQL procedure successfully completed.

scott@DEV816> /

USERNAME B.OWNER||'.'||B.NAME
------------------------------ ---------------------------------------------
SCOTT OPS$TKYTE.PRINT_TABLE
SCOTT SYS.DBMS_SYS_SQL
SCOTT SYS.DBMS_SQL
SCOTT SYS.DBMS_APPLICATION_INFO
SCOTT SYS.DBMS_OUTPUT


I can see that by scott running print_table, which uses DBMS_SQL which uses DBMS_SYSS_SQL -- scott has breakable parse locks on all of the above code....

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Missed reference to modify_package_state

Martin, July 25, 2003 - 3:43 am UTC

The article is ok, but I missed to give a hint, that for the own session a reset is possible using dbms_session.modify_package_state(1)

The solution would be, if this procedure could be executed for a foreign session (i consider this a suggestion for product enhancement), if this would be possible technically.

have a nice day,
martin

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library