Re: Import bug

Hi Chuck,

I think that Kapitza makes a key point here by saying that the CURRENT state of the database is the state of the database before the import. The import utility makes changes to this *current* state.

When you claim that "imp cannot be considered 100% reliable to restore a database from a full export" that's a result of the *normal* operation of an import. 100% reliable recoveries is the process of performing recovery commands with valid backups, redo logs and the such. The imp command is simply creating objects that existed in a previous state of the database (or indeed in another database).

Consider why the DBA set a quota of 0 to a user, what was the reason or motivation (space issues, security issues, management issues, etc.) Does it logically make sense for the DBA to override that decision when performing an import. Not really. And if it does, then it logically would make sense for the DBA to increase the quota during the duration of the import (and reset if considered necessary).

Consider the scenario where the export was performed on one database and the import is to be performed on another (quite a reasonable scenario). Does it makes sense to override a quota limit on the second database just because the first database had no such limit. Again not really when you consider the possible motives of having a 0 quota for the user on the second database.

In summary, this most definitely is *not* a bug, but the reasonable and expected behaviour of a utility who's function to recreate objects in a database (where applicable) and not necessarily to 100% guarantee a database recovery (although note the simple workarounds to the specific issue you've raised).

Keep smiling !!

Regards

Richard

"s.kapitza" <skapitza_at_volcanomail.com> wrote in message news:26703915.0206281248.71a59d80_at_posting.google.com...
> hi chuck,
>
> the user has currently no right to create tables in the
> database (he had once, but someone decided to revoke)
> so the import dont want create objects as this is
> the CURRENT state in the database.
> If the user could create tables with import he could
> create any table with exporting and importing.
>
> If Imp is invoked by the DBA and imp should ignore
> the qota then this means that the DBA have to know that
> there is a rule which he overrides. For people like me
> its better to get rememberd that there is an operation
> that conflicts with a rule.
>
> if i remberer dumps are called inconsitent, so if you want
> a "copy" of a database you need a cold backup.
>
> just an opinion (mental errors included)
>
> s.k.
>
> "Chuck" <chuckh_at_softhome.net> wrote in message
news:<afhphc$e55en$1_at_ID-85580.news.dfncis.de>...
> > I believe I've just discovered a bug in the import process.Please tell
me if
> > you agree. In the case where a user owns tables but has no quota on any
> > tablespace, you can export that user but when you try to import it the
> > tables will not be created. Even running the import as a DBA user, you
still
> > cannot import the the tables.
> >
> > I discovered this the hard way. I imported an export file to recreate a
> > database. Everything worked fone except for that one user.
Received on Sun Jun 30 2002 - 04:53:34 CDT