Re: Space problems using version 7.0.16 imp, exp

From: Ian A. MacGregor <ian_at_tethys.SLAC.Stanford.EDU>
Date: Fri, 10 Feb 1995 22:21:15 GMT
Message-ID: <D3t23F.3pp_at_unixhub.SLAC.Stanford.EDU>


In article <garyt.792392220_at_lgc.com>, garyt_at_lgc.com (Gary Thompson) writes:

[much stuff deleted]  

|> When I import a dump file and specify the same value for TOUSER and
|> FROMUSER, I can periodically check the objects in the tablespace and
|> notice a temporary object that appears to be created as a result of
|> indexing a table. The objects are named <file number>.<block number>,
|> i.e. 8.2205, 8.2292, etc. Once complete, that object is removed
|> (presumably by SMON) and a new one is present for the the table
|> currently being indexed.
|>
|> However, when I import a dump file and specifiy a TOUSER that is
|> different from the FROMUSER, it seems that none of these temporary
|> objects get cleaned up until *long* after the import is complete.
|> The result is that I have

Temporary segments should not be created in tablespaces meant for data or indexes. You need to create a tablespace for these temporary segments, and then use "alter user temporary tablespace <tablespace_name>;" for all your users including sys and system. It's also wise to separate data and index segments, through specifying a tablespace for the index on index creation. Indexes created as a result of primary/unique keys can cause problems on import Oracle wants to create the index in the user's default tablespace. When we need to export and import we, build the index creation scripts from the data dictionary, disable the constraints, drop the indexes, export the data, import the data, build the indexes from the scripts, and re-enable the constraints.

Ian MacGregor
Stanford Linear Accelerator Center
ian_at_slac.stanford.edu Received on Fri Feb 10 1995 - 23:21:15 CET

Original text of this message