通过一个数据字典表dba_external_tables
?select *from dba_external_tables where table_name='ET$00E73C1D0001';
OWNER? ? ? ? ? ? ? ? ? ? ? ? ? TABLE_NAME? ? ? ? ? ? ? ? ? ? TYP TYPE_NAME? ? ? ? ? ? ? ? ? ? ? DEF DEFAULT_DIRECTORY_NAME? ? ? ? REJECT_LIMIT? ? ? ? ? ? ? ? ? ? ? ACCESS_
?------------------------------ ------------------------------ --- ------------------------------ --- ------------------------------ ---------------------------------------- -------
?ACCESS_PARAMETERS? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PROPERTY
?-------------------------------------------------------------------------------- ----------
?SYS? ? ? ? ? ? ? ? ? ? ? ? ? ? ET$00E73C1D0001? ? ? ? ? ? ? ? SYS ORACLE_DATAPUMP? ? ? ? ? ? ? ? SYS IMPDP20130506? ? ? ? ? ? ? ? ? UNLIMITED? ? ? ? ? ? ? ? ? ? ? ? CLOB
?DEBUG = (0 , 0) DATAPUMP INTERNAL TABLE "XXDATA"."CONSUME_LOG_XXXX_BEFORE201201? ALL
可以清晰的看到是在之前做impdp的时候抛出了错误，这个表是Impdp过程中产生的临时表。
?还有一个思路就是在expdp/impdp等操作时，在数据库日志中也会有一定的信息标识，但是尝试查看数据库日志，这个问题是好几年前的了，几年前的alert日志已经被清空了，所以也无法求证在当时问题发生的时候到底是什么样的一个情况。
?解决问题的步骤就很简单了，需要直接删除这个外部表即可。
SQL> drop table "ET$00E73C1D0001";
?Table dropped.
通过这个案例可以看到，对于这些ORA错误还是需要通过日志来一步一步分析，逐个击破，可以大胆猜想，但是要小心求证，问题了解清楚了，解决起来都是很容易的。