LMT更新file header bitmap不產生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) ？  
      檔案頭的更新也是後臺程式在負責 ？