,问题描述：在导入一个用户数据的时候，大小为14G左右，导进来的时候卡半天，后来发现是表空间满了，已经恢复了大概6G左右，剩下8G左右没有恢复。此时磁盘剩余19G，加了15G的表空间，磁盘就剩下4G左右，但是因为前台终止数据泵进程，大量的归档还在产生，给空间占满，差点宕掉
1.impdp "'/ as sysdba'" directory=DATA_PUMP_DIR dumpfile=ecc_cfs20200824.dmp REMAP_TABLESPACE=ECC_CFS:THOUSEPP REMAP_SCHEMA=ecc_cfs:ecc_cfs_20200824 logfile=20200824.logfile
数据泵进行用户数据恢复，恢复的时候卡半天，查看表空间可使用率为0
2.这边前台停掉了数据泵进程，添加表空间，alter tablespace THOUSEPP add datafile '/oracle/oradata/thousepp/thousepp08.dbf' size 15G; 现在表空间可还是用率为18%
3.磁盘空间一查看一直在增长，直到根目录下剩余4.2M才停止，后来才知道是因为前台停止数据泵进程，后台还在运行的。
4.数据库日志也开始报错，无法归档，怕在晚一会数据库就进不去而且挂掉。因为归档时开启的，数据量大的导入导出会产生大量的归档，所以磁盘空间减少的很快
5.万幸数据库还能进去，要不然就很麻烦了，查看正在运行的datapump进程后台停止数据泵进程，停掉相应的job_name
SQL> select * from dba_datapump_jobs;
6.impdp "'/ as sysdba'" attach=SYS_IMPORT_FULL_01 停掉相应的job，此时ps -ef 数据泵进程已经不存在了，只能后台停止。但是发现数据泵交互界面进不去，估计是没有磁盘空间可分配了。也是一直hang住
7.清理了一些小文件也不行，万幸这个是个测试库， 手动清理了一些归档，进入了交互界面给job停掉
8.腾出来足够的空间，重新导入之前存在的用户直接覆盖掉，将已经导入的表trcuncate掉，数据量稍大，这里truncate应该会比直接replace快
impdp "'/ as sysdba'" directory=DATA_PUMP_DIR dumpfile=ecc_cfs20200824.dmp REMAP_TABLESPACE=ECC_CFS:THOUSEPP REMAP_SCHEMA=ecc_cfs:ecc_cfs_20200824 logfile=20200824.logfile table_exists_action=truncate
所以以后如果开启归档进行数据泵导出操作，一定要留够足够的空间，而且检查做任何操作之前应该先进行全面的环境检查，像这种情况只能后期加磁盘，或者测试库给归档关掉