db2回滚处理问题

wolfop · 发表于 2004-5-8 17:39

最初由 bpmfhu 发布
[B]受教了：） [/B]

如果一个节点的LOG被破坏，那么就算HACMP进行FAIL OVER，虽然存储进行了切换，那么也是无法完全正常恢复的，这个简直是废话。就算你不进行多节点，只用一个节点的ORACLE，如果DOWN机同时LOG文件被破坏，你觉得能正常前滚和回滚吗？

至于一致性，你还是没有弄清楚ORACLE鼓吹的“读一致性”究竟是什么东西，也不清楚究竟MYSQL提供了“读一致性”没有。至于数据的一致性，完全和“读一致性”就不是一个概念。

shao · 发表于 2004-5-9 10:51

最初由 cliser 发布
[B],“其实大家都有不好的地方.ORACLE的ROLLBACK 虽然并发的处理update不阻塞select,但关键业务可不敢这样用啊.有些地方还是让等一下的好.”
是啊，万一UPDATE 回滚了，那SELECT 的就查询的是错误的！ [/B]

误会,误会.
你说的是读没提交的数据(脏读),和ORACLE的读一致不一样.
抱歉,没说清楚.

Drewlee · 发表于 2004-5-9 12:11

wolfop的观点，其实在我已经理解，或许是我表达不够清楚。
请再将问题深入，而不局限在数据库概念和理论的争论上。
wolfop提到单机宕掉的情况，只能适用中小型业务，在大型和超大型业务上是不允许这种情况出现的。多节点恰恰用在后者中，用isolation level来解决并发的难题，牺牲的却是数据一致性的“及时性”，在目前的硬件处理能力下，也不失为一种方法。Oracle Parallel Server在保证数据同步的情况下也提高了并发处理能力。对于超大型系统，只有性能测试数据才能分出两个solution的优劣了。

其实文件和磁盘的损坏，也还有修复的可能。HA vs DR一段文字说的中肯。当然，时间不等人。
如果我提到的不可修复故障，成为无法解决的“废话”，在技术上完全不可逾越，那么银行的实际业务遇到此类问题时，是用的什么方式解决呢？
不会有人说：“他们一定遇不到这麻烦事。”吧。
不会有人说：“技术没法解决，就算你们倒霉。”吧。

或许有更加wonderful的technical solution。

technique不能解决的事情，process+technique能否解决呢？
是各节点业务流程的相对独立管理么？
即在节点出现难以修复的故障时，停止该节点的主要业务，避免错误的蔓延，这------不是又成了集群中的孤岛？！
还是，有更好的解决之道？？？

呵呵，话有点扯开了，从数据库技术已经进入了系统架构的范畴。
如果可能，请银行的同行给我们上一课吧。给我们说说process的结构和真实的系统架构。

Moreover，
wolfop在文中提到的“前滚”，我没有做过。谁能帮忙给个定义，介绍个书给本人？

笨笨龙骑士 · 发表于 2004-5-10 07:14

http://www-106.ibm.com/developer ... /dm-0404zikopoulos/

如m505斑竹所言，DB2新版本的HA特性：

Stinger provides new features to enrich the resiliency of the DB2 UDB OnDemand database for continuity of business operations or disaster recovery services.

The biggest feature for high availability in Stinger is high-availability disaster recovery (HADR). This implementation is based on the Informix® implementation of HDR. HADR is an easy-to-use data replication feature that provides high-availability (HA) solutions for both partial and complete site failures.

Essentially, HADR is log shipping (which DB2 UDB supports today) but from the log-buffer instead of from a hardened disk log; this method provides a lot of granularity to suit your solution’s high-availability requirements.

...

HADR also allows you to do rolling upgrades (for example, upgrading your version of DB2 UDB or the operating system) without having to suffer an outage.

Drewlee · 发表于 2004-5-10 18:56

The aricle is read.
Tks.

wolfop · 发表于 2004-5-10 19:57

没有必要吧DR和HA混为一谈，而且INFORMIX的HADR方式并不是那么好，这种同步复制的方式，对链路和备机要求很高。需要吧问题搞那么复杂吗？

m505 · 发表于 2004-5-13 15:23

Drewlee:
"现在我假定DB2的多节点同步能解决数据一致性的问题。谁能回答我的质疑。"
"多节点恰恰用在后者中，用isolation level来解决并发的难题，牺牲的却是数据一致性的“及时性”"

看来有必要谈一下share-nothing架构...在share-nothing下，每个node（partition）彼此独立运作，它们只能管理自己的数据 - 当然对用户来说只有一个数据库。所以不存在节点同步问题，当然涉及到多个NODE的更新操作，DB2用2-PHASE COMMITMENT来协调交易。也不存在一致性问题，这好像对数据库是基本要求吧
ISOLATION LEVEL和多结点并发没有关系。每个节点，或者单个数据库（没有PARTITION）使用ISOLATION LEVEL来控制对数据的同时（不是并行）访问。和数据的“及时性”有什么关系？“及时性”如何定义？当然更不存在“一致性”问题，ACID是数据库的基本要求。
其实，SHARE-DISK架构更加会导致并发行问题，为什么？因为所有的节点可以访问所有的数据，会导致I/O冲突，以及全局锁的问题。这个问题一直很困扰，呵呵。IBM DB2/zOS 用硬件来解决这个问题。