Query on V$STREAMS_APPLY_COORDINATOR used large temp space

Hi
My database recently experience ORA-1652 error consistently on temp tablespace. I found out the query to cause this was an OEM query SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR, which uses over than 800M temp space frequently. I am not sure why is this, I can query the same select statement in sqlplus, it returns immeidatly. Can anyone help to teach me on this? Thanks.
The query to find the user for temp tablespace is.
SELECT S.sid || ',' || S.serial# sid_serial, S.username, Q.hash_value, Q.sql_text,
T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace
FROM v\$sort_usage T, v\$session S, v\$sqlarea Q, dba_tablespaces TBS
WHERE T.session_addr = S.saddr
AND T.sqladdr = Q.address
AND T.tablespace = TBS.tablespace_name
ORDER BY mb_used)
where mb_used >=800;
I got
SID_SERIAL USERNAME HASH_VALUE SQL_TEXT MB_USED TABLESPACE
1626,1 DBSNMP 3741683138 /* OracleOEM */ SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR 880 TEMP1

Similar Messages

Query erroring out with lack of temp space?

I have 2 databases. One was cloned from the other on to another server.
On one server the query takes 5 seconds to run on the other server the query errors lack with lack of disk space.
The init files are the same. The Oracle memory is the same. The temp tablespace size is the same.
I'm stuck!
What should I look for to find out what is causing the error?

On both databases the version is 9.2.0.6.
This is the view that worked in database1 and errored in database2...
CREATE OR REPLACE VIEW SAP_STAGE.MTC_STG_MEASURE_POINT_V
EQUIP_NO,
MEASUR_PNTPOS,
CHARACT_NAME,
UNIT,
MEASUR_PNT_DESC,
VALUATION_CODE,
TEXT_FIELD
AS
SELECT DISTINCT xref.equnr AS equip_no, rpmp.*
FROM sap_stage.measuring_point mp JOIN xref_sap_equi xref
ON TRIM (mp.equip_no) = TRIM (xref.groes)
JOIN stg_mtc_msf600 msf600
ON TRIM (mp.equip_no) = TRIM (msf600.equip_no)
AND TRIM (msf600.dstrct_code) in ('347','315')
JOIN rec_prodstat_code_measur_pts rpmp ON 1 = 1
If I qualify all the tables with SAP_STAGE the query runs in 5 seconds in database2.
Why does the query run in database 1 without the schema names?

Query using large(in GB) temp tablespace, how to tune it?

Hi,
Below query is using large Temp tablespace, please guide for tuning this query so that it can use minimal temp space.
SELECT DISTINCT cust_alt.cust_acct_alt_id, cust_alt.cust_acct_alt_id_type_cd,
                trans.legal_entity_id, trans.exchange_id,
                trans.stamp_update_dtime, trans.book_alt_id,
                trans_alt.trans_alt_id, trans_alt.trans_alt_vers_id,
                trans_alt.src_sys_short_name, event.trans_event_sequence_id,
                event.trans_event_type_cd, prod_alt.product_alt_id,
                prod_alt.product_alt_id_type_cd, trans.buy_sell_cd,
                trans.trade_date, item.setlmt_date, item.trans_price_amt,
                item.price_yield_ind, item.trans_dirty_price_amt,
                item.trans_qty, item.trans_item_type_cd,
                event.trans_event_dtime,
                DECODE (extnn.confirm_generation_elig_ind,
                        'Y', 'In Progress',
                        NULL, 'Not Processed',
                        'Confirm Ineligible'
                       ) confirm_status,
                event_ref.trans_event_type_desc
           FROM ods_trans_event_type_ref event_ref,
                ods_trans_type_ref trans_type,
                ods_cust_acct_alt_id cust_alt,
                ods_product_alt_id prod_alt,
                ods_trans_item item,
                ods_trans_alt_id trans_alt,
                ods_trans trans,
                ods_trans_extnn extnn,
                ods_trans_event event
          WHERE event_ref.trans_event_type_cd = event.trans_event_type_cd
            AND trans_type.trans_type_id = trans.trans_type_id
            AND prod_alt.product_id = trans.product_id
            AND cust_alt.cust_acct_id = trans.cust_acct_id
            AND item.trans_vers_id = trans.trans_vers_id
            AND item.trans_id = trans.trans_id
            AND extnn.trans_vers_id(+) = trans.trans_vers_id
            AND extnn.trans_id(+) = trans.trans_id
            AND trans_alt.trans_link_reason_cd = 'FOID'
            AND trans_alt.trans_vers_id = trans.trans_vers_id
            AND trans_alt.trans_id = trans.trans_id
            AND trans.trans_vers_id = event.trans_vers_id
            AND trans.trans_id = event.trans_id
            AND item.trans_item_type_cd IN ('MAIN', '1', '2')
            AND cust_alt.cust_acct_alt_id != 'BOOKTOBOOK'
         order by trans_alt.trans_alt_id, event.trans_event_sequence_idThe Explain for this query is
| Id | Operation                                      | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                          |                             |    79 | 23384 | 1404   (1)| 00:00:17 |
|   1 | HASH UNIQUE                                   |                             |    79 | 23384 | 1404   (1)| 00:00:17 |
|* 2 |   TABLE ACCESS BY INDEX ROWID        | ODS_TRANS_ITEM       |     1 |    53 |     4   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                                |                             |    79 | 23384 | 1403   (1)| 00:00:17 |
|   4 |     NESTED LOOPS OUTER                    |                             |    73 | 17739 | 1144   (1)| 00:00:14 |
|   5 |      NESTED LOOPS                              |                             |    73 | 16717 |   965   (0)| 00:00:12 |
|   6 |       NESTED LOOPS                             |                             |    73 | 15476 |   819   (0)| 00:00:10 |
|   7 |        NESTED LOOPS                            |                             |    73 | 14089 |   673   (0)| 00:00:09 |
|   8 |         NESTED LOOPS                           |                             |    73 | 10439 |   672   (0)| 00:00:09 |
|   9 |          NESTED LOOPS                          |                             |    90 | 9810 |   312   (0)| 00:00:04 |
|* 10 |           TABLE ACCESS BY INDEX ROWID| ODS_TRANS_ALT_ID            |    92 | 3680 |    52   (0)| 00:00:01 |
|* 11 |            INDEX RANGE SCAN               | ODS_TRANS_ALT_ID_X1         |   119 |       |     5   (0)| 00:00:01 |
| 12 |           TABLE ACCESS BY INDEX ROWID| ODS_TRANS                   |     1 |    69 |     3   (0)| 00:00:01 |
|* 13 |            INDEX UNIQUE SCAN              | ODS_TRANS_PK                |     1 |       |     2   (0)| 00:00:01 |
| 14 |          TABLE ACCESS BY INDEX ROWID | ODS_TRANS_EVENT             |     1 |    34 |     4   (0)| 00:00:01 |
|* 15 |           INDEX RANGE SCAN                | ODS_TRANS_EVENT_PK          |     1 |       |     3   (0)| 00:00:01 |
| 16 |         TABLE ACCESS BY INDEX ROWID | ODS_TRANS_EVENT_TYPE_REF    |     1 |    50 |     1   (0)| 00:00:01 |
|* 17 |          INDEX UNIQUE SCAN                | ODS_TRANS_EVENT_TYPE_REF_PK |     1 |       |     0   (0)| 00:00:01 |
| 18 |        TABLE ACCESS BY INDEX ROWID   | ODS_PRODUCT_ALT_ID          |     1 |    19 |     2   (0)| 00:00:01 |
|* 19 |         INDEX RANGE SCAN                  | ODS_PRODUCT_ALT_ID_PK       |     1 |       |     1   (0)| 00:00:01 |
|* 20 |       TABLE ACCESS BY INDEX ROWID    | ODS_CUST_ACCT_ALT_ID        |     1 |    17 |     2   (0)| 00:00:01 |
|* 21 |        INDEX RANGE SCAN                   | ODS_CUST_ACCT_ALT_ID_PK     |     1 |       |     1   (0)| 00:00:01 |
| 22 |      TABLE ACCESS BY INDEX ROWID     | ODS_TRANS_EXTNN             |     1 |    14 |     3   (0)| 00:00:01 |
|* 23 |       INDEX UNIQUE SCAN                   | SYS_C0026927                |     1 |       |     2   (0)| 00:00:01 |
|* 24 |     INDEX RANGE SCAN                      | ODS_TRANS_ITEM_PK           |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------Cant avoid the order by and distinct clauses. Cant avoid Outer joins. Indexes are used properly.

Just to add on to Mark's excellent points--
1) The Oracle optimizer is estimating that your query is only going to return 79 rows. If it is using a great deal of TEMP space, that estimate would seem to be wildly incorrect which implies that you have a problem with your statistics.
2) Are you certain that you need the DISTINCT? Lots of people either throw DISTINCT clauses into their queries "just in case" or throw in a distinct when they are unexpectedly getting duplicate rows because they are missing a join condition. If that's the case here, removing the DISTINCT and figuring out which join condition is missing (if applicable) would cause much less TEMP space to be used.
Justin

SQL query using lot of Temp space

I have sql query which is using lot of temp space , please suggest some ways to reduce this
SELECT A.POSITION_NBR, TO_CHAR(B.EFFDT,'YYYY-MM-DD'), rtrim( A.SEQNO), A.EMPLID, B.REG_REGION, A.MANAGER_ID, A.REPORTS_TO, case when A.POSITION_NBR = A.REPORTS_TO THEN 'POS reports to same position' else 'Positions with multiple Emp' End Case
FROM PS_Z_RPTTO_TBL A, PS_POSITION_DATA B, PS_POSTN_SRCH_QRY B1
WHERE B.POSITION_NBR = B1.POSITION_NBR AND B1.OPRID = 'MP9621Q' AND ( A.POSITION_NBR = B.POSITION_NBR AND ( A.REPORTS_TO = A.POSITION_NBR AND B.EFFDT =
(SELECT MAX(B_ED.EFFDT)
FROM PS_POSITION_DATA B_ED
WHERE B.POSITION_NBR = B_ED.POSITION_NBR) AND A.POSITION_NBR <> '00203392') OR ( B.EFFDT =
(SELECT MAX(B_ED.EFFDT)
FROM PS_POSITION_DATA B_ED
WHERE B.POSITION_NBR = B_ED.POSITION_NBR AND B_ED.EFFDT <= SYSDATE) AND B.MAX_HEAD_COUNT <>
(SELECT Count( C.EMPLID)
FROM PS_Z_RPTTO_TBL C)) ) UNION
SELECT F.POSITION_NBR, TO_CHAR(F.EFFDT,'YYYY-MM-DD'), '', '', F.REG_REGION, '', F.REPORTS_TO, ''
FROM PS_POSITION_DATA F, PS_POSTN_SRCH_QRY F1
WHERE F.POSITION_NBR = F1.POSITION_NBR AND F1.OPRID = 'MP9621Q' AND ( F.EFFDT =
(SELECT MAX(F_ED.EFFDT)
FROM PS_POSITION_DATA F_ED
WHERE F.POSITION_NBR = F_ED.POSITION_NBR AND F_ED.EFFDT <= SYSDATE) AND F.EFF_STATUS = 'A' AND F.DEPTID IN
(SELECT G.DEPTID
FROM PS_DEPT_TBL G
WHERE G.EFFDT =
(SELECT MAX(G_ED.EFFDT)
FROM PS_DEPT_TBL G_ED
WHERE G.SETID = G_ED.SETID AND G.DEPTID = G_ED.DEPTID AND G_ED.EFFDT <= SYSDATE) AND F.REG_REGION = G.SETID AND G.EFF_STATUS = 'I') )
Thanks in Advance
Rajan

use {noformat}<your code here>{noformat} tags to format your code.
I have sql query which is using lot of temp space , please suggest some ways to reduce thisIf your sort_area_size is not set sufficient oracle used temp space for sorting operation. As your code is not readable i cant say much more than this. Check with your DBA if you have to increase the temp space.

Problem with temp space allocation in parallel query

Hello
I've got a query which matches two large result sets (25m+ rows) against each other and does some basic filtering and aggregation. When I run this query in serial it takes about 30 mins and completes successfully. When I specify a parallel degree of 4 for each result set, it also completes successfully in about 20 minutes. However, when I specify that it should be run in parallel but don't specify a degree for each result set, it spawns 10 parallel servers and after a couple of minutes, bombs out from one of the parallel servers with:
ORA-12801: error signaled in parallel query server P000
ORA-01652: unable to extend temp segment by 64 in tablespace TEMPThis appears to be when it is about to perform a large hash join. The execution plan does not change whether the parallel degree is specified or not, and there is several GB of temp space available.
I'm at a bit of a loss as to how to track down specifically what is causing this problem. I've looked at v$sesstat for all of the sessions involved and it hasn't really turned anything up. I've tried tracing the main session and that hasn't really turned up much either. From what I can tell, one of the sessions seems to try to allocate massive amounts of temp space that it just does not need, but I can figure out why.
Any ideas of how to approach finding the cause of the problem?
David

Hello
I've finally resolved this and the resolution was relatively simple - and was also the main thing that Mark Rittman said he did in his article: reduce the size of the hash join.
After querying v$sql_workarea_active I could see what was happening which was that the sum of the temp space for all of the parallel slaves was exceeding the total amount of temp space available on the system. When run in serial, it was virtually at the limit. I guess the extra was just the overhead for each slave maintaining it's own hash table.
I also made the mistake of misreading the exectuion plan - assuming that the data being pushed to the hash join was filtered to eliminate the data that was not of interest. Upon reflection, this was a rather stupid assumption on my part. Anyway, I used sub query factoring with the materialize hint to ensure that the hash join was only working on the data it should have been. This significantly reduced the size of the hash table and therefore the amount of temp space required.
I did speak to oracle support and they suggested using pga_aggregate_target rather than the separate *area_size parameters. I found that this had very little impact as the problem was related to the volume of data rather than whether it was being processed in memory or not. That said, I did try upping the hash_area_size for the session with some initial success, but ultimately it didn't prove to be scalable. We are however now using pga_aggregate_target in prod.
So that's that. Problem sorted. And as the title of Mark Rittman's article suggests, I was trying to be too clever! :-)
HTH
David

Estimating how much temp space a query will take?

I have a query that is "SELECT * FROM some_table ORDER BY field_name DESC". some_table has an avg_row_len of 458 bytes and stats are current. There are just about 6 million rows in some_table.
TEMP is set to 500MB and the query fails for lack of TEMP space. I show about 176MB of TEMP is presently in use, so worst case I should have 324MB free.
So which calculation is correct for how much TEMP space is needed:
(a) 458 avg_row_len * 6,000,000 = about 3GB of space (and DBA_SEGMENTS agrees with this rough math). That's assuming it puts the whole row into the sort.
(b) 6,000,000 rows * 4 bytes for a ROWID (I think they're 4 bytes) = 22MB. That's assuming it sorts just a bunch of pointers to rows (which is how I thought it would work).

Don't forget to add the length of the column being sorted to the rowid length before you multiply. A [url http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/logical.htm#CNCPT89008]rowid has four pieces, not four bytes. Also check your plan, in case there is more than just the sort going on for you.
With appropriate sort_area_size or pga target, you may reduce the need for temp. See [url http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/memory.htm#i49320]pga memory management in the docs, to start.

How to determine what's using data store temp space?

How can one determine what's using data store temp space? We are interested to know what structures are occupying space in temp space and if possible what pid/process connected to TimesTen created them.
Also, is there a procedure that will work if temp space is full?
Recently one of our data stores ran of space. We we're unable to run commands like "monitor", "select * from monitor", "select count(*) from my_application_table", etc. These commands failed because they required temp space to run and temp space was full. We killed the application processes, this in turned freed up temp space, then we were able to run these queries.
Ideally, we'd like to have a procedure to figure out what's using temp space when temp space is full.
The other thing we could do is periodically monitor temp space prior to it filling to determine what's using temp space.

That was my original thought, but once you click the slider track or thumb, and then enter a value in the text control, the clickTarget on the change event envoked by the change to the bound data (after entering a value in the text control) will be whatever slider element had last been clicked. If you've never clicked the slider, clickTarget=null. But once you've clicked the slider the clickTarget always has a value of "thumb" or "track", regardless of what triggered the change event.

Using large block sizes for index and table spaces

" You are not using large blocksizes for your index tablespaces. Oracle research proves that indexes will build flatter tree structures in larger blocksizes.
Is this a generic statement that I can use for all tables or indexes? I also have batch and online activity. My primary target is batch and it should not impact online. Not sure if both have common tables.
How to find the current block size used for tables and index? is there a v$parameter query?
What is an optimal block size value for batch?
How do I know when flatter tree str has been achieved using above changes? Is there a query to determine this?
What about tables, what is the success criterion for tables. can we use the same flat tree str criterion? Is there a query for this?

user3390467 wrote:
" You are not using large blocksizes for your index tablespaces. Oracle research proves that indexes will build flatter tree structures in larger blocksizes.
Is this a generic statement that I can use for all tables or indexes? This is a generic statement used by some consultants. Unfortunately, it is riddled with exceptions and other considerations.
One consultant in particular seems to have anecdotal evidence that using different block sizes for index (big) and data (small) can yield almost miraculous improvements. However, that can not be backed up due to NDA. Many of the rest of us can not duplicate the improvements, and indeed some find situations where that results in a degradation (esp with high insert/update rates from separated transactions).
I also have batch and online activity. My primary target is batch and it should not impact online. Not sure if both have common tables.
How to find the current block size used for tables and index? is there a v$parameter query?
What is an optimal block size value for batch?
How do I know when flatter tree str has been achieved using above changes? Is there a query to determine this?
What about tables, what is the success criterion for tables. can we use the same flat tree str criterion? Is there a query for this?I'd strongly recommend that you
1) stop using generic tools to analyze specific problems
2) define you problem in detail ()what are you really trying to accomplish - seems like performance tuning, but you never really state that)
3) define the OS and DB version - in detail. Give rev levels and patch levels.
If you are having a serious performance issue, I strongly recommend you look at some performance tuning specialists like "http://www.method-r.com/", "http://www.miracleas.dk/", "http://www.hotsos.com/", "http://www.pythian.com/", or even Oracle's Performance Tuning consultants. Definitely worth the price of admission.

Maximum TEMP space ever used

Hello, I would like to ask how to check the maximum space ever used for TEMP. I want to know it because I need to resize the TEMP and I want to know how small it can be.
As I can see from a documentation http://docs.oracle.com/cd/B14117_01/server.101/b10755/dynviews_2095.htm
max_size is max number of extens ever used in a segment
I could multiply max_size by extent_size and it would give me the max size of temp ever used
SQL> select segment_file, extent_size, max_size from v$sort_segment;
SEGMENT_FILE EXTENT_SIZE MAX_SIZE
0 128 23625
0 128 753
Is that correct ?
Edited by: Przemek P on Oct 2, 2012 2:19 AM

such dynamic performance views contain information since last instance startup, so this is not the ever used maximum
check historical tablespace metrics (not collected for TEMP tablespace in 10g by default if you happen to have that version)
check current allocated size of TEMP tablespace: if its made up by autoextensible tempfiles and they werent increased manually, thats the maximum amount of temp ever used
none of the above will be accurate, but they can at least give you a direction
also keep in mind that max temp usage in past will not necessarily be the max temp usage in the future

How to prevent large blank spaces on webpage when using Slide Behaviors?

I searched the forums for similar problems with applying the Slide Behaviour to elements through the DW CS5 interface and found a useful post titled "Problem with Applying Spry "Slide Effect" so now my slide effects works the way I want, except instead of sliding out a caption after clicking on an image, I slide out a list of text items when clicking on a section of text. This works, but there is a large gap when the webpage first loads. How can I remove/prevent this large white space from appearing?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Testing Document</title>

<script src="SpryAssets/SpryEffects.js" type="text/javascript"></script>
<script type="text/javascript">
function MM_effectSlide(targetElement, duration, from, to, toggle)
          Spry.Effect.DoSlide(targetElement, {duration: duration, from: from, to: to, toggle: toggle});
</script>
</head>
<body>
<p> </p>
<p> </p>
<style type="text/css">
#LOdiv{ visibility: hidden;}
#Countries{ visibility: hidden;}
</style>
<p> </p>
<p> </p>
<div id="ListOne" onclick="MM_effectSlide('LOdiv', 1000, '0%', '100%', true)">
<p><strong>Drop Down List One + show      </strong></p>
</div>
    <div id="LOdiv">
    <div>
      - Item A<br/>
      - Item B<br />
      - Item C<br />
      - Item D<br />
      - Item E<br />
      - Item F<br />
      - Item G<br />
      - Item H<br />
      - Item I</div>
</div>
</div>
<div id="ListTwo" onclick="MM_effectSlide('Countries', 1000, '0%', '100%', true)">
<p><strong >List Two + show </strong></p>
</div>
<div id="Countries">
          <div>
               - USA<br/>
      - Germany<br />
      - France<br />
      - Italy<br />
      - Japan<br />
      - China<br />
</div>
</div>
<span style=' width:990px; height:21px'><img width=990 height=21
src="image386.gif">
</span>
</body>
</html>

The link to the html code can be found at:
https://docs.google.com/leaf?id=0B_S-KEeOr-KhNzQwYzQ5MWQtNTVhYy00OTg1LWJjYTQtODIzOWUwM2ExM 2Yx&hl=en_US
but it needs to access the link SpryAssets/SpryEffects.js   (from DW)
When you open it in a browser you will see a large gap between the two lines:
"Drop Down List One +show" and
"Drop Down List Two + show"
clicking the mouse on "Drop Down List One +show" causes a hidden element to drop down. re-clicking causes it to shrink, and thus removing the large blank space between. I don't know how to initially present the two lines without the large initial blank gap between them.
I tried previewing in Chrome, Firefox, and IE - all look the same.
Thanks.

Usage of temp space in oracle

I am using Informatica to load into one table in Oracle .
Source and target table contains on CLOB colum.
Source table size is 1GB.
Target is oracle 10g with 30GB of temp space .
Whenever i run this job TEMP space usage is complete 30Gb and job is failing .
Any has any clue in this ?

Actually, the problem probably is that you are looking at the table but not at the CLOB storage. CLOB's are typically stored outside the table.. so the table might be 1GB, but you might have a MUCH larger storage for the CLOB data.
Replace the owner and segment name with your owner and table_name in this query and see what gets reported.
select segment_name, sum(bytes)
from dba_extents
where owner = 'OUTLN'
and segment_name in
(select 'OL$HINTS' from dual
union
select segment_name from dba_lobs where table_name = 'OL$HINTS' and owner = 'OUTLN')
group by segment_name;

Unable to Extend TEMP space for CLOB

Hi,
I have a data extract process and I am writing the data to a CLOB variable. I'm getting the error "Unable to Extend TEMP space" for the larger extracts. I was wondering if writing the data to a CLOB column on a table and then regularly committing would be better than using a CLOB variable assuming time taken is not an issue.

You do not need to add more temp files. This is not a problem of your temp tablespace. This is the problem of temp segments in your permanent tablespace. You need to add another datafile in EDWSTGDATA00 tablepsace. This happens when you are trying to create tables and indexes. Oracle first does the processing in temp segments(not temp tablespace) and at the end oracle converted those temp segments into permanent segments.
Also, post the result of below query
select file_name,sum(bytes/1024/1024)in_MB,autoextensible,sum(maxbytes/1024/1024)in_MB from dba_data_files where tablespace_name='STAGING_TEST' group by file_name,autoextensible order by FILE_NAME;

Investigate extend PGA vs TEMP space

I have the following request from one of my BI consultants. How would I go about troubleshooting this / finding a solution ?
"Hi Dirk
<user x> has to perform large data queries on <database y> and we keep running out of TEMP space.
Can you please investigate which will be better:
- To extend the the PGA or
- To extend the TEMP table space."

Dirk, before you go changing your system configuration in the hope the changes will fix your problem you need to understand why your application is consuming all available TEMP space. There is a very good change that even after switching to or increasing the PGA_AGGREGATE_TARGET that the same problem will exist unless you understand why the space is being used.
It is possible that the total concurrent number of sorts/hash joins/lob operations just need more temp than is allocated.
If is also possible for the query plan for a query executed concurrently is using a sort/merge or hash join that consumes a large amount of space and if the query was changed to use a Nest Loops plan or an index added to support the join that the requirement for sort space to support the sort/hash operations would go away.
HTH -- Mark D Powell --

Temp space problem

HI all,
I receive an error while executing a procedure.
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
can any one please exlain what is the problem.
thanks in advance
baskar k

hi
First ORA-01652 may occur because there is simply no space available in the temp tablespace of which is being used. The second cause of ORA-01652 may have to do with the local temp segment not being able to extent space even though there is space in other instances.
To trouble shoot for ORA-01652, and find out which of the above scenarios are causing ORA-01652 use this query offered by MetaLink:
select sum(free_blocks)
from gv$sort_segment
where tablespace_name = '<TEMP TABLESPACE NAME>'
You will know that the first scenario is causing ORA-01652 to be thrown if the free block reads '0' because it signifies that there is no free space.
If there is a good amount of space, you know that there is another cause for ORA-01652, and it is probably the second scenario. It is important to note that in a non-RAC environment, local instances are not able to extend the temp segments, so in the RAC environment, ORA-01652 has to be handled differently. If you are experiencing ORA-01652 in a non-RA environment, be aware that every SQL making use of the tablespace can fail.
In RAC, more sort segment space can be used from other instances, which can help resolve ORA-01652 more easily. Try using the query below:
select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks
from gv$sort_segment;
Basically, you can then find out how much temp segment space can be used for each instance by viewing the total_blocks, and the used_blocks can reveal the space which has been used so far, and and the free_blocks gives the amount of space allocated to this particular instance. This being, to resolve ORA-01652, you can check out that used_blocks = total_blocks and free_blocks = 0 will probably show for the instance, and ORA-01652 will be shown multiple times within the alert log.
This basically means that free space from other instances is being requested, and typically signifies that there is instance contention. Instance contention within the temporary space can make the instance take more time to process.
In sever cases, a slowdown may occur, in which you might want try one of the following work-arounds:
Increase size of the temp tablespace
Increase sort_area_size and/or pga_aggregate_target
However, remember to not use the RAC feature of DEFAULT temp space.
If ORA-01652 is causing the slowdown, SMON will probably not be able to process the sort segment requests, you you should try to diagnose the contention:
Output from the following query periodically during the problem:
select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks
from gv$sort_segment;
Global hanganalyze and systemstate dumps
Hope this helps
CHeers

Never release the temp space

It seems my oracle database never release temp space.
The usage of temp space kept at 99.8% ,but there was no alarm in alert.log.
It is not acceptable to shutdown the machine (7*24).
It is said that oracle do not use temp space if the memory for sorting can hold processing statement.
But there is no large work load on the machine and whenever
select * from v$sort_usage
no record
what s wrong?
how can i release temp space without shutting down the server?
Sun fire v880 4 cpu at 1050Mhz Memory 8G
Solaris 8 0202
Oracle 92

You do not need to worry about it, unless you are getting "Unable to allocate ... in table TEMP" messages.
I believe that the space will be released if you bounce the database.
The 99% you are seeing is like a high water mark, which says that at some point 99% of your TEMP space was used. However no rows in v$sort_usage means that no space is currently being used.
So, relax!

Query on V$STREAMS_APPLY_COORDINATOR used large temp space

Similar Messages

Maybe you are looking for