I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
find it extremely slow. However. Most of the waiting time is during
metadata (see below) where it waits for several hours. When it starts
exporting the rows, it progresses reasonably fast.
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/DOMAIN_INDEX/
INDEX
I have seen some threads on Metalink as well as on Google. All otf
tem point to these problems in Oracle 10.2 expdp version, but I see
same problem in Oracle 11.1.0.7.1 as well. A suggestion to exclude
STAITISTICS has not helped me:
expdp system/password directory=expdp_dir dumpfile=$BackupExportFile
logfile=$TLOGFILE \
full=Y compression=all exclude=STATISTICS TRACE=480300
I have turned on expdp tracing and I see statements like following for
various indexes and do not give me any clue to speed things up.
KUPW:14:48:25.668: 1: Base Process info: 6122 and processing status: C
and processing state: R
KUPW:14:48:25.668: 1: new state: R
KUPW:14:48:25.668: 1: new status: C
KUPW:14:48:25.668: 1: In procedure BUILD_SUBNAME_LIST with
INDEX:MAXDEMO71.CONTRACT_NDX2
KUPW:14:48:25.669: 1: In function NEXT_PO_NUMBER
KUPW:14:48:25.669: 1: FORALL called.
KUPW:14:48:25.676: 1: FORALL returned.
KUPW:14:48:25.678: 1: DBMS_LOB.TRIM called. v_md_xml_clob
KUPW:14:48:25.679: 1: DBMS_LOB.TRIM returned.
KUPW:14:48:25.679: 1: DBMS_METADATA.FETCH_XML_CLOB called. Handle:
200001
Is ether anyway to speed expdp.
|
|
0
|
|
|
|
Reply
|
zigzagdna
|
4/4/2010 7:01:19 PM |
|
Try if adding this parameter helps: VERSION=10.2.0.2 (you may need to remove compression parameter since it's not supported in 10.2).
You can also try excluding index statistics exclude=index_statistics
|
|
1
|
|
|
|
Reply
|
javor
|
4/4/2010 7:30:11 PM
|
|
On Apr 4, 3:30=A0pm, javor <u...@compgroups.net/> wrote:
> Try if adding this parameter helps: VERSION=3D10.2.0.2 (you may need to r=
emove compression parameter since it's not supported in 10.2).
> You can also try excluding index statistics exclude=3Dindex_statistics
>
> ---
> frmsrcurl:http://compgroups.net/comp.databases.oracle.server/expdp-is-pai=
nfully...
I cannot reduce version because I am using some partitioing fetaures
which are only in 11.1.
Problem seems to be doiman index (seraching on google). Does not look
like Oracle has fixe dthis problem/bug in 11.1 even though problem was
reported back in 10.x.
|
|
0
|
|
|
|
Reply
|
zigzagdna
|
4/4/2010 9:10:54 PM
|
|
There are multiple bugs related to datapump performance in 11.1. There are patches for some of them.
* Look at Metalink Note 984167.1
* You can also try PSU 11.1.0.7.2 (it may have some related bugs fixed)
|
|
0
|
|
|
|
Reply
|
javor
|
4/4/2010 9:49:29 PM
|
|
On Apr 4, 3:01=A0pm, zigzagdna <zigzag...@yahoo.com> wrote:
snip
> I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
HPUX 11.0 and 11.1.0.7.1 ? Is that even possible?
|
|
0
|
|
|
|
Reply
|
John
|
4/5/2010 2:59:30 PM
|
|
On Apr 5, 10:59=A0am, John Hurley <hurleyjo...@yahoo.com> wrote:
> On Apr 4, 3:01=A0pm, zigzagdna <zigzag...@yahoo.com> wrote:
>
> snip
>
> > I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
>
> HPUX 11.0 and 11.1.0.7.1 ? =A0Is that even possible?
Sorry , I HP UNIX 11 for itanium 64 (11.23)
|
|
0
|
|
|
|
Reply
|
zigzagdna
|
4/5/2010 11:23:08 PM
|
|
On Apr 5, 5:01=A0am, zigzagdna <zigzag...@yahoo.com> wrote:
> I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
> find it extremely slow. However. Most of the waiting time is during
> metadata (see below) where it waits for several hours. When it starts
> exporting the rows, it progresses reasonably fast.
> Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/DOMAIN_INDEX/
> INDEX
> I have seen some threads on Metalink as well as on =A0Google. All otf
> tem point to these problems in Oracle 10.2 expdp version, but I see
> same problem in Oracle 11.1.0.7.1 as well. A suggestion =A0to exclude
> STAITISTICS has not helped me:
> expdp system/password =A0directory=3Dexpdp_dir dumpfile=3D$BackupExportFi=
le
> logfile=3D$TLOGFILE \
> full=3DY compression=3Dall =A0exclude=3DSTATISTICS TRACE=3D480300
> I have turned on expdp tracing and I see statements like following for
> various indexes and do not give me any clue to speed things up.
> KUPW:14:48:25.668: 1: Base Process info: 6122 and processing status: C
> and processing state: R
> KUPW:14:48:25.668: 1: new state: R
> KUPW:14:48:25.668: 1: new status: C
> KUPW:14:48:25.668: 1: In procedure BUILD_SUBNAME_LIST with
> INDEX:MAXDEMO71.CONTRACT_NDX2
> KUPW:14:48:25.669: 1: In function NEXT_PO_NUMBER
> KUPW:14:48:25.669: 1: FORALL called.
> KUPW:14:48:25.676: 1: FORALL returned.
> KUPW:14:48:25.678: 1: DBMS_LOB.TRIM called. v_md_xml_clob
> KUPW:14:48:25.679: 1: DBMS_LOB.TRIM returned.
> KUPW:14:48:25.679: 1: DBMS_METADATA.FETCH_XML_CLOB called. Handle:
> 200001
>
> Is ether anyway to speed expdp.
About 3 to 4 years ago I experienced the same problem with 10g. I
narrowed down the problem to the export of the users. I had about
120,000 users in the DBA_USERS table (PeopleSoft database) and so
during testing at one stage I dropped all the users and ran expdp
again and it ran much quicker.
Anyway, that was from memory so I hope I have recalled it properly.
|
|
0
|
|
|
|
Reply
|
DG
|
4/6/2010 6:53:28 AM
|
|
On Apr 6, 2:53=A0am, DG problem <skatef...@gmail.com> wrote:
> On Apr 5, 5:01=A0am, zigzagdna <zigzag...@yahoo.com> wrote:
>
>
>
>
>
> > I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
> > find it extremely slow. However. Most of the waiting time is during
> > metadata (see below) where it waits for several hours. When it starts
> > exporting the rows, it progresses reasonably fast.
> > Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/DOMAIN_INDEX/
> > INDEX
> > I have seen some threads on Metalink as well as on =A0Google. All otf
> > tem point to these problems in Oracle 10.2 expdp version, but I see
> > same problem in Oracle 11.1.0.7.1 as well. A suggestion =A0to exclude
> > STAITISTICS has not helped me:
> > expdp system/password =A0directory=3Dexpdp_dir dumpfile=3D$BackupExport=
File
> > logfile=3D$TLOGFILE \
> > full=3DY compression=3Dall =A0exclude=3DSTATISTICS TRACE=3D480300
> > I have turned on expdp tracing and I see statements like following for
> > various indexes and do not give me any clue to speed things up.
> > KUPW:14:48:25.668: 1: Base Process info: 6122 and processing status: C
> > and processing state: R
> > KUPW:14:48:25.668: 1: new state: R
> > KUPW:14:48:25.668: 1: new status: C
> > KUPW:14:48:25.668: 1: In procedure BUILD_SUBNAME_LIST with
> > INDEX:MAXDEMO71.CONTRACT_NDX2
> > KUPW:14:48:25.669: 1: In function NEXT_PO_NUMBER
> > KUPW:14:48:25.669: 1: FORALL called.
> > KUPW:14:48:25.676: 1: FORALL returned.
> > KUPW:14:48:25.678: 1: DBMS_LOB.TRIM called. v_md_xml_clob
> > KUPW:14:48:25.679: 1: DBMS_LOB.TRIM returned.
> > KUPW:14:48:25.679: 1: DBMS_METADATA.FETCH_XML_CLOB called. Handle:
> > 200001
>
> > Is ether anyway to speed expdp.
>
> About 3 to 4 years ago I experienced the same problem with 10g. I
> narrowed down the problem to the export of the users. I had about
> 120,000 users in the DBA_USERS table (PeopleSoft database) and so
> during testing at one stage I dropped all the users and ran expdp
> again and it ran much quicker.
>
> Anyway, that was from memory so I hope I have recalled it properly.- Hide=
quoted text -
>
> - Show quoted text -
I have narrowed down the problem to domain indexes which get created
because of Oracle text indexes which my application needs.
Unfortunately, I cannot get rid of domain indexes so stuck with it god
knows until when.
I have yet another problem with 11g, cannot create db control most of
the time. Oracle support looked at it and there is a bug about it on
metalink, yet they will not document my problem as a bug and fix it.
|
|
0
|
|
|
|
Reply
|
zigzagdna
|
4/7/2010 12:33:32 AM
|
|
On Apr 6, 5:33=A0pm, zigzagdna <zigzag...@yahoo.com> wrote:
> On Apr 6, 2:53=A0am, DG problem <skatef...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Apr 5, 5:01=A0am, zigzagdna <zigzag...@yahoo.com> wrote:
>
> > > I am using Oracle 11.1.0.7.1 on HP UNIX 11.0. I ma using expdp and
> > > find it extremely slow. However. Most of the waiting time is during
> > > metadata (see below) where it waits for several hours. When it starts
> > > exporting the rows, it progresses reasonably fast.
> > > Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/DOMAIN_INDE=
X/
> > > INDEX
> > > I have seen some threads on Metalink as well as on =A0Google. All otf
> > > tem point to these problems in Oracle 10.2 expdp version, but I see
> > > same problem in Oracle 11.1.0.7.1 as well. A suggestion =A0to exclude
> > > STAITISTICS has not helped me:
> > > expdp system/password =A0directory=3Dexpdp_dir dumpfile=3D$BackupExpo=
rtFile
> > > logfile=3D$TLOGFILE \
> > > full=3DY compression=3Dall =A0exclude=3DSTATISTICS TRACE=3D480300
> > > I have turned on expdp tracing and I see statements like following fo=
r
> > > various indexes and do not give me any clue to speed things up.
> > > KUPW:14:48:25.668: 1: Base Process info: 6122 and processing status: =
C
> > > and processing state: R
> > > KUPW:14:48:25.668: 1: new state: R
> > > KUPW:14:48:25.668: 1: new status: C
> > > KUPW:14:48:25.668: 1: In procedure BUILD_SUBNAME_LIST with
> > > INDEX:MAXDEMO71.CONTRACT_NDX2
> > > KUPW:14:48:25.669: 1: In function NEXT_PO_NUMBER
> > > KUPW:14:48:25.669: 1: FORALL called.
> > > KUPW:14:48:25.676: 1: FORALL returned.
> > > KUPW:14:48:25.678: 1: DBMS_LOB.TRIM called. v_md_xml_clob
> > > KUPW:14:48:25.679: 1: DBMS_LOB.TRIM returned.
> > > KUPW:14:48:25.679: 1: DBMS_METADATA.FETCH_XML_CLOB called. Handle:
> > > 200001
>
> > > Is ether anyway to speed expdp.
>
> > About 3 to 4 years ago I experienced the same problem with 10g. I
> > narrowed down the problem to the export of the users. I had about
> > 120,000 users in the DBA_USERS table (PeopleSoft database) and so
> > during testing at one stage I dropped all the users and ran expdp
> > again and it ran much quicker.
>
> > Anyway, that was from memory so I hope I have recalled it properly.- Hi=
de quoted text -
>
> > - Show quoted text -
>
> I have narrowed down the problem to domain indexes which get created
> because of Oracle text indexes which my application needs.
> Unfortunately, I cannot get rid of domain indexes so stuck with it god
> knows until when.
>
> I have yet another problem with 11g, cannot create db control most of
> the time. Oracle support looked at it and there is a bug about it on
> metalink, yet they will not document my problem as a bug and fix it.
I have a 10g call open (several issues, Itanium hp-ux 11.23), seems to
be difficult because it really is a different product than the db, and
the whole EM support seems based on giving it its own home
environment. So try setting up an environment specific for dbcontrol,
and only start, stop, rebuild, control or modify it in that
environment, and have the same environment for system start and online
(if you have automatic startups). In the 10g case at least, it seems
important to use the built-in version of java, rather than the "or
greater" version the docs say (I'm still questioning support about
this assertion, though it makes sense in this context). In other
words, don't have any references to OS versions of perl or java in
your path, with oracle_home first. I'd be curious as to what perl or
java advocates have to say about that.
jg
--
@home.com is bogus.
hactivism, lose tenure, DoS, TIT, ivory tower, academic freedom:
http://www.signonsandiego.com/news/2010/apr/06/activist-ucsd-professor-faci=
ng-unusual-scrutiny/
|
|
0
|
|
|
|
Reply
|
joel
|
4/7/2010 4:02:36 PM
|
|
On Apr 5, 12:30=A0am, javor <u...@compgroups.net/> wrote:
> Try if adding this parameter helps: VERSION=3D10.2.0.2 (you may need to r=
emove compression parameter since it's not supported in 10.2).
> You can also try excluding index statistics exclude=3Dindex_statistics
>
> ---
> frmsrcurl:http://compgroups.net/comp.databases.oracle.server/expdp-is-pai=
nfully...
Hi,
Don't if you had a chance to check this. It seems its a bug 6460304,
No work arounds.
DATAPUMP EXPORT IS SLOWER THAT EXPORT- 783093.1
Are you using PARALLEL when exporting?
Regards
Sandy
|
|
0
|
|
|
|
Reply
|
sandeep
|
5/13/2010 4:04:16 PM
|
|
|
11 Replies
2623 Views
(page loaded in 0.155 seconds)
|