db_block_checking和db_block_chec…

先看看Oracle文档上对db_block_checking参数的说明：

DB_BLOCK_CHECKING controls whether Oracle performs block checkingfor data blocks. When this parameter is set to true, Oracleperforms block checking for all data blocks. When it is set tofalse, Oracle does not perform. block checking for blocks in theuser tablespaces. However, block checking for theSYSTEM tablespaceis always turned on.

Oracle checks a block by going through the data on the block,making sure it is self-consistent. Block checking can often preventmemory and data corruption. Block checking typically causes 1% to10% overhead, depending on workload. The more updates or inserts ina workload, the more expensive it is to turn on block checking. Youshould set DB_BLOCK_CHECKING to trueif the performance overhead isacceptable

从文档中可以看到，DB_BLOCK_CHECKING参数主要是用于数据块的逻辑（一致）检查（但只是块内，不包括块间的逻辑检查，比如索引项目的ROWID指向的是不存在的行等）。
主要用于防止在内存中损坏或数据损坏。由于是逻辑检查，因此引起的额外负荷比较高，甚至可以达到10%，因此对于一个繁忙的系统，特别是插入或更新操作很多的系统，性能影响是比较明显的。

该参数对SYSTEM表空间始终是处于“打开”状态，而不管该参数是否设置为FALSE。

下面再看看db_block_checksum参数的说明：

DB_BLOCK_CHECKSUM determines whether DBWn and the direct loaderwill calculate a checksum(a number calculated from all the bytesstored in the block) and store it in the cache header of every datablock when writing it to disk. Checksums are verified when a blockis read-only if this parameter is true and thelast  write of the block stored a checksum. Inaddition, Oracle gives every log block a checksum before writing itto the current log.

If this parameter is set to false, DBWn calculates checksums onlyfor the SYSTEM tablespace, but not for user tablespaces.

Checksums allow Oracle to detect corruption caused by underlyingdisks, storage systems, or I/O systems. Turning on this featuretypically causes only an additional 1% to 2% overhead. Therefore,Oracle Corporation recommends that you set DB_BLOCK_CHECKSUM totrue

可以看到，DB_BLOCK_CHECKSUM只是在写入（DBWn常规写法或用户进程直接路径写入），根据一个CHECKSUM算法，计算数据块的校验和。然后写入数据块的一个特定位置（CACHEHEADER，具体是块的16-17字节，以0字节起算）。在读取块时，再进行检验。主要是防止IO硬件和IO子系统的错误。

CHECKSUM的算法只是根据块的字节值计算一个效验和，因此算法比较简单，引起的系统额外负荷通常在1%-2%

实际上，即使将该参数设为TRUE，将数据块（包括SYSTEM表空间）的16-17字节清0，同时将15字节（flag），第3位（即值为16进制0x04）清为0，则在块读取时也不会做CHECKSUM检查。如果该参数为FALSE，对于除SYSTEM的其他表空间，如果原来有CHECKSUM值，将15-16字节清0也不会做CHECKSUM检查。

db_block_checking和db_block_checksum这参数设置

在Oracle 10gR2版本之后db_block_checking和db_block_checksum这两个参数有了新的变化

先来看看db_block_checking，这个参数现在有四个可能的设置：
OFF - 与原来的FALSE一样，对非SYSTEM表空间的块关闭检查，这个值在设置时仍然可以用false。
LOW -只检查块头。这个检查发生在当块的内容在内存中发生改变时，比如UPDATE、INSERT、DELETE等，以及将块从磁盘读入、RAC结点间块的传输。
MEDIUM - 比LOW更高一级，还包括了非IOT的表的块内部检查（即不仅仅是块头）。

FULL - 与原来的TRUE一样，与MEDIUM相比，还包括了索引块的检查。

再看看db_block_checksum这个参数有什么变化：
OFF - 与原来的FALSE一样，只会给SYSTEM表空间的块计算checksum值。
TYPICAL - 与原来的TRUE一样，Oracle在向磁盘写入块时计算checksum值，下次读入时进行校验。
FULL -这是新增的值，Oracle不仅在写入块时计算checksum值，而且在更改块（比如执行UPDATE语句等）之前对checksum值进行校验，同时在更改块之后对checksum值进行重新计算。另外Oracle也会在写入日志块时，计算块的checksum。这个设置大大增加了系统负荷，大约带来了4-5%的负荷。而TYPICAL值会带来1-2%的负荷。


db_block_checking的性能花销及测试

Oracle官方文档对db_block_checking各个参数设置的性能花销是有如下数据


full – see above depending on updates and insertsand how well the database is tuned it can be costly 10%
medium – midrange but can be up to 10%.
low – very low around 1 %
off – no overhead

测试过程

SQL> create table MACLEAN(t1 int,t2 char(20),t3char(20),t4 char(20), t5 char(20),t6 date) tablespace users;
Table created.

SQL> create or replace  procedureinsert_data(s int) as
  2  begin
 3    for i in1..s  loop
 4     insert into MACLEAN values(i,'A','B','C','D',sysdate);
 5     commit;
 6     end loop;
 7     end;
  8  /
Procedure created.



SQL>show    parameter   db_block_checking
NAME                                                 TYPE        VALUE
-----------------------------------           -----------   ------------------------------
db_block_checking                         string       FALSE

SQL> begin
 2   
 3   insert_data(50000);
 4    end;
 5    /

  SQL> truncate tableMACLEAN;
  SQL>alter system flushbuffer_cache;

 begin
 
  insert_data(100000);
  end;
  /

 truncate table MACLEAN;
 alter system flush buffer_cache;

  begin
 
  insert_data(150000);
  end;
  /

 truncate table MACLEAN;
 alter system flush buffer_cache;



将db_block_checking设置未true
  SQL> begin
 2   
 3   insert_data(50000);
 4    end;
 5    /

  SQL> truncate tableMACLEAN;
  SQL>alter system flushbuffer_cache;

 begin
 
  insert_data(100000);
  end;
  /

 truncate table MACLEAN;
 alter system flush buffer_cache;

  begin
 
  insert_data(150000);
  end;
  /

 truncate table MACLEAN;
 alter system flush buffer_cache;




查看消耗的cpu时间
SQL> col sql_text for a70;
SQL> select sql_text, cpu_time, elapsed_time
  2  from v$sql
  3  where sql_text like'%CHECKING%'
  4  and sql_text not like'%v$sql%'
  5  order by CPU_TIME;

SQL_TEXT                                                                                          CPU_TIME ELAPSED_TIME
----------------------------------------------------------------------                         ---------------------- ------------
begin    insert_data(50000);  end;            7222902     7675162
 begin    insert_data(50000);  end;            8285740     8522438
 begin    insert_data(100000);  end;        13142002    13327092
 begin    insert_data(100000);  end;         15353665    15686535
  begin    insert_data(150000);  end;       19346058    19502160
  begin    insert_data(150000);  end;        25374143    26539033

6 rows selected.





可以看出，这两者的差别是相当显著的，这两者参数设置为false时比设置为true竟然快了40%以上。不过这只是个简单的测试，实际情况可能没那么突出，但差异在10%以上是有可能的。

值得注意的是，性能上的差异，主要是由于CPU的消耗造成的，对于CPU资源不足的系统，将这两个参数设置为TRUE无疑会增大CPU的负担，引起性能问题。同时还会引起redocopy latch的持有时间增加和引起这个latch的竞争。

另外，由于不管db_block_checking和db_block_checksum这两个参数的值为何值，SYSTEM表空间都会进行做checking和checksum，除非把隐含参数_db_always_check_system_ts设置为FALSE，当然为了SYSTEM表空间数据安全，不建议将这个隐含参数值设置为FALSE。 因此，不要将用户表和索引放到SYSTEM空间中。
 
在启用一起特定的功能后，SYSTEM表空间中一些表和索引会增长很快。比如启用了审计并且将审计日志存储到数据库中，则AUD$和FGA_LOG$会迅速增长；如果使用高级复制，DEF$_AQCALL表会增加很快，并且如果要复制的数据量比较大，则这个表上的DML是非常多的，在这样的情况会下，会消耗更多的CPU和引起性能降低。如果使用了审计和高级复制，建议将AUD$、FGA_LOG$、DEF$_AQCALL迁移到其他表空间，一方面避免产生大量数据使得SYSTEM表空间过大，另一方面则是避免出现本文提到的性能问题。不过这些表都是特殊的对象，最好在Oracle技术支持指导下进行。

db_block_checsum的性能花销及测试

先来看下ixora的一篇文章


The checksum is a simple XOR of all the data in the block, and assuch takes a small but noticeable amount of CPU time to compute.This has to be done for every I/O operation. The extra CPU timerequired for writes is of less concern than the extra CPU timerequired for reads, because writes are typically performed in thebackground by DBWn and LGWR and foreground processes should notnormally wait for the services of these processes. However, theextra CPU time required for reads is sustained by foregroundprocesses and thus impacts end user response times directly.

The Oracle documentation acknowledges this impact and indicatesthat the overhead is typically in the order of 1% to 2%. That istrue on average ! However, the impact on I/O intensive queries on asystem with moderate to high CPU usage can be much worse than that.The following comparison on an otherwise idle system shows a 4%difference in elapsed time and an 8% difference in CPU usage. On abusy system with not much spare CPU capacity, the impact on theresponse time of such queries rises to about 10%, and it increasesfurther if the application uses mostly index-based access pathsrather than full table scans to fetch its data.


从上面的叙述来看,db_block_checksum对读的映像比对写的影响要大。这是由于在负责将数据写入磁盘的后台进程DBWn和LGWR会计算除sum值，而前台进程正常情况下不会等待DBWn和LGWR。而当进行读取的时候，前台进程需奥消耗额外的CPU时间，故影响了用户的相应速度。

在Oracle的联机文档中写道，checksum只需要消耗额外1%～2%的系统负荷。然而在I/O频繁而且CPU利用率中等偏上的系统中，可能会增加10%左右的系统负载。而且，如果大部分使用索引路径访问而不是全表扫描的话，情况会更糟！因此，当系统I/O频繁或者CPU使用率偏高时，最好禁用该参数

   SQL> show parameters db_block_checksum
   NAME                                TYPE       VALUE
   ------------------------------------ -----------------------------------------
   db_block_checksum                   boolean    FALSE
   SQL> set timing on
   SQL> select count(*) from checksum_off;

     COUNT(*)
   ----------
        10000

    Elapsed:00:00:49.02
   SQL> set timing off
   SQL> select
     2   n.name,
     3   m.value
     4  from
     5   sys.v_$mystat  m,
     6   sys.v_$statname   n
     7  where
     8   m.statistic# in (12, 42, 164) and
     9   n.statistic# = m.statistic#
    10  /

   NAME                                                                 VALUE
   --------------------------------------------------------------------------
    CPU used bythissession                                               183
    physicalreads                                                       10182
    no work -consistent readgets                                       10360

   SQL> show parameters db_block_checksum

   NAME                                TYPE       VALUE
   ------------------------------------ -----------------------------------------
   db_block_checksum                   boolean    TRUE
   SQL> set timing on
   SQL> select count(*) from checksum_on;

     COUNT(*)
   ----------
        10000

    Elapsed:00:00:51.02
   SQL> set timing off
   SQL> select
     2   n.name,
     3   m.value
     4  from
     5   sys.v_$mystat  m,
     6   sys.v_$statname   n
     7  where
     8   m.statistic# in (12, 42, 164) and
     9   n.statistic# = m.statistic#
    10  /

   NAME                                                                 VALUE
   --------------------------------------------------------------------------
    CPU used bythissession                                               198
    physicalreads                                                       10182
    no work -consistent readgets                                       1036