Data Pump Client Gets UDE-8 ORA-31626 ORA-39086 (文档 ID 549781.1)

我的解决办法: 换个目录,重新导出,或者重启数据库。

 


Data Pump Client Gets UDE-8 ORA-31626 ORA-39086 (文档 ID 549781.1)


In this Document


 


Symptoms


 


Cause


 


Solution


 


References

 

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.2 to 11.2.0.3 [Release 10.2 to 11.2]
Information in this document applies to any platform.
*** Checked for relevance on 03-FEB-2014 ***

SYMPTOMS

DataPump import or export from the client side completes with errors.

Example:

expdp system/password@inst full=y dumpfile=full_exp.dmp logfile=full_explog

In 10g, you may see errors such as:

UDE-00008: operation generated ORACLE error 31626 
ORA-31626: job does not exist 
ORA-39086: cannot retrieve job information 
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2745 
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3712 
ORA-06512: at line 1

Similar behavior is also seen in 11g:

UDI-31626: operation generated ORACLE error 31626
ORA-31626: job does not exist
ORA-39086: cannot retrieve job information
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2862
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4052
ORA-06512: at line 1

However, reviewing the log file shows that the "job successfully completed"

CAUSE

This issue has been discussed in 
Bug 5969934 - EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK

SOLUTION

The data pump client makes calls to DBMS_DATAPUMP package to start and monitor the job. Once the export/import job is underway, the client just monitors the job status by issuing DBMS_DATAPUMP.GET_STATUS. Therefore, if the logfile says "job successfully completed", the dump file generated by the job should be fine.

You can simply ignore the errors, since the dump file is still valid for an import.

In the 10.2.0.2 release, there were a number of problems that caused the expdp and impdp clients to exit prematurely, interpreting a nonfatal error as a fatal one, giving the appearance that the job had failed when it hadn't. In fact, inspection of the log file, if one was specified for the job, showed that the job ran successfully to completion. Often a trace file written by one of the Data Pump processes would provide more detail on the error that had been misinterpreted as a fatal one. Many of these errors involved the queues used for communication between the Data Pump processes, but there were other issues as well. 

With each subsequent release, these problems have been addressed, and the client has become more robust and rarely, if ever, runs into situations like this. However, this is the result of many bug fixes in subsequent releases, some in Data Pump and some in supporting layers. It's impossible to know, at this point, what combination of bug fixes would address this specific failure, and even if that was possible, it wouldn't address other possible failures that look very similar on the client side.

Given the above, there is no actual fixed provided via Bug 5969934.
However, Bug 5969934 also mentions another case that resulted in this error that is being tracked separately in Bug 17966375 and for which a generic patch is available for 11.2.0.3.

REFERENCES

BUG:5969934 - EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK
BUG:17966375 - SUCCESSFUL EXPDP JOB SHOWS UDE-31626 AND ORA-31626 IN CLIENT OUTPUT (CRON)

  

时间: 2024-10-25 10:17:57

Data Pump Client Gets UDE-8 ORA-31626 ORA-39086 (文档 ID 549781.1)的相关文章

【MOS】Redundant Interconnect ora.cluster_interconnect.haip (文档 ID 1210883.1)

                                    <>                                                                                                                                                                                  >                             

使用隐含Trace参数诊断Oracle Data Pump(expdp)故障

使用隐含Trace参数诊断Oracle Data Pump(expdp)故障  Data Pump数据泵是Oracle从10g开始推出的,用于取代传统exp/imp工具的数据备份还原组件.经过若干版本的演进和修改,Data Pump已经非常成熟,逐渐被越来越多的DBA和运维人员接受.   相对于传统的exp/imp,Data Pump有很多优势,也变得更加复杂.数据泵一个最显著的特点就是Server-Side运行.Exp/Imp是运行在客户端上面的小工具,虽然使用方便,但是需要处理数据源端和目标

Data Pump简介

1.数据泵的工作流程如下: (1)在命令行执行命令 (2)expdp/impd 命令调用DBMS_DATAPUMP PL/SQL包. 这个API提供高速的导出导入功能. (3)当data 移动的时候, Data Pump 会自动选择direct path 或者external table mechanism 或者 两种结合的方式. 当metadata(对象定义)  移动的 时候,Data Pump会使用DBMS_METADATA PL/SQL包. Metadata API 将metadata(对

Oracle Data Pump详解(5) 命令交互模式

当我们起了一个datapump job之后,可以通过v$session_longops查看当前进度. USERNAME - job owner OPNAME - job name TARGET_DESC - job operation SOFAR - megabytes transferred thus far during the job TOTALWORK - estimated number of megabytes in the job UNITS - megabytes (MB) ME

Oracle Data Pump详解(4) network_link

expdp的network_link 我们知道,expdp默认是导出本地数据库,network_link的作用是导出远程数据库到本地服务器上, 其步骤如下: 术语说明: 源数据库:远程数据库 目标数据库:本地数据库(即expdp客户端所在的服务器) 1. 在目标数据库端添加源数据库的连接字符串至tnsnames.ora: source_db = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.

oracle data pump步骤

oracle oracle data pump步骤          2004/08/27这两天在试ora10g的data pump,将执行的步骤贴出来大家看看由于我的试验的数据库数据不是很多,所以data pump的速度上的优势并不明显,但是备份的文件大小可比exp出来的大不少. -----LisaLan 20040825 oracle data pump----创建目录$ mkdir /home/oracle/backup/data/expdp ----用system登陆为用户赋权限SQL>

Oracle 10G的Data Pump (Part I)

oracle Oracle 10G的Data Pump (Part I) 作者: Fenng出处: Http://www.DBAnotes.net Oracle 10G的Data Pump技术能够在不同数据库间高速的移动数据库和元数据. 这个技术的基础是两个数据移动工具:Data Pump Export和Data Pump Import. Oracle的Data Pump是通过一个PL/SQL包来实现的:DBMS_DataPump(也叫Data Pump API).Data Pump使用直接路径

用Oracle 10g Data Pump重组表空间

Oracle 10g版本对数据输入与输出的操作功能进行重新设计,在输入或输出工作中增加断开和连接的功能.对这些功能做微小改动,就可利于DBA表空间的操作. 作为整体单元输出表空间 过去的输出和输入功能有3种模式:依赖于对象输出,如索引的单个表格:输出某个用户所有的对象:输出整个数据库.但是表空间是一个难于处理的问题.不同用户的对象存储在给定的表空间中,但是某些对象可能存储在其它表空间. 因此,唯一的解决方法则是使用查询数据字典查找列表及其从属主,然后使用"table-mode export&qu

Oracle Data Pump详解(1) 总览

从10g开始,Oracle提供更高效的Data Pump(即expdp/impdp)来进行数据的导入和导出,老的 exp/imp还可以用,但已经不建议使用.注意:expdp/impdp和exp/imp之间互不兼容,也就是说exp导出 的文件只能用imp导入,expdp导出的文件只能用impdp导入. Data Pump的组成部分 Data Pump有以下三个部分组成: 客户端工具:expdp/impdp Data Pump API (即DBMS_DATAPUMP) Metadata API(即