Oracle 數(shù)據(jù)庫使用的時間越長，操作數(shù)據(jù)庫的人越多，可能會碰到一些非法數(shù)據(jù)庫對象引起的錯誤。 例如： 按用戶 eXP 時會報錯(oracle10G) . exporting synonymsEXP-00008: ORACLE error 3113 encounteredORA-03113: end-of-file on communication channelEXP-00000: Export terminated unsUCcessfullyORACLE8i 里面的的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, SYNOBJNOFROM SYS.EXU9SYNU ORDER　BY SYNTIME;我的經(jīng)驗是這些數(shù)據(jù)庫的用戶下很可能有非法數(shù)據(jù)庫對象。刪除不合法的數(shù)據(jù)對象，就可以了。一般情況下生成當前用戶下重編譯非法數(shù)據(jù)庫對象的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掉后，依據(jù)它創(chuàng)建的同義詞就變得不能訪問了。 原始的表重建以后，同義詞仍然不可以訪問。 但在user_objects里面的status狀態(tài)是'VALID'，卻不是'INVALID'。 這需要我們把它們找出來，運行查詢同義詞表結(jié)構(gòu)的語句: spool /tmp/1.sql;select 'desc 'synonym_name';' from user_synonyms;spool off;@/tmp/1.sql;出錯的同義詞, 一定要先徹底刪除掉，再重建創(chuàng)建同義詞。 　 　drop synonym &synonym_name;create synonym &synonym_name for &owner.&table_name;重編譯后，仍然出錯的數(shù)據(jù)對象，經(jīng)開發(fā)人員同意后，我們還可以選擇drop它們。我還碰到過一次在drop非法數(shù)據(jù)庫對象的時候，不加雙引號之前，提示數(shù)據(jù)對象不存在。一定要在數(shù)據(jù)庫對象加上雙引號就可以刪掉了。(這可能跟創(chuàng)建數(shù)據(jù)對象所用的輔助性工具有關(guān)) 例如： 　 　drop table scott.'emp' cascade constraints;drop trigger scott.'trigger_name';假如所有的非法數(shù)據(jù)對象都沒有了，還會出現(xiàn)上面的錯誤。可能是jvm(java虛擬環(huán)境)的問題。DBMS_JAVA.LONGNAME()過程函數(shù)一執(zhí)行，就會報錯。還有一個解決辦法：重建sys用戶下跟同義詞有關(guān)的視圖，讓它找不到記錄。 drop view EXU9SYNU;create view EXU9SYNU asSELECT　'SYNNAM','SYNNAM2','SYNTAB', 'TABOWN','TABNODE','PUBLIC$','SYNOWN','SYNOWNID','TABOWNID','SYNOBJNO','SYNTIME'FROMsys.exu9syn-- WHERE　 synownid = UID; (原來的視圖創(chuàng)建方法)WHERE　 0=1;grant select on sys.EXU9SYNU to public;這樣一來按用戶導出數(shù)據(jù)時，可以跳過同義詞部分，繼續(xù)完成后面的工作。