Temporary Tablespace

Temporary Tablespace 用于存放瞬时数据，只有在session连接期间才能够看到数据。Permanentobject无法创建在temporarytablespace中。

空间利用原理：

它不会由smon来监控、回收空间。而是使用SEP（Sort Extent Pool）来记录空闲的extent。

在OracleDatabase创建数据库的时候会自动的创建默认临时表空间，并且临时表空间的类型是 Locally Managed Temporary Tablespace with Tempfile 。

Temporary File

本地管理临时表空间拥有temp file，它是为存放hash数据、排序数据等而设计的文件。Temp file同样在超出memory大小后存储结果集的数据。

TemporaryFile在创建的时候，就像一个稀疏文件，不会占用磁盘空间。只有当第一次使用的时候才会在其中创建temporary segment，分配disk block。

Temp file 与 通常的数据文件（permanent data file）有如下不同点：

1.      持久化数据库对象比如说通常的表，不会存放于temp file中。

2.      temp file 通常是nologging状态。

3.      无法将temp file置于read-only状态（无法write，temp file将没有意义）。

4.      无法使用alter database创建 temp file 。

5.      无法保证temp file的大小，就像UNIX系统下的sparse files 。稀疏文件解释请看附录1。

6.      查询temp file的视图也和普通数据文件视图不一样，是在dba_temp_files和v$tempfile中。

Temporary Segment

执行查询的过程中，oracle db通常需要临时工作空间。通常来说，sorting、hashing、merging bitmaps都需要用到临时段。当创建一个索引的时候，oracle db 同样将索引segment放在临时segemnt中，然后索引创建完之后转换为持久化index segment。

如果操作可以在内存中完成，那么oracle db不会使用临时segment。不管怎样如果memory不可用，那么数据库自动的分配一个在存储磁盘上面的临时segment。

临时segement的改变不会记录在online redo log中，除了那些在临时段上面的空间管理操作。

Temporary table

临时表中的数据，只保证存在于事务或者会话当中（取决于定义信息）。数据在会话当中是私有的，也就是说其他的会话只能看到自己会话内更改的数据。

在创建临时表的时候，只需要指定临时表的生命周期范围，事务 or 会话 有效，而不需要指定它的存储参数，创建一个临时表，其实只是创建了临时表的定义信息。只有当在session内第一次插入数据的时候，才会在用户相应的临时表空间内非配temporary segment（一个segment可以被多个用户使用，只是分配各自的extent）。

临时表通常只有定义信息，并且数据存放是动态的。可以存放于同一个temporary tablespace ， 也可以是不同的。比如user 1 default temporary tablespace 为temp 1 ，user 2 为temp 2 ，那么u1 存储临时数据到 temp1 中，u2 存储临时表数据到temp2 中。

虽然临时表数据的存储是动态的，但是因为临时表的定义信息是静态的，所以也可以创建索引在临时表上，数据的存放也与临时表类似，在第一次使用的时候分配临时segemnt。当然，也可以创建视图、触发器在临时表上。

什么时候需要使用Temporary Tablespace

首先就是当使用临时表的时候多个用户会共享使用一个temporarysegment，还有hashing，bitmap merge，然后就是排序操作了，当操作需要使用的内存空间大于sort_area_size的时候，就会使用临时表空间做为临时存储，进行排序操作，以下是需要排序的操作，也就是说有可能使用临时表空间的操作。

- Index creation.

创建索引的时候，服务器进程在构建tree之前按照索引值排序好（这可能会在临时表空间中进行）。排序完成后，会在indextablespace中使用临时segment构建最终的index，一旦索引构建结束，segment type改变为index 。（如果创建index失败，则需要smon来负责清理这些index tablespace中的临时空间）

- ORDER BY or GROUP BY clauses of SELECTstatements.

- DISTINCT values of SELECT statements.

需要排序来消除重复值

- UNION, INTERSECTor MINUS operations.

因为需要消除重复值，所以需要排序操作（这里不包括unionall）

- Sort-Merge joins.
如果没有索引可用，一个等值连接需要分别执行全表所描和排序操作。然后排序好的rowsource会被合并在一起，取出两个rowsource 中匹配的行。

- Analyze command execution.

分析、收集统计信息的时候会需要排序操作。优化器需要收集的统计信息在附录2

-Others

比如说创建主键，createtable as select 等操作。

附录

稀疏文件解释

百度百科：http://baike.baidu.com/view/1520961.htm

稀疏文件，这是UNIX类和NTFS等文件系统的一个特性。

　　开始时，一个稀疏文件不包含用户数据，也没有分配到用来存储用户数据的磁盘空间。当数据被写入稀疏文件时，NTFS逐渐地为其分配磁盘空间。一个稀疏文件有可能增长得很大。稀疏文件以64KB（不同文件系统不同）为单位增量增长，因此磁盘上稀疏文件的大小总是64KB的倍数。

　　稀疏文件就是在文件中留有很多空余空间，留备将来插入数据使用。如果这些空余空间被ASCII码的NULL字符占据，并且这些空间相当大，那么，这个文件就被称为稀疏文件，而且，并不分配相应的磁盘块。

　　这样，会产生一个问题，文件已被创建了，但相应的磁盘空间并未被分配，只有在有真正的数据插入进来时，才会被分配磁盘块，如果这时文件系统被占满了，那么对该文件的写操作就会失败。为防止这种情况，有两种办法：不产生稀疏文件或为稀疏文件留够空间。

　　在计算机科学方面，稀疏文件是文件系统中的一种文件存储方式，在创建一个文件的时候，就预先分配了文件需要的连续存储空间，其空间内部大多都还未被数据填充现在有很多文件系统都支持稀疏文件，包括大部分的Unix和NTFS 。

　　稀疏文件被普遍用来磁盘图像，数据库快照，日志文件，还有其他科学运用上。

优化器统计信息

■ Table s tatistics

– Number of rows

– Number of blocks

– Average row length

■ Column statistics

– Number of distinct values (NDV) in column

– Number of nulls in column

– Data distribution (histogram)

– Extended statistics

■ Index statistics

– Number of leaf blocks

– Levels

– Clustering factor

■ System statistics

– I/O performance and utilization

– CPU performance and utilization

相关视图以及SQL

查看临时表空间当前的事情情况，以及历史最大使用情况（使用shrink或者resize以后，v$temp_extent_pool中的bytes_cached清零）

select 'max' as status,
       tablespace_name,
       sum(bytes_cached) / 1024 / 1024 as usage
  from v$temp_extent_pool
 group by tablespace_name
union all
select 'current' as status,
       ss.tablespace_name,
       sum((ss.used_blocks * ts.blocksize)) / 1024 / 1024 as usage
  from gv$sort_segment ss, sys.ts$ ts
 where ss.tablespace_name = ts.name
 group by ss.tablespace_name;

创建临时表：

会话内有效：

CREATEGLOBALTEMPORARYTABLE today_sales2
   ONCOMMITPRESERVEROWS
   ASSELECT * FROM hr.employees ;

只在这个session内才能看到today_sales2
中拥有hr.employees的数据。

事务内有效：

CREATEGLOBALTEMPORARYTABLE today_sales4
   ONCOMMITdeleteROWS
   ASSELECT * FROM hr.employees ;

语句执行后today_sales4中无法看到数据，因为临时表中的数据只在事务内有效，并且如果这个ddl语句执行成功，则默认的在ddl之前和之后都会有一个隐式的commit，第二个隐式commit会将事务结束，所以在today_sales4无法看到相应的数据。