Temporary tablespace usage is always 0%

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

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

Similar Messages

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

How to view what is using up the temporary tablespace

Hi all
I am running into a problem - my temporary tablespace is being completely used up.
How would i find out what is using up this? Technically it has enough space to function properly but now we are getting 0 bytes free.
thanks!

There is nothing wrong if a temporary tablespace appears as full. It is very normal. I
For more information about temporary tablespace usage query V$SORT_USAGE and V$SORT_SEGMENT .
For more information go to this link
http://asktom.oracle.com/pls/ask/f?p=4950:8:14327914180898764224::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:374218170986

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

Check and identify cause of previous temp tablespace usage

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

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

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.

Cleaning up temporary tablespace

Hi,
I am facing a problem where temporary tablespace of the production database has grown to 23GB.The instance cannot be bounced and there is very little space left for the rest of the database.I want to free up the excess space.I know I can do it by creating a new temp tablespace,assigning it as default and dropping the old one.But I want to know how I can resize the existing temp tablespace.when I try the following command:
alter database datafile '/d02/oradata/<SID>/temp01.dbf' resize 1G;
it gives the following error:
file contains used data beyond requested RESIZE value.
How can I get around the above problem.there is no session using TEMP tablespace.Plz suggest a solution as I really want to know how this can be done.

First of all, You can't resize the temp tablespace datafiles size as once the temp tbs allocate extents, after the operation finishes, oracle won't deallocate them as it keep them for future requirements and usage.
What you can do in your case, as you cant bounce the db, create another temp tablespace and assign it as default temp tbs and drop the old one.
Also, dont keep its datafiles for auto extend and if you see any error message in alter log file like 'unable to extend temp tablespace' then increase the size. If you feel your queries may fail due to this, you can also use resumable option and investigate why does it requred 20+G for temp?
SJH
OCP DBA

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

Temporary tablespace doesn't empty itself

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

1-)Regarding the temp tablespace which one is recomended?Auto extend or not ?It really doesn't matter. However since autoextend is one way street so you aren't save much space using it if you expect temp usage is 10G just set it to 10G.
2-) and lets say if the size of the temp tablespace is 10gb and usage is 10gb and there is no transaction in the database.
This means that if the new transaction occurs that need sort usage these temp segments will be reused.Am I right? and there will be no error about temp tablespace..??That's correct. sort segment will be reused and not deallocated until database restarted.
check temp segment usage using
v$sort_usage

Problem shrinking a temporary tablespace

I have a temporary tablespace in 10.1.0.3 I need to shrink. I need to shrink the database.
1. I change all users that user that temporary tablespace to a new temporary tablespace
2. Tried to shrink it but got
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
I take this to mean there are open transactions using this temporary tablespace? How do I find who currently is using this temporary tablespace? do i need to kill those sessions?

Hi,
There may be one issue, if there are transactions open and the old temp tbsp is currently used (for sorting, etc), you will not be able to drop it without crashing the sessions. It will be nice if you check which user sessions are using the old temp and either gracefully abort the session (by asking them) or wait until they are done. Otherwise you may create the new temp and make it default (tablespace as well as user's temp tablespace name) so that no new user session will connect to the old temp and you can monitor it to stop its usage.
Thanks

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

Temporary Tablespace: cannot check it from V$TEMP_SPACE_HEADER

I've created the temporary tablespace but I cannot check it from V$TEMP_SPACE_HEADER, when I select the contents of it, it returns "no rows selected".
Could someone tell me why?
Besides, I would like to know how to check the contents in temporary table space.
Regards,
Jimmy

Hi,
I think you just did not create a TEMPORARY TABLESPACE but a PERMANENT TABLESPACE with TEMPORARY OPTION..10:43:10 TEST.SQL>CREATE TABLESPACE TS
10:43:21   2 DATAFILE '/F1.dbf' SIZE 15M
10:43:40   3 TEMPORARY;
Tablespace created.
Elapsed: 00:00:02.66
10:43:44 TEST.SQL>SELECT * FROM V$TEMP_SPACE_HEADER;
TABLESPACE_NAME                   FILE_ID BYTES_USED BLOCKS_USED BYTES_FREE BLOCKS_FREE RELATIVE_FNO
TMP                                     1 2,2424E+10     2737280 3790602240      462720            1
Elapsed: 00:00:00.01
10:43:56 TEST.SQL>SELECT * FROM DBA_TABLESPACES WHERE TABLESPACE_NAME IN ('TMP','TS');
TABLESPACE_NAME                BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS    CONTENTS LOGGING   FOR EXTENT_MAN ALLOCATIO PLU
SEGMEN DEF_TAB_
TS                                   8192          40960       40960           1                       50          0 ONLINE    TEMPORARY LOGGING   NO DICTIONARY USER      NO
MANUAL DISABLED
TMP                                  8192        5242880     5242880           1                        0    5242880 ONLINE    TEMPORARY NOLOGGING NO LOCAL      UNIFORM   NO
MANUAL DISABLED As you can see from this sample, if you useCREATE TABLESPACE blablabla DATAFILE blabla TEMPORARYOracle creates a tablespace that looks to be a pure temporary tablespace but in fact is not actually. It can be used as a TEMP would be but has not all the characteristics of it. Heh, it's got a DATAFILE, not a TEMPFILE in it.
If you use CREATE TEMPORARY TABLESPACE blabla TEMPFILE blabla then Oracle will create an actual TEMPORARY TABLESPACE which will be present in all temporary related views!
You can't distinguish one from the other via standard views (DBA_TABLESPACES) once it's been created.
To check temp space usage you can use something like:SELECT
                RPAD(TF.TABLESPACE_NAME,20) || ':' ||
                        DECODE(EXTENT_MANAGEMENT,'LOCAL','LM-','DM-') ||
                        SUBSTR(ALLOCATION_TYPE,1,1)||'+'||
                        SUBSTR(SEGMENT_SPACE_MANAGEMENT,1,1)||'@'||
                        SUBSTR(TS.STATUS,1,2)
                                        TABLESPACE_NAME,
        TF.FILE_NAME,
        USAGE.USERNAME,
        USAGE.SEGTYPE,
        LPAD(USAGE.BLOCKS*TBLKS.BLOCKSIZE/1024/1024,5) || ' Mo' BLOCKS
FROM
        DBA_TEMP_FILES TF,
        V$TEMPSEG_USAGE USAGE,
        (SELECT VALUE BLOCKSIZE FROM V$PARAMETER WHERE NAME='db_block_size') TBLKS,
        DBA_TABLESPACES TS
WHERE
        USAGE.TABLESPACE=TF.TABLESPACE_NAME
AND TS.TABLESPACE_NAME=TF.TABLESPACE_NAME
ORDER BY TF.TABLESPACE_NAME, TF.FILE_NAME, USAGE.USERNAME;Regards,
Yoann.

Switch to new temporary tablespace

How can I switch to a newly created temporary tablespace?
anyone could help provide the detailed steps of doing this?
Also, if I can see two temporary tablespaces from dba_tablespaces view, then how can I know which one is in use?
NOte: these two temporary tablespace do not belong to same tablespace group.

PhoenixBai wrote:
How can I switch to a newly created temporary tablespace?
anyone could help provide the detailed steps of doing this?Assumingly that you have Temp1 as the default tablespace for the database, you would do this
alter database default temporary tablespace TEMP2;This would change the new default for the database to Temp2. For the users, who have been explicitly assigned the tablespcae Temp1 , you would need to change that using the alter user <name> default temporary tablespace Temp2
Also, if I can see two temporary tablespaces from dba_tablespaces view, then how can I know which one is in use?
NOte: these two temporary tablespace do not belong to same tablespace group.The group or not doesn't matter. Check with the view database_properties .
SQL> select property_name, property_value
2 from database_properties
3 where property_name like '%TEMP%';
PROPERTY_NAME
PROPERTY_VALUE
--------------------------------------------------------------------------------DEFAULT_TEMP_TABLESPACE
TEMPHTH
Aman....
PS: Please make sure that you always mention your 4 digit database version with every post.

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 usage is always 0%

Similar Messages

Maybe you are looking for