我重新用SYS登录PL/SQL，查看trigger和procedure，系统提示：
ora-00604:递归SQL层1出现错误 ;
ora-06553:pls-213:standard包不可访问
里面所有对象显示都是invalid。

当时并没有想到是因为修改了SYS的权限引起的，于是换其他用户登录，结果连登录都不能，报同样的错误。隐隐感觉不妙，因为明天同事都来上班了，这个虽然是开发库，但是也会影响到很多人工作的，最主要的是自己就臭大了！

上网搜索，看了很多个类似情况，但是yangtingkun说的最为详细，于是按照他的三步：
a1> alter package standard compile;

a2> alter package dbms_standard compile;

a3> @/opt/oracle/product/9.2.0/rdbms/admin/utlrp.sql

结果第一步就宣告失败：ERROR 位于第 1 行:
ORA-00604: 递归 SQL 层 1 出现错误
ORA-06553: PLS-213: STANDARD 包不可访问。

迫不得已只好采用通用的模式建立数据字典：
b1> @/opt/oracle/product/9.2.0/rdbms/admin/catalog.sql
b2> @/opt/oracle/product/9.2.0/rdbms/admin/catproc.sql
b3> @/opt/oracle/product/9.2.0/rdbms/admin/dbmsutil.sql

开始不用是因为这个风险高，容易出错，但是现在已经没有退路了，再加上前面几天加班赶出一个测试库，开发库实在瘫掉了，就先用测试库顶几天，顺着这把火把开发库也容灾调整了。

我开始的时候把这些文件里面的东西放到PL/SQL的SQL Window里面跑，结果提示ORA-00604和ORA-06553错误，看来PL/SQL似乎利用了oracle里面的一些通用的包来封装了一下，到底不像SQLPLUS那么万能，于是我用SQLPLUS模式登录运行b1和b2。成功了，非SYS用户可以正常登录调试，但是报了很多的错误，让我没有欲望再去执行b3，而系统里面留下的是3000多个invalid对象肯定是要消除的。

到这里其实我已经很开心了，不用重建意味着里面400G的开发数据不用重新导入了，要知道那还得从几个T的正式库拉过来，拉的不好把正式库搞死了，那就飙大了。我想到了重新回到a方案，因为已经可以编译了。

问题本来可以结束的了，然而在a1:
SQL>alter package standard compile;
还没有结束的时候，我不知情的按了ctl+c，使得该命令退出到SQL>
然后我马不停蹄的执行了a2,好了，问题由此而来，这两个编译相互锁住了彼此的对象只得停滞不前，在PL/SQL里面无论干什么都会慢的要死，而且过几秒就会抛出：
ora-04020:deadlock detected while trying to lock object sys.cdc_alter_ctable_before

我看到死锁，就去把运行这个进程的SESSION杀掉，然而问题并没有解决，死锁依旧;无奈之下我shutdown abort&&startup重启了数据库，以为数据库重启了死锁肯定没有了，然而我再次高估自己了;我又试着重新运行a方案和b方案，现在连这两个都无法执行了，抛出ora-04020错误。

我只好去查看sys.cdc_alter_ctable_before到底是个什么东东，发现原来是个trigger，尝试让它失效：ALTER TRIGGER sys.cdc_alter_ctable_before DISABLE;
然后运行其他编译程序，竟然成功了！

再次运行a方案，这次死活都等他自己完成了，十分钟后一切回复正常，3000多个invalid对象只剩150个本身就有问题的对象了。但是害怕更改系统的trigger会引起连锁问题，再让它生效：
ALTER TRIGGER sys.cdc_alter_ctable_before ENABLE;

一切OK了！汗到天亮啊！！