(转)Oracle与DB2在数据库高可用技术上的相同与差异探讨

原文：http://www.talkwithtrend.com/Article/178339

数据库建设过程中，高可用是每一个企业数据中心数据库建设过程中至关重要的一个关注点，直接关系到业务连续性和稳定性。要想将这个工作做好，我们必须从其底层原理、机制、架构等方面进行深入了解，深入分析，深入对比才能知道我们应该如何去实践。下面的几个关键点，不仅仅是每一个DBA应该琢磨的事情，同时也是搞企业IT架构规划和建设的人必须了解和知道的事情。

下面总结了一些Oracle与DB2在数据库高可用技术上的相同与差异的一些典型问题和困惑，帮助大家更好地去理解这两者之间的差异。

具体如下：

数据库对象配置的差异。
数据库高可用的配置。
数据库存储机制的差异。
数据库容灾技术的差异。
数据库锁机制的差异。

一、关于数据库对象概念等方面的差异？

观点一、
DB2类似管理容器的概念，是一个实例下可以有多个数据库，各库互相独立。Oracle是一个实例只能运行一个数据库，一个数据库在群集环境下可运行于多个实例下，类似运行机的概念。

观点二、
DB2的instance和database是一对多的关系，即一个实例下面可以有多个数据库；ORACLE的instance和database是一对一的关系。

二、关于数据库仲裁机制及原理差异？

ORACLE仲裁算法：

有两个非常重要的规则：1. 保障隔离后的集群子集中节点数目最多的子集存活。2. 当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。

mysql galera 的仲裁机制：

当集群出现故障的时候，galera cluster会启动特别的仲裁算法来选举一个节点作为主节点，集群里成员的数量决定了quorum仲裁的投票数（最好是单数），当一个节点出现故障不再属于集群的时候，galera就会启动一次仲裁选举。默认设置是5秒。galera有独立的进程叫做garbd来做仲裁者Arbitrator
galera仲裁者是集群的一员，参与投票，但不真正参与复制。
galera仲裁者的设立出于以下两个目的：
1、偶数节点时，仲裁者作为一个节点使集群成为奇数，从而避免脑裂
2、它可以请求一个连续的应用状态快照，可用来做备份
尽管仲裁者不存数据，它必须能够流经所有的复制流，所以把仲裁者放在一个和其他节点网络连接差的网络环境里会导致整个cluster的性能变差。仲裁者倒了并不会影响cluster的操作，可以在任何时间挂一个新的节点上去

db2 purescale的仲裁机制：

采用的是NODE QUORUM + TieBreaker的方式进行仲裁，对于集群节点<=2的情况下，宕掉一个节点，只要仲裁盘状态正常也是可以正常工作的。

三、如何看待各个关系数据库对存储利用的原理和机制？

观点一（oracle）、
ASM有自动条带化和镜像的能力，减轻管理负担，而且存储的操作不必每次再和系统管理员约时间创建lv了！性能没觉得比裸设备好太多，主要是可用性以及和集群的兼容性。

观点二（db2）、
1.文件系统的话在aix上是基于jfs或jfs2来管理的,性能受到文件系统本身的块化结构所限制。2.裸设备影射的话就交由存储来管理,性能主要由存储缓存和通讯接口比如说光纤接口,交换机,还有服务器接口限制.还有一个非常重要的地方就是oracle ASM的failure group机制做的非常好，保障了灵活的高可用机制。db2结合GPFS也是一个非常好的解决方案，但是GPFS毕竟是文件系统映射之后提供给db2的容器，性能上还是不如ASM直接。个人理解。

观点三（oracle）、
Asm实现了的主机层面文件系统，裸设备等存储资源的自动管理和优化工作，降低了dba对lvm的管理和性能调优的成本。直接的lvm管理就是需要dba定制化的对fs，lv，VG等对象的设计和对最底层存储的磁盘阵列的设计。

四、数据库容灾中的数据复制原理？

oracle：
oracle的dataguard同步方式有两种，一种是同步，一种异步。下面先来说下DG的原理：
当用户在主库提交数据的时候，会在sga的redo缓冲区中首先记录redo信息，在提及操作的时候lgwr会将redo数据写入redo数据文件中，那么这个时候lns进程会实时的将redo数据从主库的redo缓冲区传送到备库，在备库使用rfs接受数据，传入standby logfile中，进而应用redo数据（sql apply）。在应用完成后rfs将信息返回主库进程，告知该redo条目已经在备库应用完毕，lgwr收到lns的确认消息，从而提示提交成功。
在最高可用性中，如果主库收不到备库应用的确认消息，那么会通过net_timeout值超时，继续完成本次操作，那么lns进程将不会在获得sga中的重做数据，只有当下次日志switch的时候才主动去尝试获得lns数据，如果期间还是没有和备库完成通信，当超过net_timeout参数的时候会继续停止，主机事务也继续完成，但当存在于最大保护模式下，那么必须等到备库应用redo的确认消息，那么就会停止数据库的运行操作。

db2：
非purescale环境的DB2 HADR有四种复制模式SYNC,NEARSYNC,ASYNC,SUPERSYNC; oracle支持三个模式最高性能，最高保护，最高可用性,可以归纳为两种模式SYNC,ASYNC，我觉得DB2在这一块划分的更细些。两种数据库的复制原理来讲都是基于capture log--->TCP传输---->REDO log这样一个过程。
最佳参照文章：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1010baosf/

五、关于数据库锁机制？

观点一、
Oracle是通过SCN实现多版本并发控制，并且是基于页面粒度。
Db2，旧的版本似乎是有读一致性锁存在，而且是靠Locklist来实现锁的管理。后期版本似乎是有MVCC的。
Oracle：
1 写redo。
2 写undo。
3 修改数据。

这个时候，读请求实际是可以从undo中读取历史版本的。

观点二、
ORACLE的并发机制使用的是不同类型的锁来控制.
有数据方面的锁比如TM,TX
也有内存方面的锁比如 LATCH,MUTEX,LOCK
另外TM,TX不是真实的锁, 里面还有个叫锁模式的才是真的锁,NULL,X,S
TM,TX及其他的是排队机制的结构体.
不过通俗地,大家都把TM,TX都叫成锁了.我就不在纠正了.
因此ORACLE锁不是负担,没有相应的管理成本! 在这一点上MS SQLSERVER不如ORACLE

民生银行牛总的文章引用：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0512niuxzh/