Free buffer waits
1.簡述：當資料庫要在buffer cache中尋找空閒空間來放置資料，但發現空間不足時，就會產生這個等待;
2.詳述：
a)在使用者請求塊的DBA上應用HASH函式，獲得適當的hash bucket;
b)檢索bucket對應的chain,確認塊頭是否存在，若存在就使用;
c)若不存在，使用者程序在LRU鏈上按最近最少使用的順序尋找空閒緩衝區。若在此過程中發現髒塊，則將其移到LRUW列。找到空閒緩衝區後，就可以從資料檔案將塊讀到該緩衝區上;
d)在LRU列上尋找，一般掃描40%的比例，掃完後沒有發現空閒緩衝區，就會停止掃描並驅使DBWR將髒塊寫到磁碟上;
e)在等待dbwr寫髒塊的'過程中，使用者程序在等待free buffer waits事件。
3.原因：三部分
buffer太小，導致空閒空間不夠
2.髒塊寫得慢。
a)記憶體中的髒資料太多，DBWR無法及時將這些髒資料寫到磁碟中以釋放空間，也就是可能有批量dml操作。
b)dbwr數太少，db_writer_processes引數是否設得過少，配合os上的ps -ef | grep | grep dbw檢視dbwr數量
c)緩慢的IO子系統，db file parallel write較多，v
d)延遲塊清除，即延遲塊頭事務標記清除。
3.要申請的空間過多
a)低效率的SQL語句導致過量的物理讀。
4.附錄：前臺程序掃描lru連結串列，看有沒空閒的空間，一般要掃到預定義的限度才停止掃描，這個限度是LRU連結串列的百分比，9i中預設40%, 可以通過查詢。 select * from x where kvittag = 'kcbfsp';或者查詢引數 _db_block_max_scan_pct 也是40. 出現場景：imp,impdp導數進庫也可能出現這個等待。 這個等待事件包含2個引數：File#: 需要讀取的資料塊所在的資料檔案的檔案號。 Block#: 需要讀取的資料塊塊號。 什麼是延遲塊清除? 在事務提交前，這個事務修改得block已經被dbwr寫到disk中去了。我們知道，塊頭會記錄這個塊有活動事務存在，後來這個事務commit 時，oracle不可能再把它讀回到記憶體中來修改塊頭。只能等下回用它時，到undo段裡查詢事務記錄後，再修改塊標誌為已commit.比如如果對一個大表有delete操作，後續有人對這個表有select操作，因為延遲塊清除的特性，就會佔用大量buffer.這也是為什麼select也會產生 redo的原因。(select的時候要修改塊頭)delay block cleanout : 主要針對大事務，可能在commit的時候，一些資料髒快已寫入資料檔案，提交時，無法把這些資料塊標記commit,該資料塊的下一個讀者對其進行 delay block cleanout .資料塊的下一個讀者首先檢查該塊的事務狀態是否為活動，不活動的話，修改事務的標誌(flag)。這樣可以避免不必要的事務讀。
