Re: Space problems using version 7.0.16 imp, exp

In article <garyt.792392220_at_lgc.com> garyt_at_lgc.com (Gary Thompson) writes:
>I'm seeing something unusual with with the importer in Oracle 7.0.16
>that I hadn't seen previously with version 7.0.13. I've been able to
>duplicate it while running 7.0.16 on SunOS 4.1.x, Solaris 2.3 & 2.4,
>and AIX 3.2.5p.
>
>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 to create a tablespace more than 2x as large
>as the data held in it, significantly larger than than I otherwise would
>have.
>
>This never seemed to happen using version 7.0.13 and also doesn't happen
>when using 7.0.13 dump files and the 7.0.16 importer (I noticed the 7.0.13
>exp didn't generate explicit index storage parameters in it's dump files).
>
>This is causing us quite a bit of grief. If anyone can shed some light on
>this, I'd be most grateful.

These are temporary tables created by the RDBMS to store information while it does various operations, incl, CREATE UNIQUE INDEX, DISTINCT, ORDER BY and stuff like that.

The most usual thing to do is to create a tablespace purely for these temporary segments, ie, TEMP.

This is necessary for Financials, and I'd suggest a possible TEMP tablespace size of 50-100M depending on how large your site is.

Hope this helps....

>Sincerely,
>
> Gary Thompson
 

-- 
Alligator Descartes	| 
descarte_at_mcqueen.com	|