ORA-01652 due to a SELECT DISTIINCT...ORDER BY

Hi all,
the query below fill my 32GB temporary tablespace and I get an ORA-01652.
SELECT DISTINCT x.nuaud, TO_CHAR (x.times, 'DD/MM/YY HH24:MI'), x.inde1,
                x.inde2, x.inde3, x.inde4, NVL (y.litab, '????'),
                NVL (x.useru,
                     SUBSTR (SUBSTR (x.progr, 1, INSTR (x.progr, '.') - 1),
                             1,
                             8
                x.dmlst, x.nublk, x.blkfc, x.nbord, 'A'
           FROM audtab x, audlib y
          WHERE x.cotab = y.cotab(+)
            AND DECODE (y.colan(+), 'A', 1, 0) = 1
            and exists (select 1 from audtri z where z.cotab = x.cotab)
       ORDER BY 1, 12, 10;some informations here:
SQL> select 'audtab', count(1) from audtab
2    union all
3    select 'audlib', count(1) from audlib
4    union all
5    select 'audtri', count(1) from audtri;
'AUDTA   COUNT(1)
audtab 118804430
audlib        446
audtri        219
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionI added an other datafile of 32GB to my temporary tablespace and now the query has been running for 1 hour and I have 52GB used in my temporary tablespace.
Below is the monitoring report
Global Information
Status              : EXECUTING
DBMS_SQLTUNE.REPORT_SQL_MONITOR('1DM3GYMADU2AA')
Instance ID         : 1
Session             : UBXADMIN (102:1880)
SQL ID              : 1dm3gymadu2aa
SQL Execution ID    : 16777216
Execution Started   : 03/05/2010 17:51:19
First Refresh Time : 03/05/2010 17:51:23
Last Refresh Time   : 03/05/2010 18:49:11
Duration            : 3473s
Module/Action       : SQL*Plus/-
Service             : REC1128
Program             : sqlplus.exe
DBMS_SQLTUNE.REPORT_SQL_MONITOR('1DM3GYMADU2AA')
Global Stats
======================================================================================
| Elapsed |   Cpu   |    IO    | Concurrency | Buffer | Read | Read | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s)   | Gets | Reqs | Bytes | Reqs | Bytes |
======================================================================================
|    3617 |     846 |     2771 |        0.05 |     5M | 792K | 75GB | 322K | 61GB |
======================================================================================
SQL Plan Monitoring Details (Plan Hash Value=3110686745)
============================================================================================================================================
============================================================
DBMS_SQLTUNE.REPORT_SQL_MONITOR('1DM3GYMADU2AA')
| Id   |         Operation         | Name   | Rows   | Cost |   Time    | Start | Execs |   Rows   | Read | Read | Write | Write | Mem
| Temp | Activity |       Activity Detail           | Progress |
|      |                           |         | (Estim) |      | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs | Bytes |
|          |   (%)    |         (# samples)         |          |
============================================================================================================================================
============================================================
|    0 | SELECT STATEMENT          |         |         |      |           |        |     1 |          |      |       |       |       |
|          |          |                             |          |
| -> 1 |   SORT ORDER BY           |         |     90M | 11M |      2163 | +1312 |     1 |        0 | 105K |   1GB | 157K | 23GB | 509K
| 24G |              |                             |          |
DBMS_SQLTUNE.REPORT_SQL_MONITOR('1DM3GYMADU2AA')
| -> 2 |    HASH UNIQUE            |         |     90M |   6M |      3471 |     +4 |     1 |      99M | 163K | 38GB | 87547 | 20GB | 49M
| 29G |        42.58 | Cpu (97)                    |          |
|      |                           |         |         |      |           |        |       |          |      |       |       |       |
|          |          | direct path write temp (55) |          |
|    3 |     HASH JOIN RIGHT OUTER |         |     90M |   1M |      1299 |     +4 |     1 |     119M |      |       |       |       |
|          |     0.84 | Cpu (3)                     |          |
|    4 |      TABLE ACCESS FULL    | AUDLIB |       4 |    3 |         1 |     +4 |     1 |      223 |      |       |       |       |
|          |          |                             |          |
|    5 |      HASH JOIN            |         |     90M |   1M |      1301 |     +2 |     1 |     119M |      |       |       |       |
|          |     2.52 | Cpu (9)                     |          |
|    6 |       SORT UNIQUE         |         |     217 |    1 |         1 |     +4 |     1 |      218 |      |       |       |       |
|          |          |                             |          |
DBMS_SQLTUNE.REPORT_SQL_MONITOR('1DM3GYMADU2AA')
|    7 |        INDEX FULL SCAN    | AUDTRI2 |     217 |    1 |         1 |     +4 |     1 |      219 |      |       |       |       |
|          |          |                             |          |
|    8 |       TABLE ACCESS FULL   | AUDTAB |    115M |   1M |      1300 |     +3 |     1 |     119M | 521K | 36GB | 77094 | 18GB |
|          |    54.06 | Cpu (14)                    |     100% |
|      |                           |         |         |      |           |        |       |          |      |       |       |       |
|          |          | direct path read (179)      |          |
============================================================================================================================================
============================================================Have someone an idea of how can this query be tune to generate less sort on disk ?
Thanks for helping

the query took 6 hours to complete:
SQL> SELECT DISTINCT x.nuaud, TO_CHAR (x.times, 'DD/MM/YY HH24:MI'), x.inde1,
2                  x.inde2, x.inde3, x.inde4, NVL (y.litab, '????'),
3                  NVL (x.useru,
4                       SUBSTR (SUBSTR (x.progr, 1, INSTR (x.progr, '.') - 1),
5                               1,
6                               8
7                              )
8                      ),
9                  x.dmlst, x.nublk, x.blkfc, x.nbord, 'A'
10             FROM audtab x, audlib y
11            WHERE x.cotab = y.cotab(+)
12              AND DECODE (y.colan(+), 'A', 1, 0) = 1
13              and exists (select 1 from audtri z where z.cotab = x.cotab)
14         ORDER BY 1, 12, 10;
118794436 rows selected.
Elapsed: 06:01:48.89
Execution Plan
Plan hash value: 3110686745
| Id | Operation               | Name    | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT        |         |    89M|    21G|       |    11M (1)| 37:29:22 |
|   1 | SORT ORDER BY          |         |    89M|    21G|    22G|    11M (1)| 37:29:22 |
|   2 |   HASH UNIQUE           |         |    89M|    21G|    22G| 6305K (1)| 21:01:07 |
|* 3 |    HASH JOIN RIGHT OUTER|         |    89M|    21G|       | 1364K (1)| 04:32:53 |
|* 4 |     TABLE ACCESS FULL   | AUDLIB |     4 |   144 |       |     3   (0)| 00:00:01 |
|* 5 |     HASH JOIN           |         |    89M|    18G|       | 1363K (1)| 04:32:47 |
|   6 |      SORT UNIQUE        |         |   217 | 1519 |       |     1   (0)| 00:00:01 |
|   7 |       INDEX FULL SCAN   | AUDTRI2 |   217 | 1519 |       |     1   (0)| 00:00:01 |
|   8 |      TABLE ACCESS FULL | AUDTAB |   115M|    22G|       | 1363K (1)| 04:32:39 |
Predicate Information (identified by operation id):
   3 - access("X"."COTAB"="Y"."COTAB"(+))
   4 - filter(DECODE("Y"."COLAN"(+),'A',1,0)=1)
   5 - access("Z"."COTAB"="X"."COTAB")
Statistics
      69968 recursive calls
     245941 db block gets
    5209702 consistent gets
   13934882 physical reads
          0 redo size
SP2-0642: SQL*Plus internal error state 1075, context 1:5:4294967295
Unsafe to proceed
   87116279 bytes received via SQL*Net from client
    7919631 SQL*Net roundtrips to/from client
          1 sorts (memory)
          1 sorts (disk)
118794436 rows processedI will ask today the development team about the aim of retrieving 100 millions rows.

Similar Messages

ORA-01652 and ORA-02063 in select with dblink

Hello,
I execute the following select in a Oracle database:
SELECT HAC.ENT_ID, HAC.MAT, HAC.IDAC,
NVL(HAC.DATINI, 0) AS DATINI, NVL(HAC.DATEND, 0) AS DATEND,
HAC.TIP, GAP.IDAC AS IDAC_GAP, HAP.IDAC AS IDAC_HAP
FROM USER1.GAP GAP, HAC@DBLINK HAC, HAP@DBLINK HAP
WHERE
HAC.IDAC IN (SELECT DISTINCT IDAC FROM USER1.GAC)
AND HAC.IDAC = GAP.IDAC (+)
AND HAC.IDAC = HAP.IDAC (+)
GAP 157133 regs (873mb)
GAC 13555 regs (462mb)
HAC 57198111 regs (17985mb)
HAP 3940407 regs (14184mb)
GAP, GAC, HAC and HAP are views.
The result is:
ORA-01652: unable to extend temp segment by in tablespace
ORA-02063: preceding line from DBLINK
The tablespace temporal of the local database used is:
TABLESPACE_NAME|USED_EXTENTS|USED_BLOCKS|FREE_EXTENTS|FREE_BLOCKS
ATMP |0 |0 |3157 |409404
It is this tablespace ATMP the one that fills
The tablespace temporal of the remote database is:
TABLESPACE_NAME|USED_EXTENTS|USED_BLOCKS|FREE_EXTENTS|FREE_BLOCKS
HTMP |0 |0 |3157 |409404
- Why happens this, and howto it is possible to solve?
- How count the space consume by a select?
- The select is not good? The intention of the select is to locate erroneous records and to count (dates and times) all the correct records.
- How is it possible to use another temporary tablespace apart from of default of USER1, ATMP?
- I have tried to divide also the select by the field MAT, but every select is late a lot of time, of the order of 4 minutes, and there are approximately 3000 MAT different
- If a solution was to increase ATMP, all that needs?
Thank you very much for the help,
Cesar Jorge

The explain plan is:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=CHOOSE          316037 G          2836986
MERGE JOIN          316037 G     35319894G     2836986
MERGE JOIN OUTER          2916 G     298814G     2834816
MERGE JOIN OUTER          2916 G     274366G     2834814
SORT JOIN          5 M     498 M     1025633
REMOTE          5 M     498 M     10551      DBLINK     SERIAL
SORT JOIN          51 M     440 M     1809181
VIEW     USER1.GAP     51 M     440 M     864
MERGE JOIN OUTER          51 M     1G     864
TABLE ACCESS BY INDEX ROWID     USER1.T9 (of view USER1.GAP)     882 K     15 M     826
INDEX FULL SCAN     USER1.IT9 (of view USER1.GAP) 12     882 K          26
SORT JOIN          5 K     51 K     34
INDEX FAST FULL SCAN     USER1.IB9 (of view USER1.GAP)     5 K     51 K     4
SORT JOIN          82      738      3
REMOTE          82      738      1      DBLINK     SERIAL
SORT JOIN          10 K     105 K     2170
VIEW     SYS.VW_NSO_1     10 K     105 K     2067
SORT UNIQUE          10 K     105 K     2067
TABLE ACCESS FULL     USER1.T3 (of view USER1.GAC)     10 K     105 K     1964
Regards

Error ORA-01652 while running select query

A select query returning millions of records is returning the following error.
SQL Error [
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
We requested DBA to increased the TEMP tablespace. He increased it to 20GB and also, changed to Autoextent.
When we executed the query again, we got the same error ?
What could be the reason of this issue and how it can be resolved ?

All sort operations that don't fit into the SORT_AREA_SIZE will go to the temp tablespace (they can be seen as direct writes in the trace file).
It can easy be the case, that your temp tablespace needs to be many GB in size [we have a table with millions of rows and for the loading/merging our temp is 80GB in size].
May be you can change your process of loading i.e. with this select you fill a intermediate table (with CTAS) and do your processing there or even try to do the processing in SQL while building the table. You could also try to do the processing with a cursor and BULK COLLECT LIMIT 100 and then inserting into the target table with the FORALL statement.

Although my temporary tablespace is enough space,the error occurs ORA-01652

Hello,
Although my temporary tablespace is enough space ,i am taking an error ORA-01652 and some dbfs in the tablespace are looks like as offline and it’s size looks like as 0 byte.
So that i am changing status of these datafiles to online with this command as follows;
ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp01.dbf' ONLINE;
Also, The disk that exist these datafiles was 0 in availibility.
When i issued the command df –k as follows
Filesystem kbytes used avail capacity Mounted on
/dev/vx/dsk/qdbpdg/volq23 20971520 20971520 0 100% /QDBP/q023
is pointed.
And then i have released space from disk
The current review is
/dev/vx/dsk/qdbpdg/volq14 157286400 21731141 127083885 15% /QDBP/q014
My queries and results are for the hint of about the problem:
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;
TABLESPACE |MB_TOTAL| MB_USED| MB_FREE
QT_LM_TMP |61440 |12| 61428 --temporary
TS_TEMP_SDPA |15360 |0| 15360 –temporary
Separately,i want to see you a view about alert log like points below.
KCF: write/open error block=0x1b6e0a online=1
file=3 /QDBP/q014/q014/temp/qt_lm_tmp03.dbf
error=27063 txt: 'SVR4 Error: 28: No space left on device
Additional information: -1
Additional information: 8192'
Automatic tempfile offline due to write error on
file 3: /QDBP/q014/q014/temp/qt_lm_tmp03.dbf
With sum,i have some question like below:
1)Although there is enough space on temporary tablespace why i take error ORA-01652?
2)Although there is enough space on temporary tablespace why databasefiles have offline status suddenly?
3) is it important fully rate of disk on operating system if there is enough space on temporary tablespace which has extend properties.
Best regards
Oya YALÇIN

Hi,
i don't make tablespaces offline mode.But neverthless i don't understant although there is enough space on tablespace why tablespaces are being offline status mode itself?
When i look at ‘ select file_name,status from dba_temp_files ‘ query on the database now.The result is like below;
FILE_NAME|STATUS
/QDBP/q023/q023/temp/qt_lm_tmp01.dbf|AVAILABLE
/QDBP/q023/q023/temp/qt_lm_tmp02.dbf|AVAILABLE
/QDBP/q014/q014/temp/qt_lm_tmp03.dbf|AVAILABLE
/QDBP/q023/q023/temp/ts_temp_sdpa01.dbf|AVAILABLE
/QDBP/q023/q023/temp/ts_temp_sdpa02.dbf|AVAILABLE
/QDBP/q014/q014/temp/qt_lm_tmp04.dbf|AVAILABLE
/QDBP/q014/q014/temp/qt_lm_tmp05.dbf|AVAILABLE
But when i look at first 3 dbf by orderly from tab of scripts about tablespaces on toad tool
i see that like below;
ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp01.dbf' OFFLINE;
ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp02.dbf' OFFLINE;
ALTER DATABASE TEMPFILE '/QDBP/q014/q014/temp/qt_lm_tmp03.dbf' OFFLINE;
And their size is look like 0 .
Regards
Oya.

ORA-12008: error in materialized view refresh path with ORA-01652

I have a temp tablespace with 2 tempfiles of 2GB each (total 4GB) but still refresh of materialized view is failing with following error:
5646690 - BIS Materialized View Refresh Program
ORA-12008: error in materialized view refresh path
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP1
I checked and temp ts is completly filled
SQL> select TABLESPACE_NAME, BYTES_USED, BYTES_FREE from V$TEMP_SPACE_HEADER;
TABLESPACE_NAME BYTES_USED BYTES_FREE
TEMP1 2147483648 0
TEMP1 2147483648 0
My question is how do I find out how much space I need for temp tablespace. what 's the best practise to size temp tablespace when running refresh. refresh is done by client who is submitting a request thru ebiz apps so I 'd like to size it correctly without having to keep guessing.
Thanks so much in advance for any help

Hello,
Temp tablespace size depends how much sort by , order by operation your application performing. You can create new temp tablespace and drop old one with bigger file size
CREATE TEMPORARY TABLESPACE TEMP02 TEMPFILE '\mypath_to_temp\TEMP02' SIZE 256M REUSE AUTOEXTEND ON NEXT 256M MAXSIZE 8192M EXTENT MANAGEMENT LOCAL;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP02;
Drop tablespace temp including contents; -- Make sure you delete on temp data files.Here is link for your reading purpose
http://www.idevelopment.info/data/Oracle/DBA_tips/Tablespaces/TBS_3.shtml
Regards
Edited by: OrionNet on Mar 6, 2009 6:15 PM

Query runs fine in 9i but results to ORA-01652 unable to extend temp in 10g

Hi,
We are having issues in running a SQL query in 10g. In 9i, it runs fine with no problems but when run in 10g, It takes forever and the temp tablespace grows very large upto 60GB until we get ORA-01652 error due to lack of disk space. This does not occur in 9i, where query runs in only 20 mins and does not take up temp that big. 9i version is 9.2.0.8. 10g is 10.2.0.3

Heres the SQL query:
SELECT
J2.EMPLID,
TO_CHAR(J2.EFFDT,'YYYY-MM-DD'),
J2.EFFSEQ,
J2."ACTION",
J2.ACTION_REASON,
TO_CHAR(J2.GRADE_ENTRY_DT,'YYYY-MM-DD'),
J2.COMPRATE,
J2.CHANGE_AMT,
J2.COMP_FREQUENCY,
J2.STD_HOURS,
J2.JOBCODE,
J2.GRADE,
J2.PAYGROUP,
PN2.NATIONAL_ID,
TO_CHAR(PC.CHECK_DT,'YYYY-MM-DD'),
SUM(PO.OTH_EARNS),
To_CHAR(SUM(PO.OTH_EARNS)),
PO.ERNCD,
'3',
TO_CHAR(PC.PAY_END_DT,'YYYY-MM-DD'),
PC.PAYCHECK_NBR
FROM PS_JOB J2,
PS_PERS_NID PN2,
PS_PAY_OTH_EARNS PO,
PS_PAY_CHECK PC
WHERE J2.EMPL_RCD = 0
AND PN2.EMPLID = J2.EMPLID
AND PN2.COUNTRY = 'USA'
AND PN2.NATIONAL_ID_TYPE = 'PR'
AND J2.COMPANY <> '900'
AND J2.EFFDT <= SYSDATE
AND PC.EMPLID = J2.EMPLID
AND PC.COMPANY = PO.COMPANY
AND PC.PAYGROUP = PO.PAYGROUP
AND PC.PAY_END_DT = PO.PAY_END_DT
AND PC.OFF_CYCLE = PO.OFF_CYCLE
AND PC.PAGE_NUM = PO.PAGE_NUM
AND PC.LINE_NUM = PO.LINE_NUM
AND PC.SEPCHK = PO.SEPCHK
AND EXISTS (SELECT ERNCD
FROM PS_P1_CMP_ERNCD P1_CMP
WHERE P1_CMP.ERNCD = PO.ERNCD AND EFF_STATUS = 'A')
GROUP BY J2.EMPLID,
J2.EFFDT,
J2.EFFSEQ,
J2.ACTION,
J2.ACTION_REASON,
J2.GRADE_ENTRY_DT,
J2.COMPRATE,
J2.CHANGE_AMT,
J2.COMP_FREQUENCY,
J2.STD_HOURS,
J2.JOBCODE,
J2.GRADE,
J2.PAYGROUP,
PN2.NATIONAL_ID,
PC.CHECK_DT,
PO.ERNCD,
'3',
PC.PAY_END_DT,
PC.PAYCHECK_NBR

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

Hi,
I am getting the following error while executing an insert query.
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP.
I have tried increasing the TEMP tbsp size it got resolved temporarily but occurred again after few days.
When the problem occured, following query shows all insert queries in TEMP tablespace and one of them consumes about 5GB and others are about 24MB.
SELECT S.sid || ',' || S.serial# sid_serial, S.username,
T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
T.sqladdr address, Q.hash_value, Q.sql_text
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 S.sid;
The insert query is :
INSERT INTO SEOSDATA (ENTRYID,DOMAINNAME,USERNAME,EVENTTYPE,LOGNAME,TIMSTAMP,SOURCE,COMPUTERNAME,EVENTID,EVENTCATEGORY,SEARCHSTRINGS,MSGTEXT) VALUES (ENTRYID_SEQ.NEXTVAL,:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11)
It is not expected that an insert query consumes such a huge memory.
Can someone help me in figuring out what the problem is.
What might have gone wrong? Seems like sorting is used, why an insert query uses sorting?
Regards
Ishu

Hi,
Insert statement should not use TEMP tablespace. Please check with following query which user and session id is using TEMP tablespace.
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;
Dilipkumar Patel.

DB13 Check and update optimizer stat error: ORA-01652: unable to extend tem

Hi SAP Gurus,
When running Check and Update Optimizer Statistics in DB13, an error occurs.
BR0280I BRCONNECT time stamp: 2011-03-10 06.35.52
BR0301E SQL error -1652 at location stats_tab_collect-16
ORA-01652: unable to extend temp segment by 12137 in tablespace SYSTEM
BR0886E Checking/collecting statistics failed for table SAPR3.ACCTIT
BR0280I BRCONNECT time stamp: 2011-03-10 06.36.49
BR0850I 3 of 39479 objects processed - 3.522 of 342.781 units done
BR0204I Percentage done: 1.03%, estimated end time: 15:47
Looking at tablespace SYSTEM in DB02, the percent used is 58. Auto-extent feature is OFF. Will turning the auto-extent ON, remove the error?

It seems like Your user (by a mistake) have tablespace SYSTEM as temporary tablespace.
Connect as sysdba in Your database and check which temp tablespaces awaiable, and size of them:
select tablespace_name, sum(bytes)/1024/1024 "Size of TEMP TBS in MB" from dba_temp_files group by tablespace_name;
Check which users having SYSTEM as tamp-tbs:
select username, temporary_tablespace from dba_users where temporary_tablespace like 'SYSTEM' order by 1;
Change those users to have one of your temp-tablespaces:
alter user &username temporary tablespace &&TempTBS;
It's also a good idea to have autoextend on on Your temp TBS, but remember to set maxsize so you doesn't fill up your disksystem.
Hope this solve Your problems.
Regards
Audun
DBA

ORA-01652: unable to extend temp segment by 9600 in tablespace TEMP

im just trying to execute a query with an analytic function used and this error occurs : ORA-01652: unable to extend temp segment by 9600 in tablespace TEMP
select substr(b.eff_dt,1,10) "Effective",b.amt,sum(b.amt) over (order by substr(b.eff_dt,1,10)) "running_sum"
from b_dl b, b_dl b2
where b.st_cd = '1'
and ( b.b_key is null or b.b_key not in(39,40,55,31,32,33,34,35,36,37,38,39,40,55,43,44))
and b.amt <> 0
please help

If you are not a DBA, then get in touch with your Database administrator and show him this problem. Your database is running out of TEMP tablespace because of the sorting needed by this query.
BTW, How many rows are being processed in this self join query?

ORA-01652 unable to extend temp segment in 11gR2 with ASM and 2 node RAC

Hi ,
I have a 11.2.0.1 system with 2 node RAC and ASM . We are hitting ORA-01652 very frequently
and I can see space is available in TEMP .
CREATE TEMPORARY TABLESPACE "TEMP" TEMPFILE
SIZE 21474836480,
SIZE 137437904896
AUTOEXTEND ON NEXT 655360 MAXSIZE 131071M ( Will the next size ignored as the extent size is 1MB ?)
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576
And during the failure
SELECT tablespace_name,
total_blocks,
used_blocks,
free_blocks,
total_blocks*32768/1024/1024 as total_MB,
used_blocks*32768/1024/1024 as used_MB,
free_blocks*32768/1024/1024 as free_MB
FROM gv$sort_segment;
TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS TOTAL_MB USED_MB FREE_MB
TEMP 4849568 2385728 2463840 151549 74554 76995
TEMP 0 0 0 0 0 0
Also when I checked from v$sort_usage I see only two session consuming space
SQL> SELECT b.tablespace tablespace,
2 -- b.segfile#,
3 -- b.segblk#,
4 b.blocks,
5 b.blocks * (SELECT value FROM v$parameter WHERE name = 'db_block_size')/1024/1024 bytes,
6 a.sid,
7 a.username username,
8 a.osuser osuser,
9 a.inst_id,a.sid,a.serial#,a.module
10 FROM gv$session a, gv$sort_usage b
11 WHERE a.saddr = b.session_addr and
12 b.blocks != 16 and
13 a.inst_id = b.inst_id
14 ORDER BY b.tablespace, b.blocks, bytes desc;
BLOCKS BYTES SID USERNAME OSUSER INST_ID SID SERIAL# MODULE
1,192,864 37277 381 CN obiqb 2 381 860 nqsserver@icmqapp01cdp (TNS V1
1,192,864 37277 3952 CN obiqb 2 3952 1374 nqsserver@icmqapp01cdp (TNS V1
2,385,728 74554 (mb)
Wat is causing the 1652 ?

877394 wrote:
Thanks Srini,
But I did try all that notes with no luck .
I have a temporary tablespace with 150gb (130+20) datafiles .
TABLESPACE_NAME FILE_NAME (BYTES/1024/1024)
TEMP +DATA_01/tempfile/temp.314.743964            131071
TEMP +DATA_01/tempfile/temp.312.757303             20480
and the DDL is
CREATE TEMPORARY TABLESPACE "TEMP" TEMPFILE
SIZE 21474836480,
SIZE 137437904896
AUTOEXTEND ON NEXT 655360 MAXSIZE 131071M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576
And on querying v$sort_usage
SQL> SELECT b.tablespace tablespace,
2 -- b.segfile#,
3 -- b.segblk#,
4 b.blocks,
5 b.blocks * (SELECT value FROM v$parameter WHERE name = 'db_block_size')/1024/1024 bytes,
6 a.sid,
7 a.username username,
8 a.osuser osuser,
9 a.inst_id,a.sid,a.serial#,a.module
10 FROM gv$session a, gv$sort_usage b
11 WHERE a.saddr = b.session_addr and
12 b.blocks != 16 and
13 a.inst_id = b.inst_id
14 ORDER BY b.tablespace, b.blocks, bytes desc;
TABLESPACE BLOCKS BYTES SID OSUSER INST_ID SID SERIAL# MODULE
TEMP 63,328 1,979 3952 CN 2 3952 1374
TEMP 84,384 2,637 381 CN 2 381 860
TEMP 433,184 13,537 381 CN 2 381 860
TEMP 1,117,728 34,929 3952 CN 2 3952 1374
sum 1,698,624 53,082 (mb)
So the space utilization was less than 150gb and on querying v$sort_Segment
SQL> SELECT tablespace_name,
total_blocks,
used_blocks,
free_blocks,
total_blocks*32768/1024/1024 as total_MB,
used_blocks*32768/1024/1024 as used_MB,
free_blocks*32768/1024/1024 as free_MB
FROM gv$sort_segment;
TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS TOTAL_MB USED_MB FREE_MB inst
TEMP 4849568 2311104 2538464 151549 72222 79327 2
TEMP 0 0 0 0 0 0 1
why for inst 1 it is showing 0 (which means no sort is happening in instance 1)
But still we got the error
ORA-1652: unable to extend temp segment by 32 in tablespace TEMP
01652, 00000, "unable to extend temp segment by %s in tablespace %s"
// *Cause: Failed to allocate an extent of the required number of blocks for
//          a temporary segment in the tablespace indicated.
// *Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more
//          files to the tablespace indicated.

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP2

Dear all,
received this error when generate a report.
check the TEMP1 and TEMP2 they all have lot of spaces.
check the env $APPLLCSP return empty.
Please advise how to correct this error.
Regards,
Payables: Version : 12.0.0
APXSSIMP module: Supplier Sites Open Interface Import
APPLLCSP Environment Variable set to :
Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :
American_America.UTF8
Enter Password:
REP-0069: Internal error
REP-57054: In-process job terminated:Terminated with error:
REP-300: MSG-00001: After SRWINIT
MSG-00002: After Get_Company_Name
MSG-00003: After Get_NLS_Strings
MSG-00004: After Importing Suppliers
MSG-00005: After Get_Header_Information
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP2
==> SELECT assi.org_id C_Rejected_Org_Id,
MSG-00020: After SRWEXIT
Report Builder: Release 10.1.2.0.2 - Production on Mon May 11 09:55:36 2009

>
check the TEMP1 and TEMP2 they all have lot of spaces.
>
How much is "lot" ? :-) How did you determine this "lot" ?
Pl see MOS Doc 1025288.6 (How to Diagnose and Resolve UNABLE TO EXTEND Errors)
HTH
Srini

ORA-01007 - variable not in select list error in pl\sql code

Hi,
When I tried to run this program I am getting below error:
ORA-01007 - variable not in select list.Please help to resolve.
Code:
create or replace procedure "XX_BPM_DATA_P" (P_PROCESS_ID IN VARCHAR2)
is
TYPE l_entity_type IS TABLE OF xx_BPM_data.ENTITY%TYPE INDEX BY PLS_INTEGER;
TYPE l_data_type IS TABLE OF XX_BPM_DATA.DATA%TYPE INDEX BY PLS_INTEGER;
TYPE l_count_type IS TABLE OF XX_BPM_DATA.count%TYPE INDEX BY PLS_INTEGER;
l_Entity_v l_Entity_type;
l_data_v l_data_type;
l_count_v l_count_type;
l_security_group_id number;
app_id number(20);
l_Actual_value XX_BPM_DATA.DATA%TYPE;
cursor BPM_CUR is select id,process_id , sequence, to_char(query) query,report_num from xx_test_bpm_dynamic
where
    process_id = p_process_id
       and report_num=1
order by process_id, sequence;
BEGIN
--delete xx_bpm_data where process_id = p_process_id;
for bpm_rec in bpm_cur
loop
delete xx_bpm_data
where process_id = bpm_rec.process_id
and sequence = bpm_rec.sequence
and report_num = bpm_rec.report_num;
l_security_group_id := apex_custom_auth.get_session_id_from_cookie;
--dbms_output.put_line(l_security_group_id);
execute immediate bpm_rec.query BULK COLLECT INTO l_ENTITY_v,l_DATA_v,l_count_v;
if (bpm_rec.report_num=2) then
app_id:= 108;--NV('APP_ID');
FORALL i IN l_ENTITY_v.FIRST..L_ENTITY_V.LAST
INSERT INTO XX_BPM_DATA
    (EnTITY,
value,data,count,
Process_ID,
Sequence,report_num)
VALUES(l_entity_v(i),
l_data_v(i),
'<A HREF="f?p='||app_id||':301:'||':APP_SESSION'||'::::P301_process_id,p301_sequence,p301_id,p301_entity:'||bpm_rec.process_id||','||bpm_rec.sequence||','||bpm_rec.id||','||l_entity_v(i)||':">'||l_data_v(i)||'</A>',
    l_count_v(i),bpm_rec.process_id,
BPM_rec.sequence,
bpm_rec.report_num);
else
FORALL i IN l_ENTITY_v.FIRST..L_ENTITY_V.LAST
INSERT INTO XX_BPM_DATA(EnTITY,data,
    count,
Process_ID,
Sequence,report_num)
VALUES(l_entity_v(i),
l_data_v(i),
    l_count_v(i),
    bpm_rec.process_id,
BPM_rec.sequence,
bpm_rec.report_num);
end if;
select round(avg(value),2) into l_actual_value from xx_bpm_data where process_id=bpm_rec.process_id and sequence=bpm_rec.sequence and report_num=bpm_rec.report_num;
update xx_test_bpm_dynamic set value=l_actual_value where process_id=bpm_rec.process_id and sequence=Bpm_rec.sequence and report_num= bpm_rec.report_num;
end loop;
Commit;
END;

When I tried to run this program I am getting below error:
ORA-01007 - variable not in select list.Please help to resolve.
You likely would not need any help in you wrote and tested your code using standard best practices.
Your code has NO exception handler and you are NOT identifying each step in the code so that the exception handler could print/log a message telling you EXACTLY which step raised the exception.,
v_step NUMBER;
-- before step 1
v_step := 1;
-- before step 2
v_step := 2;
Then in the exception handler the value of 'v_step' will tell you which step raised the exception.
The exception you posted refers to a 'select list' so examine ALL of the select lists in your code. If you do that you will see that the primary query being run is obtained from a database table and then executed using dynamic SQL
execute immediate bpm_rec.query BULK COLLECT INTO l_ENTITY_v,l_DATA_v,l_count_v;
We have no way of knowing what query is in 'bpm_rec.query' when the exception happens or what columns that query returns. For all we know the query returns 2 columns and you are trying to load 3 collections. Or maybe the query returns 8 columns and you are trying to load 3 collections.
Why don't you print out the query and execute it manually so you can see exactly what the result set looks like?
dbms_output.put_line(bpm_rec.query);
And don't even get us started on why you are using such security-prone dynamic sql to perform this processing instead of using ordinary SQL statements. Or why you are using associative arrays for the BULK COLLECT instead of nested tables.
In short your code could blow up in several places and, because you have NO logging statements, control statements or exception handlers, anyone having to troubleshoot that code would have absolutely no idea what part of it may be the problem.

How is it possibile that a max in a subquery gets a ORA-01652?

I've got a very complex query
Let's suppose having three tables whose alias are x, y and z (and others tables)
Inside the WHERE of the query I've got something like:
x.x2 = (select max(y.y2) from mytable y where y.y1 = z.z1)
If I try to execute it on a single key, after a while I get a
ORA-01652: unable to extend temp segment by ...
if I try to change the line above with this:
x.x2 = constant
and then I execute it, I get the result within few seconds.
Even if I change the line with this:
x.x2 in (select y.y2 from table y where y.y1 = z.z1)
the query works, even if I get more rows.
How is it possibile that the MAX in the subquery makes the whole of the query not to work?
My Oracle version is 8i
Thanks!

You can easily answer this question by looking at the PLAN for this statement.
MAX uses a SORT operation and sort will use temporary segment, if the memory required exceeds the PGA.
Sybrand Bakker
Senior Oracle DBA

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

ORA - 12801 and ORA - 01652 ?

Hello gurus,
I was running a query on Oracle 11g RAC. One of the table has about 7 billions records
Here is the error i got
ORA-12801: error signaled in parallel query server
ORA-01652: unable to extend temp segment by 128 in tablespace TEMPAny idea, what could be wrong ??
Thank you!! Appriciate it !!

Dear user642297,
In order to get rid of that error, you need to increase the temporary tablespace called TEMP and i think it is the default one for your situation.
You can also check below link;
http://www.dba-oracle.com/t_ora_12801_parallel_query.htm
But there is a comment that says increase the sort_area_size, don't do that since you are running on 11g. Instead of that parameter, increase or decrease the PGA_AGGREGATE_TARGET.
Hope That Helps.
Ogan

ORA-01652 due to a SELECT DISTIINCT...ORDER BY

Similar Messages

Maybe you are looking for