Import into a new table space is BROKEN!

From: David Taylor <drt_at_brolga.cc.uq.oz.au>
Date: Tue, 15 Sep 1992 07:33:22 GMT
Message-ID: <drt.716542402_at_brolga>


I am having a problem with some undocumented features of import.

The export file came from version 6somethingorother on a VAX. It was a straight user export.
I want to import the tables under a different username on a DOS box also running version 6somethingorother.

I created a special tablespace for the data (~200M) on a new disk. I created a user and granted resource access to the table space. I made the new table space the default for this user.

When I run import it appears to work, but it creates the tables in the SYSTEM table space, and falls over eventually because there isn't enough space there. The manual clearly states that it should load into the default table space for this user. It even gives an example of how to use this feature to transfer stuff between table spaces.

As a test I created a table from sqlplus and it went in the new tablespace just fine, by default.

OK. I'll fix it. Lets revoke all access to the system table space for this user and try again. Didn't work. Fills the system table space again.

Tricky little feature that one. Lets try creating a table in the system table space for this user and fill it with junk. Works fine. Hmmm. Drop that table. Grant 1k of quota space in system to the user. Create table. Fill it with 3k of stuff. Commit. Interesting...

The dba_ts_quotas view shows some strange numbers. The manual says NULL means unlimited quota but we actually have -1024 bytes. Doesn't seem to matter anyway, 'cause if we grant 0 bytes it still lets us have as much as we want.

Oh well, so quotas are meaningless. Lets get back to the import problem.

Run import again _interactively_ as the new user, and load the tables from the old user. Again, fills the system table space.

Run it using _command line_ parameters, as the new user, and load the tables from the old user:
ERROR: must be dba to import objects to another user's account. Huh?!?? I just did it _interactively_ and I wasn't dba.

Run it as dba. Again fills the system table space.

My observations:
I immediatly suspect that I set up the table space/username incorrectly, but from sqlplus everything works as it should.

So maybe import has some features. SOmeone must have found them by now. Is there a way around it?

The strange ignorance of quotas is disturbing. If the work around involves giving the user a 0 quota on SYSTEM then I'm stuck, because it appears to be meaningless.

Can anyone shed some light? Received on Tue Sep 15 1992 - 09:33:22 CEST

Original text of this message