Re: drop tablespace including contents -- very slow

Your problem has nothing to do with 'direct load' as such; it is purely about space manage.

Since you are using 8.1 you should look at locally managed tablespaces - they are
far more forgiving when you make mistakes of this kind.

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

chrisoc_at_ans.net wrote in message <86ieql$1it$1_at_nnrp1.deja.com>...
>I got an explanation from Oracle that is worth sharing.
>It involves the way the table got loaded (direct path).
>The load had failed due to lack of space after 10 million rows.
>I wasn't too worried, since it was just a test table and
>select count(*) showed a big number of rows.
>However, thousands of temp segments were created in that tablespace
>and there was no "commit" . So now SMON is going through the
>data dictionary removing references to that storage before
>the drop of the tablespace can finish. This occurs even though
>I have taken the datafile offline/drop and the tablespace offline.
>The query "select count(*) from dba_extents where segment_type=
>'TEMPORARY' and tablespace_name='RAW_TAB' shows the count coming
>down.
>
>I am falling out of love with direct loading.
>
>Chris O'Connor
>
>
>In article <86i2jv$ngn$1_at_nnrp1.deja.com>,
> chrisoc_at_ans.net wrote:
>>
>>
>> I am running 8.1.5 on Solaris and using raw volumes for some
>> of the tablespaces.
>>
Received on Mon Jan 24 2000 - 16:30:25 CST