本地管理表空间LMT(转自IT_PUB)

本地管理表空间——大家继续讨论！

本地管理表空间
Locally Managed Tablespace
一、概述
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. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的话，它会把相关信息记在数据字典的表里，从而产生回滚信息。
由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发操作，并减少了对数据字典的依赖。
四、本地管理表空间管理机制
表空间是一种为段（表，索引等）提供空间的逻辑结构，所以，当在表空间中增加，删除段的时候，数据库就必须跟踪这些空间的使用。
如下例所示，假定一个新创建的表空间包含了五个表
表一……表二……表三……表四……表五……未用空间
当我们删除表四的时候，就有如下结果
表一……表二……表三……空闲空间段……表五……未用空间
很明显，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
datafile '/ora01/oem/oemdemo01.dbf' size 10m
extent management local uniform size 64k;
2、在该表空间中创建一个表
SQL>create table demotab ( x number ) tablespace demo
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
datafile 'c:/dummy01.dbf' size 100m
autoallocate;
Tablespace created.

SQL> create table x1 (x number)
tablespace dummy
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
datafile 'G:/ORA9I/ORADATA/DB9/BLAH.DBF' size 10m reuse
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、 在实际使用中，本地管理表空间带来的好处
2、 本地管理表空间的bug，如8i中在临时，回滚中使用本地管理表空间
3、 关于本地管理表空间其他看法
……
……s