Re: imp-exp tools

Just to amplify on David's reply:

You have clearly changed the name of one or more tablespaces in moving from Oracle 8.0.3 to 8.1.6. The import will expect to import an owner's objects into the same tablespace as exported. In fact, it will cope with a missing tablespace name but by using the owner's default tablespace in the target database. If there is not enough space for this, then you will have problems.

You have several solutions. One is to adopt David's suggestion (and, if you have to do this frequently, it is possible to script it.) Another is to create additional tablespaces with the same name as the source database. This might be easier, so long as you have enough space on the disk.

Oh, and are you sure to to-user both exists and has adequate rights for the import?

Len

>Hello Everyone,
>
>In our business - software developper - we have to deal with data from
>all of our clients. Consequently we decided long ago to work with many
>tablespaces on the same server and many users by tablespace. So every
>tablespace logically represent a set of client.
>
>Recently, we upgrade our Oracle server from version 8.0.3 to version
>8.1.6.
>
>Since then, we have a problem using the imp-exp tools.
>
>Before the upgrade, we were able to copy all the objects from a users
>schema residing on one tablespace to another user residing on another
>tablespace on the same server. Here is an exemple:
>
>exp.exe system/manager owner=user_a file=x.dmp log=y.log direct=y
>consistent=y
>
>imp.exe system/manager fromuser=user_a touser=user_b file=x.dmp
>log=z.log commit=y
>
>We always did that with exp-imp tools using the fromuser and touser
>parametrers and it always worked.
>
>Since the upgrade, we ancounter the imp-00015 error when we are doing
>that kind of move. Oracle says to us that the default behavior of those
>tools was to try to copy the data to the same tablespace as it was
>extract with exp and that those tools are not intended for this kind of
>move. They almost didn't believe us that we were able to do that on our
>old server (but, of course, they didn't want to try to reproduce it).
>
>So, I would like to know if you have to deal with this kind of situation
>and how you proceed to do that?
>
>Any suggestions?
>
>Thank's a lot,
>
>Carl
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
  Received on Sat Nov 18 2000 - 11:57:00 CST