Home » RDBMS Server » Server Utilities » Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX (Oracle 10.2.0.3)
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505037] Thu, 28 April 2011 22:17 Go to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
Hi,

I am importing the dump.All the tables are getting imported but when it comes to the part as shown in the error it gets struck there and nothing is showed after.what would be the problem and why is it getting struck there.
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX 


Please advice . The dumps for which I am doing the import is huge. Its around 46 GB.

I ran below sql

select
sl.sid,
sl.serial#,
sl.sofar,
sl.totalwork
from
v$session_longops sl,
v$session s,
dba_datapump_sessions d
where
s.saddr = d.saddr
and s.sid = sl.sid
and s.serial# = sl.serial#
order by start_time;

It showing the lock for two sid's. Should I kill the process and import the dump again?

I used below command to import dums

impdp sys/*****@dbname directory=dump_dir dumpfile=prod_dump_%U_200311 SCHEMAS=int_aaa int_bbb int_ccc int_ddd int_eee int_fff
int_ggg int_hhh int_iii int_jjj int_kkk
 int_lll

Regards
Ved

[Updated on: Thu, 28 April 2011 22:32]

Report message to a moderator

Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505041 is a reply to message #505037] Thu, 28 April 2011 22:40 Go to previous messageGo to next message
BlackSwan
Messages: 22688
Registered: January 2009
Senior Member
>It showing the lock for two sid's
The views being queried have nothing to do with locks.

Why do you post SQL & not actual results?

why "@dbname" in connect string?
clarify what system names, OS name & version involved with this problem set
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505042 is a reply to message #505041] Thu, 28 April 2011 22:56 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
why "@dbname" in connect string?
The above is a sample code. It's the connection string.

The OS is Unix Solaris, kernel version 5.10-2006.06

The sql I posted is returning two records for sid's



Regards
Ved
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505043 is a reply to message #505042] Thu, 28 April 2011 23:01 Go to previous messageGo to next message
BlackSwan
Messages: 22688
Registered: January 2009
Senior Member
>The above is a sample code
below is sample answer.
I don't see anything wrong.
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505044 is a reply to message #505043] Thu, 28 April 2011 23:12 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
Quote:

I am importing the dump.All the tables are getting imported but when it comes to the part as shown in the error it gets struck there and nothing is showed after.what would be the problem and why is it getting struck there.

Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX

Blackswan,
when I said that was a sample code, and when I said It struck in processing does it matter to provide the orginal connect string name???



Regards
Ved
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505045 is a reply to message #505037] Thu, 28 April 2011 23:20 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
Can it be a disk space problem? I can see the free space as 4.3 M when I used df -u

Regards
Ved
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505052 is a reply to message #505045] Fri, 29 April 2011 00:51 Go to previous messageGo to next message
Michel Cadot
Messages: 58857
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
It just creates the index and this takes time.

By the way, after 900+ posts, you still don't know where you should post a question? DataPump is Server Utility, just read the subtitle of each topic if you are not sure.

Regards
Michel

Edit Typo By ROD

[Updated on: Fri, 29 April 2011 13:30] by Moderator

Report message to a moderator

Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505129 is a reply to message #505045] Fri, 29 April 2011 11:17 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
Quote:

Can it be a disk space problem? I can see the free space as 4.3 M when I used df -u

I solved my problem.I believe.It happened due to space problem.I did free up some space (around 50 gb). I ran the import again and it took 4 hrs to complete. Replying thinking it might help others.

Regards,
Ved
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505147 is a reply to message #505129] Fri, 29 April 2011 11:42 Go to previous messageGo to next message
Michel Cadot
Messages: 58857
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
By default, DataPump is a suspend-enable job with a time-out of 1800 seconds.
That means that, if there is a space error, it will wait for 1/2 hour that you solved it.

Regards
Michel
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505196 is a reply to message #505147] Sat, 30 April 2011 02:44 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
It was showing processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX for 12 hrs!


Regards
Ved
Re: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX [message #505203 is a reply to message #505196] Sat, 30 April 2011 05:25 Go to previous message
Michel Cadot
Messages: 58857
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
show parameter resumable_timeout

Regards
Michel
Previous Topic: ORA-39125,ORA-31600 during expdp
Next Topic: issue with import
Goto Forum:
  


Current Time: Fri Aug 22 01:10:49 CDT 2014

Total time taken to generate the page: 0.12197 seconds