Thursday, July 24, 2008

ORA-39001 When executing Export DataPump on RAC

While I was performing a data pump test export from one of the demo accounts a very weired error showed up. I have looked for it at the web, metalink, forums, and it seems to be the first case.

Scenario
A simple expdp proces trying to export whatever data shows up this:

-bash-3.00$ expdp sh/sh dumpfile=shSchema directory='default_dp_dest' schemas=sh
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31641: unable to create dump file "/home/oracle/default_dp_dest/shSchema.dmp"
ORA-27041: unable to open file
Linux Error: 22: Invalid argument
Additional information: 2


I have already made some expdp testing, and it has worked, the only difference during this testing is that it was made on a RAC environment.

When taking a look at the background dump dest trace files I found this:

-bash-3.00$ more rdbkdi1_dm00_31645.trc
/u01/app/admin/RDBKDI/bdump/rdbkdi1_dm00_31645.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: eg6886
Release:
2.6.16-xenU
Version: #2 SMP Tue Oct 24 16:33:50 CDT 2006
Machine: i686
Instance name: RDBKDI1
Redo thread mounted by this instance: 1
Oracle process number: 39
Unix process pid: 31645, image: oracle@eg6886 (DM00)
*** ACTION NAME:(EXPHR01) 2008-07-24 19:38:22.781
*** MODULE NAME:(Data Pump Master) 2008-07-24 19:38:22.781
*** SERVICE NAME:(SYS$USERS) 2008-07-24 19:38:22.781
*** SESSION ID:(125.291) 2008-07-24 19:38:22.781
kswsdlaqsub: unexpected exception err=604, err2=24010
kswsdlaqsub: unexpected exception err=604, err2=24010


If ever someone finds this error solution or reference to it I'll be thankful to hear about it.

5 comments:

Bradd Piontek said...

Have you tried setting the degree of a parallelism to 1 and trying again? Does the directory you are trying to write to exist on all nodes for this rac database? How do the permissions on the directory look?

Hector R. Madrid said...

Thank you Bradd.

I have created the directories at both RAC instances, and it is the same. The degree of parallelism is 1. Permissions allow r/w for oracle and it can create the logfile at the specified directory.

I think it has to do with the quotes around the directory name in the command, this shouldn't but I will retry the test as soon as I have access to the RAC environment I am currently working with.

Hector R. Madrid said...

After other testing with and without quotes, changing the format to directory:filename, the error is consistent.

A datapump command line written on a rac instance will produce an error on the previously specified environment.

If ever someone is able to reproduce this issue, I would like to hear about it, it could be a non documented bug.

Unknown said...

Hi Hector,

Am wondering if you ever found any solution for this error. Am getting the same error when trying to execute datapump through command line on a RAC instance.

Trace details:
*** ACTION NAME:(SYS_EXPORT_SCHEMA_02) 2010-02-10 11:46:01.446
*** MODULE NAME:(Data Pump Master) 2010-02-10 11:46:01.446
*** SERVICE NAME:(SYS$USERS) 2010-02-10 11:46:01.446
*** SESSION ID:(122.15060) 2010-02-10 11:46:01.446
kswsdlaqsub: unexpected exception err=604, err2=24010
kswsdlaqsub: unexpected exception err=604, err2=24010
* kjdrpkey2hv: called with pkey 662237, options x8
* kjdrpkey2hv: called with pkey 662235, options x8
* kjdrpkey2hv: called with pkey 662236, options x8

Hector R. Madrid said...

this error was from nearly two years back, at that time this was an unpatched 10.2.0.1.0 RAC environment. You should first check if your platform has already been upgraded to the latest patchset available. I have seen this bug in Itanium platforms too, so it could be also a platform specific issue. Check for r/w permissions and verify if this occurs on an NFS mounted device, there are issues when mounting permissions are not properly set.