ORA-39002: invalid operation

ORA-39070: Unable to open the log file.

ORA-29283: invalid file operation

ORA-06512: at "SYS.UTL_FILE", line 475

ORA-29283: invalid file operation

wKiom1OWc5Hx3gZRAAHKFIUvzoc087.jpg

解决方法参考1：


今天在使用IMPDP完成数据导入的过程中遇到“ORA-39002、ORA-39070……”连续报错。

导致问题原因很简单，但是提示的错误信息内容比较“诡异”，为了朋友们少走弯路，简单记录一下这个问题的处理过程。


1.问题再现

sec@secDB /db_backup/dpump_dir$ impdp sec/sec directory=dpump_dir dumpfile=20100604020437_sec.dmp logfile=impdp.log


Import: Release 10.2.0.3.0 - 64bit Production on Friday, 04 June, 2010 14:39:16


Copyright (c) 2003, 2005, Oracle.  All rights reserved.


Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

ORA-39002: invalid operation

ORA-39070: Unable to open the log file.

ORA-29283: invalid file operation

ORA-06512: at "SYS.UTL_FILE", line 475

ORA-29283: invalid file operation


2.问题分析

这里的“ORA-39070”提到的“Unable to open the log file.”初看非常的“诡异”，到底无法打开什么日志文件呢？难道是没有权限在这个目录下写文件？经过“touch”测试排除了这种可能***。

不管怎么说，这个问题与文件操作相关。顺着这个思路继续前行，终于发现原来数据库中的directory数据库对象所指向的目录为“/oradata/dpump_dir”，而在该操作系统中根本没有这个目录，因目录不存在，日志文件也就理所当然的无处可写。


不过这个报错的信息却是不够明显，如果能够给出更多的检查和明确的报错信息就更好了。


sys@ora10g> col owner for a6

sys@ora10g> col DIRECTORY_NAME for a20

sys@ora10g> col DIRECTORY_PATH for a30

sys@ora10g> select * from dba_directories where DIRECTORY_NAME = 'DPUMP_DIR';


OWNER  DIRECTORY_NAME      DIRECTORY_PATH

------ -------------------- ------------------------------

SYS    DPUMP_DIR            /oradata/dpump_dir


3.问题处理

发现问题后，处理方法就简单了许多，只需要重新创建directory数据库对象即可。

sys@sec> drop directory dpump_dir;


Directory dropped.


sys@sec> create directory dpump_dir as '/db_backup/dpump_dir';


Directory created.


sys@sec> grant read, write on directory dpump_dir to public;


Grant succeeded.


4.导致该问题的潜在原因

在10g环境中即使在创建directory数据库对象的过程中即使所引用的目录不存在，该命令也是可以正常创建的，这就是容易误操作的根本原因。

sys@ora10g> create directory dpump_dir_test as '/sec/ool/er';


Directory created.


小心陷阱。


5.小结



导致问题原因很简单，但是提示的错误信息内容比较“诡异”，为了朋友们少走弯路，简单记录一下这个问题的处理过程。


1.问题再现

sec@secDB /db_backup/dpump_dir$ impdp sec/sec directory=dpump_dir dumpfile=20100604020437_sec.dmp logfile=impdp.log


Import: Release 10.2.0.3.0 - 64bit Production on Friday, 04 June, 2010 14:39:16


Copyright (c) 2003, 2005, Oracle.  All rights reserved.


Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

ORA-39002: invalid operation

ORA-39070: Unable to open the log file.

ORA-29283: invalid file operation

ORA-06512: at "SYS.UTL_FILE", line 475

ORA-29283: invalid file operation


2.问题分析

这里的“ORA-39070”提到的“Unable to open the log file.”初看非常的“诡异”，到底无法打开什么日志文件呢？难道是没有权限在这个目录下写文件？经过“touch”测试排除了这种可能***。

不管怎么说，这个问题与文件操作相关。顺着这个思路继续前行，终于发现原来数据库中的directory数据库对象所指向的目录为“/oradata/dpump_dir”，而在该操作系统中根本没有这个目录，因目录不存在，日志文件也就理所当然的无处可写。


不过这个报错的信息却是不够明显，如果能够给出更多的检查和明确的报错信息就更好了。


sys@ora10g> col owner for a6

sys@ora10g> col DIRECTORY_NAME for a20

sys@ora10g> col DIRECTORY_PATH for a30

sys@ora10g> select * from dba_directories where DIRECTORY_NAME = 'DPUMP_DIR';


OWNER  DIRECTORY_NAME      DIRECTORY_PATH

------ -------------------- ------------------------------

SYS    DPUMP_DIR            /oradata/dpump_dir


3.问题处理

发现问题后，处理方法就简单了许多，只需要重新创建directory数据库对象即可。

sys@sec> drop directory dpump_dir;


Directory dropped.


sys@sec> create directory dpump_dir as '/db_backup/dpump_dir';


Directory created.


sys@sec> grant read, write on directory dpump_dir to public;


Grant succeeded.


4.导致该问题的潜在原因

在10g环境中即使在创建directory数据库对象的过程中即使所引用的目录不存在，该命令也是可以正常创建的，这就是容易误操作的根本原因。

sys@ora10g> create directory dpump_dir_test as '/sec/ool/er';


Directory created.


小心陷阱。


5.小结


从该问题的处理过程中我们可以看到，在报错信息不实很明显的时候我们往往手足无措。越是在这样的场景，我们越应该沉着冷静，从整个操作的源头一步一步的去排查，终有柳暗花明之时。


解决方法参考2：


 用 oracle  用户登录后 把 directory  指定的路径 赋予权限


chown oracle /data_bak然后再chmod 分别给文件夹 及文件赋予权限


错误二：

ORA-31688: Worker process failed during startup.


一般我们在修改字符集时，会把两个processes参数设置为0。

shutdown immediate;

STARTUP MOUNT;

ALTER SESSION SET SQL_TRACE=TRUE;

ALTER SYSTEM ENABLE RESTRICTED SESSION;

ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;  

ALTER SYSTEM SET AQ_TM_PROCESSES=0;  --这个参数默认就是0

ALTER DATABASE OPEN;

#ALTER  DATABASE  CHARACTER  SET  INTERNAL_USE  ZHS16GBK;


配置好 重启 用 startup 命令启动


然后执行 imppd 成功