《数据库容灾复制解决方案全分析绝对精品要点》由会员分享，可在线阅读，更多相关《数据库容灾复制解决方案全分析绝对精品要点（12页珍藏版）》请在金锄头文库上搜索。
1、数据库容灾、复制解决方案全分析（绝对精品）目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：（1）基于存储层的容灾复制方案这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。（2）基于逻辑卷的容灾复制方案这种技术的机制是通过基于TCP/IP的网络环境进行复制，
2、由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。我一直有一个困惑，存储级的 复制，假如是同步的，能保证 数据库所有文件一致吗 ？或者说是保证在 异常发生的那一刻有足够的缓冲来保障？也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？上次一个存储厂商来讲产品，
3、我问技术工程师这个问题，没有能给出答案我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在
4、发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。不
5、知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。欢迎指正！ 应该说部分地回答了我的问题，呵呵因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的，存储设备一定是做过重整的，那 不管同步或者异步的拷贝都 有可能 存在问题的。所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如 data guard 可靠了因为很明显，存储设备拷贝过去的数据文件 不一致是有很大的概率的 你的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和Oracle不一致的？这应该是一个原因。我觉得还有一种可能性就是在忽略存储设备的这种情况下，在主系统当机，发生切换的时
6、候，主系统存储上的数据文件也不一定能保证一致，就算目标系统保持了完全的同步，也一样不能保正目标端数据可可以启动。不太理解，为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿如果说仅在源端情况下，存储设备的写入顺序也是和Oracle进程不一致，那么不考虑异地冗灾，那么是不是意味着即使本地服务器crash，也无法启动存储上的数据文件？我也有这个疑问，以前一直觉得仅考虑主系统的情况下，存储设备的写入顺序应该是和数据库的写入顺序一致的， 但我觉得biti_rainy的理解也是有道理的，存储设备毕竟和一般的磁盘不一样，很可能再写入的时候会作重新的组合，不过不知道具体的证据是什么啊？按照这种
7、理解，再写入的某一瞬间，数据库的写入顺序和存储的写入顺序可能是不一致的，但既然存储写入的结果跟oracle的写入结果肯定是一致的，那么我们可以把一个比较长的写入过程分成若干个时间段，在每个时间段的结尾，oracle和存储设备的写入结果都是完全一致的，那么这个时间段的大小是多少呢？呵呵，说得我自己都快晕了，也不知道大家明白我的意思没有biti_rainy能不能给我们解释一下啊？或者论坛里有没有对存储设备比较了解的兄弟啊？ 系统上通常不一致没关系是因为还有 logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小还有存储设备上，比如掉
8、电没关系，是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下，停止存储的
9、复制，然后启动目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题还好目前还没有出问题，要是出了问题，不知道他们会怎么办上次做存储设备的来公司，谈到这个问题的时候说： 很多客户就是这么做的我就说： 很多人这么做的并不能说就没问题，因为很多 人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：1：机制上的可靠保障，这个可能只有非常理解 原理的人能回答2：实际系统的测试，要经过在我们自己提供的
10、数据场景下反复测试通过这两点之后我们才敢放心使用同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。呵呵。从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。即使是ORACLE的DATA GU
11、ARD也不能保证100%没有数据丢失（当前日志组的数据）。换个思路了，使用基于应用的同步方案吧。（3）基于oracle redo log的逻辑复制方式使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。这类产品的原理基本相同，其工作过程可以分为以下几个流程：使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目
12、标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制（主要在oracle9i环境中）。这种技术的技术特点和优势主要有以下几点：目标端数据库一直是一个可以访问的数据库；能保证两端数据库的事务一致性；因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；因为这类软件复制的只是sql
13、语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；复制环境建立起来以
14、后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？是指同步复制的情况。这个数字我不敢保证它的准确性，因为我没有做过实际的实验来验证，但从我在客户那里看到的实际情况来说，基本属实。您能告诉我你的客户用的那一家的产品吗？不管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧 因为数据库写文件是由操作系统来最终完成的，而操作系统本身又有cache，在通过逻辑复制把数据异步或同步复制到其他存储设备上，中间无论哪个环节有
15、问题，远程存储设备的数据都不能同现有数据保持一致，所以我认为 biti的怀疑是很有道理的。到10g oracle可以使用assm，直接同存储设备对话，这样是否能够好一些，不太确定存储是通过快照来记录状态，然后再进行复制进行备份的。其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句这就是oracle stream 和quest shareplex实现的功能利用oracle 9i的高级复制，加上第三方的管理工具就可以了 我对oracle 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。但管理起来比较麻烦，需要利用第三方的管理工具就可以了。我用的是 深
16、圳华尔东城公司的管理工具，能够自动进行简单故障处理，目前设置的10分钟增量同步，最大表有4000多万条记录，目前还只同步了一部分表，数据量达到了50G。容灾实际例子，不知道是不是有帮助 曾经评估了几个这方面的方案，一是利用存储本身提供的功能，在两端距离比较远（几百几千公里）的时候，只能用异步的方式，同步的话对网络的带宽要求很高，除非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的，远端存储上的写是无序的，不会根据生产端的次序写入，对用户来说是透明的，没有办法干预，也就是说对oracle来说是不同步的，如果没有人为的干预进行一次同步的话，数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响，
