dbTalk Databases Forums  

xpdp via network_link fails when specifying parallel

comp.databases.oracle.server comp.databases.oracle.server


Discuss xpdp via network_link fails when specifying parallel in the comp.databases.oracle.server forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Jesper Wolf Jespersen
 
Posts: n/a

Default xpdp via network_link fails when specifying parallel - 08-03-2010 , 07:20 AM






Hello All.

I am using Oracle 10.2.0.3 enterprise edition on Windows 2003 R2 X64
edition.

When I perform Datapump exports via a database link and parallel > 1 my
worker threads die.

The error message is: KUP-04038: internal error: kupax-meta1

It seems like its always worker thread 2 that dies, but even though the
other threads seem to continue I do not trust the export being performed.

When using only one single worker thread there is no problem.

The command line is like this:
----
expdp system/manager@dbs NETWORK_LINK=P34T_SYSTEM schemas=(panda,ecom)
directory=DATA_PUMP_DIR dumpfile=exp%u.dmp logfile=PandaExport.log
parallel=%EXP_PARALLEL% parfile=exp.par
----

The parfile tries to recreate the consistent=y of the old export
utility, the content is this:

----
FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY -MM-DD
HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')"
----

I haven been able to find any information on this behaviour on the net.

I have used the same command line but without the network_link
parameter to good effect, and parallel processing realy speeds up the
export.

But since I need to move data between servers I would need to copy all
the files from one server to the next after the export, which is a task
that is hard to automate eficiently, since the driving site is a third
node in the network.

In one setup we tried using dual hosted disks, one node can write and
the other can read. No problem for the SAN but Windows does not expect
an NTFS file system to change on its own, so we have to unmount and
remount the drive on node 2 after the export on node 1 before I can
start the import on node 2.
Also a task which is hard to automate.

Have any of you had similar experiences and what did you do ?

Greetings from Denmark
Jesper Wolf Jespersen

Reply With Quote
  #2  
Old   
John Hurley
 
Posts: n/a

Default Re: xpdp via network_link fails when specifying parallel - 08-03-2010 , 07:25 AM






On Aug 3, 8:20*am, Jesper Wolf Jespersen
<jes... (AT) remove (DOT) oz8ace.dk.remove.this> wrote:
Quote:
Hello All.

I am using Oracle 10.2.0.3 enterprise edition on Windows 2003 R2 X64
edition.

When I perform Datapump exports via a database link and parallel > 1 my
worker threads die.

The error message is: KUP-04038: internal error: kupax-meta1

It seems like its always worker thread 2 that dies, but even though the
other threads seem to continue I do not trust the export being performed.

When using only one single worker thread there is no problem.

The command line is like this:
----
expdp system/manager@dbs NETWORK_LINK=P34T_SYSTEM * schemas=(panda,ecom)
directory=DATA_PUMP_DIR dumpfile=exp%u.dmp logfile=PandaExport.log
parallel=%EXP_PARALLEL% parfile=exp.par
----

The parfile tries to recreate the consistent=y of the old export
utility, the content is this:

----
FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY -MM-DD
HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')"
----

I haven been able to find any information on this behaviour on the net.

I have used the same command line but without the network_link
parameter to good effect, and parallel processing realy speeds up the
export.

But since I need to move data between servers I would need to copy all
the files from one server to the next after the export, which is a task
that is hard to automate eficiently, since the driving site is a third
node in the network.

In one setup we tried using dual hosted disks, one node can write and
the other can read. No problem for the SAN but Windows does not expect
an NTFS file system to change on its own, so we have to unmount and
remount the drive on node 2 after the export on node 1 before I can
start the import on node 2.
Also a task which is hard to automate.

Have any of you had similar experiences and what did you do ?

Greetings from Denmark
Jesper Wolf Jespersen
Any specific reason you are sitting back on 10.2.0.3 when 10.2.0.5
should be available?

Shot in the dark guess is that you are running into a bug fixed
already.

Reply With Quote
  #3  
Old   
Mark D Powell
 
Posts: n/a

Default Re: xpdp via network_link fails when specifying parallel - 08-03-2010 , 08:30 AM



On Aug 3, 8:25*am, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:
Quote:
On Aug 3, 8:20*am, Jesper Wolf Jespersen





jes... (AT) remove (DOT) oz8ace.dk.remove.this> wrote:
Hello All.

I am using Oracle 10.2.0.3 enterprise edition on Windows 2003 R2 X64
edition.

When I perform Datapump exports via a database link and parallel > 1 my
worker threads die.

The error message is: KUP-04038: internal error: kupax-meta1

It seems like its always worker thread 2 that dies, but even though the
other threads seem to continue I do not trust the export being performed.

When using only one single worker thread there is no problem.

The command line is like this:
----
expdp system/manager@dbs NETWORK_LINK=P34T_SYSTEM * schemas=(panda,ecom)
directory=DATA_PUMP_DIR dumpfile=exp%u.dmp logfile=PandaExport.log
parallel=%EXP_PARALLEL% parfile=exp.par
----

The parfile tries to recreate the consistent=y of the old export
utility, the content is this:

----
FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY -MM-DD
HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')"
----

I haven been able to find any information on this behaviour on the net.

I have used the same command line but without the network_link
parameter to good effect, and parallel processing realy speeds up the
export.

But since I need to move data between servers I would need to copy all
the files from one server to the next after the export, which is a task
that is hard to automate eficiently, since the driving site is a third
node in the network.

In one setup we tried using dual hosted disks, one node can write and
the other can read. No problem for the SAN but Windows does not expect
an NTFS file system to change on its own, so we have to unmount and
remount the drive on node 2 after the export on node 1 before I can
start the import on node 2.
Also a task which is hard to automate.

Have any of you had similar experiences and what did you do ?

Greetings from Denmark
Jesper Wolf Jespersen

Any specific reason you are sitting back on 10.2.0.3 when 10.2.0.5
should be available?

Shot in the dark guess is that you are running into a bug fixed
already.- Hide quoted text -

- Show quoted text -
I think this is the issue covered by the following Oracle support
note:

Bug 5972794 - EXPDP via network_link with parallel > 1 fails with
KUP-4038 #5972794.8

The fix is listed as being in 10.2.0.4 on Unix but on windows patch 9
for 10.2.0.3 has the fix.

For now I would try parallel=1

HTH -- Mark D Powell --

Reply With Quote
  #4  
Old   
Jesper Wolf Jespersen
 
Posts: n/a

Default Re: xpdp via network_link fails when specifying parallel - 08-04-2010 , 02:53 AM



Hello Mark.

Quote:
I think this is the issue covered by the following Oracle support
note:

Bug 5972794 - EXPDP via network_link with parallel > 1 fails with
KUP-4038 #5972794.8

The fix is listed as being in 10.2.0.4 on Unix but on windows patch 9
for 10.2.0.3 has the fix.
Thank you for the information, I did forget to check metalink :-)

Quote:
For now I would try parallel=1
I have been using that, but I will try and patch one Oracle instance up with
the Patch 9 patchset to see if it has any advers effects :-)

The Oracle version i work on is not of my choosing, I would love to work on
the bleeding edge.
Unfortunately I have to do what I am told :-)

Greetings from Denmark
Jesper Wolf Jespersen

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.