views:

2566

answers:

4

Hi,

We're getting this error once a day on a script that runs every two hours, but at different times of the day.

ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04061: existing state of package body "PACKAGE.NAME" has been
invalidated
ORA-06508: PL/SQL: could not find program unit being called:
"PACKAGE.NAME"
ORA-06512: at line 1

Could someone list what conditions can cause this error so that we could investigate?

Thanks.

UPDATE: Would executing 'ALTER SESSION CLOSE DATABASE LINK DBLINK' invalidate a state of the package?

+5  A: 

The package has public or private variables. (Right?) This variables form the state a the package. If you compile the package in 3rd session. The next access to this package will throw the ORA-04068.

The build timestamp of a package must be older than the package session state.

If the package state is not needed for script running, the call DBMS_SESSION.RESET_PACKAGE at the beginning of your script. This cleans all package states of your session.

Christian13467
Will try the specified call. Thanks.
jonasespelita
A question though, how does compiling a package in the 3rd session invalidate it?
jonasespelita
martilyo: the new version of the package could have more/less/other package variables. In fact, if you compile a package that has no package variables at all, those ORA-04068 errors do not happen. Daredevils do that on production systems, during busy work hours..
ammoQ
Would executing 'ALTER SESSION CLOSE DATABASE LINK DBLINK' invalidate a state of the package?
jonasespelita
No it wouldn't. I think not.
Christian13467
A: 

It seems that you are making changes to your objects that make other objects invalid. Droping an index for example can put into an invalid state all the packages that dependes on that table. It can have a cascade efect. If the package is invalid, the funciton that depends on the package and the view that uses the function can become invalid. Try to recompile all the objects after every DDL query.

borjab
+2  A: 

You may also check dba_dependencies or user_dependencies.

select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and type = 'PACKAGE' --- or 'PACKAGE_BODY'
and owner = USER --- or USERNAME

This will give you the objects your package is dependent on. Check whats happening in there.

Guru
Thanks for the Info. You learn something everyday :).
jonasespelita
+1  A: 

This one liner actually solved everything:

PRAGMA SERIALLY_REUSABLE;

Be sure that your global variables are stateless to avoid any issues.

jonasespelita