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

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

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

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

具体如下:

  1. 数据库对象配置的差异。
  2. 数据库高可用的配置。
  3. 数据库存储机制的差异。
  4. 数据库容灾技术的差异。
  5. 数据库锁机制的差异。

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

观点一、
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/

原文地址:https://www.cnblogs.com/liujiacai/p/9313018.html

时间: 2024-10-08 07:14:04

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

数据库高可用架构 转载

数据库高可用架构对于我们这些应用端开发的人来说是一个比较陌生的领域,是在具体的数据库产品之上搭建的环境,需要像DBA这样对数据库产品有足够的了解才能有所涉及,虽然不能深入其中,但可以通过一些经典的高可用架构学习其中的思想.就我所了解到的有以下几种: MySQL Replication MySQL Cluster Oracle RAC IBM HACMP Oracle ASM MySQL Replication MySQL Replication就是通过异步复制多个copy以达到提高可用性的目的,

mysql数据库高可用架构-----MHA-0.56的详解

大家都知道,任何线上环境,都必须搭载高可用架构,是web的,也要是数据库的,严格来说更是整个架构的高可用. mysql作为时下比较热的数据库,高可用架构更加需求大.不过,以前老旧那一套已经不合时宜,现在用的比较多的就是MHA和PXC了. PXC的优势是做到同写同回滚,达到数据高度一致性,通过一些程序和代码来做第三方分发,可以做到一定程度的读写分离,是个相当不错的高可用解决方案,不过对网络要求比较高,配置也略复杂一些,最好是同一个机房里面做,不过这并不是本文重点,后面找时间再写相关的文章. 本文要

数据库高可用方案

数据库高可用方案 低读低写并发.低数据量方案 方案一:双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库,另一台B作为备份库:A库故障后B库作为读写库:A库恢复后A作为备库. 3.开发说明 此种情况下,数据源配置中的数据库IP地址,可采用虚拟的IP地址.虚拟IP地址由两台数据库机器上的keepalive配置,并互相检测心跳.当其中一台故障后,虚拟IP地址会自动漂移到另外一台正常的库上. 数据库的主备配置.故障排除和数据补全,需要DBA和运维人员来维护.而程序代码或配置并不需要修改.

数据库高可用实战案例-------架构优化之清爽一夏

说到高可用,看官们会想到很多方案,也许是自亲身经历过系统从单机变成高可用的痛苦过程,也许有的看官只是在自己的虚机上搭建过测试的玩具.今天本篇用我自己的真实经历给大家讲述,不管怎么样实战和测试玩耍还是很大的区别的!可能你觉得搭建一套高可用方案很简单,配置配置就OK了,但在真正的复杂系统中一切就没有那么轻松了! 文章主要讲述升级并搭建AlwaysOn高可用的过程,以实施的思路为主.文中并没有搭建集群的步骤,搭建步骤请自行学习. --------------博客地址------------------

数据库高可用方案总结

数据库高可用的两个关键: 1,数据同步 2,用于切换 数据库同步方案: Tungsten OGG Galera DRBD 应用切换方案: DRDB+heartbeat DB+Keepalived Corosync+Pacemaker_DRBD 搜索 复制

MySQL数据库高可用快速实施方案

Note:以下为MySQL+DRBD+HEARTBEAT快速实施文档,若要用于生产环境,请仔细阅读官方文档并结合实际业务调整参数,涉及数据部署请慎重!!! (个人建议:在基于个人熟悉服务的情况下并通过测试环境才可在线上使用.) 数据库高可用 MySQL+DRBD+HEARTBEAT实施方案 环境: mysql-5.5.49 heartbeat-3.0.4-2.el6.x86_64 drbd84-utils-8.9.8-1.el6.elrepo.x86_64 CentOS release 6.7

美团点评数据库高可用架构的演进与设想

本文介绍最近几年美团点评MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些创新.同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划和展望. MMM 在2015年之前,美团点评(点评侧)长期使用MMM(Master-Master replication manager for MySQL)做数据库高可用,积累了比较多的经验,也踩了不少坑,可以说MMM在公司数据库高速发展过程中起到了很大的作用. MMM的架构如下. 如上所示,整个MySQL集群提

巨杉Tech|SequoiaDB 巨杉数据库高可用容灾测试

数据库的高可用是指最大程度地为用户提供服务,避免服务器宕机等故障带来的服务中断.数据库的高可用性不仅仅体现在数据库能否持续提供服务,而且也体现在能否保证数据的一致性. SequoiaDB 巨杉数据库作为一款100%兼容 MySQL 的国产开源分布式数据库,它在高可用方面的表现如何?它的高可用性是如何实现的?本文将详细描述SequoiaDB巨杉数据库的高可用性原理,并进行测试验证. 01 巨杉分布式集群架构 SequoiaDB 巨杉数据库采用计算与存储分离架构,SequoiaSQL-MySQL 是

分享MYSQL中的各种高可用技术(源自姜承尧大牛)

图片和资料来源于MYSQL大牛姜承尧老师(MYSQL技术内幕作者) 姜承尧: 网易杭州研究院 技术经理 主导INNOSQL的开发 mysql高可用各个技术的比较 数据库的可靠指的是数据可靠 数据库可用指的是数据库服务可用 可靠的是数据:例如工商银行,数据不能丢失 可用的是服务:服务器不能宕机 灵活运用MYSQL的各种高可用技术来达到下面各种级别的高可用要求 要达到99.9%:使用MYSQL复制技术 要达到99.99%:使用MYSQL NDB 集群和虚拟化技术 要达到99.999%:使用share