问题是这样子的,建了TYPE A和TYPE B, B引用了A, 所以B依赖于A.
然后修改A和B, 但因为引用依赖的原因, 反复的drop和create B. 
然后,麻烦就来了, 无法修改A,始终报引用依赖的错.最后查sys.obj$和sys.dependency$, 发现在sys.obj$存在一条记录,记的是前一版本的B,实际上已经被删除,在pl/sql developer或enterprise mananger中都看不到它,但它却存在在sys.obj$中.更麻烦的是,在sys.dependency$中,上述这个"幽灵B",还引用着A,导致A也没法修改.这下该怎么搞,我可以直接在sys.obj$和sys.dependency$直接删除这个"幽灵B"吗?
直接操作系统数据字典表,会不会捅出什么篓子来?

解决方案 »

  1.   


    呵呵,那我问个其他问题吧. 我现在的目的在于要改掉A. A原来是一个独立的type, 现在我创建了一个TYPE C作为基类,要使A继承C. 就是改成类似create or replace type A UNDER C这样的形式.修改A,如果是加个atrribute之类的,是可以用CASCADE关键字,绕过那个"幽灵B"直接修改的.
    但要改成UNDER C, 可以直接用ALTER TYPE A+CASCADE改吗?我猜了几种写法,都没改成.
      

  2.   

    先drop type b试试,如果不行
    再create or replace type b,然后再drop type b
    查看依赖是否还在。
      

  3.   

    实在不行,强行删除后,再重建
    drop type type_name force;
      

  4.   

    强行删除后再重建了。
    drop type type_name force;
      

  5.   

    最后,终于能修改A了,但是......原先,drop type A force时,报错ORA-21700: object does not exist or is ed for delete.
    purge recyclebin,重启服务器,都无效.去吃了顿饭回来,不死心,再运行drop type A force,还是报错ORA-21700,然后诡异的事情发生了,我看到pl/sql developer提交事务的按钮亮了.点提交,再查看sys.obj$, 发现那条'幽灵B'的记录没了,sys.dependency$里面的依赖记录也没了.然后,TYPE A变成了一条幽灵记录,就是说除了在sys.obj$有记录之外,在别的地方再也看不到它. 可以重新create A,也可以drop A, 但那条幽灵记录始终存在.而事务按钮再也没亮过. 结论:撞上oracle的内部bug了.