实测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