概述
1、 描述数据库的逻辑存储结构----表空间（TABLESPACE）
2、 描述字典管理表空间（DMT）的特性以及相应缺点
3、 描述字典管理表空间的优化方法
4、 描述本地管理表空间（LMT）的特性以及相应优点
5、 描述9i新的表空间类型以及相应优化
6、 描述段自动管理表空间的特点
7、 描述10g新的表空间的特点及相应优化
一、表空间的作用与分类
表空间是数据库中最大的逻辑存储结构，为数据库提供使用空间，其对应物理结构是数据文件，一个表空间可以包含多个数据文件，但是一个数据文件只能属于一个表空间。表空间所包含的数据文件的大小，也就决定了表空间的大小，所以，表空间也是逻辑结构连接到物理结构的一个纽带。
既然表空间为数据库提供使用空间，它就必须有自己的空间管理办法，在表空间中增加，删除段的时候，数据库就必须跟踪这些段空间的使用。
如下例所示，假定一个新创建的表空间包含了五个表
表一......表二......表三......表四......表五......未用空间
当我们删除表四的时候，就有如下结果
表一......表二......表三......空闲空间段......表五......未用空间
很明显，ORACLE需要有一个机制来管理表空间中各数据文件的这些分配的或未分配的空间，为了跟踪这些可以使用的空间（包括未分配使用的和可以重复使用的），对于每一个空间，我们必须知道：
1、这个可用空间位于什么数据文件
2、这个空间的尺寸是多大
3、如果它在用了，是哪一个段占用的这个空间
在空间的管理方式上，ORACLE推出了三种主要的空间管理方式，
一种是8i以前的字典管理方式（DMT），把可用空间和未用空间在数据字典中管理，ORACLE通过一个迭归SQL语句该字典表中请求空间。
另外一种就是8i以后的本地管理模式（LMT），本地管理模式完全放弃以前的管理方法，通过在数据文件的头部建立位图区域来管理空间的分配，在一定程度上避免了并发上的冲突；而且本地管理表空间通过存储上统一的空间管理并取消了为独立的段的NEXT存储参数，也解决了表空间一直以来头疼的碎片问题。
还有一种自动区段空间管理（ASSM）是9iR2推出的一种表空间级别的段空间管理模式，ASSM表空间是通过将SEGMENT SPACE MANAGEMENT AUTO子句添加到本地管理表空间的定义句法里而实现的。通过使用位图数组取代传统单向的链接列表（FREELIST），ASSM表空间会将链接列表的管理自动化，并取消为独立的段指定PCTUSED、FREELISTS和FREELIST GROUPS存储参数。
注意：ASSM表空间一定就是LMT表空间
二、字典管理表空间
2.1 字典管理表空间的特性
在8i以前（不包括8i），只存在一种表空间的管理模式，这就是字典管理表空间。
主要语法：CREATE TABLESPACE 表空间名字
DATAFILE '数据文件详细信息' [SIZE INTETER [K|M]
|[DEFAULT STORAGE]|[PERMANENT|TEMPORARY]]
关键字DEFAULT STORAGE指明了该表空间的默认存储格式，包含了INITIAL，NEXT，PCTINCREASE等相关参数的设置，如果创建在该表空间中的对象，不指明存储参数的话，将采用表空间的默认存储参数；PERMANENT|TEMPORARY指明了该表空间的类型是永久的还是临时的。
为了确保能保存以上空间分配的信息，ORACLE用了两个数据字典表：UET$（已使用的空间）和FET$（空闲空间）来保存表空间的空间使用与释放的信息，在涉及到空间分配的时候，ORACLE使用一个迭归SQL语句到该字典表中请求空间。
2.2 字典管理表空间的缺点
字典表空间由于本身的设计上的问题，存在如下缺陷
2.2.1 并发等待
查询UET$ 或FET$我们可以看到，每个已使用空间段或空闲空间段（不一定是一个extent，可以是多个extent）都在该表中对应了一行，如：
SQL> select * from UET$;
SEGFILE# SEGBLOCK# EXT# TS# FILE# BLOCK# LENGTH
---------- ---------- --------- ------ ---------- ---------- ----------
1 127 0 0 1 127 2
1 109 0 0 1 109 4
1 119 0 0 1 119 2
1 42 0 0 1 42 2
1 133 0 0 1 133 10
1 51 0 0 1 51 2
1 69 0 0 1 69 10
......
SQL> select * from FET$;
TS# FILE# BLOCK# LENGTH
---------- ---------- ---------- ----------
1 2 1090 64
1 2 2626 128
2 3 2 99
3 4 82 8
3 4 74 8
......
它的工作方式是当建立一个新的段或者段在表空间中请求新的空间时，ORACLE通过一个迭归SQL语句来完成这个工作，移动或增加相应的行到UET$中，并改变相应FET$；当删除一个段的时候，ORACLE则移动UET$中相应的行到FET$。这个过程的发生是连续的、串行的，极可能发生等待。当并发性很高的时候，将产生数据字典的争用。
而且数据字典的表的信息发生改变，从而同时也使用了在系统表空间里的回滚段，引起空间争用，因为每一个字典改变的操作都需要记入系统回滚段，而且当一个段有几万或者几十万个区间的时候（对应字典表的几十万条记录），不用说管理该字典表的负担增加，就是对该段的drop操作都会变得异常国难，甚至导致系统回滚段空间不够而失败。
2.2.2 空间碎片
当段的空间很不连续或表空间有大量的碎片就会引起数据库性能上的下降。因为字典管理表空间没有任何措施可以保证段的所有区间是相邻存储的。当要满足一个空间要求时，数据库不再合并相邻的自由范围（除非别无选择）， 而是寻找表空间中最大的自由范围来使用。这样将逐渐形成越来越多的离散的、分隔的、较小的自由空间，即碎片。随着时间推移，基于数据库的应用系统的广泛使用，产生的碎片会越来越多，将对数据库有以下两点主要影响：
·导致系统性能减弱，如上所述，当要满足一个空间要求时，数据库将首先查找当前最大的自由范围，而"最大"自由范围逐渐变小，要找到一个足够大的自由范围已变得越来越困难，从而导致表空间中的速度障碍，使数据库的空间分配愈发远离理想状态。
·浪费大量的表空间，尽管有一部分自由范围（如表空间的PCTINCREASE为非0）将会被SMON（系统监控）后台进程周期性地合并，但始终有一部分自由范围无法得以自动合并，浪费了大量的表空间。而非0的 PCTINCREASE更容易导致更多的碎片。
2.3 字典管理表空间的优化
从以上一系列操作中，我们可以看到，UET$记录了任何使用的段的区间，如果区间数太多，将给表UET$的操作带来一定压力，所以在字典管理的表空间中，一般要求区间数少一点比较好，除非有特殊要求，一般建议在20个区间以下。还有一点就是如果发生连续的空间请求，将导致ORACLE在两个字典表之间的操作等待，对于并发性很高的数据库来说，这是一个高昂的操作，所以，我们可以采用预分配空间的方式，并不但的监控段的空间使用情况（大小，区间数），这样就可以在很大程度上解决并发处理带来的额外的代价。
在另外一个方面，我们可以指定在字典管理表空间中的所有段都具有PCTINCREASE=0的特性，保证每个区间的大小相等，然后可以设定每个区间的大小等于某一个特定数的整数倍，如= n*db_block_size* db_file_multiblock_read_count，这样可以在很大程度上防止表空间的碎片化。
三、本地管理表空间
3.1本地管理表空间的特性
在Oracle8I的版本中，Oracle推出了一种全新的表空间管理方式：本地化管理的表空间。所谓本地化管理，就是指Oracle不再利用数据字典表来记录Oracle表空间里面的区的使用状况，而是在每个表空间的数据文件的头部加入了一个位图区，在其中记录每个区的使用状况。每当一个区被使用，或者被释放以供重新使用时，Oracle都会更新数据文件头部的这个记录，反映这个变化。
本地化管理的表空间的创建过程：
主要语法：CREATE TABLESPACE 表空间名字
DATAFILE '数据文件详细信息'
[EXTENT MANAGEMENT { LOCAL
{AUTOALLOCATE | UNIFORM [SIZE INTETER [K|M] ] } } ]
关键字EXTENT MANAGEMENT LOCAL 指定这是一个本地化管理的表空间。对于系统表空间，只能在创建数据库的时候指定EXTENT MANGEMENT LOCAL，因为它是数据库创建时建立的第一个表空间。
在8i中，字典管理还是默认的管理方式，当选择了LOCAL关键字，即表明这是一个本地管理的表空间。当然还可以继续选择更细的管理方式：是自动分配（AUTOALLOCATE） 还是 统一尺寸（UNIFORM）.。若为自动分配，则表明让Oracle来决定区块的使用办法；若选择了统一尺寸，则还可以详细指定每个区间（Extent）的大小，若不加指定，则默认每个区使用1M大小。
在表空间的空间管理上，ORACLE将存储信息保存在表空间的头部的位图中，而不是保存在数据字典中。通过这样的方式，在分配或者回收空间的时候，表空间就可以独立的在数据文件头部完成操作而不用与其它对象打交道。
也因为仅仅操作数据文件头部几个块，不用操作数据字典，所以ORACLE在本地管理的表空间中添加，删除段的时候，效率要比字典管理的表空间快。特别是在并发性很强的空间请求中。
对于在本地管理的表空间内部创建的对象而言，NEXT扩展子句是过时的，因为由本地管理的表空间会自动管理它们。但是，INITIAL参数仍然是需要的，因为Oracle不可能提前知道初始段加载的大小。
在本地管理的表空间中，如果数据库块尺寸（db_block_size） 为 16k和16k以下，数据文件头是 64k 保留空间，若是32k的块尺寸，则保留 128k，以默认的8k的块大小而言，就是8个块用在数据文件头部用于系统消耗，其中的3~8用于记录区间的位图信息。
3.2 管理位图块的内部结构
3.2.1 统一尺寸的本地管理表空间
如果我们dump 统一尺寸方式的本地管理表空间包含的数据文件的第三个块，就可以得到类似如下的信息
Start dump data blocks tsn: 5 file#: 5 minblk 3 maxblk 3
buffer tsn: 5 rdba: 0x01400003 (5/3)
scn: 0x0000.202f7c64 seq: 0x01 flg: 0x00 tail: 0x7c641e01
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 5, BeginBlock: 9, Flag: 0, First: 19, Free: 63469
FFFF070000000000 0000000000000000 0000000000000000 0000000000000000
......
注意其中的FFFF07转换为二进制为 1111,1111,1111,1111,0000,0111，注意字节交换，得到1111,1111,1111,1111,1110,0000
可以看到，该表空间用19个位(bit)来代表共分配的19个区间
3.2.2 自动分配的本地管理表空间
在自动分配的本地管理的表空间中，区间尺寸可能由以下尺寸组成64k, 1m, 8m, 64m 甚至是256m。但是不管多大，都有一个通用尺寸64k，所以64K就是该表空间的一个位标记的大小。如我们同样的dump文件头的第三个块。
Start dump data blocks tsn: 19 file#: 12 minblk 3 maxblk 3
buffer tsn: 19 rdba: 0x03000003 (12/3)
scn: 0x0000.00f2959b seq: 0x01 flg: 0x00 tail: 0x959b1e01
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 12, BeginBlock: 9, Flag: 0, First: 800, Free: 62688
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFF00000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
......
可以看到这里工分配了800个位(bit)，但是自动分配模式下的位大小并不一定等于extent大小，所以不一定是对应800个区间，如它可能对应的是50个1M大小的区间，如50*1024=800*64
3.3 本地管理表空间的优点
Oracle之所以推出了这种新的表空间管理方法，让我们来看一下这种表空间组织方法的优点：
1. 本地化管理的表空间用数据文件的头部记录来管理空闲块，避免了递归的空间管理操作，避免了利用系统回滚段因此带来的性能与空间问题。
2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲空间、已使用空间的信息，从而减少了数据字典表的竞争，提高了空间管理的并发性。
3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一个统一的大小，避免了字典表空间一直头疼的碎片问题。
四、段自动管理表空间
4.1 段自动管理表空间的特性
在920以前，表的剩余空间的管理与分配都是由链接列表（FREELIST）来完成的，因为链接列表存在串行的问题因此往往容易引起段头的争用与空间的浪费，而且还需要DBA 花费大量的精力去管理这些争用并监控表的空间利用。
自动段空间管理（ASSM），它首次出现在Oracle920里。有了ASSM，链接列表被位图数组所取代，它是一个二进制的数组，能够迅速有效地管理存储扩展和剩余区块（free block），因此能够改善分段存储本质。
让我们看看位图数组是如何实现链接列表的功能的。我会从使用区段空间管理自动参数创建表空间开始：
CREATE TABLESPACE demo
DATAFILE '/u01/oracle/demo01.dbf '
SIZE 5M
EXTENT MANAGEMENT LOCAL -- Turn on LMT
SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM;
带有ASSM的本地管理表空间会略掉任何为PCTUSED、NEXT和FREELISTS所指定的值。Oracle9i会使用位图数组来自动地管理表空间里对象空间使用。
新的管理机制用位图数组来跟踪或管理每个分配到对象的块，每个块有多少剩余空间根据位图的状态来确定，如>75%,50%-75%,25%-50%和<25%，也就是说位图其实采用了四个状态位来代替以前的PCTUSED，什么时候该利用该数据块则由设定的PCTFREE来确定。
使用ASSM的一个巨大优势是，位图数组肯定能够减轻缓冲区忙等待（buffer busy wait）的负担，这个问题在Oracle9i以前的版本里曾是一个严重的问题，因为在没有多个位图数组的时候，每个Oracle段在段的头部都曾有一个数据块用于链接列表，用来管理对象所使用的剩余区块，并为任何SQL申请的新数据行提供数据块。当数据缓冲内的数据块由于被另一个DML事务处理锁定而无法使用的时候，缓冲区忙等待就会发生。当你需要将多个任务插入到同一个表格里的时候，这些任务就被强制等待，而同时Oracle会在同时分派剩余的区块，一次一个。
有了ASSM之后，Oracle宣称显著地提高了DML并发操作的性能，因为位图数组的不同部分可以被同时使用，这样就消除了寻找剩余空间的串行化。根据Oracle的测试结果，使用位图数组会消除所有分段头部（对资源）的争夺，还能获得超快的并发插入操作。
4.2位图管理段内部结构
如果我们dump ASSM表空间的第10个块，我们可以发现如下信息
Start dump data blocks tsn: 6 file#: 7 minblk 10 maxblk 10
buffer tsn: 6 rdba: 0x0680000a (7/10)
scn: 0x0000.00181a39 seq: 0x01 flg: 0x04 tail: 0x1a392101
frmt: 0x02 chkval: 0x2738 type: 0x21=SECOND LEVEL BITMAP BLOCK
Dump of Second Level Bitmap Block
number: 8 nfree: 8 ffree: 0 pdba: 0x0680000b
opcode:0
xid:
L1 Ranges :
--------------------------------------------------------
0x06800009 Free: 5 Inst: 1
0x06800019 Free: 5 Inst: 1
0x06800029 Free: 5 Inst: 1
0x06800039 Free: 5 Inst: 1
0x06800049 Free: 5 Inst: 1
0x06800059 Free: 5 Inst: 1
......
可以看到，块10是一个二级管理位图块，负责记录一级位图块的地址，其中的9,19,29等就是记录自由空间的一级位图块的地址，从这里可以看到，每个一级位图块管理16个（十六进制10个）块的存储信息。如果在并发的处理中，每个一级位图块可以单独的管理或者是分配空间，而不是再由以前的一个链接列表块来进行空间的管理，在实际的情况中，每个一级位图块也不一定是管理16个块的空间信息，也有可能是32个或者更多。
位图数据的级别可以分为三个级别，当存在一个或多个一级位图块（如块9，19）的时候，将由二级位图（如块10）块来保存一级位图块的地址，同理，一个二级位图块不够使用而出现多个二级位图块的时候，将由三级位图块来保存二级位图块的地址（由于三级位图块的出现需要很多数据块，所以这里不讨论三级位图块）。整个位图数组的结构形成一个树状结构，有利于ORACLE跟踪所有的位图数据块的位置。
如果我们dump其中的一个一级位图块，如块39，对应的是十进制的57。
Start dump data blocks tsn: 6 file#: 7 minblk 57 maxblk 57
buffer tsn: 6 rdba: 0x06800039 (7/57)
scn: 0x0000.0018b7cb seq: 0x04 flg: 0x04 tail: 0xb7cb2004
frmt: 0x02 chkval: 0x27d2 type: 0x20=FIRST LEVEL BITMAP BLOCK
Dump of First Level Bitmap Block
--------------------------------
nbits : 4 nranges: 2 parent dba: 0x0680000a poffset: 3
unformatted: 8 total: 16 first useful block: 1
owning instance : 1
instance ownership changed at 08/19/2003 10:41:42
Last successful Search 08/19/2003 10:41:42
Freeness Status: nf1 1 nf2 0 nf3 0 nf4 6
Extent Map Block Offset: 4294967295
First free datablock : 1
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Highwater:: 0x06800041 ext#: 6 blk#: 8 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 50
mapblk 0x00000000 offset: 6
HWM Flag: HWM Set
--------------------------------------------------------
DBA Ranges :
--------------------------------------------------------
0x06800039 Length: 8 Offset: 0
0x06800041 Length: 8 Offset: 8
0:Metadata 1:FULL 2:FULL 3:75-100% free
4:75-100% free 5:75-100% free 6:75-100% free 7:0-25% free
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
--------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 57 maxblk 57
我们可以看到，在位图块57管理的16个数据块中
1个位图+2个FULL+4个75-100% free+1个0-25% free+8个未使用的共16个块，如果在下次的插入或者更新中，位图块57将负责这16个数据块的空间的分配与使用以及相应的状态记载，可以想象，如果是除了这16个块之外的块的空间的管理，将由类似块57的块来完成，多个位图块并行管理将明显的增加并发的处理能力。
4.3、段自动管理表空间的优化
尽管ASSM显示出了令人激动的特性并能够简化Oracle DBA的工作，但是Oracle9iR2的位图分段管理还是有一些局限性的：
· 一旦DBA被分配之后，它就无法控制表空间内部的独立表格和索引的存储行为。
· 大型对象不能够使用ASSM，而且必须为包含有LOB数据类型的表格创建分离的表空间。
· 你不能够使用ASSM创建临时的表空间。这是由排序时临时分段的短暂特性所决定的。
· 只有本地管理的表空间才能够使用位图分段管理。
· 使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的时候可能会出现性能上的问题。
正因为ASSM还不是太稳定与完善，所以至少在9iR2的版本上，还不建议生产系统中大规模使用ASSM的表空间。
五、9i对表空间的管理优化
5.1自动undo管理的表空间
在9i以前，回滚段全是手工管理与监控的，DBA需要花费一定的时间去管理与监控回滚段的性能，创建不好或管理不好的回滚段，将引起很大的性能瓶颈。从ORACLE9i，为了更好的管理回滚段，ORACLE，默认采用自动回滚段管理。
自动回滚段管理可以最大限度的避免8i中比较有名的ORA-01555"快照太老"的错误，ORACLE9i通过如下四个初试化参数来设置自动回滚段管理：
undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS1
undo_management表明了回滚段管理采用自动方式，ORACLE建议采用自动方式，如果不是对数据库非常了解，不要修改该参数。
undo_retention表明了回滚信息在回滚段中保持的时间，单位是秒，默认3个小时，如果数据库的事务量特别大，可以适当的减少该参数值，避免回滚表空间的膨胀，但是过小的值也将导致ORA-01555错误的重现以及FLASHBACK QUERY功能的局限。
undo_suppress_errors表明不显示某些错误信息，如对系统回滚段的操作将不显示错误，虽然这个操作没有成功。
undo_tablespace表明了使用自动回滚的表空间，DBA需要监控该表空间的大小。
自动回滚段的另外一个好处就是可以利用FLASHBACK QUERY来查看提交以前的数据或导出当前时间点以前的数据，防止一定程度上的人为错误。
5.2 完全本地的临时表空间
通过9i默认的本地管理的临时文件，总是处于nologging模式，控制文件也不记录临时文件的位置，由于不记载redo信息，所以9i的临时数据文件不需要进行备份与恢复，如果发生意外，只需要重新创建一个即可。
另外，由于9i默认临时表空间的出现，减少了9i以前因为默认临时表空间是系统表空间而导致的表空间碎片问题。
六、10g对表空间的优化
SYSAUX表空间在Oracle Database 10g中被引入，作为SYSTEM表空间的辅助表空间，这是一个管理及规划上的改进，进一步独立SYSTEM表空间，保证其存储及性能。以前版本使用独立表空间或系统表空间的数据库组件现在SYSAUX表空间中创建。通过分离这些组件和功能，SYSTEM表空间的负荷得以减轻。反复创建一些相关对象及组件引起SYSTEM表空间的碎片问题得以避免。而且，由于大量的独立表空间中的对象都被移往了SYSAUX表空间，使得10g的表空间数目变的很少，对于空间管理，备份与优化都是一个不错的福音。
而且如果SYSAUX表空间的不可用，数据库核心功能将保持有效，所以使用SYSAUX表空间的特点将会失败或功能受限，使数据库变的更稳定可靠。
小结
了解字典管理表空间的工作原理，尽量减少空间分配的串行化与表空间的碎片化。
了解本地管理表空间的工作原理，尽量使用空间管理的本地化来减少字典管理表空间带来的问题。
了解段自动管理表空间的工作原理，理解链接列表的工作原理，理解ASSM对于大量并发处理的好处以及相关缺点
了解9i新型自动重作表空间的好处以及完全本地管理的临时表空间的优点
了解10g新型SYSAUX表空间出现的原因以及相应管理上的优化
附录
表空间的空间监控
表空间的空间使用其实是一个需要特别注意的问题，因为数据文件不可扩展而导致表空间的空间不够，可能导致无法写入任何新的数据，而甚至导致数据库的停止。以下的语句可以监控表空间的空间利用情况，如果使用了9i的完全临时表空间，则加入后半部分用于检测临时表空间。
SELECT D.TABLESPACE_NAME,SPACE "SUM_SPACE(M)",BLOCKS SUM_BLOCKS,SPACE-NVL(FREE_SPACE,0) "USED_SPACE(M)",
ROUND((1-NVL(FREE_SPACE,0)/SPACE)*100,2) "USED_RATE(%)",FREE_SPACE "FREE_SPACE(M)"
FROM
(SELECT TABLESPACE_NAME,ROUND(SUM(BYTES)/(1024*1024),2) SPACE,SUM(BLOCKS) BLOCKS
FROM DBA_DATA_FILES
GROUP BY TABLESPACE_NAME) D,
(SELECT TABLESPACE_NAME,ROUND(SUM(BYTES)/(1024*1024),2) FREE_SPACE
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME) F
WHERE D.TABLESPACE_NAME = F.TABLESPACE_NAME(+)
--如果采用了完全本地管理的临时表空间，就加入如下部分
UNION ALL --if have tempfile
SELECT D.TABLESPACE_NAME,SPACE "SUM_SPACE(M)",BLOCKS SUM_BLOCKS,
USED_SPACE "USED_SPACE(M)",ROUND(NVL(USED_SPACE,0)/SPACE*100,2) "USED_RATE(%)",
NVL(FREE_SPACE,0) "FREE_SPACE(M)"
FROM
(SELECT TABLESPACE_NAME,ROUND(SUM(BYTES)/(1024*1024),2) SPACE,SUM(BLOCKS) BLOCKS
FROM DBA_TEMP_FILES
GROUP BY TABLESPACE_NAME) D,
(SELECT TABLESPACE_NAME,ROUND(SUM(BYTES_USED)/(1024*1024),2) USED_SPACE,
ROUND(SUM(BYTES_FREE)/(1024*1024),2) FREE_SPACE
FROM V$TEMP_SPACE_HEADER
GROUP BY TABLESPACE_NAME) F
WHERE D.TABLESPACE_NAME = F.TABLESPACE_NAME(+)
段的空间利用监控
段的空间与区间的利用，在字典管理的表空间有尤为重要，如果一个对象的区间数太多，不但大大加重了字典表的管理负担与系统回滚段的压力，也严重影响对该段（如表或索引）的性能。该查询也可以看到现在利用的区间与最大区间数的差异，如果该差值已经很小，就需要注意新的空间的分配，避免因为不能分配新的区间而导致新数据的写入错误。
SELECT S.OWNER,S.SEGMENT_NAME,S.SEGMENT_TYPE,S.PARTITION_NAME,
ROUND(BYTES/(1024*1024),2) "USED_SPACE(M)",
EXTENTS USED_EXTENTS,S.MAX_EXTENTS,S.BLOCKS ALLOCATED_BLOCKS,
S.BLOCKS USED_BOLCKS,S.PCT_INCREASE,S.INITIAL_EXTENT,
S.NEXT_EXTENT/1024 "NEXT_EXTENT(K)",S.TABLESPACE_NAME
FROM DBA_SEGMENTS S
WHERE S.OWNER = USER
ORDER BY Used_Extents DESC
