oracle 数据库使用的时间越长，操作数据库的人越多，可能会遇到一些非法数据库对象引起的错误。
oracle 数据库使用的时间越长，操作数据库的人越多，可能会遇到一些非法数据库对象引起的错误。
例如：
按用户 exp 时会报错(oracle10g)
| . exporting synonyms exp-00008: oracle error 3113 encountered ora-03113: end-of-file on communication channel exp-00000: export terminated unsuccessfully |
oracle8i 里面的的exp错误 ora-00980。
跟踪文件里的错误:
| ora-07445: exception encountered: core dump [joe_well_known_internal()+39] [sigsegv] [address not mapped to object] [0x1268d5c] [] [] ...... select synnam, dbms_java.longname(synnam), dbms_java.longname(syntab),tabown, tabnode, public$, synown, synownid, tabownid, synobjno from sys.exu9synu order by syntime; |
我的经验是这些数据库的用户下很可能有非法数据库对象。删除不合法的数据对象，就可以了。一般情况下生成当前用户下重编译非法数据库对象的sql语句:
| set pages 500; set lines 200; set trims on; set heading off; spool /tmp/1.sql; select 'alter '||object_type||' '||object_name||'; compile' from user_objects where status='invalid'; spool off; @/tmp/1.sql; |
但也有例外的情况:
当原始的表被drop掉后，依据它创建的同义词就变得不能访问了。
原始的表重建以后，同义词仍然不可以访问。
但在user_objects里面的status状态是'valid'，却不是'invalid'。
这需要我们把它们找出来，运行查询同义词表结构的语句:
| spool /tmp/1.sql; select 'desc '||synonym_name||';' from user_synonyms; spool off; @/tmp/1.sql; |
出错的同义词, 一定要先彻底删除掉，再重建创建同义词。
| drop synonym &synonym_name; create synonym &synonym_name for &owner.&table_name; |
重编译后，仍然出错的数据对象，经开发人员同意后，我们还可以选择drop它们。我还遇到过一次在drop非法数据库对象的时候，不加双引号之前，提示数据对象不存在。一定要在数据库对象加上双引号就可以删掉了。(这可能跟创建数据对象所用的辅助性工具有关)
例如：
| drop table scott."emp" cascade constraints; drop trigger scott."trigger_name"; |
如果所有的非法数据对象都没有了，还会出现上面的错误。可能是jvm(java虚拟环境)的问题。dbms_java.longname()过程函数一执行，就会报错。还有一个解决办法：重建sys用户下跟同义词有关的视图，让它找不到记录。
| drop view exu9synu; create view exu9synu as select "synnam","synnam2","syntab", "tabown","tabnode","public$","synown", "synownid","tabownid","synobjno","syntime" from sys.exu9syn -- where synownid = uid; (原来的视图创建方法) where 0=1; grant select on sys.exu9synu to public; |
这样一来按用户导出数据时，可以跳过同义词部分，继续完成后面的工作。
闽公网安备 35060202000074号