To get some more information, you could use logminer to filter out updates
to obj$ table for dbms_standard's corresponding row in there.
----- Original Message -----
From: "Alex Gorbachev" <gorbyx@(protected)>
To: "ORACLE-L" <oracle-l@(protected)>
Sent: Monday, May 15, 2006 6:50 PM
Subject: CATPROC gets invalidated
> Hi all,
> This is very weird... Third time in the last few days catproc got
> invalidated. This is on 10.1.0.4 database on AIX that was upgraded to
> 10.2.0.2 and than downgraded back to 10.1.0.4 (almost a month ago).
> it's a DW environment.
> Last occurrence's description:
> The issue appears in different forms one of which is trying to run
: existing state of packages has been discarded
: not executed, altered or dropped stored procedure
: PL/SQL: could not find program unit being called
: at "SYS.DBMS_STATS", line 12210
: at line 2
> I checked invalid objects DBMS_STATS and DBMS_STANDARD packages are
> VALID. There are some invalid objects though. For example,
> DBMS_SQLTUNE and DBA_HIST_* views. CATPROC component in
> DBA_SERVER_REGISTRY is shown as invalid. This time I was able to fix
> it with simple utlrp.sql.
> Two time before we couldn't run utlrp.sql because DBMS_STANDARD was
> actually invalid and I could see it! So first time we went to startup
> migrate and catrelod.sql. Second time I just complied DBMS_STANDARD
> manually and than was able to run utlrp.sql happily.
> After the second issue I enabled auditing for all DDL using AUDIT ANY
> PRIVILEGE (and excluded than SELECT/UPDATE/DELETE/INSERT). However, I
> couldn't see any DDL on sys objects in audit trail.
> So how to catch what causes packages' invalidation and in the last
> case what the heck I couldn't run DBMS_STATS if it was valid as well
> as DBMS_STANDARD (which was in the error text)?
> I can only add that another similar database in the same environment
> showed similar behavior just couple days ago. It's gotta be something
> similar and I believe caused by some user action. (This environment
> setup in very un-secure way and I wouldn't be surprised that some
> users/developers have actually access to DBA privileges but this is
> another story).
> Thanks in advance for any hints.
> Best regards,
> Alex Gorbachev