Problems in the impdp process of Oracle under Solaris

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

Solution 1:

Today, when I used IMPDP to import data, I encountered "ORA-39002, ORA-39070 ......" Continuous Error Reporting.
The cause of the problem is very simple, but the content of the error message is "weird". To avoid detours for friends, simply record the problem handling process.

1. Problem Reproduction
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,200 5, 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. Problem Analysis
Here the "ORA-39070" mentioned "Unable to open the log file." at the beginning of the very "strange", in the end can not open any log files? Is there no permission to write files in this directory? This possibility was ruled out by the "touch" test.
In any case, this issue is related to file operations. Following this idea, we finally found that the directory to which the directory database object in the original database directs is "/oradata/dpump_dir", and this directory is not in the operating system, because the directory does not exist, the log file is naturally nowhere to be written.

However, this error message is not obvious enough. It would be better to provide more checks and clear error messages.

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. troubleshooting
After the problem is found, the solution is much simpler. You only need to re-create the directory database object.
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. potential causes of the problem
In a 10g environment, this command can be created normally even if the referenced directory does not exist during the creation of directory database objects. This is the root cause of misoperations.
Sys @ ora10g> create directory dpump_dir_test as '/sec/ool/er ';

Directory created.

Be careful about traps.

5. Summary

The cause of the problem is very simple, but the content of the error message is "weird". To avoid detours for friends, simply record the problem handling process.

1. Problem Reproduction
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,200 5, 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. Problem Analysis
Here the "ORA-39070" mentioned "Unable to open the log file." at the beginning of the very "strange", in the end can not open any log files? Is there no permission to write files in this directory? This possibility was ruled out by the "touch" test.
In any case, this issue is related to file operations. Following this idea, we finally found that the directory to which the directory database object in the original database directs is "/oradata/dpump_dir", and this directory is not in the operating system, because the directory does not exist, the log file is naturally nowhere to be written.

However, this error message is not obvious enough. It would be better to provide more checks and clear error messages.

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. troubleshooting
After the problem is found, the solution is much simpler. You only need to re-create the directory database object.
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. potential causes of the problem
In a 10g environment, this command can be created normally even if the referenced directory does not exist during the creation of directory database objects. This is the root cause of misoperations.
Sys @ ora10g> create directory dpump_dir_test as '/sec/ool/er ';

Directory created.

Be careful about traps.

5. Summary

We can see from the process of handling this problem that we are often helpless when the error information is false. The more in this scenario, the more calm we should be, the more we will troubleshoot from the source of the entire operation step by step.

Solution 2:

Grant permissions to the path specified by directory after logging on with an oracle user

Chown oracle/data_bak and then chmod grant permissions to folders and files respectively

Error 2:
ORA-31688: Worker process failed during startup.

Generally, when modifying the character set, we will set the two processes parameters to 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; -- the default value of this parameter is 0.
Alter database open;
# Alter database character set INTERNAL_USE ZHS16GBK;

Run the startup command to restart the instance.

The imppd is successfully executed.