db block checking & checksum

这两个参数的含义经常让人混淆，虽然都是对block进行检查。
db_block_checksum 是在将数据块写到数据文件的时候对block内数据做一个校验写在块头，当读入时候重新计算校验和写出时候的校验对比，如果不同则认为是块损坏。这通常应该是由于脱离oracle以外在os或者硬件中出现了损坏，如果设置为false则只对系统表空间有效。从8i开始设置为true的时候也同时对log block进行校验。

db_block_checking 是当block发生任何变化的时候进行逻辑上的完整性和正确性检查，这在内存中进行，当发现错误就立即回退，设置为false则只对系统表空间有效。

这意味着，如果db_block_checking = false ,非系统表空间中数据在逻辑上可能已经损坏，但是 db_block_checksum 却是无法检查出来的，原样写到磁盘原样读到内存，因为它只校验块在写出后和读入之间是否发生变化而不检查写出前是否存在 逻辑上的正确。

比如有时索引块损坏，造成通过索引无法获得数据，但是读索引块的时候并没有出1578错误，可能就是这个原因。

db_block_checking和db_block_checksum这两个参数对性能的影响。下面做个测试：

首先建一个测试表，并设置db_block_checking和db_block_checksum为false：
SQL> show  parameter db_block

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------
db_block_buffers                     integer     0
db_block_checking                    string      FALSE
db_block_checksum                    string      TRUE
db_block_size                        integer     8192

SQL> create table t2 (a int) tablespace test;

表已创建。
SQL> alter system set db_block_checking=false;

系统已更改。

SQL> alter system set db_block_checksum=false;

向测试表T2中四次分别插入100，000行数据：
SQL>set timing on;
SQL> begin
 for i in 1..100000 loop
 insert into t2 values(i);
 end loop;
 end;
 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 05.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01

四次数据插入中，最长的时间为7.04秒，最短时间为5.05秒，平均6.29秒。

下面再看看将这两个参数设置为true的测试结果：

SQL> alter system set db_block_checking=true;

系统已更改。

SQL> alter system set db_block_checksum=true;

系统已更改。

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 12.01
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 09.00
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.04
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02

在上面的测试中，四次数据插入，最长的时间为12.01秒，最短时间为9.00秒，平均为10.77秒。

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

值得注意的是，性能上的差异，主要是由于CPU的消耗造成的，对于CPU资源不足的系统，将这两个参数设置为TRUE无疑会增大CPU的负担，引起性能问题。同时还会引起redo copy 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技术支持指导下进行。DEF$_AQCALL的迁移，请参考metalink doc ID 1037317.6 “Moving the Replication Queue Tables (DEF$) Out of the System Tablespace”；AUD$的迁请参考metalink doc ID 72460.1 “Moving AUD$ to Another Tablespace and Adding Triggers to AUD$”

对这两个参数引起的性能差异的深入分析，有兴趣的可参考Oracle hidden costs revealed, Part2 - Using DTrace to find why writes in SYSTEM tablespace are slower than in others

这两个参数不光对DML，对读也是有性能影响的。db_block_checksum参数对读的性能影响和测试，有兴趣的可参考ixora上的文章Note the db_block_checksum parameter setting

此文不知道出处，转帖至此。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22779291/viewspace-667590/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22779291/viewspace-667590/