實測DB_BLOCK_CHECKSUM=FULL的作用

從10.2.0.3開始 DB_BLOCK_CHECKSUM有三個選項：OFF TYPICAL FULL 在10.2.0.3之前 DB_BLOCK_CHECKSUM有2個選項： TRUE FALSE 在11g中DB_BLOCK_CHECKSUM和 DB_BLOCK_CHECKING參數 被 DB_ULTRA_SAFE參數整合到一起： DB_ULTRA_SAFE sets the default values for other parameters that control protection levels. Values: OFF When any of DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or DB_LOST_WRITE_PROTECT are explicitly set, no changes are made. DATA_ONLY DB_BLOCK_CHECKING will be set to MEDIUM. DB_LOST_WRITE_PROTECT will be set to TYPICAL. DB_BLOCK_CHECKSUM will be set to FULL.   DATA_AND_INDEX DB_BLOCK_CHECKING will be set to FULL. DB_LOST_WRITE_PROTECT will be set to TYPICAL. DB_BLOCK_CHECKSUM will be set to FULL. DB_BLOCK_CHECKSUM 參數決定了DBWn程序和直接路徑讀取程序是否為塊計算checksum并将該checksum存放在每個資料塊的cache header并寫入到磁盤中。當該資料塊被讀取時，該checksum會受到驗證， 前提是DB_BLOCK_CHECKSUM 被設定為TYPICAL 或 FULL，且最近一次該塊的寫出中存有checksum。 在FULL模式下，Oracle還會當塊要發生變化應用前對該塊驗證checksum，并會在DML update/insert/delete語句引起變化被應用到塊後再次計算該checksum。 此外，Oracle會對寫入到目前redo日志檔案的每一個redo block計算checksum。 若該參數設定為OFF，則 DBWn程序僅為system表空間上的對象計算checksum， 而對于普通表空間不計算。 checksum讓Oracle具備檢測由底層磁盤、存儲子系統、IO子系統引起的壞塊。 若設定為FULL， 則DB_BLOCK_CHECKSUM還會捕捉記憶體訛誤并避免将存在邏輯訛誤的塊被寫入到磁盤上。 官方文檔介紹設定DB_BLOCK_CHECKSUM為TYPICAL模式可能引起1%-2%的性能損耗，設定為FULL mode可能引起4%-5%的性能損耗。   除非有極高的資料安全性要求，否則推薦使用者設定DB_BLOCK_CHECKSUM為TYPICAL。 實際測試發現在 Linux +版本11.2.0.3上DB_BLOCK_CHECKSUM=FULL對普通的記憶體訛誤(memory corruption)幾乎無效，詳見以下測試：  

    以上通過oradebug poke指令反複修改資料庫塊内的T1字段，模拟資料塊在記憶體中出現記憶體訛誤(block corruption in memory)，發現DB_BLOCK_CHECKSUM=FULL對該種簡單的記憶體訛誤卻無法實際檢測到(這不代表DB_BLOCK_CHECKSUM=TYPICAL無法檢查到檢測由底層磁盤、存儲子系統、IO子系統引起的壞塊，DB_BLOCK_CHECKSUM=TYPICAL仍是檢測實體壞塊的最佳預設推薦配置)，通過update/delete修改對應手工訛誤的記憶體塊，均可以正常工作并生成redo且flush髒塊(dirty buffer)到磁盤上，則會将該記憶體訛誤的情況持久化，且即便在db_block_checking=FULL的情況下也無法檢測到一丁點邏輯訛誤，這說明不管是db_block_checksum還是db_block_checking都對記憶體中資料塊的細微訛誤無法有效檢測，雖然這不代表checksum+checking無法檢測到更破壞塊結構的記憶體訛誤，但多少還是有些悲哀的。  

本文轉自maclean_007 51CTO部落格，原文連結:http://blog.51cto.com/maclean/1278472