Re: Import bug

In article <afidu3$e3id5$1_at_ID-85580.news.dfncis.de>, "Chuck" says...
>
>
>"Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
>news:3D1C8C6A.8E0DD5FC_at_exesolutions.com...
>
>>
>> I am continuing to read your postings with absolute amazement.
>>
>> You seem to think that your desire to violate Oracle's security model is a
>bug.
>>
>
>No I think that it's reasonable to expect an import to restore the database
>to them same condition as when the export was taken? Don't you?
>
>> Quotas on tablespaces exist for a reason. They exist to keep people from
>taking
>> space that has not been allocated to them.
>>
>> If the space hasn't been allocated to you ... the reasonable thing to do
>would
>> be to increase your allocation. If you can not then either you are trying
>to do
>> something not approved by the DBA responsible for the system (my guess) or
>you
>> believe that the security model should be compromised by people too lazy
>to go
>> in with DBA privileges and enter a single line of SQL at the command
>prompt.
>>
>> Daniel Morgan
>>
>
>You missing the point.Under normal database operation I would agree. But a
>full database import is not normal operation. It's used to copy or restore a
>database. You would expect that if you do a full export of a database, drop
>all non-system users, and then import that export file, that you would have
>the same database you started with. In this case it does not. That is a flaw
>in the design of the import program. If a DBA is doing a full import it
>should not take into account tablespace quotas.
>
>

it would be a trivial way to get around quota's no? (yes, it would). But then again, if I'm a DBA the solution is rather trivial -- alter the user, correct the problem.

DMP files are not a good or practical way to restore your database. That be what backups are all about.

--
Thomas Kyte (tkyte@oracle.com)             http://asktom.oracle.com/ 
Expert one on one Oracle, programming techniques and solutions for Oracle.
http://www.amazon.com/exec/obidos/ASIN/1861004826/  
Opinions are mine and do not necessarily reflect those of Oracle Corp