数据泵进程异常处理
a、在使用Oracle Datapump API时应注意如果定义了job_name则任意导致job失败或挂起的情形都将导致以job_name命名的table存在.
b、对于当前失败的job,再次执行时会碰到job(ORA-31634)已经存在的提示,此时应删除对应表名再使用原来的job_name再次实现Datapump.
c、对于出现的故障一般的建议是不要使用自定义的Job_name,由Oracle自动生成Job_name以自动销毁异常的job.
摘要: 今天查看数据库的负载，发现cpu消耗异常的高。里面有不少dw的进程.但是查看impdp的进程却不存在。 查看datapump的进程情况，发现大量的job，但是状态都是not running.
1、 查看CPU情况
iostat -x
2、 查看datapump进程情况
ps -ef|grep impdb
3、 查看datapump的job状态
set pagesize 200;
select OWNER_NAME,JOB_MODE,STATE,job_name from dba_datapump_jobs where owner_name='XXX';
SYS_IMPORT_TABLE_01
SYS_IMPORT_TABLE_02
SYS_IMPORT_TABLE_03
。。。。
说明：
没有impdp的任务，查看用户，发现下面有很多SYS_IMPORT_TABLE_xx的表，ETxxx, ERRxxx的表。
这些表都是datapump在数据导入的时候创建的临时表。
ERR的表类似下面的形式:
ERR$DP13FC20810001
ERR$DP16F10AF10001
ET的表类似下面的形式:
ET$000D0F650001
ET$00C11B410001
4、查看里面的内容也是被禁止的。
SQL> select *from ET$1B5C6DCF0001;
ERROR:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
KUP-11024: This external table can only be accessed from within a Data Pumpjob.
分析：
既然没有对应的impdp的任务来跑，那些session也就是在空跑了。
和同事确认了下，这个测试中的数据任务执行时间太长，就被删除了进程。没想到杀掉impdp的进程，对应的parallel process还是存在，
把一张分区表分成了100份，每一份包含一些分区的数据，这样并行4个，下来就有120个左右的session了，
他们使用的脚本类似下面的形式。
nohup impdp xxxx/xxxx directory=memo_dir dumpfile=par1_xxxxxxxx.dmp parallel=2 include=table_data logfile=par1_xxxxxxxx_impdp.log parfile=xxxxxxxx_partition_parallel_1.par_impdp TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS &
nohup impdp xxxx/xxxx directory=memo_dir dumpfile=par2_xxxxxxxx.dmp parallel=2 include=table_data logfile=par2_xxxxxxxx_impdp.log parfile=xxxxxxxx_partition_parallel_2.par_impdp TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS &
nohup impdp xxxx/xxxx directory=memo_dir dumpfile=par3_xxxxxxxx.dmp parallel=2 include=table_data logfile=par3_xxxxxxxx_impdp.log parfile=xxxxxxxx_partition_parallel_3.par_impdp TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS &
nohup impdp xxxx/xxxx directory=memo_dir dumpfile=par4_xxxxxxxx.dmp parallel=2 include=table_data logfile=par4_xxxxxxxx_impdp.log parfile=xxxxxxxx_partition_parallel_4.par_impdp TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS &
nohup impdp xxxx/xxxx directory=memo_dir dumpfile=par5_xxxxxxxx.dmp parallel=2 include=table_data logfile=par5_xxxxxxxx_impdp.log parfile=xxxxxxxx_partition_parallel_5.par_impdp TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS &
确认了下，准备删除session。可以使用如下的sql来查找对应的session，确认后删除。
select 'alter system kill session '||chr(39)||sid||','||serial#||chr(39) ||';' from v$session where username='MIG_TEST';
5、尝试
5.1、尝试使用attach来手工停掉job.但是对应的process还是没有停掉。
Import> stop
Are you sure you wish to stop this job ([yes]/no): yes
5.2、 尝试使用kiill选项，直接hang住了。
但是查看主机的cpu消耗，还是异常的高。对应的并行session对应的进程还是在，而且消耗了大量的资源。
5.3.1、先尝试删除由dba_datapump_jobs查出来的临时表，
SQL> drop table GOEX_WEBUSER."Go_Data_Dumping_Job" ; -->删除该临时表名，不加purge，有问题就闪回
Table dropped.
5.3.2、 最后尝试删除对应的et,err,export临时表。删除后，对应的dw process就消失了。
drop table "ET$1C125B790001";
drop table SYS_IMPORT_TABLE_21
说明：
几种ET的表是作为中间的数据缓存表，而ERR的表则是完全基于oracle的新版本特性，启用了错误日志。
有了这些信息也就明白，datapump在数据有冲突的情况下是怎么缓存那些信息的。这些信息都被放入了ERR的表中。
et$xx表为系统在逻辑导入导出过程中产生的临时表，可以通过dba_external_tables查看。(这点有待验证)
strace -c -p 进程号 （监视进程是否活跃）
重新连接数据泵进程
node1-> expdp \'sys/oracle as sysdba\' ATTACH=sys.SYS_EXPORT_FULL_01