home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / oracle / 1584 < prev    next >
Encoding:
Text File  |  1992-09-14  |  2.8 KB  |  70 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!brolga!drt
  3. From: drt@brolga.cc.uq.oz.au (David Taylor)
  4. Subject: Import into a new table space is BROKEN!
  5. Message-ID: <drt.716542402@brolga>
  6. Sender: news@bunyip.cc.uq.oz.au (USENET News System)
  7. Organization: Prentice Centre, University of Queensland
  8. Date: Tue, 15 Sep 1992 07:33:22 GMT
  9. Lines: 59
  10.  
  11.  
  12. I am having a problem with some undocumented features of import.
  13.  
  14. The export file came from version 6somethingorother on a VAX. It was
  15. a straight user export.
  16. I want to import the tables under a different username on a DOS box
  17. also running version 6somethingorother.
  18.  
  19. I created a special tablespace for the data (~200M) on a new disk.
  20. I created a user and granted resource access to the table space.
  21. I made the new table space the default for this user.
  22.  
  23. When I run import it appears to work, but it creates
  24. the tables in the SYSTEM table space, and falls over eventually
  25. because there isn't enough space there. The manual clearly states
  26. that it should load into the default table space for this user.
  27. It even gives an example of how to use this feature to transfer
  28. stuff between table spaces.
  29.  
  30. As a test I created a table from sqlplus and it went in the new
  31. tablespace just fine, by default.
  32.  
  33. OK. I'll fix it. Lets revoke all access to the system table space for
  34. this user and try again. Didn't work. Fills the system table space again.
  35.  
  36. Tricky little feature that one. Lets try creating a table in the
  37. system table space for this user and fill it with junk. Works fine.
  38. Hmmm. Drop that table. Grant 1k of quota space in system to the user.
  39. Create table. Fill it with 3k of stuff. Commit. Interesting...
  40.  
  41. The dba_ts_quotas view shows some strange numbers. The manual says NULL
  42. means unlimited quota but we actually have -1024 bytes. Doesn't seem
  43. to matter anyway, 'cause if we grant 0 bytes it still lets us have
  44. as much as we want.
  45.  
  46. Oh well, so quotas are meaningless. Lets get back to the import problem.
  47.  
  48. Run import again _interactively_ as the new user, and load the tables 
  49. from the old user. Again, fills the system table space.
  50.  
  51. Run it using _command line_ parameters, as the new user, and load the
  52. tables from the old user:
  53. ERROR: must be dba to import objects to another user's account.
  54. Huh?!?? I just did it _interactively_ and I wasn't dba.
  55.  
  56. Run it as dba. Again fills the system table space.
  57.  
  58. My observations:
  59. I immediatly suspect that I set up the table space/username incorrectly,
  60. but from sqlplus everything works as it should.
  61.  
  62. So maybe import has some features. SOmeone must have found them by now.
  63. Is there a way around it?
  64.  
  65. The strange ignorance of quotas is disturbing. If the work around
  66. involves giving the user a 0 quota on SYSTEM then I'm stuck, because
  67. it appears to be meaningless.
  68.  
  69. Can anyone shed some light?
  70.