Increasin the temp tablespace

Hello All,
I am using Oracle 11g R2 i want to increase the temp tablespace size. can i use the below command? can i increase while the database is open and some queries are running and use the temp table space?
ALTER DATABASE TEMPFILE '....../datafile/name_datafile.tmp' RESIZE 100M
Regards,

Hello,
I am using Oracle 11g R2 i want to increase the temp tablespace size. can i use the below command? can i increase while the database is open and some queries are running and use the temp table space?Why do you intend to extend the Temporary Tablespace ? Do you have any ORA-01652 error ?
If not, may be it's not necessary to extend it. Even if it seems to be full Free Extents are reused.
ALTER DATABASE TEMPFILE '....../datafile/name_datafile.tmp' RESIZE 100MYes you can use this statement, but be aware that the Size specified (here 100 Mo) is the target size not the supplemental size.
Hope this help.
Best regards,
Jean-Valentin

Similar Messages

How to add a datafile in the temp tablespace

how i can add a datafile in the temp tablespace.
becuase i am getting tyhe following error
SQL> select aa.question_desc,a.answer_desc from answer a ,
2 (select * from question_t where rownum <=100 order by dbms_random.random) aa
3 where a.question_id = aa.question_id
4 /
select aa.question_desc,a.answer_desc from answer a ,
ERROR at line 1:
ORA-01652: unable to extend temp segment by 256 in tablespace TEMP

select * from question_t where rownum <=100 order by dbms_random.random After all the discussion about random select a random generated number... why don't you go for one of the suggestion like : 
select *
from (select * from question_t order by dbms_random.random)
where rownum <=100 The result is different. 
In your query, you take 100 rows and order randomly, in the second query, order randomly, and take 100 first rows... 
As you can see above, with your last query, output row are always same, but in different order : 
SCOTT@demo102> select ename from emp where rownum<=5 order by dbms_random.random;
ENAME
SMITH
ALLEN
MARTIN
JONES
WARD
SCOTT@demo102> /
ENAME
MARTIN
JONES
SMITH
ALLEN
WARD
SCOTT@demo102> /
ENAME
JONES
ALLEN
MARTIN
SMITH
WARD
SCOTT@demo102> /
ENAME
ALLEN
SMITH
WARD
MARTIN
JONES
SCOTT@demo102> 
Anyway, I don't restart this discussion here. 
For your actual problem, Pierre has already give you a suggestion. 
 
Nicolas.

Any way to avoid the hit on the TEMP tablespace?

I'm running a CTAS query that unions 13 tables with about 7,000,000 rows each, inner joins that union again against a global temporary table with 13 rows, and then doing a GROUP BY against the result, summing about 6 fields. The resulting query runs in about 2 hours with about a 16 Gig hit on the TEMP tablespace.
In production I will need to join 52 tables with about that many rows against a GTT with 52 rows. I haven't experimented with it yet but I'm guessing the time and memory increase will be linear (i.e. 8 hours, 64 Gig hit).
I'm being asked if there's any way to avoid the hit on the TEMP tablespace. It was suggested that I look into using a materialized view, but won't that just transfer the hit from the harddrive to the RAM? I don't think this particular database has 64 Gigs of RAM dedicated to it, and I'm sure the row counts will grow in the future anyway.
Thoughts?
Thanks
Joe

I don't have visibility to the TEMP tablespace on their database so I don't know if the hit there is any less.
If you have privileges you can use SQL*PLUS autotrace (or possibly Oracle trace, if you're really that interested) to get run-time statistics on a query as you run it. Waiting for the 2-hour results will be a bit tedious though. If you don't have privileges for autotrace it won'r work; the error messages explain what's wrong rather well ;)
SQL> set autotrace on
SQL> select * from dual;
D
X
Execution Plan
Plan hash value: 3543395131
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
          3 consistent gets
          2 physical reads
          0 redo size
        204 bytes sent via SQL*Net to client
        234 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processedI still haven't figured out why selecting from dual is doing 3 consistent gets and 2 physical reads ;)

Clean the temp tablespace

to clean i drop a temp tablespace and create another with same name..
Have an another way to clean an temporary tablespace?

Hi,
when show full the tablespace i can't resizeDon't worry, see this other thread : Re: can not create table...!
It's better do not to use an autoextend file for temp tbs.
Nicolas.

Sizing of the OLAP temp tablespace!!

We are using 10gR2 OLAP along with Disco Plus OLAP to build a prototype. The metadata is built with AWM 10.2.0.1.0A.
Our test data is about 40M records, 1.7G in a flat file. After loaded to a fact table via Sql*loader, it takes about 2G for the tablespace, along with 7 dim tables. Only one cube and one measure are used. A compressed composite with 6 dims in it is associated with the cube.
However, when run the AWM maintenance steps to get a full cube aggregation. The temp tablespace for the AW shot for 30G and then generated an out of disk space error. The AW tablespace remains untouched. The maintenace cannot be finished.
Interesting to note, the data was solved in the Xpress already. When do a eif exp/imp, the result tablespace is about 5G while the eif file takes 1.3G.
Also, before doing this round data, we have sucessfully created and maintained a AW with very small set of data. The data is displayed in Disco Plus correctly.
The disk space for the temp tablespace seems surprisingly demanding. We need to get an idea how much space it really needs. Is there anybody that has some contributable experience on this issue? Please reply this post. Not sure if Oracle has formal publishing on the temp tablespace sizing issue. Believe they should have one.
Thanks,

Chris,
No upgrading was done here. The metadata and objects were defined using AWM model view manually, but matching to the definition on the Xpress side for the same object, like dim order etc. The fact data then dumped to a flat file from Xpress, transferred to the olap db server and loaded to a star schema with sql*loader. AWM mapping and maintenance features were used to build the cube.
I am saying the data was solved means the summary level data was included in the dump. So we know the size of the solved cube. My reasoning is that there should be no place for the size increase to out of control because too much new summary level data was added.
Another fact I should mention last time is all the data are in one time period. 40M is the number of tuples.
Thanks for the help.
Haiyong

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

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)

How can I know which queries run in the TEMP tbs (Oracle 9i and 10g) ?

Dear friends, do you have a query which can shows which statements are running currenly in the TEMP tablespace?
Many Thanks in advance, Marcelo.

Marcelo,
you can check DBMS_XPLAN.DISPLAY_CURSOR - if you find a column TempSpc there, it's using Temp space.
select source from sys.source$ order by source;
select * from table(dbms_xplan.display_cursor(NULL, NULL, NULL));
PLAN_TABLE_OUTPUT
SQL_ID 5ywbw0z6gupwk, child number 0
select source from sys.source$ where rownum < 555555 order by source
Plan hash value: 1381731087
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | | 11492 (100)| |
| 1 | SORT ORDER BY | | 555K| 37M| 87M| 11492 (1)| 00:02:18 |
|* 2 | COUNT STOPKEY | | | | | | |
| 3 | TABLE ACCESS FULL| SOURCE$ | 572K| 38M| | 1834 (1)| 00:00:23 |
---------------------------------------------------------------------------------------or for all your statements currently available:
SELECT t2.*
FROM v$sql s, table(DBMS_XPLAN.DISPLAY_CURSOR(s.sql_id, s.child_number)) t ,
 table(DBMS_XPLAN.DISPLAY_CURSOR(s.sql_id, s.child_number)) t2
WHERE t.PLAN_TABLE_OUTPUT like '%TempSpc%';Edit: Sorry, I didn't see you are also asking for 9i. DISPLAY_CURSOR is only available in 10g+ - but Tom Kyte and others have shown WorkArounds to use DBMS_XPLAN.DISPLAY from 9i to show the information for all available SQLs.
2nd Edit:
TempSpc only shows the estimation the optimizer makes.
You can check V$SQL_PLAN_STATISTICS_ALL for the columns max_tempseg_size and tempseg_size. In Addition please have also a look on [http://antognini.ch/about/] Blog [http://antognini.ch/2009/05/wrong-information-about-temporary-space-usage/] .
I used:
select PARENT_ID, ID, DEPTH, POSITION,
 MAX_TEMPSEG_SIZE, LAST_TEMPSEG_SIZE
from v$SQL_PLAN_STATISTICS_ALL
where MAX_TEMPSEG_SIZE > 0;hth,
Martin
Edited by: berx on Jun 17, 2009 4:11 AM
Edited by: berx on Jun 17, 2009 6:18 AM

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.

Temp tablespace issue

Hi,
We are facing continuous problem of slow performance in some applications...i found that temp tablespace is becoming full frequently...so after that reports are getting delayed..is there any permanent fix for this problem..
We have recreated the temp tablespace...
Regards,
Joshua

Hi,
pls find the details...
VERSION:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
some info abt temp tablespace:
TABLESPACE_NAME BYTES_COALESCED EXTENTS_COALESCED PERCENT_EXTENTS_COALESCED BLOCKS_COALESCED PERCENT_BLOCKS_COALESCED
TEMP_SCHEMA_USR 50724864 2 100 6192 100
is that means coalescing would solve the problem ?...
We have some limitation that we cant control the users since they are very critical in operation...
Is Adding datafile will solve the problem(bcoz b4 sometime i added one file....no improvement)...

Informatica Workflow fails because of TEMP tablespace

Hi,
I am trying to do a Complete Oracle 11.5.10 load. However my execution plan fails because the SDE_ORA_Payroll_Fact fails. The error in the session log is as follows:
READER_1_1_1> RR_4035 SQL Error [
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
From the error message it is very clear that the Source Qualifier is unable to select the data from the source tables. i have increased the TEMP tablespace too however I keep getting the error. Because of this error my other mappings are also Stopped. Any solutions to this problem?

Hi,
Would you not want to use the following parameters to say load one fiscal year at a time?
Analysis Start Date
The start date used to build the day dimension and to flatten exchange rates and costs lists.
$$ANALYSIS_START, $$ANALYSIS_START_WID
Default : Jan 1, 1980
Analysis End Date
The end date used to build the day dimension and to flatten exchange rates and costs lists.
$$ANALYSIS_END, $$ANALYSIS_END_WID
Default : Dec 31, 2010
Thanks,
Chris

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.

Adding Temp tablespace to physical stand by database?

I am getting the below error when i try to load data using SQL loader from physical stand by database to another database after making the physical stand by database in read only mode.
ORA-25153: Temporary Tablespace is Empty.
On primary database when i query
SQL>select ts#,name from v$tablespace;
TS# NAME
2 TEMP
On physical stand by when i query
SQL>select ts#,name from v$tablespace;
TS# NAME
2 TEMP
On primary DB when i query
select name from v$tempfile where ts#=2;
NAME
/dev/vx/rdsk/oradata/tempfile0101
On standby when i query
SQL>select name from v$tempfile where ts#=2;
no rows selected
At this point do i need to add datafile to the TEMP tablespace of stand by database or just need to add TEMP tablespace to stand by database.?
DB version:9.2.0.6
Thank You all...

Can you make sure that /dev/vx/rdsk/oradata/tempfile0101 is copied to standby site during the standby creation. Often it happens that the hot backups are copied to standby ste and generally they dont contain temp files. If the files is present , then i'll suggest you to do a quick bounce of standby instance to make sure that controlfile attempted to access it. You can also try recreating the standby control file on promary and copy it to standby site along with the tempfile and start the instance with new control file.
If you want to add temp files to the standby instance, the only option you have is to add them on primary site. If you have standby_file_management as auto they will get copied over. If not you can copy the files to standby instance and restart the recovery.
Please let us know if any of the hints are applicable to your case.
-Ravi

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.

ORA-01652 in TEMP Tablespace

Hi,
We have the following errors:
RMAN> crosscheck archivelog all;
starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 01/07/2009 14:26:10
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 01/07/2009 14:26:10
ORA-01652: unable to extend temp segment by in tablespace
RMAN>
We have tried to increase the size of the TEMP tablespace, but this operation keeps using up the entire temp tablespace. It's the temp tablespace in the target database that is filling up.
We cannot keep increasing the size of the TEMP ts to fill the disk.
We have also tried to create a new repository but this had the same outcome.
I reckon there is something in the database tables, as one of our backups used the target control file as its repository. Should I remove the entries from these tables in the target tablespace to make the repository think there is no re-synching to be done?
Regards,
Tim.

If you are sure that it is on the target DB what you can do is enable a trace for the event to see what triggers this error
it doesnt have to be on temporary table because there are temp segments on normal tables used for index creation type operations as well so you need to find the problem before assuming it is temp tablespace error
alter system set events '1652 trace name errorstack level 1';
to turn off
alter system set events '1652 trace name context off';
If you cant find anything from trace then you can send the trace output here maybe somebody can catch something.
Coskan Gundogar
http://coskan.wordpress.com
Edited by: coskan on Mar 30, 2009 4:28 PM

Increasin the temp tablespace

Similar Messages

Maybe you are looking for