没有合适的资源?快使用搜索试试~ 我知道了~
Oracle数据库容灾、复制解决方案全分析
8 下载量 91 浏览量
2020-03-04
10:46:36
上传
评论
收藏 64KB DOC 举报
温馨提示
试读
12页
目前,针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案:基于存储层的容灾复制方案;基于逻辑卷的容灾复制方案。如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是非常高的,在异地环境中几乎不可能实现。
资源推荐
资源详情
资源评论
数据库容灾、复制解决方案全分析(绝对精品)
目前,针对 oracle 数据库的远程复制、容灾主要有以下几种技术或解决方案:
(1)基于存储层的容灾复制方案
这种技术的复制机制是通过基于 SAN 的存储局域网进行复制,复制针对每个 IO 进行,
复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的
系统来说有很大的优势(每天日志量在 60G 以上),但是对主机、操作系统、数据库
版本等要求一致,且对络环境的要求比较高。
目标系统不需要有主机,只要有存储设备就可以,如果需要目标系统可读,需要额外
的配置和设备,比较麻烦。
(2)基于逻辑卷的容灾复制方案
这种技术的机制是通过基于 TCP/IP 的网络环境进行复制,由操作系统进程捕捉逻辑
卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或
异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比
较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和
上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容
灾复制。
我一直有一个困惑,存储级的 复制,假如是同步的,能保证 数据库所有文件一致吗 ?
或者说是保证在 异常发生的那一刻有足够的缓冲来保障?
也就是说,复制的时候起文件写入顺序和 oracle 的顺序一致吗?如果不一致就可能
有问题,那么是通过什么机制来实现的呢?
上次一个存储厂商来讲产品,我问技术工程师这个问题,没有能给出答案
我对存储级的复制没有深入的研究过,主要是我自己的一些理解,你们帮我看一下吧
……
我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化,而不是每隔一段时间
去复制一下原系统存储上文件内容的改变结果,所以在任意时刻,如果原系统的文件
是一致的,那么目标端也应该是一致的,如果原系统没有一致,那目标端也会一样的。
形象一点说它的原理可能有点像 raid 0,就是说它的写入顺序应该和原系统是一样的。
不知道我的理解对不对。另外,在发生故障的那一刻,如果是类似断电的情况,那么
肯定会有缓存中数据的损失,也不能 100%保证数据文件的一致。一般来说是用这种
方式做 oracle 的容灾备份,在发生灾难以后目标系统的数据库一般是只有 2/3 的机
会是可以正常启动的(这是我接触过的很多这方面的技术人员的一种说法,我没有实
际测试过)。我在一个移动运营商那里看到过实际的情况,他们的数据库没有归档,
虽然使用了存储级的备份,但是白天却是不做同步的,只有在晚上再将存储同步,到
第二天早上,再把存储的同步断掉,然后由另外一台主机来启动目标端存储上的数据
库,而且基本上是有 1/3 的机会目标端数据库是起不来的,需要重新同步。
所以我觉得如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据
库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是
非常高的,在异地环境中几乎不可能实现。
不知道我的理解对不对,也不知道是不是回答了你的问题,呵呵。欢迎指正!
应该说部分地回答了我的问题,呵呵
因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的,存储
设备一定是做过重整的,那 不管同步或者异步的拷贝都 有可能 存在问题的。
所以我一直对这个方案的可靠性不敢完全相信,这样一来,倒不如 data guard 可靠
了
因为很明显,存储设备拷贝过去的数据文件 不一致是有很大的概率的
你的意思是说即使不考虑目标端,仅在源端的情况下,存储设备的写入顺序也是和
Oracle 不一致的?这应该是一个原因。我觉得还有一种可能性就是在忽略存储设备
的这种情况下,在主系统当机,发生切换的时候,主系统存储上的数据文件也不一定
能保证一致,就算目标系统保持了完全的同步,也一样不能保正目标端数据可可以启
动。
不太理解,为什么说存储设备的写入顺序会和 oracle 进程的写入顺序不一致阿
如果说仅在源端情况下,存储设备的写入顺序也是和 Oracle 进程不一致,那么不考
虑异地冗灾,那么是不是意味着即使本地服务器 crash,也无法启动存储上的数据文
件?
我也有这个疑问,以前一直觉得仅考虑主系统的情况下,存储设备的写入顺序应该是
和数据库的写入顺序一致的, 但我觉得 biti_rainy 的理解也是有道理的,存储设备毕
竟和一般的磁盘不一样,很可能再写入的时候会作重新的组合,不过不知道具体的证
据是什么啊?
按照这种理解,再写入的某一瞬间,数据库的写入顺序和存储的写入顺序可能是不一
致的,但既然存储写入的结果跟 oracle 的写入结果肯定是一致的,那么我们可以把
一个比较长的写入过程分成若干个时间段,在每个时间段的结尾,oracle 和存储设备
的写入结果都是完全一致的,那么这个时间段的大小是多少呢?
呵呵,说得我自己都快晕了,也不知道大家明白我的意思没有……
biti_rainy 能不能给我们解释一下啊?或者论坛里有没有对存储设备比较了解的兄弟
啊?
系统上通常不一致没关系是因为还有 log&le 的存在,而日志文件通常是被写入了磁
盘的,oracle 本身是顺序写的,还不需要读,应该是被重整的几率比较小
还有存储设备上,比如掉电没关系,是因为存储设备都有足够的短时间供电能力使得
cache 中的数据能被写入磁盘,这个如果不能保证那一掉电基本都要出问题的
但是在复制的那端,我就不清楚是怎么处理的,比如我要停掉复制,开始用起这数据
来,或者说设备掉电了,这个时候是怎么处理的
在复制的那端,我感觉是没有经过特殊处理的,因为存储设备完全是物理上的同步,
在你停掉复制的时候,他最多只能保证在停止复制或原系统掉电的这一刻所有文件在
物理上是和原系统的存储是完全一致的,但他绝对不会去校验或保证 oracle 的数据
文件在逻辑上是否一致,所以会造成复制端在停止复制后有很大几率不能正常启动。
我在客户那的情况就是在原系统正常运行的情况下,停止存储的复制,然后启动目标
端数据库,但还是有 1/3 的几率无法启动,如果是在原系统发生故障或断电的情况下,
估计就更不好说了。
我还是比较佩服那个客户的勇气,一个省级移动运营商的数据中心,数据库连归档都
没有,一旦系统崩溃,至少要损失当天的数据,同时容灾端的数据库能不能起来还是
个问题……
还好目前还没有出问题,要是出了问题,不知道他们会怎么办……
上次做存储设备的来公司,谈到这个问题的时候说: 很多客户就是这么做的
我就说: 很多人这么做的并不能说就没问题,因为很多 人没有出现事故,是因为隐
藏的问题没有机会暴露出来。我需要:
1:机制上的可靠保障,这个可能只有非常理解 原理的人能回答
2:实际系统的测试,要经过在我们自己提供的数据场景下反复测试
通过这两点之后我们才敢放心使用
同意,确实很多人都是这么用的,也确实都很可能出现问题,所以我一直以为基于存
储的数据库容灾方案是有问题的,但在有些环境中好像还只能这么做,例如我们的一
个客户,也是一个省级的移动运营商,其数据库每天的日志量达到 100G 以上,在这
种条件下,好像只有这种解决方案比较可行,其他的都会有一些问题,至少那些使用
软件实现的逻辑复制方案是不行的,我感觉 oracle 自己的 standby 好像也负担不了
吧?不过他们的数据库至少还是归档的,还有一点保证。呵呵。
从 ORACLE 的角度来衡量基于存储的容灾肯定是有问题的,不可能做到 100%可用。
即使是 ORACLE 的 DATA GUARD 也不能保证 100%没有数据丢失(当前日志组的
数据)。
换个思路了,使用基于应用的同步方案吧。
(3)基于 oracle redo log 的逻辑复制方式
使用这种方式的主要有一些第三方的软件,以及 oracle 自己的 DATAGUARD 中的
logical Standby。先介绍一下第三方的软件产品吧……
目前,国外已经有了很多比较成熟的产品及成功案例,国内也有类似的产品, 但在产
品的成熟程度和成功案例上跟国外还有一定的差距。
这类产品的原理基本相同,其工作过程可以分为以下几个流程:
使用 oracle 以外的独立进程,捕捉 redo log &le 的信息,将其翻译成 sql 语句,再
通过网络传输到目标端数据库,在目标端数据库执行同样的 sql。如果其进程赶不上
oracle 日志切换,也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位,
当一个事务完成后,再把它传输到目标端。所有的产品一般都是以表为单位进行复制,
同时也支持大部分 DDL 的复制(主要在 oracle9i 环境中)。
这种技术的技术特点和优势主要有以下几点:
目标端数据库一直是一个可以访问的数据库;
能保证两端数据库的事务一致性;
剩余11页未读,继续阅读
资源评论
weixin_38609732
- 粉丝: 8
- 资源: 964
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功