Re: xpdp via network_link fails when specifying parallel
From: John Hurley <hurleyjohnb_at_yahoo.com>
Date: Tue, 3 Aug 2010 05:25:42 -0700 (PDT)
Message-ID: <864b1a09-4dd0-4ed9-9c92-455f09f8ca5a_at_y11g2000yqm.googlegroups.com>
On Aug 3, 8:20 am, Jesper Wolf Jespersen <jes..._at_remove.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_at_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
Date: Tue, 3 Aug 2010 05:25:42 -0700 (PDT)
Message-ID: <864b1a09-4dd0-4ed9-9c92-455f09f8ca5a_at_y11g2000yqm.googlegroups.com>
On Aug 3, 8:20 am, Jesper Wolf Jespersen <jes..._at_remove.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_at_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. Received on Tue Aug 03 2010 - 07:25:42 CDT