No temp usage

Hi Guru
I am gathering schema statistics where my user data size around 750 GB
So far I know when we gather statistics temporary segment use highly but I found it has no usage.
EXEC DBMS_STATS_GATHER_SCHEMA_STATS('DATA1',DEGREE=>4);
SQL> select sum(BLOCKS*8/1024)m from v$sort_usage;
M
Can you tell me why it happens?
Regards
Jewel

hi,
So far I know when we gather statistics temporary segment use highly but I found it has no usage.Can you please let me know where it is mentioned ?
thanks,
baskar.l
Edited by: baskar.l on Sep 5, 2010 4:18 AM

Similar Messages

Tuning temp usage - 21GB Table

Hello,
11gR2 OEL, 2 CPU machine (test box).
select id,avg(col1),avg(col2),avg(col3),avg(col4),avg(col5)
from t1
group by id;id - VARCHAR2(15) NOT NULL - Not Indexed
Avg row length - 100 bytes
Table t1 is 21GB in size. Degree 4.
The query fails with ORA-01652 even after consuming 35 GB of Temp.
Problem at hand is to reduce temp usage as DBAs are not Ok with such huge temp usage with other jobs running.
We have come up with 2 options.
1. Create Index on id column - Looks like this works but takes longer. Testing is ongoing.
2. Create Hash Partitions (10 partitions) hash by id column. Loop through each partition and compute avg.
Option 1 is being tested currently.
The question I have is, is Option 2 reliable. Is it guaranteed that a given value for id will always go to partition x ?
Meaning, is it possible the same id value is stored in more than one hash partition ?
Pls let me know.
Rgds,
Gokul

The table has about 270 million rows with 3 - 4 million unique ids.
Will Hash partitioning still help in this case ?With 4 million Unique IDs, you'd have to create a large number of HASH partitions to "reasonably" distribute them ! You could also use RANGE partitioning if you can predict the ID values.
But don't go and partition/re-partition a table just to suit one type of query. Partitioning can well impact all sorts of queries (and DML) against the table. So you need to review the pattern of activity, performance implications for each type of access and maintenance overheads before deciding on a partitioning scheme.
Hemant K Chitale

Question about PGA and TEMP usage

hi,
we had a situation whereby OEM was reporting that because the PGA was too small during a time frame that extra I/O on the TEMP was being created. Does this then mean that the TEMP was acting as a pseudo PGA.
regards

Have a look at these threads
Re: PGA memory problem - Oracle 10.2.0.4 on windows 2003
Re: PGA Memory Usage Details
<br>
Oracle Database FAQs
</br>

UNDO and TEMP usage by a schema

Hi,
How can I findout UNDO and TEMP space usage by a schema? do we have any tables for this?
If I want to get UNDO,TEMP space or any other resource used by a schema for 24 Hours period,can get this info.
Can you please suggest the procedure to know the high resource consumption application?
I am using Oracle 9.2.0.4 in SUN cluster environment.
Thanks very much in advance.I apreciate your help
Thanks
Thanks

Hi,
About UNDO, you can check the status of the undo segment currently used by active transactions.
select s.username, t.xidusn, t.ubafil, t.ubablk, t.used_ublk
from v$session s, v$transaction t
where s.saddr = t.ses_addr;About others user session's information, you can try this below:
select osuser,
       machine,
       username,
       segment_name,
       sa.sql_text
from   v$session s,
       v$transaction t,
       dba_rollback_segs r,
       v$sqlarea sa
where s.taddr = t.addr
and    t.xidusn = r.segment_id(+)
and    s.sql_address = sa.address(+)
order by osuserAbout TEMP:
To monitor tempspace eating by sessionSELECT a.sid,b.BLOCKS FROM v$session a , v$sort_usage b
WHERE a.saddr=b.SESSION_ADDR;
To monitor tempspace eating by SQLSELECT a.sql_text,b.BLOCKS FROM v$sql a , v$sort_usage b
WHERE a.sql_id=b.sql_id;Cheers

Query to find the temp usage

oracle 10.2.0.4 on win2008
I got two queries from google to find the free space in temp tablespace. but both are showing different results.
Please let me know which one is showing the correct space usage in temp tablespace.
query 1 :
SELECT A.tablespace_name tablespace, D.mb_total,
SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM v$sort_segment A,
SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;
query 2 :
select tablespace_name,sum(bytes_used/1024/1024),sum(bytes_free/1024/1024) from v$temp_space_header group by tablespace_name;
Edited by: %bala% on Apr 30, 2013 8:31 PM

%bala% wrote:
ERROR:
ORA-04043: object DBA_TEMP_FREE_SPACE does not exist
This table is available from 11g.yes, V11 is only supported version now.

Estimate temp usage

Hello all,
we have a quite complex query (based on several views) that works fine in a test environment but fails in the production environment because the temp segment is too small (ORA-01652).
Fixing this problem is quite easy obviously by increasing the size of the tablespace. We'd like to find an "optimal" size for this - big enough, but not wasting space. So I would like to estimate the (current) usage of temp space of the query in some way.
Is there any way of finding out the correct size without an incremental increase of the tablespace (add 100MB, try again, if it fails add another 100MB and so on).
Would the "BYTES" column of an explain plan indicate the "correct" size for the temp segment?
Kind regards
Thomas

Thomas, first you should run an explain plan and see why the temp segment space is used: order by, group by, hash area, etc....
It is very possible for one statement to require multiple three temp areas concurrently.
You may want to compare the test and production plans to be sure the query does not need tuning, that an index added to test exists in production, etc....
Then based on the number of rows you expect to be passed to the temp area you can estimate how much space is required to support the query.
HTH -- Mark D Powell --

TEMP usage in Parallel Query | Why can't it use the spare RAM?

Hi All
I have a query running with parallel degree 8 on Red Hat 64 bit, 10.2.0.4.0, with 16 CPUs and 32GB of RAM.
My PGA target is 28 GB, SGA target at 2 GB.
I am using this Oracle instance purely for some datamart ETL, in order to deliver data to a separate reporting database. No other clients hit the instance.
I watch the instance during the query. Depending on volumes, I will sometimes get TEMP memory spill. This is not huge - maybe 2 to 4 GB of use, but even so, I don't want it to spill ,as the duration of the batch job is bigger than it needs to be.
I've tried increasing pgamax_size to use more RAM, and this helps to a point. However, there are some Oracle limits, after which TEMP space comes back into play. I've also tried tinkering with the smmmax_size and smmpx_max_size, but cannot seem to get any improvement. Changing the degree of parallelism makes little difference.
Looking at the Linux config, I have reduced swappiness to prevent the Oracle processes from being swapped out. And I can observe that only 4 to 6 GB of actual RAM is being used. I still have 20 - 24 GB completely free.
So - how do I get Oracle to actually consume this RAM rather than using TEMP space?
One option is to configure a RAM DISK of 8GB, and build the TEMP tablespace in that location. But is this really the answer? It seems like a 'fudge' rather than a solution.
The query plan is tuned well, and seems optimal.
Any help would be appreciated - thanks, Ankle.

MaskedAnkle wrote:
The query plan is tuned well, and seems optimal.
How about showing us the execution plan; and the output from v$pq_tqstat after running the query would be helpful.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)

Temp usage in system tablespace

Hi
I have oracle 9i with dictionary managed tablespaces.
I have put a trigger to capture sql statement which cause temp errors.
Recently, I have found out that the below sql cause:
ORA-1652: unable to extend temp segment by 5394 in tablespace SYSTEM
select distinct i.*
from PREM i, Summ p
WHERE i.Contract_Branch_Id = p.Pol_Branch_Id
AND i.Product_Code = p.Product_Code
AND i.Contract_Pol_No = p.Pol_No
AND p.Transaction_Type = 'V23'
AND p.Accounting_Prd IN
(TO_NUMBER(TO_CHAR(ADD_MONTHS(SYSDATE, -1),'YYYYMM')), TO_NUMBER(TO_CHAR(SYSDATE, 'YYYYMM')))My question is, how come such a sql uses temp segments in System tablespace rather than normal temp tablespace ?

in sqlplus do the following
SET AUTOTRACE TRACEONLY EXPLAIN STATISTICS
select distinct i.*
from PREM i, Summ p
WHERE i.Contract_Branch_Id = p.Pol_Branch_Id
AND i.Product_Code = p.Product_Code
AND i.Contract_Pol_No = p.Pol_No
AND p.Transaction_Type = 'V23'
AND p.Accounting_Prd IN
(TO_NUMBER(TO_CHAR(ADD_MONTHS(SYSDATE, -1),'YYYYMM')), TO_NUMBER(TO_CHAR(SYSDATE, 'YYYYMM')))
post FORMATTED results back here

Check and identify cause of previous temp tablespace usage

Hi
Our production ERP database is on solaris and on version 9.2.0.8.0. The application tier and database tier are on two separate nodes.
Recently we observed that the temporary tablespace is being consumed more on a particular day. While monitoring the database,we observed the free temp tablespace was less and hence added 10gb space to it. However within 5-6 hours this space was utilised and certain requests/jobs failed due to no space in temp. This happened on 04th December 2012. Though the situation returned to normal post that,we need to find the cause of consumption of temporary tablespace in such large volumes. We are on 9i database and hence tried identifying the queries through statspack report as no views in particular exist for 9i.
We came across many queries which would help us identfy the current temp usage,but in 9i,we didnot find anything which would guide us on the historic temp tablespace usage. Can it be found via statspack? If yes,what exactly to check for in it? Request you to all please advice. Thanks.
Regards
Rdxdba

-- To get historic information for a spesific sid,serial
column temp_mb format 99999999
column sample_time format a25
prompt
prompt DBA_HIST_ACTIVE_SESS_HISTORY
prompt
select sample_time,session_id,session_serial#,sql_id,temp_space_allocated/1024/1024 temp_mb,
temp_space_allocated/1024/1024-lag(temp_space_allocated/1024/1024,1,0) over (order by sample_time) as temp_diff
from dba_hist_active_sess_history
--from v$active_session_history
where
session_id=&1
and session_serial#=&2
order by sample_time asc
prompt
prompt ACTIVE_SESS_HIST
prompt
select sample_time,session_id,session_serial#,sql_id,temp_space_allocated/1024/1024 temp_mb,
temp_space_allocated/1024/1024-lag(temp_space_allocated/1024/1024,1,0) over (order by sample_time) as temp_diff
--from dba_hist_active_sess_history
from v$active_session_history
where
session_id=&1
and session_serial#=&2
order by sample_time asc
=========================================================================
---- For global temp usage info
col sid_serial format a10
col username format a17
col osuser format a15
col spid format 99999
col module format a15
col program format a30
col mb_used format 999999.999
col mb_total format 999999.999
col tablespace format a15
col statements format 999
col hash_value format 99999999999
col sql_text format a50
col service_name format a15
prompt
prompt #####################################################################
prompt #######################LOCAL TEMP USAGE#############################
prompt #####################################################################
prompt
SELECT A.tablespace_name tablespace, D.mb_total,
SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM v$sort_segment A,
SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;
prompt
prompt #####################################################################
prompt #######################LOCAL TEMP USERS#############################
prompt #####################################################################
prompt
SELECT S.sid || ',' || S.serial# sid_serial, S.username, S.osuser, P.spid,
--S.module,
--P.program,
s.service_name,
SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
COUNT(*) statements
FROM v$tempseg_usage T, v$session S, dba_tablespaces TBS, v$process P
WHERE T.session_addr = S.saddr
AND S.paddr = P.addr
AND T.tablespace = TBS.tablespace_name
GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid,
S.module,
P.program,
s.service_name,TBS.block_size, T.tablespace
ORDER BY mb_used;
--prompt
--prompt #####################################################################
--prompt #######################LOCAL ACTIVE SQLS ############################
--prompt #####################################################################
--prompt
-- SELECT sysdate "TIME_STAMP", vsu.username, vs.sid, vp.spid, vs.sql_id, vst.sql_text,vsu.segtype, vsu.tablespace,vs.service_name,
-- sum_blocks*dt.block_size/1024/1024 usage_mb
-- FROM
-- SELECT username, sqladdr, sqlhash, sql_id, tablespace, segtype,session_addr,
-- sum(blocks) sum_blocks
-- FROM v$tempseg_usage
--     group by username, sqladdr, sqlhash, sql_id, tablespace, segtype,session_addr
-- ) "VSU",
-- v$sqltext vst,
-- v$session vs,
-- v$process vp,
-- dba_tablespaces dt
-- WHERE vs.sql_id = vst.sql_id
-- AND vsu.session_addr = vs.saddr
-- AND vs.paddr = vp.addr
-- AND vst.piece = 0
-- AND vs.status='ACTIVE'
-- AND dt.tablespace_name = vsu.tablespace
-- order by usage_mb;
--prompt
--prompt #####################################################################
--prompt #######################LOCAL TEMP SQLS##############################
--prompt #####################################################################
--prompt
--SELECT S.sid || ',' || S.serial# sid_serial, S.username, Q.sql_id, Q.sql_text,
--T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace
--FROM    v$tempseg_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;
--

Temp tablespace usage...

hi,,
how to check the usage of temp tablespace?
thanks,
bicho

Temp used:
SELECT A.tablespace_name tablespace, D.mb_total,
SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM v$sort_segment A,
SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;
Temp usage per session:
SELECT S.sid || ‘,’ || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
P.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
COUNT(*) statements
FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
WHERE T.session_addr = S.saddr
AND S.paddr = P.addr
AND T.tablespace = TBS.tablespace_name
GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
P.program, TBS.block_size, T.tablespace
ORDER BY sid_serial;
Thanks

The Sky is Falling! ORA-01652: unable to extend temp segment by 128

So we currently have a production problem and I'm not so in the know as a lowly java developer and not an Oracle expert.
We keep getting this error(below) when a certain heavy query hits the DB.
Our DBA claims that the tablespace for 'TABLE_SPACE_NAME_HERE' is 20GB of space and that the problem is the query.
The query has been running fine for many many months but all of a sudden is presenting a problem and we have to do something quick.
We tried bouncing the application server but the error came right back when the big select query gets hit.
Any thoughts? Help! : )
java.sql.SQLException: ORA-01652: unable to extend temp segment by 128 in tablespace TABLE_SPACE_NAME_HERE
     at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
     at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:754)
     at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
     at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:972)
     at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1074)
     at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:854)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1156)
     at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415)
     at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3460)
     at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:296)

LosLobo wrote:
So, the next question... what is our lesson learned in this case?It depends on the root cause.
Our DBA thinks 30GB is an unreasonable size for the tablespace and is fingering the select query that was causing the error to occur. Their solution is move to the query to a view and then reduce the tablespace back to 20GB.
My thoughts are shouldn't the DB be able to handle a query that has been running fine for the last couple years? Also, if we do what is suggested what would prevent another query from coming along and causing the same issue all over again?Has the DBA identified the source of the issue? Did the query plan change? It's possible that something with statistics (or with some configuration change) causes Oracle to believe that two different query plans are roughly equally efficient. One plan might take substantially more TEMP space than another. It's possible that Oracle had been choosing the plan that involved less TEMP space being used and recently changed to preferring the plan that takes more TEMP space. If that's the issue, you may want to force Oracle to use the plan that involves less TEMP usage.
Regardless of your TEMP tablespace size, another query may come along that causes TEMP to run out of space. Or data growth may cause TEMP to run out of space. Or an increase in the number of users may cause TEMP to run out of space. Ideally, the DBAs would be identifying how much TEMP space is used over the course of the day so that if things are growing steadily additional space can be added as necessary. If TEMP space increases dramatically because a query plan changes, however, even the best monitoring is unlikely to be able to predict that level of growth.
Whether 30 GB is unreasonable (or whether 20 GB is unreasonable) will depend heavily on your application. We don't know enough to be able to comment. A TB-sized OLTP database serving millions of customers will have very different TEMP requirements than a multi-TB data warehouse which will have very different TEMP requirements than a small department-level application.
My surmising is we must have just crossed a watermark threshold and the simplest most reasonable solution is to just leave the larger tablespace size.Why do you believe this is the case? It is entirely possible that you need more TEMP because your TEMP usage has been growing slowly over time. It is entirely possible that the query in question has always been using more TEMP space than it really should and that you finally have enough usage to cause the problem to bubble to the surface. It is entirely possible that the query used a reasonable amount of TEMP for the past couple years and suddenly started using far more because of a query plan change. Once you identify the source of the problem, we can figure out the appropriate solution. Without knowing the source of the problem, we're all just guessing.
Justin

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

Temporary tablespace usage is always 0%

Friends,
I have this strange issue. My Oracle 9iR2 database always show temp tablespace usage as 0% no matter how much sorting is going on, it is never used.
select status from dba_temp_files;
=> AVAILABLE
select tablespace_name, status from dba_tablespaces where contents = 'TEMPORARY';
=> TEMP1, ONLINE
All users have TEMP1 as temporary tablespace.
I ran this random query to analyze temp usage.
SELECT * FROM DBA_EXTENTS ORDER BY 1,4,2,3,7,8;
I am using this query to analyze temp usage
http://www.oracle.com/technology/oramag/code/tips2004/110104.html
[re]
SELECT s.sid "SID",s.username "User",s.program "Program", u.tablespace "Tablespace",
u.contents "Contents", u.extents "Extents", u.blocks*8/1024 "Used Space in MB", q.sql_text "SQL TEXT",
a.object "Object", k.bytes/1024/1024 "Temp File Size"
FROM v$session s, v$sort_usage u, v$access a, dba_temp_files k, v$sql q
WHERE s.saddr=u.session_addr
and s.sql_address=q.address
and s.sid=a.sid
and u.tablespace=k.tablespace_name;
Any idea what going on here.
Regards,
Vishal V.

Hi,
===To find out the who is using the temp space===
SELECT b.tablespace, b.segfile#, b.segblk#, b.blocks, a.sid, a.serial#,
a.username, a.osuser, a.status
FROM v$session a,v$sort_usage b
WHERE a.saddr = b.session_addr
ORDER BY b.tablespace , b.segfile#, b.segblk#, b.blocks;
===== to find out the free space in temp space ===
SQL> select tablespace_name, file_id, bytes_used, bytes_free
2 from v$temp_space_header ;

Query to know TEMP and UNDO utilisation

Hi All,
DB - 9.2.0.8
I would appriciate, if somecone come up with a query which will show the UNDO and TEMP utilisation in termes of
user, query , size utilising the most undo and temp space.?
hare krishna

For undo you can use
SET LINESIZE 200
COLUMN username FORMAT A15
SELECT s.username,
       s.sid,
       s.serial#,
       t.used_ublk,
       t.used_urec,
       rs.segment_name,
       r.rssize,
       r.status
FROM   v$transaction t,
       v$session s,
       v$rollstat r,
       dba_rollback_segs rs
WHERE s.saddr = t.ses_addr
AND    t.xidusn = r.usn
AND    rs.segment_id = t.xidusn
ORDER BY t.used_ublk DESC;for session temp usage
SELECT a.sid, a.username, a.osuser, a.program, a.tablespace_name,
a.bytes "BYTES_USED", round(a.blocks / b.total_blocks,3) "PERC_USED"
from (select sor.tablespace_name, ses.sid, ses.username,
ses.osuser, ses.program, sor.blocks, sor.bytes
from (select /*+ optimizer rule */ u.tablespace "TABLESPACE_NAME", u.session_addr,
sum(u.blocks) blocks, sum(u.blocks) * &blksize bytes
FROM v$sort_usage u GROUP BY u.session_addr, u.tablespace) sor,
(select /*+ optimizer rule */ saddr, sid, username, osuser, program from v$session) ses
where ses.saddr=sor.session_addr) a, (select tablespace_name, sum(decode(maxblocks,0,blocks,maxblocks)) "TOTAL_BLOCKS"
from dba_temp_files group by tablespace_name) b
where a.tablespace_name=b.tablespace_name order by a.bytes;Anand

Query running out of temp

Hi,
on my 9.2.0.8 I've got query like this
select DISTINCT T.ID_KONTR as ID_KONTR,
                 T.PESEL as PESEL,
                 T.NAZWISKO as NAZWISKO,
                 T.IMIE as IMIE,
                 T.DATA_REJ as DATA_REJ
from T,
    (SELECT DISTINCT MAX(T.ID_KONTR) as ID_KONTR from T ,
        (select DISTINCT T.ID_KONTR as ID_KONTR,T.PESEL as PESEL,
                          T.NAZWISKO as NAZWISKO,
                          T.IMIE as IMIE,
                          T.DATA_REJ as DATA_REJ
                from T
                where
                    (T.OK =1)
                   and (T.PESEL is not null)
                   and T.data_rej between to_date('2011-10-21' , 'YYYY-MM-DD') and to_date('2011-10-25','YYYY-MM-DD')
         ) aaa
    where
        (T.OK =1)
        and (T.PESEL is not null)
        and T.pesel = aaa.pesel
        group by T.PESEL
        having count(*) >1
   ) bbb
where T.ID_KONTR=bbb.ID_KONTR order by T.DATA_REJ desc;
with plan
lan
SELECT STATEMENT RULE
     15 SORT UNIQUE
          14 NESTED LOOPS
               11 VIEW INSTALL.
                    10 SORT UNIQUE
                         9 FILTER
                              8 SORT GROUP BY
                                   7 VIEW SYS.
                                        6 SORT UNIQUE
                                             5 TABLE ACCESS BY INDEX ROWID T
                                                  4 NESTED LOOPS
                                                       2 TABLE ACCESS BY INDEX ROWID T
                                                            1 INDEX RANGE SCAN NON-UNIQUE TK_DATA_REJ
                                                       3 INDEX RANGE SCAN NON-UNIQUE TK_PESEL
               13 TABLE ACCESS BY INDEX ROWID T
                    12 INDEX UNIQUE SCAN UNIQUE TK_PK
          Unfortunately this query fills up temp space (because of huge sorts) , any ideas how that query can be rewritten to
decrease temp usage ?
Regards
GregG

Hello
Just to follow on from what Don is saying, I think you can start to rewrite the query like so
SELECT
      id_kontr,
      pesel,
      nazwisko,
      imie,
      data_rej
FROM
    (   SELECT
              t.id_kontr AS id_kontr,
              t.pesel    AS pesel,
              t.nazwisko AS nazwisko,
              t.imie     AS imie,
              t.data_rej AS data_rej
              COUNT(CASE
                         WHEN t.data_rej BETWEEN to_date('2011-10-21', 'YYYY-MM-DD')
                                             AND to_date('2011-10-25', 'YYYY-MM-DD')
                         THEN 1
                    END
                   ) OVER(PARTITION BY t.pesel) p_count,
              MAX(t.id_kontr) OVER (PARTITION BY t.pesel) max_id_kontr
        FROM
             t
        WHERE
             t.ok = 1
        AND
             t.pesel IS NOT NULL
WHERE
     p_count > 1
AND
   id_kontr = max_id_kontr
ORDER BY
      data_rej DESCWithout understanding the need for the distinct, I can't say whether it does exactly what you need but it should be a start and it also means you're only accessing "t" once.
HTH
David

No temp usage

Similar Messages

Maybe you are looking for