语句来自于 <<教你如何成为Oracle10g OCP>> 第六章
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
红色部分是问题源头。
1. 每个bit位对应一个extent 比较好理解， 多个bit对应一个extent 是如何对应的 ？
2. 更新文件头部， 虽然不是写数据字典了， 但是文件头部更新也是更新block , 应该会有redo 吧 (因为是底层的更新， 应该不会产生所谓的undo) ？
文件头的更新也是后台进程在负责 ？
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
红色部分是问题源头。
1. 每个bit位对应一个extent 比较好理解， 多个bit对应一个extent 是如何对应的 ？
2. 更新文件头部， 虽然不是写数据字典了， 但是文件头部更新也是更新block , 应该会有redo 吧 (因为是底层的更新， 应该不会产生所谓的undo) ？
文件头的更新也是后台进程在负责 ？
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/35489/viewspace-678011/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
