Temporary tablespace not cleared

Hi,
I have a temporary tablespace in one of my Oracle 9i databases that does not ever get cleared of data. I have altered the tablespace to autoextend by a few megabytes each time but I was wondering why a temp tablespace remains full even after all sessions are done. Its grown larger than my datafiles and I need a solution. Any ideas?
Thanks in advance.
James.

Hi James,
You need to alter your temporary tablespace with adding a fresh new (small) tempfile, and when done, you need to put your other 'old' tempfiles offline so that you can delete them afterwards.
Your temporary tablespace will not shrink/release the space even when you bounce your DB (the undo tbs will)
Regards,
Thierry

Similar Messages

Temporary Tablespace not shrinking automatically after restarting the DB.

I had a Database with 2GB tempfile. It gave me an error that it's unable to extend the temporary segment. I added a new tempfile of 500MB. Within a few min the new file was filled. In process of shrinking the temporary files, I shutdown the DB, and restarted it. But the Tempfiles were still filled to the max. I still don't understand why? Then I attached a new tempfile of 1GB to the Temp Tablespace, but it didn't use the new tempfile. I repeated the restart process again but still the output was same.
1. Both datafiles were filled to the max
2. It didn't use the new (3rd) attached tempfile.
Finally I've created a new tablespace with new Tempfiles, and it's working now. But I'm still confused. Please suggest me with the possibilities. How can i shrink the Temporary Tablespace/Tempfiles.
Thanks & Regards
Vikas Verma
Manager (IT) / Sr. DBA
Hero Cycle Group,
India

It all depends from what you understand by shrinking:
If you would like to shrink tempfile for tablespace I would suggest using following procedure:
Find out to which size you can shrink tempfile
select extent_size,current_users,total_extents,used_extents,free_extents
from v$sort_segment
where tablespace_name='TEMP';
alter database tempfile 'XXXX' resize YYM;
YY is the size which can be found by above query.
But Ithink you are more interested in following procedure:
create new
make this new one the default temporary tablespace for the database
drop old
ps. Yoogesh ask you about DB version
you can find bd version by:
select *
from v$version
select *
from product_component_version
Best Regards
Krystian Zieja / mob

Resizing temporary tablespace in oracle 8i

Please,
I some questions on oracle 8i.
1. how do I know on oracle 8i if the tablespace X is the temporary tablespace?
2. I have someone that increase the size of the temporary tablespace, so I have to decrease it to its normal size, my question is when I do the following command.
alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' resize 250M;
alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' resize 250M
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
Does someone show me how to solve this issue?
Thanks

you can use the below sqls
sql>SELECT tablespace_name, extent_size, total_extents, used_extents,
free_extents, max_used_size FROM v$sort_segment;
From the output of the v$sort_segment query:
extent_size      : size of one extent, in number of Oracle blocks
total_extents     : total number of extents in the segment (free or in use)
used_extents      : total number of extents currently in use
free_extents      : total number of extents currently marked as free
max_used_size: maximum number of extents ever needed by an operation (like a sort):
sql> SELECT s.username, u.tablespace, u.contents, u.extents, u.blocks FROM v$session s,
v$sort_usage u WHERE s.saddr=u.session_addr;
SQL> select s.username, s.sid, u.tablespace, u.contents, u.segtype,
round(u.blocks*8192/1024/1024,2) MB
from v$session s, v$sort_usage u
where s.saddr = u.session_addr
and u.contents = 'TEMPORARY'
order by MB DESC ;
reference
### search MetaLink on: resize tempfile
Note 273276.1 How to Shrink the datafile of Temporary Tablespace
Note 274283.1 How to resize Tempfiles if receive an ORA-03297 error Gen RDBMS.
RD-9014 :
Note 132663.1 ORA-03296 Resizing Temporary Locally Managed Tablespace
Note 180578.1 Cannot Resize Tempfiles in Bitmapped Temporary Tablespaces
Note 161103.1 Space For a Tempfile Not Allocated In The Filesystem

Clear the temporary tablespace

Dear All,
I've created a database in 10G (10.2.0). But currently running with a space problem in temporary tablespace. My database in 365X24 hrs. in such situation how to clear the temporary tablespace by keeping the database open for future operation.

Granting privileges to a role is not necessary either ETC however everybody grants privs. to a role and roles are granted to users. When you do not do that way, you will get confused.
What i ment with necessary is this. I tried to describe it but you don't want to understand i guess.
I am not feel offended but Paul M. is an Oracle ACE member and he can reply to me. He asked me the question and i answered.
As you can see it from above, i posted that it's not necessary. What i want to say is an useful fact.

Temporary tablespace is not being used

hello all,
we have oracle 10g 10.2.1.0 on windows server 2003 platform (32-bit). we have 24*7 database. we have OLTP with heavy transactions. last night we ran a report which is supposed to fetch more than 2500 rows and query include group by and order by clause.
i have rebuild all indexes on index tablespace, which were previously on users tablespace where my all data resides.
but it is taking too much long to generate report more that 40 minutes (expected 5 minutes) my SGA is set to 1.2 GB shared pool sixe is 500M and db_cache_size=400M. and when i check tablespace status from enterprise manager everytime , i see that temporary tablespace is never being used..it always shows that temporary tablespace usages 0.0 and i allocated 4 GB to temp tablespace and it is also default temporary tablespace.
what else i can do to force oracle to use temporary tablespaces??? it is not using for sorting also...thats why it is taking so long to generating report..
any suggestion would be appreciable..
thanks and regards
VD

vikrant dixit wrote:
we have oracle 10g 10.2.1.0 on windows server 2003 platform (32-bit). we have 24*7 database. we have OLTP with heavy transactions. last night we ran a report which is supposed to fetch more than 2500 rows and query include group by and order by clause.
i have rebuild all indexes on index tablespace, which were previously on users tablespace where my all data resides.
but it is taking too much long to generate report more that 40 minutes (expected 5 minutes) Are you saying that you tried rebuilding all your indexes because the report started to run slowly, or conversely that you rebuilt all the indexes and then the report ran slowly ?
If it's just a report that you could simply re-run, then all you have to do is re-run it and watch exactly where the time goes (you've been told about the 10046 trace already).
If it's a report that ran, and was tuned, regularly in the past then you presumably have the execution plan stored somewhere so you could even check the current execution plan compared to the old one to see if it has changed.
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's no sense in being precise when you don't even know what you're talking about"
John von Neumann

Temporary tablespace groups - all available temp files not used

We have a temporary tablespace group TEMP_GROUP made of the following pre-existing temp files. I have placed the size in MB in brackets. Names have been changed to protect our privacy. NLS is spanish
SQL> select * from dba_tablespace_groups;
TEMP_GROUP TEMP1 --(1024)
TEMP_GROUP TEMP2 --(2000)
TEMP_GROUP TEMP3 --(8048)
This tablespace group is the default temp tablespace of this database, and is the default temp tablespace of sys in the example that follows
connect sys/password
alter INDEX schema1.idx1 rebuild
ERROR en línea 1:
ORA-01652: no se ha podido ampliar el segmento temporal con 128 en el tablespace TEMP1
-- this coinicdes with the TEMP1 showing 100% used
NOTE that the message refers to the tempfile TEMP1 and not the TEMP_GROUP, which has 11GB of space available
The size of the index is small enough to be handled by this TEMP_GROUP, although quite large to be handled by TEMP1 on its own.
SQL> SELECT sum(bytes)/1048576 Megs, segment_name
2 FROM dba_extents
3 WHERE segment_name = 'IDX1'
4 GROUP BY segment_name
5 /
MEGS SEGMENT_NAME
840 IDX1
What appears to be happening is that when the rebuild index has used all the space available in TEMP1 tempfile, it does not go on to use the space available in the other two tempfiles that make up the TEMP_GROUP. This seems to be contrary to the very idea of having set up a TEMP_GROUP.
This suposition is born out by the repitition of the operation using the owner of the index, whose default temp file is not TEMP_GROUP as a whole, but the component tempfile TEMP_3 which has 8048MB available
connect schema1/password
SQL> alter INDEX schema1.idx1 rebuild
Índice modificado.
-- This time the index does get rebuilt, pesumably because there is space available in TEMP_3 to carry out the rebuild.
My questions are
1. ¿Why does the original operation fail out when it has reached the limit of tempfile TEMP1 instead of using the further space availbel within TEMP_GROUP? ¿Isn´t the point of temporary tablespace groups the explicit avoidance of this type of issue?
2. Depending on the answer to #1, and asuming that the behaviour is normal (ie, that a rebuild index should not be expected to take place using more than one temp file), does anyone have any idea ¿what dicatates the order of usage of the component temp files in a group?. ¿Is it alphabetical order of tempfile name?, ¿file create time? or ¿something else?
3. As I mentioned the group was created out of existing tempfiles, rather than creating some temp file specifically to form the group. ¿Could this fact explain the inability of the operation to move onto the next temp file, once the first is exhausted. There is nothing in the documentation to suggest that there should be any difference in behaviour between a temp group created with new temp files, or the inclusion of existing temp files when creating a temp group.
As you can see, we have worked round this problem, but it is an issue of importance given that it may affect other operations that leverage this temp file group. Any information or pointers to documented instances of similar occurances would be greatly appreciated. Thank you.
Edited by: user602617 on 06-may-2009 0:57

Half solved. This thread seems to suggest that there should be n expectation that a sort operation will begin to use the n+1 member of a temp tablespace group once it has exhausted member n.
TEMP Tablespace Groups
But this does not answer my secondary question as to how to determine which temp tablespace member is used first. I guess the solution would be to drop the the group and recreate it with three adequatly sized temp tablespaces.

Error : Temporary Tablespace is Empty when doing expdp/impdp

Hi all,
I was doing expdp on my oracle 10.1.0.2.0 DB on Win XP P, though the user is having a default temporary tablespace with a temp file on autoextend enabled, I got the message as...
ORA-25153: Temporary Tablespace is Empty
Then I created a new temporary tablespace for the user with 500M tempfile and autoextend enabled, then expdp went through.
Now I am doing the impdp for the same .dmp file to generate one sqlfile for the DB,
again I am facing the same error message as...
ORA-25153: Temporary Tablespace is Empty
----- PL/SQL Call Stack -----
object line object
handle number name
17FE07EC 13460 package body SYS.KUPW$WORKER
17FE07EC 5810 package body SYS.KUPW$WORKER
17FE07EC 3080 package body SYS.KUPW$WORKER
17FE07EC 3530 package body SYS.KUPW$WORKER
17FE07EC 6395 package body SYS.KUPW$WORKER
17FE07EC 1208 package body SYS.KUPW$WORKER
17ABE058 2 anonymous block
Job "CHECKUP"."SYS_SQL_FILE_FULL_02" stopped due to fatal error at 10:09
The message indicates that...
ORA-25153: Temporary Tablespace is Empty
Cause: An attempt was made to use space in a temporary tablespace with no files.
Action: Add files to the tablespace using ADD TEMPFILE command.
SO my question is every time I do any imp exp have I to add temp file in my temporary tablespace? will it not be cleared on the completion of the job?
Any advice please.

Hi Sabdar,
The result of the query is as...
SQL> SELECT * FROM DATABASE_PROPERTIES where
2 PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';
PROPERTY_NAME
PROPERTY_VALUE
DESCRIPTION
DEFAULT_TEMP_TABLESPACE
TEMP
Name of default temporary tablespace
So the default temporary tablespace is TEMP which is not having any tempfile as I cloned this DB from the primary DB, but the user I am using for the impdp is 'checkup' and the temporary tablespace for 'checkup' is 'checkup_temp1' which s having tempfile.
SO then why the impdp job is going to server's temporary tablespace instead of user's temporary tablespace.
Is there any way to get whether 'checkup_temp1' tablespace is the default temporary tablespace for 'checkup' or not?
Can I create create the user mentioning default temporary tablespace anyway because it is giving me error as...
SQL> create user suman identified by suman
2 default tablespace checkup_dflt
3 default TEMPORARY TABLESPACE checkup_temp1;
default TEMPORARY TABLESPACE checkup_temp1
ERROR at line 3:
ORA-00921: unexpected end of SQL command
Then I did ...
SQL> create user suman identified by suman
2 default tablespace checkup_dflt
3 TEMPORARY TABLESPACE checkup_temp1;
User created.
Regards

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 ...*

Dropping default temporary tablespace

Hi
(regarding Oracle 9i)
I am getting two conflicting messages. The first one says you cannot drop a default temporary tablespace, and the second one says you can and that SYSTEM then becomes the default temporary tablespace. Which one is correct?
http://www.idevelopment.info/data/Oracle/DBA_tips/Tablespaces/TBS_12.shtml says: The DBA cannot drop a default temporary tablespace, but it is possible to assign a new default temporary tablespace and then drop the old one. You also cannot change a default temporary tablespace to a permanent tablespace, nor can you take a default temporary tablespace offline.
http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/c04space.htm#1945 says: If you drop the default temporary tablespace, then the SYSTEM tablespace is used as the default temporary tablespace
Which one is correct?!?!
thanks

select * from database_properties where property_name='DEFAULT_TEMP_TABLESPACE';
PROPERTY_NAME
PROPERTY_VALUE
DESCRIPTION
DEFAULT_TEMP_TABLESPACE
TEMP
Name of default temporary tablespace
drop tablespace temp;
drop tablespace temp
ERROR at line 1:
ORA-12906: cannot drop default temporary tablespaceBut as your earlier quotations make clear, there is nothing stopping from creating a NEW temporary tablespace, making that the default, and then dropping TEMP, the original-but-no-longer default.
The principle is logical: a default's not much of a default if it can cease to exist. For a default to be meaningful, it has to be protected from being gotten rid of.
The other thing you hinted at: the default default temporary tablespace is still SYSTEM, because it's the only tablespace that HAS to exist from the moment a database exists (though 10g elevates SYSAUX to almost the same status). So if you choose to create your database manually, using syntax of the form 'create database XXX....', it is allowed NOT to create a temporary tablespace. And if you choose to do that, then SYSTEM will be used as the default temporary tablespace.

OEM alert: temporary tablespace more than 100% full

Hi,
I created an event in OEM which checks tablespaces. Once in a while I'm having an alerts like:
Tablespace TEMP is 102.08% full. -339968.0 KBytes of free space remain
What to do ?

Did you do the calc yourself?
Ideally a temporary tablespace will show roughly 100% full (95-105%) at all times, using standard extent calculations. Any small amount over 100% is usually the result of rounding error, or using several independent queries and catching the reuse and realloc of segments.
The only time a temporary tablespace should show nearly empty is shortly affter restarting the instance. Once it starts getting used, the temp tablespace should get blocks used by active sessions. When a session needs an empty block, it formats that block for the purpose (sort, global tempo table, hash area, etc.) Once sessions are finished with them, the blocks are reused - for performance, blocks are not cleared (reformatted to 'empty') and therefore simply show 'being used' in a typical dba_segments/dba_extents select.
The only time to worry about it is when a session (or the system) compains about being out of temp space. In which case, make it bigger ... or figger why it needs the extra space and fiux that.

INCLUDED_IN_DATABASE_BACKUP for temporary tablespace

Hi,
The query output from v$tablespace shows the INCLUDED_IN_DATABASE_BACKUP value for temp tablespace in my db is "YES". The only way to have the value "NO" is to configure rman to exclude tbs. But you can not exclude temporary tablespace. Based on the size of total full backup files, the temp tablespace does not seem to be backup by rman. Is this a bug or is there other way to set this value for temporary tablespace to "NO"? I'm using 9iR2. Thanks.

>...The only way to have the value "NO" is to configure rman to exclude tbs. But you can not exclude temporary tablespace.
RMAN doesn't include the temporary tablespace in the backups.
SQL> select * from v$tablespace;
       TS# NAME                           INC
         0 SYSTEM                         YES
         7 TEST                           YES
         3 USERS                          YES
        4 TEMP YES
         6 UNDO                           YES
RMAN> list backup of tablespace TEMP;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 01/26/2006 20:04:06
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "TEMP"
RMAN> list backup of tablespace UNDO summary;
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Tag
3125    B 0 A DISK        22-JUL-05       1       1       TAG20050722T102731
3207    B 0 A DISK        24-OCT-05       1       1       TAG20051024T163622
3248    B 1 A DISK        02-NOV-05       1       1       TAG20051102T225318
3360    B F A DISK        23-JAN-06       1       1       TAG20060123T172135Aron

Temporary tablespaces in Oracle 10g

Hi,
I have created temporary tablespaces in Oracle 10g from the SQL prompt,but when i list the corresponding datafiles from v$datafile there tempfiles are not listed there,why is it so?
Regards,
Cherry

Hi,
Take a look in
1 - DBA_TEMP_FILES :http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch2398.htm
2 - V$TEMPFILE: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch3225.htm
Cheers,
Marcello M.

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);

Temporary tablespace in oracle 8i

hi,
i am working in oracle 8.1.7.4.0.i am creating a temporary tablespace.
After creating the temp tablespace i am going to assign it as default temporary tablespace.
alter database default temporary tablespace <tbs-name>;
but its showing error...as
ora-02231 - missing or invalid option to alter database,
how to assign the default temporary tablespace in this oracle version.
Rgds...

You can not set the temporary tablespace at the database level as default temporary tablespace in Oracle 8i. From Oracle 9i onwards, you can create and assign the temporary tablespace at the database level.
Only possible way in Oracle 8i is at the user level.
i.e.
SQL> alter user scott default tablespace TEMP;
HTH.
Regards,
Sabdar Syed.

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 not cleared

Similar Messages

Maybe you are looking for