LMT :  本地管理表空间，不使用FET$及UET$, 而是在表空间的数据文件头部选出6个block(从第
3个block到第8个block), 在其中存放bitmap来管理extent的分配及释放。

数据文件头部的bitmap由多个bit组成，比如 11001010001100111001000001,每个bit位对应一个extent,
或者多个bit位对应一个extent(因为有时一个extent过大)。 当进程需要extent时，只需要扫描文件
头部的bitmap, 找到0位，分配bit位对应的可用空间，更新bit值为1，删除extent则相反。

LMT的优点： 克服了DMT的缺点，没有递归SQL,只需要更新文件头部，无事务，速度快，没有锁及undo,
redo, 且不存在合并空间的问题。 Oracle9i开始需要创建LMT，而不是DMT . 

10g数据文件头中会有64K的空间用来存放bitmap，其他空间都可用，所以我们在建立数据文件大小
的时候，需要在uniform. size 整数倍的前提下再加入这64K的大小，以免浪费空间 。  

---------------------------------------------------------------------------------------
备注：

The locally-managed (bitmapped) tablespace (LMT) file has the following structure:

1、File header: 1 block
2、Bitmapped file space header: 1 block
3、Head portion of bitmap blocks: N blocks
4、Useful file blocks: U units (A unit is a number of blocks.)
5、Tail portion of bitmap blocks: M blocks

If a Unit = B blocks, then the total file size = 1 + 1 + N + U*B +M.
The operating system file allocated will in some cases be file size + 1 block for
the OS header.

---------------------------------------------------------------------------------------

一直疑惑的问题是 ：

1.    存放bitmap 的大小一般是 64K 。   LMT 表空间的数据文件头部选出6个block(从第3个block到第8个block), 在其中存放bitmap来管理extent的分配及释放。 那么6个block 和 64K 应该以哪个为准， 因为定义库的block size 是不一样的， 还有64K 包含了哪些内容， 应该不止 bitmap 部分的大小吧 ？  因为 64K 大小不是 6 的倍数 (假设block size 是4K, 8K , 16K  等)  。 

2.  “ 每个bit位对应一个extent, 或者多个bit位对应一个extent(因为有时一个extent过大) ” ， 这里的 “多个bit位对应一个extent ,  因为有时一个extent 过大” 如何解释 ？