DB2锁机制详细解释

你可以看看我blog中的文章, 希望对你有帮助:
http://www.db2china.net/home/space.php?uid=1167&do=blog&id=3956收起

回复 14# 苏州易博创云

严格来说有问题，只不过中文文章中几乎没有提及而已。
你可以看http://www.itpub.net/thread-1914632-1-1.html这贴，是讨论oracle隔离级别实现中的问题，特别是18L的那个pdf。

这是里面的一张图片，oracle的隔离级别是倒数第二个Snapshot，ANSI SQL的SERIALIZABLE是最后一项。可以看到Snapshot会出现Write Skew这种反常，而ANSI SQL的SERIALIZABLE不会。收起

回复 12# shadowflare


   oracle完全按照事务一致性的模式去设计的，所以undo对于这一点是非常关键的，正因为undo所以oracle才有正真意义上的row lock。收起

oracle默认的cs隔离级别是不能看到别人未提交的事物的，要是能看到别人还未提交的数据那么就不叫读一致了，恰恰相反那就叫读不一致了收起

回复 9# 欧阳峰
不是说读不到未提交数据就满足了一致性的，你看一下我回复中的链接。收起

回复 9# 欧阳峰

读before image这个想法不错，只是不要用到写操作里面。收起

这一点上oracle做的比较灵活收起

oracle是通过undo保证读一致性的，当有人去更改每一行的时候，通过undo把更改之前的前印像数据提供给另外一个人查询，如果undo表空间不够了会返回ora-01555快照太老的错误告诉他前印象被覆盖了收起

回复 7# 欧阳峰

还是不太一样，DB2的cur_commit特性主要在默认隔离级别CS下发挥作用，实现读写互不阻塞的功能。在更高一级的RS下作用很小，到了最高的RR级别就无效了。而ORACLE从undo空间读before image的设计在任何隔离级别下都可用。
而且DB2的cur_commit是只适用于读操作的，写操作定位目标行时没用。所以DB2中会出现两个事务更新同一张表中不同记录（filter字段上无索引）时互相阻塞的现象。ORACLE因为对写操作也会读取before image，故无此现象。
至于DB2为什么不设计成ORACLE那种方式，应该不是技术上的问题，主要是严格遵守ANSI-SQL的需要，并发性再提升就该出现一致性问题了。（严格来说ORACLE的隔离级别都没有满足ANSI-SQL标准的要求，想了解ORACLE的实现方式到底有何问题，可以参考我发的这篇帖子： http://www.itpub.net/thread-1914632-1-1.html )收起

9.7之后的这个相当于oracle里面的undo 表空间的意思了收起