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

Similar Messages

How do i know if my query using SORT_AREA_SIZE   or temporary tablespace ?

Good Morning Everyone !
My DB version is 10.2.0.1
I have large table exactly 3 million records.
SQL> select count(*) from tab1;
COUNT(*)
   300000
SQL> select * from tab1 order by no DESC;
sorting ... in process
300000 rows selected.
in Terminal 2 : I tried to find sorting details -   ( No rows selected - why ? )
SQL> select USERNAME , USER , TABLESPACE , SQL_ID from v$tempseg_usage ;
no rows selected
SQL> /
no rows selected
When i google i have seen this ;
If Oracle cannot do the sort in memory (SORT_AREA_SIZE initialisation parameter), space will be allocated in a temporary tablespace for doing the sort operation.
REF_LINK : TEMPORARY Tablespaces and TEMPFILES | Oracle FAQ
MY DOUBT QUESTION :   How do i know if my query using SORT_AREA_SIZE or temporary tablespace ?
Thanks in advance.

@ JohnWatson
I have seen some articles from ORA - FAQ. Good.
SQL> select USERNAME , USER , TABLESPACE , SQL_ID from v$tempseg_usage;
USERNAME                       USER   TABLESPACE                      SQL_ID
   SCOTT                               SYS          TEMP                            fh9vqgyd6m0d1
PGA management means that sorting only 300000 rows may well occur in memory
            Is this (3 million rows) - standard value for 10g version ?
Thanks JohnWatson

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

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.

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

Oci_execute() [function.oci-execute]:ORA-25153:Temporary Tablespace isEmpty

hi all,
One of the user told us that they are facing problem while developing membership online fee payment, when theay are trying to access member table in oracle server. It works fine for single or fewer records,but when we try to fetch all records for the purpose of membership/date of birth site it generates some oracle error:
Warning: oci_execute() [function.oci-execute]: ORA-25153: Temporary Tablespace is Empty in /usr/local/apache/htdocs/memberdbupdateoracle.php on line 41
Warning: oci_fetch_array() [function.oci-fetch-array]: ORA-24374: define not done before fetch or execute and fetch in /usr/local/apache/htdocs/memberdbupdateoracle.php on line 49Db version is oracle 9.2.0.6
pls suggest me...

My suggestion is you look up the error message in the online docs, and add the tempfile to the temporary tablespace as indicated.
My suggestion is also you read the Forums Etiquette post, and stop bothering this forum with questions for which you can find the answer yourself without effort.
This forum is not about having someone else do your work for free.
Sybrand Bakker
Senior Oracle DBA

ORA-03212 temporary tablespace

Hi all,
we run a single instance database on file system (no ASM).
The database has benn running fine for several weeks now. 2 days ago however the following error came up:
"*** MODULE NAME:(DBMS_SCHEDULER) 2012-09-02 06:00:03.470
*** ACTION NAME:(MGMT_CONFIG_JOB_1) 2012-09-02 06:00:03.470
ERROR: kfnUseConn - failure to make a connection
ORA-03212: Temporary Segment cannot be created in locally-managed tablespace".
I changed the user's (oracle_ocm) temp tablespace to "TEMPORARY LOCAL". which should avoid that error in future.
My question:
What is the appropriate temporary tablespace for system users?
We run quite a lot of databases that were created with version 7.x and migrated up to version 10 or 11. They all used to have PERMANENT tablespaces as temp tbs for the users 'SYS, SYSTEM, DIP, APPQOSSYS, CSMIG' which did not make any problems up to now.
Should I change default temporary tbs to TBLSPC_TEMP for all users including those mentioned above?
FJH

Please post output of below commands :
1. select tablespace_name from dba_data_files where tablespace_name like '%TEMP%';
If you gets any name here, it means your temp tablespace is not really a temp one, its a permanent one whose name is temp, because if you have created temp tablespace with the TEMPFILE keyword, then only its a really temp tablespace. DBA_DATA_FILES do not shows the datafiles which have been created with TEMPFILE keyword.
2.set long 999999;
SELECT DBMS_METADATA.GET_DDL('TABLESPACE','TEMP') FROM DUAL;
In above output if you don't see TEMPFILE keyword then ORA-03212 is correct and as documented.
Now, if you want your TEMPORARY tablespace to be Locally Managed then you should use the TEMPFILE clause and NOT DATAFILE while creating the TEMPORARY TABLESPACE.
create temporary tablespace temp tempfile
'/u10/oradata/cprpt/temp01.dbf' size 250M reuse,
'/u10/oradata/cprpt/temp02.dbf' size 250M reuse,
'/u10/oradata/cprpt/temp03.dbf' size 250M reuse,
'/u10/oradata/cprpt/temp04.dbf' size 250M reuse
extent management local uniform size 3M;
http://www.dbasupport.com/forums/showthread.php?t=31317
Regards
Girish Sharma

Group temporary tablespace

Greetings,
oracle 10.2.0.4
suse linux 9
we have a group temporary tablespace called ATEMP which contains 9 tablespaces ATEMP01 - ATEMP09
but the in the alert log we have this warning
WARNING: the following temporary tablespaces contain no files.
this condition can occur when a backup controlfile has been restored.
it may be necessary to add files to these tablespace. that can be done using SQL.....
alternatively, if these temporary tablesapces are no longer needed, then
they can be dropped. Empty temporary tablespace: ATEMP
then I was confirmed on this forum after a question that...in this case oracle is using SYSTEM tablespace
as a temporary tablespace and this has a performance impact and the system may hung if SYSTEM tbs gets
full. which I totally agree according to oracle documentation
and my question for today is
how can I show to somebody that the current temp segments are in SYSTEM tablesapce because as I run
the query
SELECT TABLESPACE_NAME,BYTES_USED,BYTES_FREE FROM V$TEMP_SPACE_HEADER;
the return show the tablespaces are ATEMP01,ATEMP02....instead of SYSTEM which was my expectation.
thanks

thank you
I just passed the query to the view
select tablespace,contents from v$tempseg_usage
and what I found is
ATEMP02 and TEMPORARY
now what is contradicting for me is that...the alert log is showing as if ATEMP which is a temporary
tablespace group is not having a file and we need to add files to it ...which implies that SYSTEM tablespace
is being used as a residing place for the temp segments but the query returns ATEMP02 as the temporary
tablesapce where temp segment is residing
can you help me reconsile this seemingly confusing scenario

Temporary tablespace

Our temporary tablespace doesn't empty itself after a commit, rollback or end-session. Can't find the reason why not.
Next size is set to 256K but we get error messages that the temp tablespace is unable to extend next size with 128K which is in fact the next size of all rollbacks segs.
1. Does a rollback segment empties itself into the temporary tablespace?
2. How can I change the settings so that the temporary tablespace empties itself?
Thanks Henry

Hi
The first answer of your question is not fully correct. If you
mark your tablespace 'temporary' it is not used for storing
database objects. It is used onle for sort operations. Oracle
recomend to set equal initial and next segments for this
tablespace and pctincrease=0. You can see recomendation for this
in Oracle Server Tunning. A good size for segments is 2 times of
sort area size and some overhead. But if your users execute many
statements needed big sorts and same time you will need big
temporary tablespace.
Regards

How big for the temporary tablespace is proper?

Hi,
I get the error several times per month:
ORA-1652: unable to extend temp segment by 256 in tablespace temp
The size of this temporary tablespace is 1G. Of couse I can inrease to 2G or 10G.
questions:
How to determine the new size for this tablespace properly?
what factors will be considered for it?
Thanks

I think more than one 1GB for a 6GB is acceptable. I agree the temp size is not determied by database size, but satistically it should be in a range compared with database size, right?
Well, what I did in this situation is to create a scheduled job, get information from v$sort_usage and kepp it in a table. This job run in every 5 mins. I let it run a couple of days, then I can know which SQL consumes too much temp space. After that, I tune this SQL to resolve the issue. Hopefully it would be help to you.

Temporary Tablespace Sizing and SNOTE 164925

Hi All,
I am facing a dilemma when I look into the temporary tablespace setting.
I have gone thru the SNOTE 164925, for the sizing parameters of PSAPTEMP.
There is a calculation on the note for selecting initial extent next extent etc.....
My PSAPTEMP is locally managed and having default initial extent value of 1 MB but as per the calculation given on SNOTE 164925 solution section.
But the point is in the How Can I check the specified value section on the same note it says....
"As of Oracle 8i, SAP recommends using the assignment of locally managed
temporary tablespaces (see Notes 659946 and 662900). This means that when
problems with a 'dictionary managed' temporary tablespace occur, you should
change to a 'locally managed' temporary tablespace instead of optimizing
the settings of the 'dictionary managed' temporary tablespace."
Now my question is whther I should still go with the default value or with the new values as per the formula given in the same note.
I am using Oracle 10g behind SAPR3 4.6D
Regards,
Soumen

Hello Soumen,
to be honest - i don't really understand your question / problem.
Just use locally managed temporary tablespace and set an uniform size.
The values initial, next and pctincrease doesn't matter in this case. Set the uniform size to 1 - 5 MB.
As you told us you are using oracle 10g .. just check the documenation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_7003.htm#CJAIDDDB
Specify LOCAL if you want the tablespace to be locally managed. Locally managed tablespaces have some part of the tablespace set aside for a bitmap. This is the default for permanent tablespaces. Temporary tablespaces are always automatically created with locally managed extents.
AUTOALLOCATE specifies that the tablespace is system managed. Users cannot specify an extent size. You cannot specify AUTOALLOCATE for a temporary tablespace.
UNIFORM specifies that the tablespace is managed with uniform extents of SIZE bytes.The default SIZE is 1 megabyte. All extents of temporary tablespaces are of uniform size, so this keyword is optional for a temporary tablespace. However, you must specify UNIFORM in order to specify SIZE. You cannot specify UNIFORM for an undo tablespace.
Restriction on Dictionary-managed Tablespaces
You cannot specify DICTIONARY if the SYSTEM tablespace of the database is locally managed or if you have specified the temporary_tablespace_clause.
Regards
Stefan

User tried to grant quota on an undo or temporary tablespace

Hi.
I got this error (see below).
Question - did it happen because one cannot grant a quota on a temp TS or because I ran the ALTER USER as a user with DBA role and not as SYS?
Thanks,
Error starting at line 14 in command:
ALTER USER IM_DBA QUOTA UNLIMITED ON FIM_DBA_TEMP
Error report:
SQL Error: ORA-30041: Cannot grant quota on the tablespace
30041. 00000 - "Cannot grant quota on the tablespace"
*Cause: User tried to grant quota on an undo or temporary tablespace
*Action: Check the tablespace name and reissue the command
ALTER USER IM_DBA succeeded.

Found this thread...
Re: Cannot grant quota on tablespace
Thanks!

Who fills temporary tablespace?

Hello,
a short question. How can I select who/which statement fills the temporary tablespace?
Thanks!

Hi,
You can try use these SQL's below:
To monitor tempspace eating by session
select a.sid,b.blocks from v$session a , v$sort_usage b
where a.saddr=b.session_addr;
To monitor tempspace eating by SQL
select b.sql_id,a.sql_text,b.blocks from v$sql a, v$sort_usage b
where a.sql_id=b.sql_id;Cheers
[url http://eduardolegatti.blogspot.com]Legatti

Temporary tablespace questions

Similar Messages

Maybe you are looking for