Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Temp. segments/extents not being dropped

Re: Temp. segments/extents not being dropped

From: Chuck Hamilton <chuck_hamilton_at_yahoo.com>
Date: Tue, 6 Jun 2000 06:34:13 -0700 (PDT)
Message-Id: <10520.107864@fatcity.com>


--0-1804289383-960298453=:11457
Content-Type: text/plain; charset=us-ascii

 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!
--0-1804289383-960298453=:11457
Content-Type: text/html; charset=us-ascii


<P> 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.
<P>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.
<P> <BR><B><I>Dan.Hubler_at_midata.com</I></B> wrote: <BR>
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR><BR>Looking for some information on the following:<BR><BR>We had an incident last week where an Oracle instance (7.3.4.4) on NT<BR>was running into problems acquiring space for additional extents on<BR>the defined temporary tablespace.<BR><BR>While looking at the situation, we discovered that there was just about<BR>zero<BR>free space left in the tablespace. There was a whole bunch of extents<BR>created and owned by "SYS" and they had some flaky numeric<BR>identifier for the segment-name (something like 37.123).<BR><BR>Other processes were failing, being unable to allocate temp space.<BR><BR>We looked around on Metalink, and discovered a note about<BR>forcing temporary segments/extents to be cleaned up by<BR>performing an "ALTER TABLESPACE TEMP DEFAULT STORAGE (PCTINCREASE 0);"<BR><BR>We executed the statement. Lo and behold, all the segments disappeared,<BR>back into<BR>free space.<BR>!
<BR>My guess is that there was a large sort (we do some of those) that failed,<BR>and left segments out there. I do not understand why they wouldn't clean<BR>up.<BR><BR>Any information?<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></BLOCKQUOTE><BR><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://photos.yahoo.com/">Yahoo! Photos</a> -- now, 100 FREE prints!
Received on Tue Jun 06 2000 - 08:34:13 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US