Temporary Tablespace growing Rapidly

Hi
My temporary tablespace is getting too large,now it is about 19GB,
How can i mange it?How can i decrease it's size?
Thank You In Advance

Select from v$session & v$sort_usage to find out who is using the space. If no one is using the space currently the you can rebuild.
for example:-
CREATE
TEMPORARY TABLESPACE "TMP" TEMPFILE
'C:\oradata\TMP1.dbf' SIZE 2000M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 131072K;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE "TMP";
Then drop TEMP including datafiles.
If the name is needed you could then create a TEMP tablespace and return to the original name. The key to all of this is being able to monitor who is using TEMP space and why.
N.B. I like setting a large uniform size to ensure most TEMP requests get the space in one hit per segment.

Similar Messages

Temporay tablespace grows rapidly. . .

Dear All,
When I run a large query the temporary tablespace grows continuously.
The max size of temporary tablespace is 6G.
I set Autoextend on, next size is 10m and maxsize is 6291456M.
Also I set the SORT_AREA_SIZE = 256m.
How to stop the rapid growth of temporary tablespace.
Thanks in advance,
PratHamesh.

If your Oracle version is 9i you can set your PGA_AGGREGATE_TARGET into a appropriate value(i.e. PGA_AGGREGATE_TARGET=1G to avoid sorting on TEMP tablespace.
Frequently sorting happens on your DB and it supposed to shrink.
You can also think of allocating other users to an specific TEMP tablespace but you have to identify which users it is.

EBS Database R12.1 temporary tablespace grow too quick??

we have a EBS R12.1 database on Redhat LINUX server. Recently this database every day Temporary tablespace grow at least 1 GB. This database temporary tablespace (with two temp files) has been grow to 45 GB.
Does anyone know what wrong?
How to fix problem?

I eventually figure out this temporary tablespace grow is cause by OEM.
SQL statement is:
/* OracleOEM */ SELECT end_time, status, session_key, session_recid, session_stamp, command_id, start_time, time_taken_
display, input_type, output_device_type, input_bytes_display, output_bytes_display, output_bytes_per_sec_display
FROM (SELECT end_time, status, session_key, session_recid, session_stamp, command_id, start_time,
time_taken_display, input_type, output_device_type, input_bytes_display, output_bytes_di
splay, output_bytes_per_sec_display FROM v$rman_backup_job_details ORDER BY end_time DESC) WHERE rownum
= 1;
ANyone know why this statement will take 30GB temporary space on EBS R12.1?
Thanks.

PSAPSID tablespace grows rapidly

Hi All,
We are having a BI7[SP11] system on oracle. All were normal operations till the 1 month past. This month, we have been observing that the PSAP<SID> tbspc has been growing rapidly very much. When checked with functionals no extra loads were used.
Now I can monitor from DB02 on the tbspc by checking the history, when more delta occured, but I wanted to see which table, related to which data, all that delta happened, so that i can check with functionals.
Is there anyway to still dig this and get the proof. Can any body please help..
Thanks a lot
VR.

Hi Vera,
I would recommend to you if you wish to see the table, via the table space name, in transaction DB02, and then relate that to the table in your BW system.
I would use the following steps
Monitor in DB02 and then get your table space name
Under DB02 you should see under the "Space" drill down a option called "Tables and Indexes" double click on this option
Hopefully your basis team would of Reorged the tables so you have the latest stats
Hit continue then enter your table space name as selection criteria
From here you can get the table space name,
Take your table space name and enter this into the table SE16 RSTSODS you should be able to get the generic PSA name that is being wrote to
Other wise if it is not in this table you should have a very good idea of what sort of data is being recorded by the naming convention.
Thanks
Ben
**Please assign points if helpful**

APPS_TS_MEDIA tablespace growing rapidly

Hi,
The APPS_TS_MEDIA tablespace stores all the attached documents in Oracle Applications. But it is growing at a very rapid rate.
Is there a way to delete the old attachments from this tablespace?
When users raise a PO/PR, they attach the document along with the PR. But once the PR is closed, we no longer require those attachments.
Could someone please let me know if there is any way of deleting those old files from APPS_TS_MEDIA tablespace?
Thanks!

OWNER     SEGMENT_NAME          SEGMENT_TYPE     SIZ
APPLSYS     SYS_LOB0000057442C00004$$     LOBSEGMENT     53,561,262,080
APPLSYS     FND_LOBS               TABLE          114,294,784
APPLSYS     SYS_IL0000057442C00004$$     LOBINDEX     22,544,384
APPLSYS     FND_LOBS_N1          INDEX          2,359,296
APPLSYS     FND_LOBS_U1          INDEX          2,097,152
CSF     CSF_MD_LYR_METADATA     TABLE          131,072
CSF     CSF_MD_RD_SEGS          TABLE          131,072
CSF     CSF_TDS_BINARY_TILES     TABLE          131,072
CSF     CSF_TDS_SEGMENTS          TABLE          131,072
CSF     SYS_IL0000060656C00011$$     LOBINDEX     131,072
CSF     SYS_IL0000061938C00007$$     LOBINDEX     131,072
CSF     SYS_IL0000061011C00013$$     LOBINDEX     131,072
CSF     SYS_LOB0000060628C00010$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060628C00011$$     LOBSEGMENT     131,072
CSF     CSF_LF_ROADSEGMENTS     TABLE          131,072
CSF     CSF_MD_RAIL_SEGS          TABLE          131,072
CSF     SYS_IL0000060656C00010$$     LOBINDEX     131,072
CSF     SYS_IL0000061068C00016$$     LOBINDEX     131,072
CSF     SYS_IL0000061938C00008$$     LOBINDEX     131,072
CSF     SYS_IL0000209418C00012$$     LOBINDEX     131,072
CSF     SYS_IL0000060957C00013$$     LOBINDEX     131,072
CSF     SYS_IL0000061112C00011$$     LOBINDEX     131,072
CSF     SYS_IL0000060704C00011$$     LOBINDEX      131,072
QP     QP_DOCUMENTS_U1          INDEX          131,072
CSF     SYS_LOB0000060588C00018$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060869C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061979C00003$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000062083C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209422C00011$$     LOBSEGMENT     131,072
CSF     CSF_LF_NAMES          TABLE          131,072
CSF     CSF_LF_PLACE_NAMES          TABLE          131,072
CSF     CSF_LF_POIS          TABLE          131,072
CSF     CSF_LF_ROADSEGM_PLACES     TABLE          131,072
CSF     CSF_MD_INST_STYLE_SHTS     TABLE          131,072
CSF     CSF_MD_NAMES          TABLE          131,072
CSF     CSF_TDS_ROADBLOCKS     TABLE          131,072
CSF     CSF_MD_OM_ROADS          TABLE          131,072
CSF     SYS_IL0000061938C00005$$     LOBINDEX      131,072
CSF     SYS_IL0000061068C00017$$     LOBINDEX 131,072
CSF     SYS_IL0000060588C00018$$     LOBINDEX      131,072
FRM     SYS_IL0000285924C00004$$     LOBINDEX      131,072
CSF     SYS_LOB0000060588C00017$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060656C00010$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060656C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060704C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061068C00016$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061938C00005$$     LOBSEGMENT     131,072
CSF     CSF_LF_PLACES          TABLE          131,072
CSF     CSF_LF_POI_NAMES          TABLE          131,072
CSF     CSF_LF_ROADSEGM_POSTS     TABLE          131,072
CSF     CSF_MD_LAND_USES          TABLE          131,072
CSF     CSF_MD_POI_NM_ASGNS     TABLE          131,072
CSF     CSF_MD_THEME_METADATA     TABLE          131,072
CSF     CSF_TDS_CONDITIONS     TABLE          131,072
CSF     CSF_TDS_TILES          TABLE          131,072
CSF     CSF_MD_OM_POIS          TABLE          131,072
FRM     FRM_REPOSITORY_LOBS     TABLE          131,072
CSF     SYS_IL0000060588C00017$$     LOBINDEX      131,072
CSF     SYS_IL0000061979C00004$$     LOBINDEX      131,072
CSF     SYS_IL0000062083C00011$$     LOBINDEX      131,072
CSF     SYS_IL0000209418C00011$$     LOBINDEX      131,072
CSF     SYS_IL0000209420C00012$$     LOBINDEX      131,072
CSF     SYS_IL0000061112C00010$$     LOBINDEX      131,072
CSF     SYS_IL0000060704C00012$$     LOBINDEX      131,072
CSF     SYS_LOB0000060897C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061011C00013$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061112C00010$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061156C00028$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061938C00008$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000062261C00013$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209418C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209422C00010$$     LOBSEGMENT     131,072
CSF     CSF_LF_ROADSEGM_NAMES     TABLE          131,072
CSF     CSF_MD_ADM_BOUNDS     TABLE          131,072
CSF     CSF_MD_HYDROS          TABLE          131,072
CSF     CSF_TDS_BINARY_MAPS     TABLE          131,072
CSF     CSF_TDS_NODES          TABLE          131,072
CSF     CSF_TDS_RDBLCK_INTVLS     TABLE          131,072
CSF     SYS_IL0000062083C00010$$     LOBINDEX      131,072
CSF     SYS_IL0000060628C00010$$     LOBINDEX      131,072
CSF     SYS_IL0000061011C00012$$     LOBINDEX      131,072
CSF     SYS_IL0000209422C00010$$     LOBINDEX      131,072
CSF     SYS_IL0000060957C00012$$     LOBINDEX      131,072
CSF     SYS_LOB0000060897C00013$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060957C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060957C00013$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061011C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061938C00007$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061979C00004$$     LOBSEGMENT     131,072
QP     SYS_LOB0000296934C00002$$     LOBSEGMENT     131,072
CSF     CSF_MD_LYR_STYLE_SHTS     TABLE          131,072
CSF     CSF_TDS_COND_SEGS          TABLE          131,072
CSF     CSF_TDS_INTERVALS          TABLE          131,072
CSF     SYS_IL0000061979C00003$$     LOBINDEX      131,072
CSF     SYS_IL0000060628C00011$$     LOBINDEX      131,072
CSF     SYS_IL0000060869C00013$$     LOBINDEX      131,072
CSF     SYS_IL0000061156C00028$$     LOBINDEX      131,072
CSF     SYS_IL0000061156C00029$$     LOBINDEX      131,072
CSF     SYS_IL0000209424C00011$$     LOBINDEX      131,072
CSF     SYS_IL0000209420C00011$$     LOBINDEX      131,072
CSF     SYS_IL0000060897C00012$$     LOBINDEX      131,072
CSF     SYS_IL0000060897C00013$$     LOBINDEX      131,072
CSF     SYS_IL0000062261C00014$$     LOBINDEX      131,072
CSF     SYS_LOB0000061938C00006$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209424C00010$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209424C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209420C00012$$     LOBSEGMENT     131,072
FRM     SYS_LOB0000285924C00004$$     LOBSEGMENT     131,072
CSF     CSF_MD_POIS          TABLE          131,072
CSF     CSF_MD_RDSEG_NM_ASGNS     TABLE          131,072
CSF     CSF_MD_OM_HYDROS          TABLE          131,072
CSF     SYS_IL0000061938C00006$$     LOBINDEX     131,072
CSF     SYS_IL0000060869C00012$$     LOBINDEX     131,072
CSF     SYS_IL0000062261C00013$$     LOBINDEX     131,072
FRM     FRM_REPOSITORY_LOBS_N1     INDEX          131,072
QP     SYS_IL0000296934C00002$$     LOBINDEX     131,072
CSF     SYS_LOB0000060704C00012$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000060869C00013$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061068C00017$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061112C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000061156C00029$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209418C00011$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000209420C00011$$     LOBSEGMENT     131,072
CSF     CSF_LF_PLACE_POSTCS     TABLE          131,072
CSF     CSF_LF_POSTCODES          TABLE          131,072
CSF     CSF_TDS_RDBLCK_SGMNTS     TABLE          131,072
CSF     CSF_TDS_SEGM_NODES     TABLE          131,072
CSF     CSF_MD_OM_ADMINS          TABLE          131,072
QP     QP_DOCUMENTS          TABLE          131,072
CSF     SYS_IL0000209424C00010$$     LOBINDEX     131,072
CSF     SYS_IL0000209422C00011$$     LOBINDEX     131,072
FRM     FRM_REPOSITORY_LOBS_UK1     INDEX          131,072
CSF     SYS_LOB0000062083C00010$$     LOBSEGMENT     131,072
CSF     SYS_LOB0000062261C00014$$     LOBSEGMENT     131,072
I looked into thoe MOS, but nothing seems to help!
I have raised a TAR with Oracle and they say, this functionality of deleting attachment doesnt exist and they are finding a solution for it.
Thanks!

Shrinking a Locally Managed Temporary Tablespace

So, even thoguh the documentation is pretty clear about how to use this feature, I cannot get it to do what I expect it to do for me.
And that would be shrinking the tempfile ;)
Now lets face it, I have a large tempfile and want to resize it without restarting the database:
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Di Nov 20 05:49:59 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
SQL> select file_name
, ceil(bytes / 1024 / 1024) "size MB"
from dba_temp_files
FILE_NAME size MB
R:\MXVC01\TEMP01.DBF 31,231
SQL> select su.username
, ses.sid
, ses.serial#
, su.tablespace
, ceil((su.blocks * dt.block_size) / 1048576) MB
from v$sort_usage su
, dba_tablespaces dt
, v$session ses
where su.tablespace = dt.tablespace_name
and su.session_addr = ses.saddr
USERNAME SID SERIAL# TABLESPACE MB
VPXADMIN 15 15 TEMP 14
VPXADMIN 17 5 TEMP 1,203
VPXADMIN 17 5 TEMP 1
VPXADMIN 18 3 TEMP 7
VPXADMIN 19 3 TEMP 1
VPXADMIN 144 3 TEMP 1
VUMADMIN 156 2597 TEMP 1
7 rows selected.
Or this one:
SQL> select tablespace_size/1024/1024 "tablespace_size mb"
, allocated_space/1024/1024 "allocated_space mb"
, free_space/1024/1024 "free_space mb"
from dba_temp_free_space
tablespace_size mb allocated_space mb free_space mb
31230,9922 1228,99219 30002
Documetation from here: http://docs.oracle.com/cd/E11882_01/server.112/e25494/tspaces007.htm#ADMIN12353
+"Shrinking a Locally Managed Temporary Tablespace+
+Large sort operations performed by the database may result in a temporary tablespace growing and occupying a considerable amount of disk space. After the sort operation completes, the extra space is not released; it is just marked as free and available for reuse. Therefore, a single large sort operation might result in a large amount of allocated temporary space that remains unused after the sort operation is complete. For this reason, the database enables you to shrink locally managed temporary tablespaces and release unused space.+
+You use the SHRINK SPACE clause of the ALTER TABLESPACE statement to shrink a temporary tablespace, or the SHRINK TEMPFILE clause of the ALTER TABLESPACE statement to shrink a specific tempfile of a temporary tablespace. Shrinking frees as much space as possible while maintaining the other attributes of the tablespace or tempfile. The optional KEEP clause defines a minimum size for the tablespace or tempfile.+
+Shrinking is an online operation, which means that user sessions can continue to allocate sort extents if needed, and already-running queries are not affected.+
+The following example shrinks the locally managed temporary tablespace lmtmp1 to a size of 20M.+
+ALTER TABLESPACE lmtemp1 SHRINK SPACE KEEP 20M;+
+The following example shrinks the tempfile lmtemp02.dbf of the locally managed temporary tablespace lmtmp2. Because the KEEP clause is omitted, the database attempts to shrink the tempfile to the minimum possible size.+
+ALTER TABLESPACE lmtemp2 SHRINK TEMPFILE '/u02/oracle/data/lmtemp02.dbf';"+
OK, lets do it:
SQL> alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
It seems there is a bug? Should I report it, or is it the expected behaviour?
Now lets try this one:
SQL> alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF' keep 2048M;
Tablespace altered.
SQL> select file_name
, ceil(bytes / 1024 / 1024) "size MB"
from dba_temp_files
FILE_NAME size MB
R:\MXVC01\TEMP01.DBF 31,231
So .... this lasts about *10 minutes*, and nothing changes?
It seems there is a bug? Should I report it, or is it the expected behaviour?
Could someone enlighten me, what this SHRINK is actually doing?
Is it worth to report this as bug, if not a software bug it is at least a documentation bug because it doesn't mention under which conditions it is working?
P.S.: OMG the posting looks terrible, who's the one to blame for this forum software where it is not possible to use fixed size fonts, or format paragraphs as code, or what about the fact that the forum software is using default SQLPlus output as META for some graphical lines?
Isn't this the forum for Oracle Database users?
Edited by: Gerrit Haase on 20.11.2012 13:44

So, you are kidding with me? No? Who are you?
How can I block users here? Is there a moderator present at this forum?
Maybe you read my initial post again?
I didn't look at the wrong place.
I reported you for general abuse.
SQL> define
DEFINE _DATE           = "20.11.12" (CHAR)
DEFINE CONNECTIDENTIFIER = "MXVC01" (CHAR)
DEFINE _USER           = "SYS" (CHAR)
DEFINE _PRIVILEGE      = "AS SYSDBA" (CHAR)
DEFINE SQLPLUSRELEASE = "1102000200" (CHAR)
DEFINE _EDITOR         = "Notepad" (CHAR)
DEFINE OVERSION = "Oracle Database 11g Release 11.2.0.2.0 - 64bit Production" (CHAR)
DEFINE ORELEASE = "1102000200" (CHAR)
SQL> SELECT * FROM dba_temp_free_space;
TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
TEMP 3,2748E+10 1306517504 3,1443E+10
SQL> select TABLESPACE_SIZE/power(2,20), ALLOCATED_SPACE/power(2,20), FREE_SPACE/power(2,20) from dba_temp_free_space ;
TABLESPACE_SIZE/POWER(2,20) ALLOCATED_SPACE/POWER(2,20) FREE_SPACE/POWER(2,20)
31230,9922 1245,99219 29986
SQL> ALTER TABLESPACE temp SHRINK SPACE;
Tablespace altered.
SQL> select TABLESPACE_SIZE/power(2,20), ALLOCATED_SPACE/power(2,20), FREE_SPACE/power(2,20) from dba_temp_free_space ;
TABLESPACE_SIZE/POWER(2,20) ALLOCATED_SPACE/POWER(2,20) FREE_SPACE/POWER(2,20)
31230,9922 1244,99219 *29986*
R:\mxvc01>dir temp
Volume in drive R is Disk_R
Volume Serial Number is 248B-61D4
Directory of R:\mxvc01
20.11.2012 08:09 32.748.077.056 TEMP01.DBF
1 File(s) 32.748.077.056 bytes
0 Dir(s) 8.259.297.280 bytes free
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
*It clearly says that there is 29986 MB Space FREE and the above shrink space changes nothing and so does shrink tempfile:*
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF' KEEP 20M;
Tablespace altered.
R:\mxvc01>dir temp
Volume in drive R is Disk_R
Volume Serial Number is 248B-61D4
Directory of R:\mxvc01
20.11.2012 08:24 32.748.077.056 TEMP01.DBF
1 File(s) 32.748.077.056 bytes
0 Dir(s) 8.259.280.896 bytes free
*... nothing changes, the tempfile isn't smaller now ...*

Temporary tablespace questions

I have an Oracle 9.2.0.1.0 database running on a Windows 2000 server. I'm encountering several problems with its temporary tablespace. Here is how the temporary tablespace is created:
create database testdb
datafile 'd:\oradb\testdb\datafiles\testdbsys1.dbf'
size 200M AUTOEXTEND ON NEXT 10M
default temporary tablespace temporary
tempfile 'd:\oradb\testdb\datafiles\tmp1.dbf'
size 16400K reuse autoextend on next 16400K
undo tablespace undotbs
datafile 'd:\oradb\testdb\datafiles\testdbrbs1.dbf'
size 100M reuse autoextend on next 10M maxsize unlimited;
Questions:
1- Despite the fact that the temporary tablespace datafile is specified "autoextend on", it autoextends up to 4 Gb then it fails. The exact error is ORA-0652: unable to extend temp segment by 64 in tablespace TEMPORARY. If I manually extend it beyond 4 Gb, everything works fine. Is this a bug or is it something I do wrong ? If so, what should I do to correct this ?
2- I can't figure out what statement of my application makes the temporary tablespace grow so big. I looked at all the trace files in UDUMP and I noticed it's always the same statement that is logged when the "autoextend" error occurs. But when I run the statement on its own in SQLPlus, nothing special happens to the temporary tablespace. What is the best way to track what statement uses what resources of the temporary tablespace ?
3- I don't know if this is what happens, but it looks like space isn't reused in the temporary tablespace. Is this possible ? If so, how can I tell Oracle to reuse it ?
Thanks.

1-You can try to modify the maxsize for datafaile to UNLIMITED. I am not sure it shall work, but it's worth a try
2-Probably it's a statement that uses an order by on a large result set
3-You can try to force the wakeup of SMON process that would free the unused extents of temporary tablespace.
Try http://www.ixora.com.au/tips/admin/stray_temp.htm
There is also a script to force the wakeup of smon

Temp tablespace grow too big???

we have EBS R12.1 on LINUX X86_64 with ORACLE database version 11.1.0.7. every week we have temporary tablespace grow too big (> 32 GB) and out of extent.
Based on our research some some sql statement or report cause this issue. if we 'analyze stratistics", most time problem can fix. It cause us some time need run "analyze statistics" several times in one day.
Does anyone have solution for this?
Thanks.

Please see if these docs help.
Temporary Segments: What Happens When a Sort Occurs [ID 102339.1]
Queries to monitor Temporary Tablespace usage [ID 289894.1]
How Can Temporary Segment Usage Be Monitored Over Time? [ID 364417.1]
Thanks,
Hussein

Rapid and Huge growth of of used space of temporary tablespace

Hi,
Have a query (select) that run quick (no more than 10 seconds).
As soon I insert the data into a temporary table or even on physical table, the temporary table used space starts to growth very fast. The used space is totally used and the query crash since e reach the limit (65GB), or even more if I add more table files to temporary tablespace!
The problem also happen only if the period (dates) is one year (2013). If the period is the first trimestre of 2013 (same amount of data), the problem does not happen!!
I also confirm that on another instance ( a test one), even with less resources this ORACLE behavior do not happen. I confirm differente execution plan queries, between the two instances .
What I really do not understant is the behavior of the ORACLE with the huge and rapid growth!!!
Any one experiment such a similiar situation?
Thanks in advance,Rui
Plan
INSERT STATEMENT ALL_ROWSCost: 15.776 Bytes: 269 Cardinality: 1
28 LOAD TABLE CONVENTIONAL MIDIALOG_OLAP.MED_INVCOMP_FACTTMP_BEFGROUPBY
27 FILTER
26 NESTED LOOPS
24 NESTED LOOPS Cost: 15.776 Bytes: 269 Cardinality: 1
22 NESTED LOOPS Cost: 15.775 Bytes: 255 Cardinality: 1
19 NESTED LOOPS Cost: 15.774 Bytes: 205 Cardinality: 1
17 NESTED LOOPS Cost: 15.773 Bytes: 197 Cardinality: 1
14 NESTED LOOPS Cost: 15.770 Bytes: 180 Cardinality: 1
11 NESTED LOOPS Cost: 15.767 Bytes: 108 Cardinality: 1
9 HASH JOIN Cost: 15.757 Bytes: 8.346.500 Cardinality: 83.465
7 HASH JOIN Cost: 13.407 Bytes: 6.345.012 Cardinality: 83.487
5 HASH JOIN Cost: 11.163 Bytes: 5.010.550 Cardinality: 100.211
3 HASH JOIN Cost: 5.642 Bytes: 801.288 Cardinality: 22.258
1 INDEX RANGE SCAN INDEX MIDIALOG.IX_INSCOMP_DTCEIDICIDLCPECIDOP Cost: 120 Bytes: 489.676 Cardinality: 22.258
2 INDEX FAST FULL SCAN INDEX (UNIQUE) MIDIALOG.IX_LINHACOMPRADA_IDLCIDOPSEQ Cost: 5.463 Bytes: 123.975.530 Cardinality: 8.855.395
4 INDEX FAST FULL SCAN INDEX (UNIQUE) MIDIALOG.IX_LINHACOMPRADA_IDLCIDOPSEQ Cost: 5.463 Bytes: 123.975.530 Cardinality: 8.855.395
6 TABLE ACCESS FULL TABLE MIDIALOG.ITEM_AV Cost: 1.569 Bytes: 6.963.736 Cardinality: 267.836
8 TABLE ACCESS FULL TABLE MIDIALOG.ITEM_AV Cost: 1.572 Bytes: 7.713.672 Cardinality: 321.403
10 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.IX_BOFINALBO_IDBOIDFINALBO Cost: 0 Bytes: 8 Cardinality: 1
13 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.INSERCAO_COMPRADA Cost: 3 Bytes: 72 Cardinality: 1
12 INDEX RANGE SCAN INDEX (UNIQUE) MIDIALOG.IX_INSCOMPRADA_IDLCDATAPECAINS Cost: 2 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.INSERCAO_ITEMFACTURA Cost: 3 Bytes: 17 Cardinality: 1
15 INDEX RANGE SCAN INDEX MIDIALOG.IX_INSITFACT_INSCOMPRADA Cost: 2 Cardinality: 1
18 INDEX RANGE SCAN INDEX (UNIQUE) MIDIALOG.UQ_ITEMFACTURA_IDITF_IDFACT Cost: 1 Bytes: 8 Cardinality: 1
21 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.FATURA Cost: 1 Bytes: 50 Cardinality: 1
20 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.PK_FATURA Cost: 0 Cardinality: 1
23 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.PK_TIPO_ESTADO Cost: 0 Cardinality: 1
25 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.TIPO_ESTADO Cost: 1 Bytes: 14 Cardinality: 1
Edited by: rr**** on 19/Fev/2013 15:25

I run the select with sucess, no more that 1 minute from on year of data. Few temporary used space used.
As soon I plug the insert (global temporary table, also experiment with physical table) the used space of temporary table space start to grow crazy!!
insert into midialog_olap.med_invcomp_facttmp_befgroupby
select fac.numefatura,
fac.codpessoa,
fac.dtemiss,
tef.nome as estado_factura,
opsorig.demid,
opsorig.anoplano,
opsorig.numplano,
opsorig.numplanilha,
ops.nome as ordem_publicidade,
ops.external_number as numero_externo,
ops.estado,
lic.seq,
inc.data,
inc.peca,
fac.id_versao_plano,
fac.ano_proforma || '.' || fac.numrf as num_proforma,
iif.tipo_facturacao,
opsorig.codveiculo as id_veiculo,
opsorig.codfm as id_fornecedor_media,
icorig.chkestado as id_estado_checking,
0 as percentagem_comissao_agencia,
0 as valor_pbv,
0 as valor_stxtv,
0 as valor_ptv,
0 as valor_odbv,
0 as valor_pbbv,
0 as valor_dnv,
0 as valor_pbnv,
0 as valor_stxv,
0 as valor_pbtv,
0 as valor_dav,
0 as valor_plv,
0 as valor_odlv,
0 as valor_pllv,
0 as valor_ca,
0 as valor_trv,
0 as valor_txv,
0 as valor_base_facturacao,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pb_compra * fac.percentagem_facturada / 100))
as valor_pbc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_stxt_compra * fac.percentagem_facturada / 100))
as valor_stxtc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pt_compra * fac.percentagem_facturada / 100))
as valor_ptc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_odb_compra * fac.percentagem_facturada / 100))
as valor_odbc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pbb_compra * fac.percentagem_facturada / 100))
as valor_pbbc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_dn_compra * fac.percentagem_facturada / 100))
as valor_dnc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pbn_compra * fac.percentagem_facturada / 100))
as valor_pbnc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_stx_compra * fac.percentagem_facturada / 100))
as valor_stxc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pbt_compra * fac.percentagem_facturada / 100))
as valor_pbtc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_da_compra * fac.percentagem_facturada / 100))
as valor_dac,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pl_compra * fac.percentagem_facturada / 100))
as valor_plc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_odl_compra * fac.percentagem_facturada / 100))
as valor_odlc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_pll_compra * fac.percentagem_facturada / 100))
as valor_pllc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_transcricoes * fac.percentagem_facturada / 100))
as valor_trc,
decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
inc.total_tx_compra * fac.percentagem_facturada / 100))
as valor_txc,
--nvl((select cfm.total_comprado
-- from fin_custos_facturados_media cfm
-- where cfm.id_factura = fac.id_factura and
- -- cfm.id_op = ops.id_op
-- ), 0) / opsorig.number_of_bought_insertions as custos_associados,
0 as custos_associados,
fac.iss as percentagem_iva,
fac.percentagem_facturada,
fac.currency_exchange as taxa_cambio,
iif.associated_code as insertions_associated_code
from fatura fac, item_fatura itf, insercao_itemfactura iif,
insercao_comprada icorig, linha_comprada lcorig, item_av opsorig,
med_bookingorder_finalbo opfin,
insercao_comprada inc,
linha_comprada lic, item_av ops,
--veiculo vei,
tipo_estado tef
where fac.id_factura = itf.id_factura and
itf.id_itemfactura = iif.id_itemfactura and
iif.id_ic = icorig.id_ic and
icorig.id_lc = lcorig.id_lc and
lcorig.id_op = opsorig.id_op and
opsorig.id_op = opfin.id_booking_order and
opsorig.number_of_bought_insertions > 0 and
opfin.id_final_booking_order = ops.id_op and
-- ops.id_op = (
-- select max(ops.id_op)
-- from item_av ops
-- start with ops.id_op = opsorig.id_op
-- connect by prior ops.id_opsubstituicao = ops.id_op) and
ops.id_op = lic.id_op and
lic.seq = lcorig.seq and
lic.id_op = inc.id_op and
lic.id_lc = inc.id_lc and
inc.data = icorig.data and
inc.peca = icorig.peca and
--opsorig.codveiculo = vei.codveiculo and
fac.estado = tef.estado and
fac.estado != 305 and
ops.estado != 223 and
iif.tipo_facturacao != 'SO_CA' and
icorig.data between :dtBeginDate and :dtEndDate and
(fac.codagenciafat = :iIdAgency or :iIdAgency is null);

WF_ITEM_ACTIVITY_STATUSES_H table is growing rapidly in PROD.

Hi,
We are noticing one of the table WF_ITEM_ACTIVITY_STATUSES_H size was 6 GB on 20-APR-11. Today it is at 25 GB (in 1 month) with 356 million rows and growing rapidly! any idea.
Thanks
Rao

I have one question for you. How to purge the workflow date where item_type(OEOH,OEOL) specific only. I would really appreciate if you can guide us in the right direction this issue is becoming more and more critical to the business and also it's degrading the whole back groung process too.
Righ now in prod we are running the "Purge Obsolete Workflow Runtime Data" 21 days Temporary:Y:500:N. i checked the count fro OEOL and OEOH by using below query
select item_type, count(*)
from WF_ITEM_ACTIVITY_STATUSES_H group by item_type
OEOL14982271 14 Million
OEOH504495652 510 Million
select count(*) from WF_ITEM_ACTIVITY_STATUSES_H;
519793016 519 million
Thanks
Ganga

Problem with Temporary Tablespace in 8i

Hello friends,
I have the 8.1.7.4 version, with a 18GB Temporary Tablespace.
An external process (from Datawarehouse tool) is making a query over a 10.000.000 records.
It appeared the error:
SQL error 1652 occurred when accessing table XXX
It's supposed it occurs due to temporary tablespace is full
DWH tool makes different "big" queries.. but.. are the enough to grow up to 18GB???
Any idea?
[It's not possible to change sort_area_size or any other parameter in init.ora]
Apart form this: Which would be the best way to clean this temporary tablespace?
Thanks

Jose, I think you are right and the problem is that Oracle was unable to obtain additional temp tablespace extents for the query since you mention the problem occurred on a query.
The question is was the lack of free temp due to the combination of tasks running at the time or is the plan for the query in question the issue?
If you resubmit the query does the 01652 error re-occur. If it does then I suggest grabbing a copy of the contents of v$sort_usage and resubmitting the query. Monitor the sort usage every 30 seconds, minute, or several minutes depending on how long the query runs before returning the error. This will give you an idea of how much temp space the query wants and maybe why (see following).
Also get the explain plan and see where temp is being used. One query may use multiple allocations of temp space at a time such as one chunk to support hash joins, one to support aggregation, and one to support order by so the total sort space necessary may be a lot more than you would think just based on the result set size.
In the case where the query in question is using too much temp you have to ask if the plan is the issue or if you really need more temp. When the plan is not efficient then converting to using nested loops over hash joins might be one way to eliminate excess temp space usage.
HTH -- Mark D Powell --

Temporary tablespace size

Hi,
I have a doubt regarding temporary tablespace. Oracle 9.2.0.5
When I create the default tablespace temp I see it growing and growing during some days until it reaches the maximum size and then it give the error ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
but monitoring the v$sort_segment I see one or 2 users logged and using the temp.
So my doubt is: what I have to do to find the BEST size for my temp tablespace. which queries is the recomended one to see the temp segments being used ?
Thank you

See http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/tspaces.htm#9566
To improve the concurrence of multiple sort operations, reduce their overhead, or avoid Oracle space management operations altogether, create temporary tablespaces. A temporary tablespace can be shared by multiple users and can be assigned to users with the CREATE USER statement when you create users in the database.
Within a temporary tablespace, all sort operations for a given instance and tablespace share a single sort segment. Sort segments exist for every instance that performs sort operations within a given tablespace. The sort segment is created by the first statement that uses a temporary tablespace for sorting, after startup, and is released only at shutdown. An extent cannot be shared by multiple transactions.
You can view the allocation and deallocation of space in a temporary tablespace sort segment using the V$SORT_SEGMENT view. The V$TEMPSEG_USAGE view identifies the current sort users in those segments.

Temporary tablespace-Problem

Hi,
How to view the temporary tablespace usage?
How to deallocate the used temporary tablespace segments/ resize temporary tablespace?
I am running a query which is consuming 4GB temporary tablespace and failing.
pga_aggregate_traget=500m;
oracle -9.2.0.1.0
OS:Windows 2003
How to solve this?
regards
Mathew

Hi,
We are using the following View and it is fetchhing 46,56,00,000 rows.
PGA=500m
While running the query temporary tablespace is growing upto 4GB and query is failling.
CREATE OR REPLACE FORCE VIEW MHUBADMIN.LOAN_PIPELINE_VIEW
(LOAN_ID, USER_ID, FIRST_NAME, LAST_NAME, BORROWER_NAME,
SSN, USERNAME, SELLERLOANNUMBER, LOANNUMBER, LOANAMOUNT,
STATUS_DESC, LOAN_TYPE, LOCK_EXPIRE_DATE, ORG_NAME, ORG_PARENT_ID,
ORG_CHILD_ID, NO_CASCADE_FLAG, PRODUCT_NAME, INT_RATE, UPDATE_DATE,
UPDATE_DATE_STR, CURRENT_DATE, LOWER_FIRST_NAME, LOWER_LAST_NAME, LOWER_SSN,
LOWER_STATUS_DESC, STATUS_ID, AMORTIZATION_TYPE, STREET1, LOCK_EXTEN_EXPIR_DATE,
RELOCK_EXPIR_DATE, LOCK_RELOCK_COUNT, UNDERWRITE_FLAG, RECENT_EXPIR_DATE, STATUS_DATE)
AS
SELECT
LOAN.loan_id,
LOAN.user_id,
PERSON.first_name,
PERSON.last_name,
PERSON.last_name||', '||PERSON.first_name AS Borrower_Name,
PERSON.ssn,
HUBUSER.username,
LOAN.sellerloannumber,
LOAN.loannumber,
LOAN.loanamount,
STATUS.status_desc,
LOAN.loan_type,
PRICE.lock_expire_date,
ORGANIZATION.org_name,
BUSINESS_RELATIONSHIP.org_parent_id,
BUSINESS_RELATIONSHIP.org_child_id,
BUSINESS_RELATIONSHIP.no_cascade_flag,
product_name,
PRICE.final_rate,
LOAN.update_date,
TO_CHAR (LOAN.update_date,
'MM/DD/YYYY HH:MI:SS AM') update_date_str,
sysdate,
LOWER (PERSON.first_name),
LOWER (PERSON.last_name),
LOWER (PERSON.ssn),
LOWER (STATUS.status_desc),
STATUS.status_id,
LOAN.amortization_type,
ADDRESS.STREET1,
PRICE.LOCK_EXTEN_EXPIR_DATE,
PRICE.RELOCK_EXPIR_DATE,
LOAN.LOCK_RELOCK_COUNT,
LOAN.UNDERWRITE_FLAG,
decode (status.STATUS_ID,
22, PRICE.LOCK_EXTEN_EXPIR_DATE,
          23, PRICE.lock_expire_date,
          13, PRICE.lock_expire_date,
          24, PRICE.RELOCK_EXPIR_DATE,
          PRICE.lock_expire_date) RECENT_EXPIR_DATE,
          LOAN_STATUS_HISTORY.STATUS_DATE
FROM
LOAN,
HUBUSER,
ORGANIZATION,
BUSINESS_RELATIONSHIP,
BORROWER,
PERSON,
STATUS,
PRICE,
product,
PROPERTY,
ADDRESS,
LOAN_STATUS_HISTORY
WHERE
ORGANIZATION.org_id = BUSINESS_RELATIONSHIP.org_child_id AND
LOAN.org_id = BUSINESS_RELATIONSHIP.org_child_id AND
LOAN.loan_id = BORROWER.loan_id AND
LOAN.registration_loan_status_id = STATUS.status_id AND
LOAN.price_id = PRICE.price_id AND
BORROWER.primaryborrower = 'T' AND
PERSON.person_id = BORROWER.person_id AND
LOAN.product_id = product.product_id AND
LOAN.PROPERTY_ID = PROPERTY.PROPERTY_ID AND
PROPERTY.ADDRESS_ID = ADDRESS.ADDRESS_ID AND
LOAN.user_id = HUBUSER.user_id (+);
Any one know how to tune this query?
regards
Mathew

SYSAUX Growing Rapidly

Hi,
When i configured IC mode the SYSAUX Growing Rapidly.
Please let me know what happens.
Thank

Hello,
Seems like the log mining server has grow this tables due any reason. May be the execution of a large transacction, a massive UPDATE, DELETE or INSERT.
Once these tables have grown, no free space.
Would have to test whether making a shutdown / startup instance these tables are truncated. Since the information they hold, I think, would only be necessary for the Log Miner session.
Which is the result of this queries:
SELECT COUNT(*) FROM SYSTEM.LOGMNRC_GTCS ;
SELECT COUNT(*) FROM SYSTEM.LOGMNR_COL$ ;
You can confirm that there is no transaction in the database for long term? You can look at the view v $ TRANSACTION, has a column that specifies the date and time when a transaction began.
From MOS:
There is no official way to reclaim the space but as a workaround you can use the DBMS_LOGMNR_D.SET_TABLESPACE routine to recreate all LogMiner tables in an alternate tablespace. For example, the following statement will recreate all LogMiner tables to use the LOGMNRTS tablespace:
From MOS.
How to Reclaim Space Used by LogMiner Tables (Doc ID 456814.1)
SQL> connect / as sysdba
SQL> EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE ('LOGMINER_DATA');
However this command requiere stop GG capture process.
This procedure move the Logminer tables to the tablespace indicated, then, in the move operation the space is compacted.
May be a good practice using GG IC is to define a dedicated tablespace to Logminer.
I hope help.
Regards
Arturo

Undo Tablespace and Temporary Tablespace - autoextend ?

- In general, should I allow the Undo Tablespace to grow (autoextend)?
- In general, should I allow the Temporary Tablespace to grow (autoextend)?

The size of undo tablespace should always keeps in mind otherwiase you eill get ORA-1555 or out of space errors.
This paper is to help DBA’s in calculating the size of UNDO tablespace by using a simple formula.
It is tough to know about the number of transactions and subsequently number of rows changed per second.
So I suggest having a “big undo tablespace” to start with and based on load, after doing some calculations and resize your UNDO tablespace.
In my case one of the applications was going to production (live), and I had no idea that how many transactions will happen against this database. All what I was told that there will be optimum (transactional) activity on this database.
So I started with UNDO tablespace with size of 3GB and datafiles with autoextend “on” .
Note:
In production, you must be very careful in using this (autoextend on) as the space may grow to inifinity very fast. So my advice is either dont use this option, or use with "maxsize" or continuously monitor space (which is tough).
I month later, I noticed the activity from V$undostat.
Here is the step by step approach:
Step 1: Longest running query.
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
1793
This gives you ideal value for UNDO_RETENTION. To be on the safer size you should add few more seconds to get the right value. So in my case, the size of undo retention should be say 2000 secs.
Step 2: Size of UNDO tablespace.
Size of UNDO needed = UNDO_RETENTION x [UNDO block Generation per sec x DB_BLOCK_SIZE] + Overhead(30xDB_BLOCK_SIZE)
Out of these we know UNDO_RETENTION and DB_BLOCK_SIZE
All we need is to find out “UNDO Blocks per second”
Which can be easily fetched from v$undostat
SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 24*60*60) "UPS"
2 FROM v$undostat;
UPS
8.11985583
V$undostat stores data for every 10 mins and begin/end times are start/end time of those intervals. We multiplied it with 24*60*60 because the difference between two dates will be in days and to get to seconds, we need it to multiply with 24hrs*60mins*60secs
So now we have all the values needed.
Undo size needed = [8.12 x 2000 x 8192] + [30 x 8192] = 133283840 bytes = 127.11 MB

Temporary Tablespace growing Rapidly

Similar Messages

Maybe you are looking for