数据泵:impdp导入用户ORA-01653

,问题描述:在导入一个用户数据的时候,大小为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

 

 

所以以后如果开启归档进行数据泵导出操作,一定要留够足够的空间,而且检查做任何操作之前应该先进行全面的环境检查,像这种情况只能后期加磁盘,或者测试库给归档关掉

相关文章

文章浏览阅读773次,点赞6次,收藏9次。【代码】c# json字符...
文章浏览阅读8.7k次,点赞2次,收藏17次。此现象一般定位到远...
文章浏览阅读2.8k次。mysql脚本转化为oracle脚本_mysql建表语...
文章浏览阅读2.2k次。cx_Oracle报错:cx_Oracle DatabaseErr...
文章浏览阅读1.1k次,点赞38次,收藏35次。本文深入探讨了Or...
文章浏览阅读1.5k次。默认自动收集统计信息的时间为晚上10点...