expdp操作无效无法打开日志文件

早上九点，作无志文DBA老周盯着终端里滚动的效无报错信息，骂了句粗口。法打他执行了一夜的开日expdp导出任务，日志文件显示“ORA-39002: 操作无效”，作无志文紧接着是效无“ORA-39070: 无法打开日志文件”。这活儿他干了十年，法打头一回遇到这么邪门的开日事——导出进程明明启动了，参数文件也没写错，作无志文可日志就是效无写不进去。

老周先查了目录权限。法打`SELECT * FROM dba_directories;` 结果显示`DATA_PUMP_DIR`指向`/u01/app/oracle/admin/orcl/dpdump/`。开日他`ls -ld`一看，作无志文权限是效无`drwxr-x---`，属主是法打`oracle:oinstall`。没问题啊。他又试着手动往那个目录里`touch test.log`，居然成功了。那问题出在哪？

他重新检查expdp命令行，发现了一个被忽略的细节——他用了`PARALLEL=4`，但日志文件名写的是`export_%U.log`。这个`%U`通配符在并行模式下会生成多个日志分片，但问题是，他同时用了`LOGFILE=export.log`这种固定名称。两种写法混在一起，Oracle直接懵了，报出“操作无效”。这属于典型的参数自相矛盾。

更隐蔽的坑还在后面。他去掉`%U`，改成固定日志名，重新跑。这回报错变成了“ORA-39002”后面跟着“ORA-29283: 无效的文件操作”。老周眉头一皱，觉得事情不简单。他检查了`/u01/app/oracle/admin/orcl/dpdump/`所在文件系统的挂载选项——`mount | grep dpdump`。结果发现这目录挂在一个NFS共享上，而且挂载参数里没有`rw`选项，只有`ro`。也就是说，数据库进程以为自己在写文件，但操作系统层面直接拒绝了写入动作。日志文件打不开的原因就这么简单——文件系统只读。

但为什么`touch test.log`能成功？因为老周是用`oracle`系统用户执行的，走的是本地shell路径，而NFS的只读限制只对数据库的服务器进程生效。数据库进程以`oracle`用户身份通过NFS客户端访问，但NFS导出端的权限配置不同。这解释了为什么手动测试一切正常，expdp却死活写不进日志。

处理办法也直白——把dump目录挪到本地文件系统，或者重新挂载NFS加上`rw`选项。老周选择后者，改了`/etc/fstab`，重新`mount -o remount,rw`，再跑expdp，日志刷刷地写出来了。

这事儿给咱们的教训不是权限检查不够仔细，而是别被表面现象骗了。手动测试成功不代表数据库进程也能成功，因为进程上下文、挂载点、NFS导出权限都可能不同。遇到“无法打开日志文件”，先别急着改目录权限，先查文件系统挂载状态，再检查expdp参数里有没有混用通配符和固定名称。这两个坑，占了八成以上的案例。

老周后来在工位上贴了张便签：“日志打不开，先看mount，再看参数。”简单粗暴，但管用。