db2回滚处理问题

jiangzx

从2000年到现在，这几年IT的技术发展的确是很迅猛，从大趋势来看，各种数据库，应用软件，都在朝方便管理方面花了不少功夫，的确也是收到了预期的部分效果，但系统其实也变得越来越复杂了，关联的内容也越来越多了，在这一方面，其实又增加了系统管理的复杂性，真正出了问题，要能快速定位及解决，也是越来越遥不可及了

春雨惊春

4年了，我居然看到4年前的热帖，热泪盈眶啊！

jhe_001

看看Oracle和DB2在insert、update、select操作的异同。
1.insert和update操作
a、Oracle使用当前读（注意不是一直读，这时别人可以查数据）获取最新的数据块，插入修改数据。
b、DB2获取锁再插入修改数据（这时别的人不能查数据）。
2.select操作
a、Oracle有两种方式，一种是一致读（遇到别人在查询点后修改的数据到undo段重构查询时间点的数据）。一种是和DB2一样的在读的时候不希望别人改数据用select * from xxx for update实现，当然还可以有别的实现方式。
b、DB2处理select操作和insert、update一样，先获取锁再读（读的时候别人不能改数据，这点Oracle第二种方式和这个一样的效果）

mdkii

看完了帖子， 忍不住也想说两句。

db2用了好多年了，对db2熟一些。
但对Oracle 可以说基本没用过。

单单从Oracle的回滚段来看，如果楼上各位朋友所说属实的话，
我觉得对读一致性控制来说，Oracle的回滚段还是做得很好的，确实也提高了并发性，如果db2也要提高并发，必须
降低隔离等级，以读脏数据为代价。


本来还有点疑问，就是银行取钱的事务（有些事务必须要按事务发生的先后顺序串行处理）
先select账户balance
中间处理
update set balance = balance - var

如果同一个账户顺序发起两个事务，A和B
B发起时，A正在做update（对当前账户已经上了写锁），但未提交。
按照业务逻辑，显然是B事务应该看到A修改后的结果才能进行下一步处理。

对于oracle来说，当B未提交（有的朋友说即使提交了也一样）始终看到的
是A修改前的余额。这样会导致B事务发生错误（可能余额实际已经不够扣款了）。
这样的并发度提高反而导致了业务逻辑的错误。
而DB2应该会让B等A commit 了（释放了写锁）之后才开始select。

本来对这种情况有点疑惑 oracle会怎么办，不过楼上的朋友说了可以用
“select * from xxx for update实现，当然还可以有别的实现方式”
但这样一来，事务的并发程度就跟db2一样了。


因此，事务如果不需要按事务发生的先后顺序串行处理，或者这样的事务很少，
oracle的回滚段应该是一个比较好的增加并发的设计，尤其在有olap和oltp混合负载的
应用上优势体现最明显。
db2经常会遇到跑批与联机交易锁冲突的情况（当然也会有一些解决办法，
楼上很多大侠技术都很高深，在此就不再献丑了）。

wangkxxe

学习。。。精彩的讨论啊

wangkxxe

总感觉还是oracle回滚处理用起来方便的多！

huajieaixue

好老的精华帖子
IBM在最新发布的DB2 V9.7 中已经解决了部分问题：
The next new feature within DB2 is an improvement to its transaction concurrency model. This concurrency enhancement provides more granularity for the transactions. Within some high-performance systems, one transaction writing data and another transaction reading data can be blocked or delayed before the writer transaction is committed. This delay or blocking situation can cause some high-performance systems issues, so the DB2 team developed a new isolation level called Currently Committed that is now the default within the system.

The new Currently Committed isolation level allows writer transactions to continue processing while the other reader transactions within the system get their data. It works by retrieving the data row information that the reader transaction needs from the DB2 logs-usually from the log's memory cache, which is very fast. As a result, the reader transaction can continue processing without waiting for the writer transaction to be committed. This functionality provides more robust concurrency and implements it in a way that does not cause extra overhead for the system or transaction processing.

wangkxxe

精彩的帖子！ 支持！

joyw

5年前的， 把很多人都“讨论” 没影儿了，  db2 在OLTP 里用的也不少， 看看SAP ECC 成功案例就知道了，  另外ORACLE 的undo 01555 实在是太烦人了
总也解决不了 （ORACLE 10G ，SAP 跑个报表8万秒， 多大的UNDO TBS 都不行）

wolfop

DB2 9.7缺省的CS隔离级别对读取的锁定已经取消，应用感受和ORACLE类似。而且不需要undo tablespace