Re: Import bug

The reason I think IMP is a special case is documented already in this thread. I will restate it in this branch of the thread in case you are missing those posts and leave it at that. This thread has been dragged on too long already. I am apparently the only one who thinks it's a bug (more accurately a design flaw) and furthermore, thinks that IMP is a special case.

A full import is already treated as a special case by Oracle in order to be able to restore an entire database. My argument on this is that it does things that you normally can't do even as a DBA. It allows a DBA doing a full import to grant permissions on tables he does not own. You can don't do that under normal circumstances. That would be a violation of the security model. But during a full import it happens because it has to if you want to restore the entire database to the same state as when the export occurred. My feeling is that tablespace quotas ought to be treated the same way.

That said. Let's let this thread die. I've gotten enough abuse and grief from others on this. Apparently there are a few self appointed moderators in this NG that don't believe you're allowed to defend yourself when insulted.

--
Chuck

"Norman Dunbar" <Norman.Dunbar_at_lfs.co.uk> wrote in message
news:E2F6A70FE45242488C865C3BC1245DA7024D7F3D_at_lnewton.leeds.lfs.co.uk...


> Morning all,

>

> I've been lurking on this one, and have surfaced now to point out

> something that no-one else has done yet (I hope - I seem to be missing

> some postings in this NG - firewall troubles again ?)

>

> Chuck things that Import is a 'special case' - why ?

> He thinks that running it as a DBA user should impart special privs -

> again, why ?

> Check out a dmp file and one of the commands in it is CONNECT

> <user_bieng_imported>

> followed by a load of create table, insert into table, create index,

> alter table add constraint commands. All of which are run as the user

> being imported.

>

> Therefore, it follows, that if the user being imported has no quota,

> then it cannot do any of the above.

>

> Cheers,

> Norman.

>

> PS. If you really want to do a restore procedure that makes the new

> database identical to the old one, exp/imp do a LOGICAL copy and not a

> physical copy. Use a cold backup/restore instead.

>

> -------------------------------------

> Norman Dunbar

> Database/Unix administrator

> Lynx Financial Systems Ltd.

> mailto:Norman.Dunbar_at_LFS.co.uk

> Tel: 0113 289 6265

> Fax: 0113 289 3146

> URL: http://www.Lynx-FS.com

> -------------------------------------

>