Re: Import bug

Chuck wrote:

> "Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
> news:3D1C8ACA.BFB2FB16_at_exesolutions.com...
> > I don't think that is what Tom said at all. And I find your original
> posting
> > logically inconsistent. How exactly does a schema come to have tables in a
> > tablespace in which its quota is zero?
>
> Easy. After tables are created the DBA sets the quota on the tablespace to
> 0? How is that logically inconsistent?
>
> >
> > And what developer, or DBA, could possibly think that they are going to
> violate
> > the security model by building objects in a tablespace for which they have
> no
> > privilege to create anything.
> >
> > The only bug I see here is in not doing reasonable preparation before
> trying the
> > import.
>
> The problem here is an export can be taken of a database, that when imported
> into an empty database will not restore the database to it's original
> condition. I call that a *serious* problem with the import utility.

As someone with 30+ years in the industry I call this a serious problem with your education and your understanding on what constitutes a security policy. Did you get into IT without any formal training in a computer science department or on a UNIX or mainframe system?

In response to your question ... Absolutely not. Quota on one database should under no conditions confer quota on another. Do you also think that DBA privileges on one (say DEV) should confer DBA privs on another (say PROD). If anyone tried to implement rules like this on one of my projects they would quickly get to meet the friendly people at the unemployment office.

And why would anyone set quota to zero on a schema with existing tables? To make sure that no table can possibly grab another extent? Why? If the DBA did it ... it leads me to consider a lot of possibilities. All of which I think are reasonably obvious.

Daniel Morgan Received on Fri Jun 28 2002 - 15:18:39 CDT