数据泵: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

 

 

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

posted @   我爱睡莲  阅读(952)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· DeepSeek在M芯片Mac上本地化部署
点击右上角即可分享
微信分享提示