物理上是和原系统的存储是完全一致的,但他绝对不会去校验或保证 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 环境中)。
这种技术的技术特点和优势主要有以下几点:
目标端数据库一直是一个可以访问的数据库;
能保证两端数据库的事务一致性;