ORA-31639报错奇怪数据出现，远程帮忙修复故障的那些事儿

（引用来源：某位资深DBA的论坛技术分享帖）

这事儿说起来还挺有意思的，那天下午，我正闲着摸鱼，想着快下班了，手机突然嗡嗡震起来，是个陌生的号码，接起来一听，那头是个小伙子，声音急得都快冒烟了，说他们的数据库导数据出大问题了，报了个ORA-31639的错误，搞了一下午都没弄好，项目卡住了,眼看就要延误。

我一听ORA-31639，脑子里先过了一遍，这个错误通常跟Oracle的数据泵（Data Pump）工具有关，意思是导出的数据文件已经存在了，解决办法很简单，要么在导出命令里加上个REUSE_DUMPFILES=Y的参数，告诉它覆盖掉原来的文件就行；要么更干脆，手动去服务器上把那个已经存在的文件删了再重新导，我心里还嘀咕,这问题不是挺基础的嘛。

我就跟他说：“你别急，先看看你指定的那个导出文件目录下，是不是已经有一个同名的文件了？有的话删掉，或者你改个文件名试试。”

过了一会儿，他更沮丧地回话说：“老师，我看了，目录是空的！啥文件都没有！所以才觉得奇怪啊，明明没有文件，它为啥非说已经存在了呢？我们试过改文件名，甚至换了个完全没使用过的目录，它还是报这个错！真是活见鬼了！”

他这么一说，我也觉得蹊跷了，按常理出牌的问题好解决，这种“不按常理出牌”的才磨人，我让他把完整的报错信息截图发给我看看，图发过来后，我仔细瞅了瞅，错误信息确实是ORA-31639没错,但下面还跟着一些其他的提示。

（引用来源：当时的错误日志截图记忆）

我让他别挂电话，远程连上了他的服务器，首先确认了他执行导出命令的用户权限是足够的，有读写那个目录的权限，这点没问题，我让他带我看一下目录的绝对路径，他一边操作我一边看，突然，我注意到一个细节：他输入的目录路径,用的是小写字母。

我心里一动，有了个猜测，我问他：“你们这个数据库服务器，操作系统是Linux吧？”他说是，我又问：“那你创建这个数据泵目录对象（DIRECTORY）的时候，指定的物理路径，大小写跟你现在输入的是完全一致的吗？”

他愣了一下，说应该是吧，我让他立刻查询一下数据字典视图，看看那个目录对象到底指向了哪个物理路径，命令一执行，结果出来了——问题找到了！果然，他创建目录对象时，手滑把路径里的一个目录名打成了大写，比如本来是‘/home/oracle/export’，他建的时候写成了‘/home/oracle/EXPORT’，而实际上，操作系统里根本不存在这个大写的‘EXPORT’目录，只有小写的‘export’目录。

（引用来源：基于类似案例的通用分析）

这下就真相大白了，Oracle的数据泵在工作时，它认的是目录对象映射的那个物理路径字符串，当你执行导出时，它不会去检查物理路径是否真实存在，而是直接尝试在那个“它认为的”路径下创建文件，虽然操作系统是大小写敏感的，‘/home/oracle/export’和‘/home/oracle/EXPORT’是两个不同的路径，但Oracle的目录对象在记录路径时，会严格记录你创建时输入的样子，当它试图在那个不存在的‘/home/oracle/EXPORT’路径下创建文件时，操作系统当然会返回错误，但这个错误经过Oracle的封装，可能就被解释成了类似“文件操作失败，可能因为已存在”这样的信息，最终以ORA-31639的形式报了出来，这是一种非常隐晦的“指鹿为马”式的报错。

我把这个原因跟他一解释，电话那头的小伙子恍然大悟，连声说“原来是这样！我们光盯着文件存不存在，没想到是路径的‘名字’对不上！” 我指导他要么重新创建一个指向正确小写路径的目录对象，要么干脆在操作系统下建一个和大写路径名匹配的目录，他选择了重建目录对象，几分钟后，他兴奋地告诉我，导出命令顺利开始运行了,进度条哗哗地往前走。

这件事儿给我的印象特别深，很多时候，看起来最奇怪、最不合逻辑的报错，根源往往是一些最不起眼的细节，比如一个字母的大小写、一个不起眼的分隔符，或者一个权限的细微差别，远程帮忙虽然看不到对方的环境，但就像破案一样，需要根据有限的线索，结合经验去大胆假设，然后一步步小心求证，当最终找到那个看似微不足道却又至关重要的“罪魁祸首”时，那种帮人解决问题的成就感，还是挺棒的，那个小伙子最后在电话里千恩万谢，说救了他们的项目,我也觉得这个忙帮得挺值。