DB2缺省的事务及并发锁机制

试验了一下DB2的并发锁机制，结果，和MSSQL的差不多：1、DB2的缺省行为，事务以可执行的SQL开始，以COMMIT或ROLLBACK结束；2、DB2缺省是否提交，以工具的不同而不同，这也是DB2的特点，对外界环境依赖比较明显，比如：用户认证就是，依赖操作系统或第三方认证。3、今天我的试验过程是这样：（1）先启动DB2CLP，db2cmd->db2（2）连接TEST数据库，connect to test（3）创建一个试验表，create table test（id int,aa varchar（10））（4）验证表结构，describe table test（5）插入两行数据，insert into test values（1,"aaaa"）insert into test values（2,"bbbb"）（6）验证数据，select * from testh 历史命令；r n 运行第n条命令；e n编辑第n条命令；（7）update test set aa="cccc" where id=1（8）启动另一个DB2CLP,update test set aa="dddd" where id=1,结果没什么阻塞，大为震惊，都说Oracle的锁独步天下，没想到DB2的锁也是独步天下啊。回头觉得不对劲，查了一下DB2的文档，结果DB2是否自动提交依赖于接口或工具，那么DB2CLP的这个选项缺省是什么呢？（9）DB2CLP下查各种命令选项，list command options;（10）结果选项c 缺省为ON,打开的，意味着在DB2CLP中，缺省对SQL命令是自动提交的。（11）把C 选项改为OFF，update command options using c off,注意在每个DB2CLP中都要改，因为这个命令只会影响到当前连接。（12）修改完三个DB2CLP连接中的C 选项后，开始试验；（13）第一个DB2CLP中，update test set aa="eeee" where id=1;第二个DB2CLP中，update test set aa="ffff" where id=1;结果阻塞；然后在第三个DB2CLP中，update test set aa="GGGG" where id=2;也是阻塞，说明db2不但阻塞了同行数据的修改，这是正常的，而且也阻塞了不同行但在一个page页中的行的修改，看来它得锁模型也是和MSSQL一样，属于悲观模型。这段时间一直看DB2的资料，可以说受益匪浅，更把各种系统的锁模型进行了比较，结果发现，DB2和MSSQL比较相似的，之前，我对MSSQL的锁进行了更进一步的跟踪，发现MSSQL对未提交事务涉及的表是加表级锁的，这会阻塞其他事务对该事务涉及表的修改操作。同时，也会阻塞其他事务的读操作。而对于ORACLE和MYSQL来说，是不会产生这种表或块级阻塞的，主要还是因为锁模型的不同，主要还是观念的原因吧，或者说是乐观和悲观的原因。谈不上谁好谁坏，大家只看到了并发度，而没看到乐观锁会给应用带来的坏处，就一味的说悲观锁不好，不可否认ORACLE等系统的乐观锁会带来系统性能上的好处，让大家用着会舒服，可应用上的处理就会麻烦些，这也是DB2,MSSQL始终不改变这点的原因，观念不同而已。推荐阅读：DB2数据库性能调整和优化（第1、2版） PDF http://www.linuxidc.com/Linux/2013-09/90679.htmDB2数据库性能优化介绍 http://www.linuxidc.com/Linux/2013-09/90678.htmOracle数据库学习总结MySQL Replication（主从服务器）配置实例相关资讯 DB2

RHEL5 下安装 DB2 V9.7 数据库（今 09:39）
DB2常用脚本整理（01月19日）
Linux下DB2SQL1024N A database （01月12日）

DB2中REVERSE函数的实现（01月19日）
使用 IBM Data Studio 创建和管理（01月12日）
TOAD连接DB2报错SQL1460N解决（01月12日）

本文评论查看全部评论（0）