Help with Temp tablespace..

Oracle 11g - 11.1.0.7, Redhat 5.3 64BIT w/4GB RAM
================================
Hello All,
I just inherited a DB from a person that left the company, and I've noticed something interesting in the TEMP tablespace. One file is located in /u02 and the additional file that was added latter - is staged at /u01. To make matters worse, temp01.dbf is a 968MB file where 744MB is being used, (no auto extend), temp02 looks like it was mistakenly created at 25GB (should have been 2GB) and it is using 3GB of space (with Auto extend on).
I would like to first delete temp02 from the /u01 folder and recreate it in /u02 with its partner, but as a 2GB file only. What is the best way to proceed with this? Should I mount the DB, (not open) then drop and recreate it? Can it be done in an 'OPEN' state?
Thanks.
Ron
Current Configuration:
temp01.dbf /u02/oradata/CTS/ 968.36 744.00
temp02.dbf /u01/oradata/CTS/ 25,792.00 3,009.00

Ron,
Create a new temp tablespace in desired location with desired size and set it as default temporary tablepsace and drop old temporary tablespace including temporary data files.
You can use following and replace it wiht your path
CREATE TEMPORARY TABLESPACE TEMP02 TEMPFILE
      '/u02/.../temp02.dbf' SIZE 100M AUTOEXTEND ON NEXT 128M
      MAXSIZE 2048M , '/u02/.../temp03.dbf' SIZE 128M AUTOEXTEND
      ON NEXT 128M MAXSIZE 2048M EXTENT MANAGEMENT LOCAL;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP02;
-- Drop old temporary tablespace and datafile
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;Regards

Similar Messages

Restored coldbackup and having trouble with TEMP tablespace

Hi, i succesfully restored from a coldbackup on solaris.(oracle 9.2)
i can log on to database using toad, query the database, but when i try to take an export or something i got the error
EXP-00056: ORACLE error 1157 encountered
ORA-01157: cannot identify/lock data file 203 - see DBWR trace file
ORA-01110: data file 203: '/sun2int1/oracle92/app/oracle/product/9.2.1/oradata/TPRS/temp03.dbf'
ORA-06512: at "SYS.DBMS_LOB", line 424
ORA-06512: at "SYS.DBMS_METADATA", line 1140
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfully
when i did the restore, i simply renamed the datafiles and redo logs.
But i didnt rename the TEMP datafile, as you can not rename it with a "alter database rename file ..." command
so thats the problem!
i planned to create a new default temp. tablespace, and simply make it default and drop the other one. but it does not work!
i tried to execute:
CREATE TEMPORARY TABLESPACE temp4 TEMPFILE '/oracleAS/TPRS/oradata/TPRS/temp4.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
create temporary tablespace temp01 tempfile '/oracleAS/TPRS/oradata/TPRS/temp01.dbf' size 100M;
but they all hang! i wait, but nothing happens! (and alert log does not log anything too)
and finally i tried to drop the default tablespace, and i couldnt drop it as i thought. (ORA-12906: cannot drop default temporary tablespace
So, im stuck and i beleive i have to RENAME the datafile for temporary tablespace. how can i do this?
Edited by: merope on Jun 9, 2009 11:32 AM

SQL> col file_name for a50
col status for a15
col tablespace_name for a15
col PROPERTY_VALUE for a20
select file_name,tablespace_name,bytes/1024/1024 as "SIZE_IN_MB",status,autoextensible from dba_temp_files;
SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES where PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';
SQL> SQL> SQL> SQL> SQL> SQL> ERROR:
ORA-01157: cannot identify/lock data file 202 - see DBWR trace file
ORA-01110: data file 202: '/izmir1/oradbTPRS/temp1.db'
no rows selected
SQL>
PROPERTY_NAME PROPERTY_VALUE
DEFAULT_TEMP_TABLESPACE TEMP3
This is not the actual directory: /izmir1/oradbTPRS/temp1.db
it is the old location, but in the restored db, the temp1.db file is in some other directory
how can i rename this?
Edited by: merope on Jun 9, 2009 11:50 AM

9i on Linux. Problems with Temp tablespace cleanup

I am currently running Oracle 9i Enterprise on SUSE Linux 7.2.
I am executing queries against the new XMLType datatype and every query adds to the Temp tablespace, which doesn't get cleaned up. Eventually, the tablespace will run out of space and Oracle will issue and error:
ORA-01652: unable to extend temp segment by 128 in tablespace <name>
The only way to clean up the Temp tablespace seems to be by restarting the server.
Is that happening on other platforms as well? I would appreciate any help.

Hi
You can connect to the database as DBA (Sys or System) and make a bigger temporal tablespace. Or create a new bigger temporary tablespace and assign it to the user.
A10!
PS: Temporary tablespace is used when no memory available for the session, for example when a big ORDER BY is done. Try to increase the memory assigned, just look at initXXX.ora (sort_size)

Need help with interpreting tablespace usage script

Hi,
I have a script to find all the used and free spaces of a datafiles. The script is as below:
SELECT Substr(df.tablespace_name,1,20) "Tablespace Name",
Substr(df.file_name,1,40) "File Name",
Round(df.bytes/1024/1024,2) "Size (M)",
Round(e.used_bytes/1024/1024,2) "Used (M)",
Round(f.free_bytes/1024/1024,2) "Free (M)",
Rpad(' '|| Rpad ('X',Round(e.used_bytes*10/df.bytes,0), 'X'),11,'-') "% Used"
FROM DBA_DATA_FILES DF,
(SELECT file_id,
Sum(Decode(bytes,NULL,0,bytes)) used_bytes
FROM dba_extents
GROUP by file_id) E,
(SELECT Max(bytes) free_bytes,
file_id
FROM dba_free_space
GROUP BY file_id) f
WHERE e.file_id (+) = df.file_id
AND df.file_id = f.file_id (+)
ORDER BY df.tablespace_name,
df.file_name
The output displays data for all the datafiles. But when i check the free space, its much lesser than actual free space. Is this has something to do with High Water Mark? All the data is in MB.
Tablespace             Datafile                                        SIZE           Used        Free
GNP2000     D:\DATABASE\GNP2005.ORA     6110.8     5646.6     8.95
GNP2000     D:\DATABASE\GNP2009.ORA     3500     3357.98     8.95
GNP2000     D:\DATABASE\GNP2010.ORA     2000     1999.49     0.06
GNP2000     E:\ORANT\DATABASE\GNP2000.ORA     3500     3463.8     8.95
GNP2000     E:\ORANT\DATABASE\GNP2002.ORA     3046.88     2976.41     2.21
Please explain why it displays different data and also how to find actual free space my database has?
Thank You,

This is because the script is WRONG.
This is a lesson for you, if you are on 10g on higher, rather to trust the database control, which has already facilities for this, instead of someone developing a script. At least the Oracle provided material is correct.
Admittedly, it does require you to read documentation and to find out things on your own.
This part is WRONG
SELECT Max(bytes) free_bytes,
file_id
FROM dba_free_space
GROUP BY file_id)
As an exercise, please try to find out for yourself, what is wrong.
Please do not state you can not do this, this indicates you will never learn Oracle.
Sybrand Bakker
Senior Oracle DBA

Should I increase TEMP tablespace size here ?

Version: 10.2.0.4
Platform : RHEL 5.8
Currently we are running a batch job in a schema. The default temporary tablespace for that schema is TEMP.
But I see that the tablespace is full.
SQL> select file_name, bytes/1024/1024/1024 gb from dba_temp_files where tablespace_name = 'TEMP';
FILE_NAME                                                                 GB
/prd/fdms/oradata_db18/fdmsc1sdb/oradata/ts_temp/temp01.dbf               10
SQL> SELECT     TABLESPACE_NAME, FILE_ID,
        BYTES_USED/1024/1024,
        bytes_free/1024/1024
FROM V$TEMP_SPACE_HEADER where tablespace_name = 'TEMP' 2    3    4 ;
TABLESPACE_NAME                             FILE_ID BYTES_USED/1024/1024 BYTES_FREE/1024/1024
TEMP                                              1                10240
So, far the application users have not complained and I didn't see any 'unable to extend' error in the alert log yet, but the above scenario is dangerous. Right? I mean SQL statements with sorting can error out. Right ? Unlike UNDO, with temp tablespace, temp segments cannot be reused. Right ?

Hello,
As said previously, the Sort Segments can be reused, the Views V$SORT_SEGMENT and V$TEMPSEG_USAGE are relevant to monitore the usage of the Temporary Tablespace.
You'll find in the Note below a way to control over time the Temporary Tablespace:
How Can Temporary Segment Usage Be Monitored Over Time? [ID 364417.1]
More over, you may also check for any ORA-01652 in the Alert Log.
But don't worry to much to get a Full Temporary Tablespace, here "Full" doesn't mean "unreusable".
Hope this help.
Best Regards,
Jean-Valentin Lubiez

Is there any way to alter temp tablespace into normal tablespace

Even though It might be stupid question, i want to know the solution for that...
Is it possible to alter TEMP tablespace into Normal tablespace?
One more question, is it possible to create user with TEMP tablespace,
(I know the usage of temp tablespace also, and we cannot create user with temp tablespace.)
If some trick or any solution, share with me.
Thanks in advance.

1) Can you explain why you want such an unusual situation. By understanding your requirement, perhaps we can suggest alternatives
2) The requirements and restrictions are described in the CREATE USER command in the SQL Reference manual for whatever version you are using. (The stupid part of your question happens by not specifying any version range. <g>)
The requirement to use a TEMPORARY tablespace is documented and enforced in 9i. In 8i, we only required a tablespace to be named.
3) On 10gR2 you see the following response:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Hans>sqlplus system/oracle
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jun 18 06:33:31 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> create user test1 identified by test account unlock
2 default tablespace temp
3 temporary tablespace temp;
create user test1 identified by test account unlock
ERROR at line 1:
ORA-12910: cannot specify temporary tablespace as default tablespace
SQL> create user test2 identified by test account unlock
2 default tablespace users
3 temporary tablespace users;
create user test2 identified by test account unlock
ERROR at line 1:
ORA-10615: Invalid tablespace type for temporary tablespace
SQL> create user test3 identified by test account unlock
2 default tablespace users
3 temporary tablespace temp;
User created.
SQL Rem Just on case it's complaining about using the same temp tablespace
SQL> create temporary tablespace temp2 tempfile 'C:\ORACLE\ORADATA\XE\TEMP2.DBF'
size 10m;
Tablespace created.
SQL> create user test4 identified by test account unlock
2 default tablespace temp
3 temporary tablespace temp2;
create user test4 identified by test account unlock
ERROR at line 1:
ORA-12910: cannot specify temporary tablespace as default tablespace
SQL>

Need help on extending my TEMP tablespace (Ora ver - 8.1.7.0.0)

Hi
I am having problem in executing the SQL query with certain parameters in the WHERE clause.
ORA-01114: IO error writing block to file 4 (block # 524242)
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 524247)
ORA-01114: IO error writing block to file 4 (block # 524242)
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 524247)
I get the above listed error. And i assumed there may be some issue due to Temp tablespace. I also verified the space occupied by the TEMP tablespace and it was 99% occupied.
Kindly let me know is there a way to extend the space without affecting the existing DB content
Regards
Srinivasan B

Didn't you got a answer in your Getting error while executing the SQL ( ver 8.1.7.0.0), did you ?
Furthermore, don't worry about the TEMP tablespace utilization, Oracle doesn't freed space until you need it. By the way, how your TEMP tbs is defined (AUTOEXTEND, DATAFILE/TEMPFILE...) ?
Anyway, you have to be sure about the free space on your device. And check on metalink website to get some notes advices.
Nicolas.

Cleaning up temp tablespace with out restarting Oracle instance.

Hi,
I've a scenario where my temp tablespace gets filled up and i rarely restart my Oracle instance.
My temp tablespace is not auto-incremental and the Oracle version i have is 9.2.4
Appreciate if any one can provide the answers/suggestions?
Thanks.

Thanks for the reply...
I gone through the thread on Jeff Hunter where he is altering by making the temp table space to auto increment.
But my tablespace an i can't change my tablespace to autoincrement since it is in continous use 24x7 and 365 days.
Any ideas please?
Thanks

TEMP tablespace getting full while inserting a CLOB in Trigger

We have a Oracle 10g (10.2.0.4.0) DB on a Solaris 9 box which also runs our J2EE web-service application on Weblogic 8sp6 server.
We get around 220K web-service requests from upstream callers daily to insert data in the main table, say TABLE1, which has daily partitions on a date column. This table has around 21 columns out of which 1 is a CLOB column.
Now this table has an AFTER INSERT trigger which calls a package procedure to insert the same record into another table, say TABLE2.
From Java application insert statement in executed in below format using a weblogic jdbc connection pool :
INSERT INTO TABLE1(COLUMN1, COLUMN2, ........., CLOB_COLUMN,........, COLUMN21) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20);
Clob object is prepared in application using ojdbc14.jar.
We are observing a strange issue here. The TEMP tablespace utilization keeps on growing as more and more inserts are executed by application and after ~125K inserts the TEMP tablespace gets full and we start getting ORA-01652 error.
On further analysis we could see that there are only 7-10 session being maintained but as more and more inserts happen TEMP tablespace utilization goes on increasing for each of these sessions.
When we tried with inserting just few records and then watching the session details in v$session_wait then we could see that it is in INACTIVE state and waiting for the event ‘SQL*Net message from client’. This does not seem correct as the session has successfully inserted the data and committed the transaction and we can see the data in the tables as well.
The confusing thing here is when we modify the trigger to pass blank string('' ) instead of the CLOB column to TABLE2 then this issue does not occur. All 200K records are inserted properly and TEMP tablespace utilization also keep always below 1%.
Can you please help us in solving this issue. Is this related to any oracle issue?
Inside the package we have tried using DBMS_COPY statement to copy the CLOB column after insert but still same result.
Code for reference:
Trigger:
=====================================
CREATE OR REPLACE TRIGGER trg
AFTER INSERT OR UPDATE
ON TABLE1
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF (:NEW.date_col > SYSDATE - 2)
THEN
IF (:NEW.cat IN (1001, 1002))
THEN
pkg.process_change
     (:NEW.COLUMN1,
          :NEW.COLUMN2,
          :NEW.CLOB_COLUMN,
FLAG
END IF;
END IF;
END;
=====================================
Package:
=====================================
procedure PKG.Process_change(
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
flag boolean
) is
v_watermark pls_integer;
v_type varchar2(1);
begin
if (flag) then
v_type := 'U';
else
v_type := 'I';
end if;
select t_seq.nextval into v_watermark from dual;
insert into TABLE2(
COLUMN1 number,
COLUMN2 varchar2,
CLOB_COLUMN clob,
watermark,
dml_type
)values (
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
v_watermark,
v_dml_type
end;
=====================================

My first thought on reading your post is that not only are you using a database version that is now so old it is in extended support and even then not even the most recent patchset for it.
The first thing I would do is move to 11gR2 and if you can't do that at least get to 10.2.0.5 and apply CLOB relevant patches as well.
Same goes for your operating system. Solaris 9 is ancient: So move to 10 which has vastly improved memory management.
To help you further it would be really valuable to know the table layout. For example is this a heap table or an IOT? Is it partitioned? Is this RAC? What size are the CLOBs? Are they stored in-line? Chunk size? etc.
This page should start you down the right road:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14249/adlob_tables.htm#sthref204
But I am also wondering why you would use a trigger to, as you say, "insert the same record into another table." This description is a poster child for "bad design."

Oracle 9i TEMP tablespace backup problem using RMAN!

Oracle8/8i whole backup is ok for our backup software(using RMAN without RC database), but for Oracle 9i, I get following error messages when backing up temp tablespace.
1. RMAN-20202: tablespace not found in the recovery catalog
2. RMAN-06019: could not translate tablespace name "TEMP"
I check some views of Oracle9i, and know some changes happen for temp tablespace in 9i, but how to deal with this problem. Any idea, please!

In 9i RMAN does not restore temporary datafiles. Instead, you should create them after your restore. I believe that Oracle is going to make a change to this in the next release of 9i and have RMAN create the temporary files. You can view the temporary datafiles @ v$tempfile.
I believe RMAN doesn't restore temporary files because they are locally managed and not in the control files. RMAN reads the controlfile of the target database to obtain info about backups, datafiles, etc.
Hope this helps.

To shrink the size of TEMP tablespace

Dear all,
There is a databse with RAC, now in OEM the size of TEMP tablespace has been reached at 99.9%. now we want to shrink the size of TEMP tablespace.
how to we do that???????
plz help me...........

Temporary tablespaces usually show they are full, however this space is not actually in use. It is rather allocated. Oracle has evaluated the best way to obtain the most of performance, and he said it is better to allocate once than allocate-deallocate-reallocate extents, so temporary space is not 'released'.
If you want to feel psychologically more confortable with lower allocated space, you can drop your tablespace (create an interim default temporary tablespace first) and recreate it.
You can also rebuild temporary datafiles:
alter tablespace temp add tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.dbf' size 32m;
SQL> select name from v$tempfile;
NAME
C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP.DBF
C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF
SQL> alter database tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF' drop including datafiles;
Database altered.

Queries are not releasing temp tablespace in 11g standard edition

Queries are not releasing temp tablespace in 11g standard edition

user8928004 wrote:
Hi any one faced one issue.... please help
Patience, Grasshopper
You posted this follow-up a mere two minutes after your previous post.
This forum is not a chat line, and it is not paid support.
Everyone here has a job for which they are paid, and this forum is not it.
No one is responsible for monitoring it and giving a quick response.
Furthermore, it is a global forum. The person with the information you seek may very well live 20 time zones away from you and was going to bed just as you posted. He will not even see your post for several more hours.
Your original post went up in the middle of the night for half the world.
No one with the information you seek is deliberately withholding it until you sound sufficiently desperate.
======================================================
Please present evidence to backup your assertion that "Queries are not releasing temp tablespace"
From the very fine 11g Database Administrator's Guide, at Managing Tablespaces
Space Allocation in a Temporary Tablespace
You can view the allocation and deallocation of space in a temporary tablespace sort segment using the V$SORT_SEGMENT view. The V$TEMPSEG_USAGE view identifies the current sort users in those segments.
When a sort operation that uses temporary space completes, allocated extents in the sort segment are not deallocated; they are just marked as free and available for reuse.

PDB without local TEMP Tablespace

Due to the Oracle Database 12c Concepts Guide it should be possible to create a PDB without a local TEMP Tablespace and the create PDB syntax includes the option (MAX_SHARD_TEMP_SIZE).
But I cannot find any hint how to create a PDB without a TEMP Tablespace or how to change the default temp tablespace to point to the CDB:
Any help will be appreciated.

There is no standard way to create a PDB without a TEMP tablespace
Yes - there is. But you CLEARLY don't want to do things the standard way. You want to use some particular non-standard way.
It is not 'standard' to create a database without a temporary tablespace. That is almost ALWAYS a mistake. That generally happens when you use the CREATE DATABASE command and don't specify it properly.
When you create a database you do NOT have to create a temporary tablespace. That has been the RULE from the very beginning and it is still true for 12c. For proof see the DBA Guide:
http://docs.oracle.com/cd/E16655_01/server.121/e17636/create.htm#i1009290
Creating a Default Temporary Tablespace
The DEFAULT TEMPORARY TABLESPACE clause of the CREATE DATABASE statement creates a default temporary tablespace for the database. Oracle Database assigns this tablespace as the temporary tablespace for users who are not explicitly assigned a temporary tablespace.
You can explicitly assign a temporary tablespace or tablespace group to a user in the CREATE USER statement. However, if you do not do so, and if no default temporary tablespace has been specified for the database, then by default these users are assigned the SYSTEM tablespace as their temporary tablespace. It is not good practice to store temporary data in the SYSTEM tablespace, and it is cumbersome to assign every user a temporary tablespace individually. Therefore, Oracle recommends that you use the DEFAULT TEMPORARY TABLESPACE clause of CREATE DATABASE.
You don't have to believe me or the docs.
Try it yourself. That is the best way to learn. Post your results here for all to see.
That is what that 12c doc says and what ALL of the docs for the versions before say. See for yourself. Here is the doc link for Oracle 7.3 so you can see the CREATE DATABASE systax yourself
http://docs.oracle.com/cd/A57673_01/DOC/server/doc/SQL73/ch4a.htm#createdatabase
Without a temp tablespace Oracle is forced to use the SYSTEM tablespace for the temporary.
These are the STANDARD ways:
1. Create PDB with a temporary tablespace.
2. Use the DBCA with a custom template
3. Create your own PDB seed database without a temp tablespace and then clone your seed to create other PDBs without a temp tablespace
4. Use CREATE DATABASE to create a DB without a temp tablespace and then plug it in to your CDB root container.
Those are ALL standard methods. The last three result in PDBs withoug a temp tablespace.
#1 is what you should be using.
1. Create PDB with a temporary tablespace.
2. Shrink/resize the temp tablespace down to a minimum if you want
3. Assign the users to the CDB temp tablespace if you don't want them using the PDB temp
I would appreciate if you only answer to questions if you have tested it or have a precise answer to it!
I have done BOTH of those things. Your failure to recognize that is NOT my problem.
I have created a PDB without a temp tablespace using DBCA and a custom template.
I have also created a PDB without a temp tablespace by using the historical standard method of CREATE DATABASE without a temp tablespace and then plugging it into the CDB and a PDB.
It is YOUR responsibility to RTFM and YOUR responsibility to actually put your fingers on the keyboard and try things.
The forum is NOT a coding service so you have no right to expect someone to write code for you and no right to get upset if they don't.
dbca doesn't use any other commands than the one's I've already tried!
Your reality is different than Oracle's. Support your reality with some facts.
I just created a PDB (create pluggable database) and no wonder that one comes with a temp tablespace.
I don't see where you posted ANYTHING that shows:
1. exactly WHAT you did
2. exactly HOW you did it
3. exactly what results you got.
If you want help with the code or a process you are using you have to POST that code or process.
We can NOT see your computer screen to see what screens you see or what entries you make.
Complain about the messenger all you want.
But you will NOT be successful with 12c if you refuse to RTFM and refuse to try things yourself. Making unsubstantiated statements or trying to attack me may make you feel better but you won't learn anything from it.

Help on resizing tablespace

i have a tablespace with 23 datafiles of varying sizes, with a total size of 91,060MB, it has consumed 79,457MB. Would it help the performance of the database if I change the size of the individual datafile to have the same size? e.g. 10 to 20Gig each?
What would you suggest I do? The important thing is to avoid or lessen database downtime.
I have a TEMP tablespace which has a size of 22,074MB, it's always full, is this normal and what would you suggest.

Thanks for your response.
Tablespace size, or getting the data files the same size, has very little to do with performance.
-----thank you for this info.
Using the files effectively has a lot to do with performance.
For example, are the files on RAID striped disk? Or are they all on the same disk? (If on the same, every request for info from the disk is going to cause the heads to move and cause all other possible requests to wait for that to finish ... very inefficient!)
----yes the files are on RAID striped disk.
Do you have enough memory assigned available for outside the database (not part of the SGA) that could be used for sorting, to avoid spilling sorts to the temp tablespace?
----how can I check this? kindly help
Do you have enough memory, or too much memory, assigned to the SGA? Are you using the SGA efffectively?
-----how can I check this? kindly help
How are you arriving at the conclusion that the 'temp tablespace is full'? If you use the same info as the permanent tablespace, you are barking up the wrong tree - the temp tablespace SHOULD be full of temp segments. The question should be "how many of these segments are actually in use?"
------When I look at the temp tablespace in the Enterprise Manager, it states 99% used.
What version of the database is this? What optimization techique are you using? Have you looked at the Performance Tuning document in the doc set for your database?
-----9iR1. No optimization technique used. No I haven't looked at the performance tuning, but I'm studying it right now. sorry i'm just new to this.

CLOB processing consuming large memory in temp tablespace

We are having a stored procedure, which is called from a Java process to enqeue a message in to AQ. The input for the procedure is CLOB.
In some installations where oracle standard editions is used, the temp tablespace is growing in large volumes and the only process accessing the temp tablespace is the procedure. Oracle version is 9i 9.2.0.5.0
We are doing a trim on the clob variable inside the procedure. Will that cause any issues like this ?
Procedure is as below
procedure enq_msg
(queue_name varchar2, msg_text in clob,p_result out number) as
queue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
message_id RAW(16);
v_msg_text               clob default msg_text;
v_queue_name          varchar2(40) deafult queue_name;
BEGIN
v_msg_text := trim(v_msg_text);
v_queue_name := queue_name;
DBMS_AQ.ENQUEUE(queue_name => v_queue_name,
                         enqueue_options => queue_options,
                         message_properties => message_properties,
                         payload => v_msg_text,
                         msgid => message_id
     commit;
     p_result := 0;
exception
when no_data_found then
p_result := 1;
     rollback;
when others then
     rollback;
p_result := sqlcode;
END enq_msg;

Is there a reason you have v_msg_text and v_queue_name defined? You can use queue_name directly in the call to dbms_aq.enqueue and also payload => trim(msg_text)
This would eliminate the copying of the clob that is currently occurring and may help your space issue.
Is trim really needed?
I'm not familiar with any CLOB related bugs in 9i but the above is just some things I would try or question.

Help with Temp tablespace..

Similar Messages

Maybe you are looking for