Re: Temp. segments/extents not being dropped

From: Chuck Hamilton <chuck_hamilton_at_yahoo.com>
Date: Thu, 8 Jun 2000 06:07:08 -0700 (PDT)
Message-Id: <10522.108206@fatcity.com>

--0-1804289383-960469628=:9170

Content-Type: text/plain; charset=us-ascii

Yes, it's the contents column. You do have it defined correctly as temporary. I must've read the original post wrong and thought you were referring to multiple segments (not extents) within the temporary tablespsace. The only way that happens is if the tablespace is defined as 'permanent', not 'temporary'.

What probably happened to you is that you had several queries using up all of the space in the temp tablespace. If you anticipate this continuing to happen you mught want to consider one or more the following...

Increase the size of the temp tablespace. Rewrite/hint some of the SQL that's doing sort/merges to use another join method (hash join, or nested loops). Increase the sort_area_size parameter. This will cause fewer sorts to use the temp tablespace and sort in memory instead. It may even convert some of your sort/merge joins to much faster hash joins.

Dan.Hubler_at_midata.com wrote:

I don't understand your statement
"Sounds like your temporary tablespace was defined to contain permanent objects."

Here is the definition from the dictionary:

1* select * from sys.dba_tablespaces where tablespace_name like 'TEMP%' SQL> / TABLESPACE_NAME INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
------------------------------ -------------- ----------- ----------- ----------- ------------
STATUS CONTENTS
--------- ---------

TEMP2 20480 2097152 1 249 0
ONLINE TEMPORARY SQL> Is the "contents" definition what you were referring to?

Thanks.

Chuck Hamilton @fatcity.com on 06/06/2000 09:43:39 AM

Please respond to ORACLE-L_at_fatcity.com

Sent by: root_at_fatcity.com

Sent From the mail file of: Dan Hubler

To: Multiple recipients of list ORACLE-L cc:

Subject: Re: Temp. segments/extents not being dropped

Sounds like your temporary tablespace was defined to contain permanent objects. That should be changed. You should clean up the temporary segments and then do an "alter tablespace temp temporary;" on it to make it perform better. To clean up the temp segments currently out there you can try a couple of things. One is to offline the tablespace, then bring it back online. If that doesn't work you may have to boucne the database.

Once you've done this, you'll notice the tablespace will contain one segment that occasionally grows. This is normal. Space inside the temp tablespace, space is managed apart from the dictionary to reduce extent managment overhead.

Dan.Hubler_at_midata.com wrote:

Looking for some information on the following:

We had an incident last week where an Oracle instance (7.3.4.4) on NT was running into problems acquiring space for additional extents on the defined temporary tablespace.

While looking at the situation, we discovered that there was just about zero
free space left in the tablespace. There was a whole bunch of extents created and owned by "SYS" and they had some flaky numeric identifier for the segment-name (something like 37.123).

Other processes were failing, being unable to allocate temp space.

We looked around on Metalink, and discovered a note about forcing temporary segments/extents to be cleaned up by performing an "ALTER TABLESPACE TEMP DEFAULT STORAGE (PCTINCREASE 0);"

We executed the statement. Lo and behold, all the segments disappeared, back into
free space.
! !
My guess is that there was a large sort (we do some of those) that failed, and left segments out there. I do not understand why they wouldn't clean up.

Any information?

--

Author:
INET: Dan.Hubler_at_midata.com

Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).

Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!

Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
--0-1804289383-960469628=:9170

Content-Type: text/html; charset=us-ascii

<P> Yes, it's the contents column. You do have it defined correctly as temporary. I must've read the original post wrong and thought you were referring to multiple segments (not extents) within the temporary tablespsace. The only way that happens is if the tablespace is defined as 'permanent', not 'temporary'.</P>
<P>What probably happened to you is that you had several queries using up all of the space in the temp tablespace. If you anticipate this continuing to happen you mught want to consider one or more the following...</P>
<OL>
<LI>Increase the size of the temp tablespace.</LI>
<LI>Rewrite/hint some of the SQL that's doing sort/merges to use another join method (hash join, or nested loops).</LI>
<LI>Increase the sort_area_size parameter. This will cause fewer sorts to use the temp tablespace and sort in memory instead. It may even convert some of your sort/merge joins to much faster hash joins.</LI></OL>
<P>&nbsp;<BR><B><I>Dan.Hubler_at_midata.com</I></B> wrote: <BR></P>
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR><BR><BR>I don't understand your statement<BR>"Sounds like your temporary tablespace was defined to contain permanent<BR>objects."<BR><BR>Here is the definition from the dictionary:<BR><BR>1* select * from sys.dba_tablespaces where tablespace_name like 'TEMP%'<BR>SQL&gt; /<BR><BR>TABLESPACE_NAME INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE<BR>------------------------------ -------------- ----------- ----------- ----------- ------------<BR>STATUS CONTENTS<BR>--------- ---------<BR>TEMP2 20480 2097152 1 249 0<BR>ONLINE TEMPORARY<BR><BR><BR>SQL&gt;<BR><BR><BR>Is the "contents" definition what you were referring to?<BR><BR>Thanks.<BR><BR><BR><BR><BR><BR><BR><BR>Chuck Hamilton <CHUCK_HAMILTON_at_YAHOO.COM>@fatcity.com on 06/06/2000<BR>09:43:39 AM<BR><BR>Please respond to ORACLE-L_at_fatcity.com<BR><BR>Sent by: root_at_fatcity.com<BR><BR><BR>Sent From the mail file of: Dan Hubler<BR>!
<BR><BR>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_FATCITY.COM><BR>cc:<BR><BR>Subject: Re: Temp. segments/extents not being dropped<BR><BR><BR><BR><BR>Sounds like your temporary tablespace was defined to contain permanent<BR>objects. That should be changed. You should clean up the temporary segments<BR>and then do an "alter tablespace temp temporary;" on it to make it perform<BR>better. To clean up the temp segments currently out there you can try a<BR>couple of things. One is to offline the tablespace, then bring it back<BR>online. If that doesn't work you may have to boucne the database.<BR><BR>Once you've done this, you'll notice the tablespace will contain one<BR>segment that occasionally grows. This is normal. Space inside the temp<BR>tablespace, space is managed apart from the dictionary to reduce extent<BR>managment overhead.<BR><BR><BR>Dan.Hubler_at_midata.com wrote:<BR><BR><BR>Looking for some information on the following:<BR><BR>We had an incident last week wher!

e an Oracle instance (7.3.4.4) on NT was running into problems acquiring space for additional extents on the defined temporary tablespace. While looking at the situation, we discovered that there was just about zero free space left in the tablespace. There was a whole bunch of extents created and owned by "SYS" and they had some flaky numeric identifier for the segment-name (something like 37.123). Other processes were failing, being unable to allocate temp space. We looked around on Metalink, and discovered a note about forcing temporary segments/extents to be cleaned up by performing an "ALTER TABLESPACE TEMP DEFAULT STORAGE (PCTINCREASE 0);" We executed the statement. Lo and behold, all the segments disappeared, back into free space. ! ! My guess is that there was a large sort (we do some of those) that failed, and left segments out there. I do not understand why they wouldn't clean up. Any informa!

tion?<BR><BR><BR><BR>--<BR>Author:<BR>INET: Dan.Hubler_at_midata.com<BR><BR>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051<BR>San Diego, California -- Public Internet access / Mailing Lists<BR>--------------------------------------------------------------------<BR>To REMOVE yourself from this mailing list, send an E-Mail message<BR>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in<BR>the message BODY, include a line containing: UNSUB ORACLE-L<BR>(or the name of mailing list you want to be removed from). You may<BR>also send the HELP command for other information (like subscribing).<BR><BR><BR><BR>Do You Yahoo!?<BR>Yahoo! Photos -- now, 100 FREE prints!<BR><BR><BR><BR></BLOCKQUOTE><BR><p><br><hr size=1><b>Do You Yahoo!?</b><br>

Received on Thu Jun 08 2000 - 08:07:08 CDT