本地管理表空间(LMT)
来学习一下LMT(Locally Managed Tablespace)的知识。虽然这个现在已经很少用到了，而且基本上默认创建的SYSTEM都已经是LMT的了，这样是无法再创建DMT的。所以说这种方法其实已经没有什么熟练掌握的必要了，但是作为丰富知识的作用，还是可以了解一下的，因为毕竟也还是尝尝会碰到这个概念。
一、概述
1、理解本地管理表空间的由来
2、理解什么是字典管理表空间及工作原理
3、理解本地管理表空间的优势(为什么要使用本地管理表空间)
4、理解本地管理表空间的内部结构
5、理解字典管理表空间与本地管理表空间的转换
二、名词解释与约定
表空间(Tablespace)
：为数据库提供使用空间的逻辑结构，其对应物理结构是数据文件，一个表空间可以包含多个数据文件
本地管理表空间(Locally Managed Tablespace简称LMT)：8i以后出现的一种新的表空间的管理模式，通过本地位图来管理表空间的空间使用。
字典管理表空间(Dictionary-Managed Tablespace简称DMT)：8i以前包括以后都还可以使用的一种表空间管理模式，通过数据字典管理表空间的空间使用。
段(Segment)：数据库一种逻辑结构，如表段，索引段，回滚段等，段存在于表空间中，并对应一定的存储空间。
区间<简称区>(Extent)：段的存储可以分成一个或多个区间，每个区间占用一定数量的数据块(block)，在本地管理的表空间中，表空间的Extent就对应段的Extent。
块(Block)：数据库最小的存储单位，在本文中Block的大小约定为8192字节。
位(Bit)：本地管理表空间的空间管理单位，一个位可能等于一个区间，也可能多个位组成一个区间。
三、本地管理表空间的由来
在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。若为AUTOALLOCATE，则表明让Oracle来决定区块的使用办法；若选择了UNIFORM，则还可以详细指定每个区块的大小，若不加指定，则为每个区使用1M大小。
Oracle之所以推出了这种新的表空间管理方法，让我们来看一下这种表空间组织方法的优点：
1. 本地化管理的表空间避免了递归的空间管理操作。而这种情况在数据字典管理的表空间是经常出现的，当表空间里的区的使用状况发生改变时，数据字典的表的信息发生改变，从而同时也使用了在系统表空间里的回滚段。
2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲空间、已使用空间的信息，从而减少了数据字典表的竞争，提高了空间管理的并发性
3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一个统一的大小，避免了字典表空间一直头疼的碎片问题。
5. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的话，它会把相关信息记在数据字典的表里，从而产生回滚信息。
由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发操作，并减少了对数据字典的依赖。
四、本地管理表空间管理机制
表空间是一种为段(表、索引等)提供空间的逻辑结构，所以，当在表空间中增加，删除段的时候，数据库就必须跟踪这些空间的使用。
如下例所示，假定一个新创建的表空间包含了5个表：
T1……T2……T3……T4……T5……Free
当我们删除T4的时候，就有如下结果：
T1……T2……T3……Free……T5……Free
很明显，ORACLE需要有一个机制来管理表空间中各数据文件的这些分配的或未分配的空间，为了跟踪这些可以使用的空间（包括未分配使用的和可以重复使用的），对于每一个空间，我们必须知道：
1、这个可用空间位于什么数据文件
2、这个空间的尺寸是多大
3、如果它在用了，是哪一个段占用的这个空间
直到8i之前，所有的表空间都是采用字典管理模式，为了确保能保存以上的信息，ORACLE用了两个数据字典表:UET$(已使用的区间)或FET$(空闲空间)：
SQL> desc UET$
Name Null? Type
----------------- ---------- -----------
SEGFILE# NOT NULL NUMBER
SEGBLOCK# NOT NULL NUMBER | The segment that uses this space
EXT# NOT NULL NUMBER
TS# NOT NULL NUMBER | The tablespace ID and the file
FILE# NOT NULL NUMBER | ID for that tablespace
BLOCK# NOT NULL NUMBER
LENGTH NOT NULL NUMBER | The location and size of the chunk
SQL> desc FET$
Name Null? Type
----------------- ---------- -----------
TS# NOT NULL NUMBER | The tablespace ID and the file
FILE# NOT NULL NUMBER | ID for that tablespace
BLOCK# NOT NULL NUMBER
LENGTH NOT NULL NUMBER | The location and size of the chunk
查询该表可以看到，每个使用空间或空闲空间(不一定是一个extent，可以是多个extent)都在该表中对应了一行。它的工作方式是当一个段被删除的时候，ORACLE就移动UET$中相应的行到FET$，这个过程的发生是连续的，而且可能发生等待。当并发性很高的时候，数据字典的争用就来了。另外有一个问题就是，当表的空间很不连续或表空间有大量的碎片引起这两个表的增大，那么也就会引起数据库性能上的下降。
本地管理表空间正是为了解决这一问题来的，在表空间的空间管理上，ORACLE将存储信息保存在表空间的头部的位图中，而不是保存在数据字典中。通过这样的方式，在分配回收空间的时候，表空间就可以独立的完成操作也不用与其它对象关系。
下面就让我们进入到本地管理表空间的内部，看看ORACLE是怎么实现这一工作的。
Uniform方式的本地管理表空间
1、先创建了一个本地管理的表空间，区间统一大小分配为64K
SQL> create tablespace demo
2 datafile '/ora01/oem/oemdemo01.dbf' size 10m
3 extent management local uniform size 64k;
2、在该表空间中创建一个表
SQL>create table demotab ( x number ) tablespace demo
2 storage ( initial 1000K next 1000k );
我们通过查询该表
SQL> select t.table_name,t.initial_extent,t.next_extent from user_tables t where t.table_name = 'DEMOTAB';
TABLE_NAME INITIAL_EXTENT NEXT_EXTENT
---------------------------- -------------- -----------
DEMOTAB 1024000 65536
可以发现，该表的存储参数并不是我们指定的参数INITIAL_EXTENT，而是uniform size的整数倍，NEXT_EXTENT则等于uniform size。我们从该查询就也可以看到如下情况
SQL>select count(*) from user_extents where segment_name = 'DEMOTAB';
COUNT(*)
----------
16
也就是说，该表在该表空间中已经存在16个extent，而不是一个extent(这是与字典管理的差别，如果是字典管理的表空间，如果创建以上的表，该查询的结果是1)
3、获取该数据文件的文件ID
SQL> col name format a30 trunc
SQL> select file#, name from v$datafile;
File# NAME
----- --------------------
1 /oras1/oem/oemsystem01.dbf
2 /oras3/oem/oemundo01.dbf
3 /ora01/oem/oemoem_repository01
4 /ora01/oem/oemrcat01.dbf
5 /ora01/oem/oemdemo01.dbf
我们可以检查uet$与fet$
SQL> select count(*) from uet$ where file# = 5;
COUNT(*)
----------
0
SQL> select count(*) from fet$ where file# = 5;
COUNT(*)
----------
0
4、可以看到，ORACLE没有在这两个表中保存任何信息，现在我们dump该数据文件的第三个块
SQL> alter system dump datafile 5 block 3;
System altered.
查看DUMP文件，有如下信息
Start dump data blocks tsn: 5 file#: 5 minblk 3 maxblk 3
buffer tsn: 5 rdba: 0x01400003 (5/3)
scn: 0x0000.202f7a6f seq: 0x01 flg: 0x00 tail: 0x7a6f1e01
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 5, BeginBlock: 9, Flag: 0, First: 16, Free: 63472
FFFF000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
.....
注意其中的FFFF00,，这是16进制的表现方法，我们转换为二进制，有
1111,1111,1111,1111,0000,0000
发现这里有16个1，每一个1就是一个位(bit)，代表64K，也就代表了该表空间有已经分配了的16个extent，如果我们将该表扩展，将又有什么结果呢？
SQL> alter table demotab allocate extent;
Table altered.
SQL> alter table demotab allocate extent;
Table altered.
SQL> alter table demotab allocate extent;
Table altered.
这样之后，我们应该有19个extent了，再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
FFFF07 0000000000 0000000000000000 0000000000000000 0000000000000000
除了以前的FFFF，现在多了07，怎么解释呢？
07转换为二进制为0000,0111，但是还是不够解释以上的情况，这里我们没有考虑到字节交换的情况，因为以上FF交换后还是FF，但是如果是07， 我们就必须考虑字节交换（因为计算机是一个字节一个字节的写，一个字节占两位当然是先写后面了，如从01到0F到FF为止。 如果我们明白了，那么FFFF07转换为二进制为 1111,1111,1111,1111,0000,0111。
每个字节交换得
1111,1111,1111,1111,1110,0000
可以发现，这里有19个1，也就是19个位(bit)，代表了现在的19个extent。
5、同样我们dump该数据文件第9个块，则有
Start dump data blocks tsn: 5 file#: 5 minblk 9 maxblk 9
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
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 space2: 0 #extents: 16 #blocks: 127
last map 0x00000000 #maps: 0 offset: 4128
Highwater:: 0x01c0000a ext#: 0 blk#: 0 ext size: 7
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
Disk Lock:: Locked by scn: 0x0006.012.00000017
Map Header:: next 0x00000000 #extents: 16 obj#: 3090 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x01c0000a length: 7
0x01c00011 length: 8
0x01c00019 length: 8
0x01c00021 length: 8
0x01c00029 length: 8
0x01c00031 length: 8
0x01c00039 length: 8
0x01c00041 length: 8
0x01c00049 length: 8
0x01c00051 length: 8
0x01c00059 length: 8
0x01c00061 length: 8
0x01c00069 length: 8
0x01c00071 length: 8
0x01c00079 length: 8
0x01c00081 length: 8
nfl = 1, nfb = 1 typ = 1 nxf = 0
SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 End dump data blocks tsn: 5 file#: 5 minblk 9 maxblk 9
这是该数据文件中表DEMOTAB的表头(一个块)信息， 从这里可以看到，该表从第9个块开始使用Highwater:: 0x01c0000a已经是第10个块了，从以上列表，我们也能清楚的看到，该表耗费了16个区间
由于该表是数据文件的第一个表，所以位图区占用从3到8共6个块，加上前面两个文件头，也就是说，在数据文件头部共8个块用于系统消耗。如果我们的db_block_size为8192，那么很明显，
占用的空间为64K。
也因为仅仅操作数据文件头部几个块，不用操作数据字典，所以ORACLE在本地管理的表空间中添加，删除段的时候，效率要比字典管理的表空间快。特别是在并发性很强的空间请求中。
ORACLE通过强制性的手段使本地管理表空间中的所有Extent是同样大小的，尽管你可能自定义了不同的存储参数。
6、补充一些字典管理表空间的不同
a. 如果是字典管理，表空间中的表的区间的大小取决于表的存储参数，如果没有定义，则取表空间的通用存储参数。所以每个表的区间大小可以不一样。
b. 如果不指定表的最少区间数，那么默认创建的时候，该表只有一个区间，而不是多个区间。
c. 字典管理的文件头只占用一个块，第一个表的HWM应当是Highwater:: x01c00003，关于这个可以自己dump该数据文件查看。
Autoallocate的本地管理表空间
在自动分配的本地管理的表空间中，区间尺寸可能由以下尺寸组成64k, 1m, 8m, 64m 甚至是256m。但是不管多大，都有一个通用尺寸64k，所以64K就是该表空间的位大小。
SQL> create tablespace dummy
2 datafile 'c:\dummy01.dbf' size 100m
3 autoallocate;
Tablespace created.
SQL> create table x1 (x number)
2 tablespace dummy
3 storage (initial 50M);
Table created.
SQL> select file# from v$datafile where name like '%DUMMY%';
FILE#
----------
12
SQL> select extents from user_segments
where segment_name = 'X1' ;
EXTENTS
---------
50
SQL> alter system dump datafile 12 block 3;
System altered.
*** SESSION ID11.59) 2002-11-22 10:37:35.000
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
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
可以看到该表实际只有50个区间(extent)，但是有800个位(bit)
50*1024=800*64
还可以看出，位大小并不等于extent大小
五、迁移到本地管理表空间
在很多情况下，如果你想在字典表空间与本地表空间之间转换是很难的，你可能需要转出该表空间所有的数据，从新创建表空间，再加载该数据。但是在816以后，有一个叫dbms_space_admin的包使两类表空间的互相转换变成可能，体现在如下两个过程：
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL
但是在你想利用这个过程进行转换的时候，你必须注意两件事：
1、 数据库版本必须是816以上，兼容版本(compatible)必须是8.1以上
2、 如果是转换成为本地管理，必须有足够的空闲空间做本地位图空间（8个块）
当从字典管理到本地管理的过程中，全部转换其实基本上是不可能发生的，实际情况是，对于已经存在的数据和空间，该过程是没有任何办法的，仅仅是简单把空间 取整并标记。所以说，这种转换后的表空间可以减缓UET$和FET$的压力，但并不能解决碎片问题。从查询DBA_TABLESPACES你还可以看到，转换之后的表空间管理方式是LOCAL，但实际段分配是USER(不是uniform或automatic)
很显然，在字典管理的表空间中，存在许多大小不同的区间(extent)尺寸，所以转换为本地管理的时候，ORACLE怎么样把这些已经存在的空间转换为通用大小了？为了做到这一点，ORACLE必须扫描该表空间的每个数据文件，主要是检查以下三个问题：
1、 所有的已经存在的区间
2、 所有的以前用过，但是现在空闲的空间
3、 由表空间MINIMUM EXTENT语句标记的大小
在转换的时候，ORACLE试图发现一个适合于以上三个标准的最大的区间的尺寸作为本地管理的区间尺寸，也就是说，在最坏的情况下，这个最大的区间可能就是单个块(如果说一个表的区间尺寸是7个块，另外一个表的区间尺寸是8个块)
我们看一个从字典管理表空间到本地管理表空间的例子
1、首先，我们创建一个字典管理表空间
SQL> create tablespace blah
2 datafile 'G:\ORA9I\ORADATA\DB9\BLAH.DBF' size 10m reuse
3 extent management dictionary;
Tablespace altered.
SQL> col bytes format 999,999,999
SQL> select * from dba_free_space where tablespace_name = 'BLAH';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCK RELATIVE_FNO
--------------- -------- ----------- ----------- ------- ----------------
BLAH 8 2 10,477,568 1279 8
2、我们在上面创建三个表，最小公用尺寸是400K
SQL> create table t1 ( x number ) storage ( initial 400k) tablespace blah;
Table created.
SQL> create table t2 ( x number ) storage ( initial 800k) tablespace blah;
Table created.
SQL> create table t3 ( x number ) storage ( initial 1200k) tablespace blah;
Table created.
SQL> select * from dba_free_space where tablespace_name = 'BLAH';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCK RELATIVE_FNO
--------------- -------- ----------- ----------- ------- ----------------
BLAH 8 302 8,019,968 979 8
SQL> select bytes from dba_extents where tablespace_name = 'BLAH';
BYTES
----------
409,600
819,200
1,228,800
3、现在我们开始转换该表空间为本地管理的表空间，假定每个位图大小400K，也就是50个块。
SQL> exec dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50);
BEGIN dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50); END;
*
ERROR at line 1:
ORA-03241: Invalid unit size
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 0
ORA-06512: at line 1
如果我们设置表空间的minimum extent语句为400K：
SQL> alter tablespace blah minimum extent 400k;
Tablespace altered.
SQL> exec dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50);
PL/SQL procedure successfully completed.
Conversion goes through with no problems.
从以上可以看到，转换成功，但实际情况远远比这么复杂，或许你根本就不知道表空间里面的公用尺寸是多大。而且通过这种转换后的表空间，并没有消除碎片，也不一定有优化的作用。所以建议不要用该方法进行转换，而是使用alter table move的办法进行表空间的转换将可能是最好的办法。
再转一些其他的论述
*************************************************************************************
本地管理表空间与字典管理表空间的比较
本地管理表空间与字典管理表空间相比大大提高了管理效率和数据库性能，其优点如下：
1.减少了递归空间管理
本地管理表空间是自己管理分配，而不是象字典管理表空间需要系统来管理空间分配，本地表空间是通过在表空间的每个数据文件中维持一个位图来跟踪在此文件中 块的剩余空间及使用情况。并及时做更新。这种更新只对表空间的额度情况做修改而不对其他数据字典表做任何update操作，所以不会产生任何回退信息，从 而大大减少了空间管理，提高了管理效率。同时由于本地管理表空间可以采用统一大小分配方式(UNIFORM),因此也大大减小了空间管理，提高了数据库性 能。
2.系统自动管理extents大小或采用统一extents大小
本地管理表空间有自动分配(AUTOALLOCATE)和统一大小分配(UNIFORM)两种空间分配方式，自动分配方式(AUTOALLOCATE)是 由系统来自动决定extents大小，而统一大小分配(UNIFORM)则是由用户指定extents大小。这两种分配方式都提高了空间管理效率。
3.减少了数据字典之间的竞争
因为本地管理表空间通过维持每个数据文件的一个位图来跟踪在此文件中块的空间情况并做更新，这种更新只修改表空间的额度情况，而不涉及到其他数据字典表，从而大大减少了数据字典表之间的竞争，提高了数据库性能。
4.不产生回退信息
因为本地管理表空间的空间管理除对表空间的额度情况做更新之外不修改其它任何数据字典表，因此不产生回退信息，从而大大提高了数据库的运行速度。
5.不需合并相邻的剩余空间
因为本地管理表空间的extents空间管理会自动跟踪相邻的剩余空间并由系统自动管理，因而不需要去合并相邻的剩余空间。同时，本地管理表空间的所有extents还可以具有相同的大小，从而也减少了空间碎片。
6.减少了空间碎片
7.对临时表空间提供了更好的管理
*************************************************************************************
Oracle之所以推出了这种新的表空间管理方法，让我们来看一下这种表空间组织方法的优点：
1. 本地化管理的表空间避免了递归的空间管理操作。而这种情况在数据字典管理的表空间是经常出现的，当表空间里的区的使用状况发生改变时，数据字典的表的信息发生改变，从而同时也使用了在系统表空间里的回滚段。
2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲空间、已使用空间的信息，从而减少了数据字典表的竞争，提高了空间管理的并发性
3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一个统一的大小，避免了字典表空间一直头疼的碎片问题。
5. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的话，它会把相关信息记在数据字典的表里，从而产生回滚信息。
由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发操作，并减少了对数据字典的依赖。
对于每一个空间，我们必须知道：
1、这个可用空间位于什么数据文件
2、这个空间的尺寸是多大
3、如果它在用了，是哪一个段占用的这个空间
本地化管理的表空间上，ORACLE将存储信息保存在表空间的头部的位图中，而不是保存在数据字典中。通过这样的方式，在分配回收空间的时候，表空间就可以独立的完成操作也不用与其它对象关系。
*************************************************************************************