Tablespace Groups

Hi,
Going throug the documentations, I found a few references to tablespace groups, specifically in reference to temporary tablespaces. I found it in the Administrator's Guide and the Concepts manuals. But I could not find any explanations as to what a tablespace group is or how to create it. Could one of you please clarify the same for me or point me to the documentation/white papers where I could find an explanation ?
Thanks in advance,
Regards,
Sriraman

A tablespace group enables a user to consume temporary space from multiple tablespaces.
A tablespace group has the following characteristics:
It contains at least one tablespace.
There is no explicit limit on the maximum number of tablespaces that are contained in a group.
It shares the namespace of tablespaces, so its name cannot be the same as any tablespace.
You can specify a tablespace group name wherever a tablespace name would appear when you assign a default temporary tablespace for the database or a temporary tablespace for a user.
You do not explicitly create a tablespace group. Rather, it is created implicitly when you assign the first temporary tablespace to the group. The group is deleted when the last temporary tablespace it contains is removed from it.
Using a tablespace group, rather than a single temporary tablespace, can alleviate problems caused where one tablespace is inadequate to hold the results of a sort, particularly on a table that has many partitions. A tablespace group enables parallel execution servers in a single parallel operation to use multiple temporary tablespaces.
Data Dictionary Object dba_tablespace_groups
Group Creation
With Create Tablespace
CREATE TEMPORARY TABLESPACE batchtemp
TEMPFILE '/u02/oradata/temp04.dbf'
SIZE 250M
TABLESPACE GROUP temp_grp;
With Alter Tablespace ALTER TABLESPACE <tablespace_name>
TABLESPACE GROUP <group_name>;
ALTER TABLESPACE tools TABLESPACE GROUP apps_grp;
Remove A Group Member
Tablespace Removal ALTER TABLESPACE <tablespace_name> TABLESPACE GROUP '';
ALTER TABLESPACE batchtemp TABLESPACE GROUP '';
Default Temporary Tablespace Assignment
Make a group the default group ALTER DATABASE <tablespace_name>
DEFAULT TEMPORARY TABLESPACE <group_name>;
ALTER DATABASE orabase
DEFAULT TEMPORARY TABLESPACE app_grp;

Similar Messages

ORA-10914: invalid TABLESPACE GROUP clause

hai im trying to create a database in oracle 10g
tablespace sysaux datafile 'E:\oracle\product\10.1.0\oradata\multi\ts_sysaux01.d
bf' size 10m autoextend on extent management local
ERROR at line 9:
ORA-10914: invalid TABLESPACE GROUP clause
can any one explain me ,
regards,
ashik

first i thank u mr.venkat and user526020 for replied for ,
here i enclosed my database creation for ur ref,
create database multi logfile
group 1 'E:\oracle\product\10.1.0\oradata\multi\redo01.log' size 10m,
group 2 'E:\oracle\product\10.1.0\oradata\multi\redo02.log' size 10m,
group 3 'E:\oracle\product\10.1.0\oradata\multi\redo03.log' size 10m
datafile 'E:\oracle\product\10.1.0\oradata\multi\system01.dbf' size 10m autoextend on
default tablespace users datafile 'E:\oracle\product\10.1.0\oradata\multi\ts_users01' size 10m autoextend on extent management local
default undo tablespace undotbs datafile 'E:\oracle\product\10.1.0\oradata\multi\ts_undotbs01.dbf' size 10m autoextend on
default temporary tablespace temptbs tempfile 'E:\oracle\product\10.1.0\oradata\multi\ts_temptbs01.tmp' size 10m autoextend on
tablespace sysaux datafile 'E:\oracle\product\10.1.0\oradata\multi\ts_sysaux01.dbf' size 10m autoextend on extent management local
character set al32utf8
SYS at multi>/
tablespace sysaux datafile 'E:\oracle\product\10.1.0\oradata\multi\ts_sysaux01.d
bf' size 10m autoextend on extent management local
ERROR at line 9:
ORA-10914: invalid TABLESPACE GROUP clause
here im getting error only on sysaux tablespace size then i tried to increase the size even it shows the same,
so can any one give solution.
regards,
ashik

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.

10G: TEMPORARY TABLESPACES GROUP

제품 : ORACLE SERVER
작성날짜 : 2004-05-25
10G: TEMPORARY TABLESPACES GROUP
==================================
PURPOSE
이 문서에서는 10g New Feature 인 Temporary tablespace 의 group 에 대해 알아 보도록 한다.
Explanation
10g 에서는 temporary tablespaces 에 대해 group 을 지정하여 생성할 수 있고
consumer group 을 지정하여 resource manager 와 함께 적용하여 사용이 가능하다.
다음은 Temporary tablespace group 지정을 위한 기본적이 사항이다.
1. 하나의 temporary tablespace group 은 적어도 하나의 tablespace 가 존재해야 하고
maximum number tablespace 에 대한 limit 은 정해져 있지 않다.
2. Ttemporary tablespace 와 group name 을 동일하게 지정할 수 없다.
3. Temporary tablespace group 은
     1) 한 group 에서 다른 group 으로 move 가 가능하고
     2) Group 내에서 삭제 될 수 있으며
     3) 추가적으로 add 가 가능하다.
4. Temporary tablespace group 사용으로 인해
     1) Sort 결과를 유지하여 space 낭비를 막을 수 있고
     2) 동시에 여러개의 session connect 시에도 서로 다른 temporary tablespaces 를 사용함으로써
     temporary tablespaces 의 사용을 분산 시킬 수 있다.
     3) Parallel operation 시에도 multiple temporary tablespaces 사용이 가능하다.
Example
1. GROUP1 을 지정하고 GROUP1 에 속하는 temporary tablespace LMTEMP 1 를 생성한다.
이 때 GROUP 1 을 따로 생성할 필요 없고 temporary tablespace 생성시에 지정하도록 한다.
SQL> create temporary tablespace LMTEMP 1
tempfile 'D:\ORACLE10\ORCL\temp1_01.dbf' size 50M
tablespace group GROUP1;
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP1 LMTEMP1
2. LMTEMP2 를 GROUP1 에 새로 추가한다.
SQL> create temporary tablespace lmtemp2
tempfile 'D:\ORACLE10\ORCL\temp1_02.dbf' size 2M
tablespace group group1;
Tablespace created.
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP1 LMTEMP1
GROUP1 LMTEMP2
3. 기존에 존재하는 LMTEMP1 를 GROUP2 로 move 한다.
SQL> alter tablespace LMTEMP1 tablespace group GROUP2 ;
Tablespace altered.
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP2 LMTEMP1
GROUP1 LMTEMP2
4. LMTEMP1 이 속해 있던 GROUP2 에서 LMTEMP1 를 제외 시키고 다시 포함시킬 수 있다.
SQL> alter tablespace LMTEMP1 tablespace group '';
Tablespace altered.
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP1 LMTEMP2
SQL> select tablespace_name from dba_tablespaces where contents='TEMPORARY';
TABLESPACE_NAME
TEMP
LMTEMP1
LMTEMP2
SQL> alter tablespace LMTEMP1 tablespace group GROUP1;
Tablespace altered.
5. Temporary tablespace 와 group name 을 동일하게 지정할 경우 ORA-10918 에러가 발생한다.
즉, temporary tablespace 와 group name 을 동일하게 지정이 불가능하다.
SQL> create temporary tablespace lmtemp5
tempfile 'D:\ORACLE10\ORCL\temp1_05.dbf' size 50M
tablespace group lmtemp5;
create temporary tablespace lmtemp5
ERROR at line 1:
ORA-10918: TABLESPACE GROUP name cannot be the same as tablespace name
6. 존재하던 모든 temporary tablespaces 를 drop 하게 되면 group 은 자동으로 remove 된다.
SQL> create temporary tablespace LMTEMP3
tempfile 'D:\ORACLE10\ORCL\temp1_03.dbf' size 2M
tablespace group GROUP2;
Tablespace created.
SQL> create temporary tablespace LMTEMP4
tempfile 'D:\ORACLE10\ORCL\temp1_04.dbf' size 2M
tablespace group GROUP2;
Tablespace created.
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP1 LMTEMP1
GROUP1 LMTEMP2
GROUP2 LMTEMP3
GROUP2 LMTEMP4
SQL> drop tablespace lmtemp3 including contents and datafiles;
Tablespace dropped.
SQL> drop tablespace lmtemp4 including contents and datafiles;
Tablespace dropped.
SQL> select * from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
GROUP1 LMTEMP1
GROUP1 LMTEMP2
7. Group 에 user 사용이 가능하도록 지정할 수 있다.
SQL> alter user scott temporary tablespace GROUP1;
User altered.
8. Temporary tablespace group 을 database level 의 default temporary tablespace 로도 지정할 수 있다.
SQL> alter database <db_name> default temporary tablespace GROUP1;
Database altered.
만약, temporary tablespaces 가 default database temporary tablespace group 에 속해 있는경우
drop 시 ORA-10921 에러가 발생하게 된다. 즉, default temporary tablespace group 에 속해 있는 경우
drop 할 수 없다.
SQL> drop tablespace LMTEMP2 including contents and datafiles;
drop tablespace lmtemp2 including contents and datafiles
ERROR at line 1:
ORA-10921: Cannot drop tablespace belonging to default temporary tablespace
group
Reference Documents
<NOTE. 245645.1>

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

TEMP Tablespace Groups

In Datawarehouse environment, Database verion 10gR2:
Created two temp tablespaces TEMP1 and TEMP2 with 10GB each in a temp tablespace group(TEMP_GROUP) and assigned the TEMP_GROUP as default temporary tablespace to user "BATCH", expecting the batch user can use 20GB of temp tablespace.
When a process needs a temp tablespace of more than 10GB, the process fails with an error unable to extend temp tablespace. It is not utilizing the other 10GB TEMP tablespace.
When I assign a dedicated TEMP tablespace TEMP3 with 15GB as the default temp tablespace, the process succeeds.
It looks like when a session starts it assigns one TEMP tablespace(from group), if that fills up it is not taking advantage of the other TEMP tablespace in the group, which makes me think that Groups are not helping here.
Is there an other way around to utilize multiple temp tablespaces for a single user.
Can we expect an improvement of this feature in the future releases or is that not a possible scenario?

-- Using a tablespace group, rather than a single temporary tablespace, can alleviate problems caused where one tablespace is inadequate to hold the results of a sort, particularly on a table that has many partitions. A tablespace group enables parallel execution servers in a single parallel operation to use multiple temporary tablespaces.
CREATE TEMPORARY TABLESPACE TEMP2 TEMPFILE '/u10/oracle/oradata/dbt1/datafile/temp02.dbf'
SIZE 20M
TABLESPACE GROUP tempgroup1;
CREATE TEMPORARY TABLESPACE TEMP3 TEMPFILE '/u10/oracle/oradata/dbt1/datafile/temp03.dbf'
SIZE 20M
TABLESPACE GROUP tempgroup2;
ALTER TABLESPACE temp TABLESPACE GROUP tempgroup1;
select * from v$tempfile ;
select * from dba_tablespace_groups ;
alter user ABCD temporary tablespace tempgroup1 ;
-- Verify that temp group is assigned to user
select * from dba_users where username='ABCD' ;
After you assign the group to the user abcd then retry your operation as abcd user.
This time it will use both the temporary tablespaces for sort operations.
Thanks
GC

Temp Tablespace Group or Not

Hi Gurus,
We are in desiging phase of databse and wanted to look at the benefits for temporary tablespace group over the conventional temporary tablespace.
Any idea?
Thoughts are welcome
Can somebody move this thread to Database General? I think I have posted it at wrong place
Regards,
Virendra
Edited by: Virendra.K1.Yadav on Oct 1, 2012 1:32 PM

The thrust of my replies is that OP hasn't really determined 'the type of thing' that needs done so, as yet, there IS no target to aim at. The solution could be as simple as enabling PARALLEL operations that are disabled server wide for some reason. The example doesn't resemble the temp tablespace group as PARALLELISM by default is enabled but temp tablespace group is not. As mentioned by John I am still in design phase of new database as we are migrating from orace 10gR2 to 11gR2 and was thinking of option. In 10g temp space is around 700G and we are trying to decrease it as low as possible without affecting the query performance at least (if not improve).
Certainly it can be informative to study and learn Oracle features, what they are for, relevant scenarios, etc. But you still wind up with a solution waiting for an appropriate problem. One can not wait for the bug to be hit and then apply PSU. There are two things proactive and reactive. Waiting for problem to occur and then go for solution is not a good idea for me and I consider more investment in designing than in maintaining.
It is the problem/cause definitions that are lacking here. Until an appropriate problem has been identified there isn't really any basis for applying any particular solution.I don't agree, sitting idle and waiting for problem to occur and then applying solution.
Regards,
Virendra

Qeustion regarding temp tablespace group

Hi All,
I am new to this concept. I've been reading about it but there is something I am not sure to understand.
If I have a temp tablespace group using tablespace temp1 and temp2 and a user submit a large query, will the query use both temp1 and temp2 or just 1 of them?
Group Name: temp
Tablespace: temp01 (1 datafile temp01.dbf)
Tablespace: temp02 (1 datafile temp02.dbf)
Thank you!

1. A single workarea execution can't use space from more a single tablespace even when the user is assigned a temporary tablespace group. Or in other words: A single workarea execution can only allocate a single temporary segment, and segments in general can't span multiple tablespaces in Oracle, i.e. they must fit into a single tablespace.
2. Even multiple workareas for a single session can't use space from the multiple temporary tablespaces available. So this looks like a session attribute, i.e. assigned to the session, and all workareas of that session will use the single temporary tablespace assigned (taken from the group)
3. Multiple sessions of the same user can be assigned to different temporary tablespaces taken from the group.
4. Parallel execution slave sessions can do the same, they can be assigned to different temporary tablespaces taken from the group.
So in order to leverage the power of temporary tablespace groups you need either multiple sessions running serial SQL or the parallel execution option.
Source:http://oracle-randolf.blogspot.in/2009/06/temporary-tablespace-groups.html
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

Tablespaces and block size in Data Warehouse

We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. The question is what are general advices in such considerations according table spaces and block size? I made some research and it is hard to find some clear answer, there are resources advising that block size is not important and can be left small (8 KB), others state that it is crucial and should be the biggest possible (64KB). The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
Any help highly appreciated and thank you in advance.

Wojtus-J wrote:
We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. With little experience, the key feature is to avoid big mistakes - don't try to get too clever.
The question is what are general advices in such considerations according table spaces and block size? If you need to ask about block sizes, use the default (i.e. 8KB).
I made some research and it is hard to find some clear answer, But if you get contradictory advice from this forum, how would you decide which bits to follow ?
A couple of sensible guidelines when researching on the internet - look for material that is datestamped with recent dates (last couple of years), or references recent - or at least relevant - versions of Oracle. Give preference to material that explains WHY an idea might be relevant, give greater preference to material that DEMONSTRATES why an idea might be relevant. Check that any explanations and demonstrations are relevant to your planned setup.
The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
It is often convenient, and sometimes very important, to separate data into different tablespaces based on some aspect of functionality. The performance thing was mooted (badly) in an era when discs were small and (disk) partitions were hard; but all your other examples of why to split are potentially valid for administrative. Big/Small, table/index, old/new, read-only/read-write, fact/dimension etc.
For data warehouses a fairly common practice is to identify some sort of aging pattern for the data, and try to pick a boundary that allows you to partition data so that a large fraction of the data can eventually be made read-only: using tablespaces to mark time-boundaries can be a great convenience - note that the tablespace boundary need not match the partition boudary - e.g. daily partitions in a monthly tablespace. If you take this type of approach, you might have a "working" tablespace for recent data, and then copy the older data to "time-specific" tablespace, packing it and making it readonly as you do so.
Tablespaces are (broadly speaking) about strategy, not performance. (Temporary tablespaces / tablespace groups are probably the exception to this thought.)
Regards
Jonathan Lewis

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.

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.

TEMP tablespace

I see the TEMP tables space currently allocating 32GB and is 100% full.
Can someone give me a quick explanation of what this is for and if I can delete all data from this or re-create it?

#change temp tablespace
1. create new temp tablespace.
CREATE TEMPORARY TABLESPACE TEMP TEMPFILE
'/oracle/product/oradata/syslog/temp01.dbf' SIZE 2048M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED
TABLESPACE GROUP ''
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
2. make it default
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
3. drop the old one
drop tablespace temp2 including contents and datafiles.
Regards
Asif Kabir

Storage parameter for Temp tablespace

Hi all,
Greetings of the day...
DB version is 10.2.0.4 ..Size of db is 550gb and in that temp tablespace is 40gb... daily and frequently we used to unable to extent temp segments...Saw the storage parameters of temp segments it has only 'EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16777216'
Please suggest as how to define storage parameters for temp tablespace...Am able to find the query which uses temp segments...Just needed to know abt the storage parameters for it..
thanks,
baskar.l

CREATE TEMPORARY TABLESPACE TEMP TEMPFILE
'/u02/TSTLOG/temp01.dbf' SIZE 15360M AUTOEXTEND ON NEXT 100M MAXSIZE 32767M
TABLESPACE GROUP ''
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Hope this will work.
Regards
Asif Kabir

Drop a temporary tablespace

Hi all
I have created a temporary tablespace temp01 and assign it as the default temporary tablespace for the database (10.0.2.0)
How can I drop it without changing the default temporary tablespace?
thanks for help

phaeus wrote:
Hello,
create a new temporary tablespace. Make it to your default database temp tablespace and then you can drop the old one.
A couple of thoughts I'd want to check on that - based on memories of problems in the dim and distant past.
If you take this approach, do you still have to worry about users who have already got the dropped tablespace associated with their temp tablespace in dba_users ? Memory says they'll either get an error message, or they'll fall back to SYSTEM despite there being a new default.
One of the reasons for creating tablespace groups for temporary tablespaces is that you can assign a tablespace group to a user, and then invisibly create and drop temporary tablespaces in that group without having to adjust the users' details. But there used to be a bug that resulted in excessive hits on dc_tablespaces if you did this, and extreme numbers of executions of a query against ts$ (or maybe file$).
Regards
Jonathan Lewis

Change temporary tablespace for session

hi.
i wonder if it's possible to change temporary tablespace for session in the way other then `alter user <user> temporary tablespace <tbc>'?

Hi,
Temporary tablespace is set at database level and user level. It is not set at the session level.
The below is an extract from Oracle Docs for 10gR2
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.You can specifically assign a temporary tablespace for the user but not for the session.
regards,
Vijayaraghavan K

Tablespace Groups

Similar Messages

Maybe you are looking for