Re: drop tablespace including contents -- very slow

From: <chrisoc_at_ans.net>
Date: Mon, 24 Jan 2000 21:05:29 GMT
Message-ID: <86ieql$1it$1@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.
>
> I tried "drop tablespace raw_tabsp including contents" and
> was surprised to see the command still running after 30 minutes.
> It is almost 2 GB in size.
> I didn't think that this operation would use RBSes.
> What could be taking so much time?
>
> Chris O'Connor
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Jan 24 2000 - 15:05:29 CST