关于Oracle数据库中使用DBMS_DATAPUMP包时遇到的ORA-31626: job does not exist和ORA-06512错误,以下是对这些错误的详细分析和解决方案: 错误分析 ORA-31626: job does not exist 这个错误通常表明DataPump作业在数据库中没有找到指定的作业。这可能是因为作业名称错误、作业未正确创建或作业已被删除。 ORA-06512 ...
根据查询出来的对象,我们使用drop table XXX purge 进行逐一删除,也可以通过脚本进行批量删除;待所有的被终止的对象删除之后,再次尝试数据泵导出,惊喜地发现已经可以 正常导出了。 总结 由此可见,此次故障的原因是 dba_datapump_jobs里面的被终止对象太多,我们将其删除后,问题即可得到解决。
查看trace文件,如下截图所示,提示“ksedmp:internal or fatal error" ,搜索了一下metalink,发现还真有一模一样的错误 但是这个案例中,在验证表结构时,发现表不存在,所以必须reload the DataPump utility,reload the DataPump utility候就能正常的导入导出了。 SQL> analyze table kupc$datapump_quetab validate structu...
查看trace文件,如下截图所示,提示“ksedmp:internal or fatal error" ,搜索了一下metalink,发现还真有一模一样的错误 但是这个案例中,在验证表结构时,发现表不存在,所以必须reload the DataPump utility,reload the DataPump utility候就能正常的导入导出了。 SQL> analyze table kupc$datapump_quetab validate structu...
DataPump遭遇ORA-06512&ORA-39080&ORA-01403错误案例 最近使用数据泵(DataPump)比较多,遇到了奇奇怪怪的问题,似乎Apply了补丁PSU 10.2.0.5.180717后,DataPump的问题就格外多。如下所示: expdp system/xxx DIRECTORY=DUMPDIR DUMPFILE=xxxx.dmp TABLES=xxxx.xxxx LOGFILE=expdp.log...
UDE-00008: operation generated ORACLE error 31626 ORA-31626: job does not exist ORA-06512: at "SYS.KUPC$QUE_INT", line 536 ORA-25254: time-out in LISTEN while waiting for a message ORA-06512: at "SYS.DBMS_DATAPUMP", line 2772 ORA-06512: at "SYS.DBMS_DATAPUMP",...
报错信息如下: UDE-31623: operation generatedOracleerror 31623ORA-31623: a job is not attached to this session via the specified handleORA-06512: at "SYS.DBMS_DATAPUMP", line 3263ORA-06512: at "SYS.DBMS_DATAPUMP", line 4488ORA-06512: at line 1 ...
根据查询出来的对象,我们使用drop table XXX purge 进行逐一删除,也可以通过脚本进行批量删除;待所有的被终止的对象删除之后,再次尝试数据泵导出,惊喜地发现已经可以 正常导出了。 总结 由此可见,此次故障的原因是dba_datapump_jobs里面的被终止对象太多,我们将其删除后,问题即可得到解决。
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4551 ORA-06512: at line 1 开始以为是版本的问题,因为源端是10g的库,而目标端是11g的库,但其实只有在exp方式导出的时候可能需要考虑加上version参数导出,expdp是不需要的 然后又想到是不是因为system用户是否对directory没有权限,但对相应的directory加上read,write权限...
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2772 ORA-06512: at "SYS.DBMS_DATAPUMP", line 3886 查了一下说是ORACLE的BUG(客户这边ORACLE使用版本10.2.0.1) 解决办法比较简单,检查了一下告警日志,数据库没有什么异常告警,把库正常停止一下,再启动。