重新编译失效的对象导致row cache lock狂高

首先从当天的awr报表中发现cpu占用很高，转而跳到cpu wait去查找top 5的cpu wait，结果发现这样一句sql：
DECLARE threads pls_integer := 0; BEGIN utl_recomp.recomp_parallel(threads); END;
其中sql_id为3cmwr02yfw7ud
而且这个sql还没有运行结束，于是登陆生产查找问题

首先到v$session视图中查找运行此sql的终端等信息，发现这个是从数据库服务器本地登陆上去运行的，而且从凌晨3点开始到现在都没有结束。首先怀疑是谁定义了自动运行的脚本，到crontab和job中找了一圈没有任何发现，然后回到session视图，看看是从哪个客户端发起的，在machine字段中得到是本机，而program字段得到sqlplus@xxx.xxx.com (TNS V1-V3)，然后查到了pid＝1662，然后
[oracle@billdb1 bdump]$ ps -ef|grep 1662
oracle 1662 1606 0 03:00 ? 00:00:47 oraclebilldb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 19661 14083 0 17:59 pts/2 00:00:00 grep 1662

也看到是本机登陆的，而且应该是用sysdba权限直接登陆的，去audit目录查找sysdba登陆的信息，发现时间和此sql开始的时间吻合。

最后想到了job sched，果然里面有一个UTL_RECOMP_SLAVE_29
其中的action为sys.utl_recomp.parallel_slave(0)，查找此job运行的记录，发现前几天也在运行，但是都很快结束了，这次却结束不了了。

开始查找v$session_wait视图，
select event,p1text,p1,p2text,p2,p3text,p3 from v$session_wait where sid=495
row cache lock cache id 8 mode 0 request 5

查询select parameter from v$rowcache where cache#=8

返回
dc_objects
dc_object_grants

也可以看到它在等待数据字典的某个对象。

然后开始准备dump这个session的信息，结果发现dump将要写的文件被oracle进程占用，导致dump失败，而这个文件中的内容也看不出问题的原因。

准备让它再跑一个晚上第二天再来查找问题，结果同事怕晚上出问题，把它kill了。

线索断了。。。