write-through和write-back這個概念在存儲工程師眼里絕對不會陌生，而對於數據庫管理員來說並卻並不一定十分清楚。我說看到的數據庫管理員與存儲工程師的接口無非就是這些：
1. 我需要一個scalable vg，大小是100g。
2. 我需要使用三個1T的裸盤用來做asm。
3. 我需要一個IOPS為12000的陣列，底層做成raid 10， 條帶大小為1M
沒有人願意去了解關於磁盤cache是怎么工作的，因為那不是我工作的范疇。
俗話說： “不想當廚師的裁縫不是個好司機“， 如果預備做Exadata的管理員，或許您應該先了解了解cache的寫模式。Take it easy, it is not rocket science.
在進入正題之前，先來問問wikipedia怎么看： Writing Policies 。 wiki大神已經解釋得非常清楚了，看來沒有寫下去的必要了。這篇文章就到這吧，再見。No， to make it more clear， I would like to interpret it in an Exadata way, that is the point. 俗話說：“No pictures, No trues”, let’ s get started.
Write-Through 模式：
1. DB向Cell發送一個寫請求， cellsrv進行驗證確認其請求有效;
2. cellsrv將發送指令將其寫入到物理磁盤;
3. 寫完成以后，給DB確認已經寫成功;
4. cellsrv判斷次數據是否適合緩存到cache中，如果滿足條件則緩存，否則不緩存。
Write-Back 模式：
1. DB向Cell發送一個寫請求， cellsrv進行驗證確認其請求有效;
2. cellsrv將發送指令將其寫入到磁盤Cache;
3. 將此數據的狀態置為dirty的狀態。（直到下次臨界條件將臟數據刷新到磁盤，並判斷此數據是否適合緩存，如果不適合，刷新完成以后會丟棄，刷新和緩存過程是異步的，並不在步驟3來完成）
4. 寫完成以后，給DB確認已經寫成功;
Write-Back 模式明顯更高效，因為寫數據到cache的速度比寫到物理磁盤速度要快幾個數量級。但是cache屬於揮發性設備，無法持久的保存數據，所以需要磁盤控制器/Flash卡有獨立的電源模塊作為驅動將cache中的數據寫回到磁盤。如果沒有電源模塊，則原本保存在cache中的數據並無法保障總能成功寫入到磁盤，如果這個時候主機發生掉電，則可能造成數據不一致。為了保證數據的一致性，如果磁盤控制器或者flash卡的電量不足，則會自動從write-back模式轉到write through 模式， 進而對系統的I/O造成影響。在exadata中可以使用exachk工具來檢查，以下是Exachk中磁盤raid控制器電池不足導致自動切換到write-through的告警。
實際上可以在BIOS中強行修改磁盤控制器的wirte-back或者write-through模式，但是為了保證數據的一致性，我們並不建議這么做。如果出現了以上問題，正確的做法應該是開一個sr，上傳對應的exachk報告要求更換電池。