有很多DBA朋友在入门时总觉得不得路径，长久的徘徊于门外，而过来人的经验又往往高屋建瓴难以落地，两者总觉得难以对接起来，如何才能解决这个问题呢？
我一直推荐的学习方法，之前在文章 DBA入门之路：学习与进阶之经验谈 中就有描述。如果能讲这些方法和实践一一对应起来，我想就可以更形象的帮助一些朋友。结合今天的一个小案例，和大家做一个分享。
回顾：由点及面由浅入深的学习方案
我一直主张"由点到线再及面"的学习方法。特别是对于初学者，如果没有经过专门的培训和系统学习，那么自己通过实践的学习和思考就应当深入，在知识上，从某个角度来说，是"不患寡，而患不精深"。在我们遇到问题时，就应该不断深入研究，直至问题的核心本质，这样通过一个案例或实际问题的诊断学习和研究，我们就可以带动很多连带知识的学习，这样从一个点深入下去就形成一条线，再横向扩展就可以形成一个知识网，解决和研究的问题多了，就可以逐渐覆盖一个面，形成一个知识体系，这样慢慢的你就会觉得学习不再困难，而是一件得心应手的事情。
案例：Expdp ORA-31626 错误的启示
今天有朋友在‘云和恩墨大讲堂’提出一个关于expdp的导出问题。
操作：
expdp system/password directory=expdir full=y dumpfile=20151230.dmp logfile=20151230.log
错误提示：
UDE-00008: 操作产生了 ORACLE 错误 31626
ORA-31626: 作业不存在
ORA-39086: 无法检索作业信息
ORA-06512: 在 "SYS.DBMS_DATAPUMP", line 2772
ORA-06512: 在 "SYS.DBMS_DATAPUMP", line 3886
ORA-06512: 在 line 1
在面对错误的时候，DBA不能有畏缩的心理，一定要认真阅读错误，对于这个提示，其实可以看到明确的信息“作业不存在”，也就是JOB检测不到了，那么要么这个JOB执行完了，要么异常中止了。
建议：
以下两条是我们给所有初学者的建议，收集信息、保护现场，这是寻求解决和帮助的必要手段。
在面对任何错误时，都应当详细的排查所有可以获得的日志；
在面对复杂问题时，一定要得出结论后再操作，在操作前尽量保留可回退的现场。
其实在获取了充足的信息之后，无论是提问还是自己排查都容易接近真相。
结论：
检查导出操作日志，可以看到导出是完整成功的，我们由此可以判定导出的正常执行，那么前台抛出的错误可以安全的忽略。当然也可以测试一下，判定导出文件是完好的。到这一步判断，是每一个工程师应该自主做出的。
. . 导出了 "SYSTEM"."REPCAT$_USER_ATH"0 KB 0 行
. . 导出了 "SYSTEM"."REPCAT$_USER_PS" 0 KB 0 行
. . 导出了 "SYSTEM"."SQLPLS_T_PROFILE" 0 KB 0 行
. . 导出了 "TSMSYS"."SRS$" 0 KB 0 行
已成功加载/卸载了主表 "SYSTEM"."SYS_EXPORT_FULL_01"
***************************************************************************
SYSTEM.SYS_EXPORT_FULL_01 的转储文件集为:
/oradata/20151230.dmp
作业 "SYSTEM"."SYS_EXPORT_FULL_01" 已于 09:41:33 成功完成
进一步的确认：
通过MOS官网进一步的确认问题，是Oracle DBA的必要技能。在MOS上可以找到这个问题的相关BUG，BUG号是5969934。
Bug 5969934 : EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK
这个BUG的从 10.2.0.2 到 11.2.0.3，都可能发生，其根本原因是JOB的执行和客户端的通讯出现问题。
Oracle Support的提示也包括检查日志：
Relying on information in the log file is one way to verify that the job actually completed successfully.
问题源自：DBMS_DATAPUMP.GET_STAUS 的调用。在以下的MOS回复中，可以看到，执行EXPDP的工作是通过DBMS_DATAPUMP包进行的，其中GET_STAUS用于状态获取。当获取状态时发现JOB进程失踪，就抛出前台的异常，而从日志可以判断，事实上是导出已经完成。如果EXPDP能够争取反馈给客户端完成状态，那么这个问题就不会出现了。
The expdp client makes calls to DBMS_DATAPUMP package to start and monitor export job. Once the export job is underway, the client just monitors the job status by issuing DBMS_DATAPUMP.GET_STAUS. Therefore, if the export 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.
这是一个简单的例子，我们希望大家也能够分析、总结自己遇到的问题，如此即可以分享给大家，又可以提升自我的学习和总结能力。
这个案例，从一个最简单的错误分析猜测，到日志检查判断，进一步确认BUG根源，由此又可以进一步了解EXPDP的工作原理，这就是由浅入深，逐层递进，形成思路和方法。在遇到任何问题时，都可以借鉴这样的过程和方法。
文章转自数据和云公众号，原文链接
