Re: "Import succeded with warnings" and ERRORS!?

"Lionel Mandrake" <nobody_at_nospam.nowhere.nohow> wrote:

>You can easily get a "dump" of what the import file contains by specifying
>indexfile=<filename> on the imp command line. The indexfile you specify
>will contain the sql statements that imp would run if you had just imported
>the file. Specifying indexfile causes the file to not be imported.

That's a good hint, although it contradicts in my view the general assessment of import as a "very easy tool to use".

>The source database has the packages for replication (the repcat messages
>you received) plus others given the existence of MDSYS and CTXSYS.

As I understand, if CTXSYS exists in the exporting DB, then the InterMedia option was installed there, but that does not mean that this user or related objects are necessary used. On the target DB, there is no InterMedia option installed. As I don't know any details about the internal structures of the DB I am importing (nor am I supposed to know), this raises a question for me whether I should install this option prior to importint the dump. As for MDSYS, I dont't know anything about that user. Neither existed in the target DB.

>Did you specify full=y?

At import time, yes. The database is supposed to be a 1:1 duplication of another one.

>I would not recommed dropping the system user.

OK

Thanks

Rick
>"Rick Denoire" <100.17706_at_germanynet.de> wrote in message
>news:8tb1ttoqj477n56pfmembms29555t71kvi_at_4ax.com...
>> Hello
>>
>> I got a full dump file from another company and imported it into our
>> development DB (8.1.7, Solaris). I did this my first time and it did
>> not work at my first try since the objects in the target DB are
>> populated, and we need an exact copy of the DB which produced the dump
>> file. Just using IGNORE=Y is not enough for our needs. The dump
>> corresponds to a newer, more experimental version of the DB than the
>> one contained at the target.
>>
>> I could have created a new, empty instance but the tablespaces are
>> needed too because otherwise the import will fail if the paths of the
>> DB files differ (they probably do). So I dropped cascade all users but
>> SYS and SYSTEM in the target DB and did the import. But I got hundreds
>> of errors along a final notice that "the import succeded with
>> warnings". Now I am quite confused.
>>
>> First of all, I was warned that the exporting and importing user do
>> not match (I imported as user / as sysdba).
>>
>> Then lots of errors occured because users MDSYS and CTXSYS weren't
>> found. Well, I thought there were supposed to be created!!
>>
>> It seems that constraints are violated, views or roles or users do not
>> exists (weren't they supposed to be created?). Perhaps I should have
>> dropped the SYSTEM user too, not sure.
>>
>> I never thought that achieving the right conditions for an import
>> would be so hard. Of course, I could have created the tablespaces on a
>> new instance, but how the hell I know which tablespaces are going to
>> be needed, and how they were created in the originating DB?
>>
>> What is the standard procedure in order to import a dump file when the
>> paths of the datafiles on the origin and on the target differ?
>> (Because if they didn't, I could use a clean instance).
>>
Received on Sat Oct 20 2001 - 04:31:54 CDT